Re: [netmod] Alissa Cooper's Abstain on draft-ietf-netmod-artwork-folding-09: (with COMMENT)

Martin Bjorklund <mbj@tail-f.com> Thu, 05 September 2019 15:17 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796A71207FC for <netmod@ietfa.amsl.com>; Thu, 5 Sep 2019 08:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhIoxX7ZX8sn for <netmod@ietfa.amsl.com>; Thu, 5 Sep 2019 08:17:55 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8145012089A for <netmod@ietf.org>; Thu, 5 Sep 2019 08:17:55 -0700 (PDT)
Received: from localhost (unknown [173.38.220.50]) by mail.tail-f.com (Postfix) with ESMTPSA id A06031AE02AB; Thu, 5 Sep 2019 17:17:53 +0200 (CEST)
Date: Thu, 05 Sep 2019 17:17:30 +0200
Message-Id: <20190905.171730.1203130976409295649.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016d01f89905-2d99967e-a660-4ae2-a0a3-1fd270ad4a07-000000@email.amazonses.com>
References: <156762337738.22782.18440951708689230098.idtracker@ietfa.amsl.com> <ceb3f6865a14b79bc9cab81e77ce34043ca1d760.camel@nic.cz> <0100016d01f89905-2d99967e-a660-4ae2-a0a3-1fd270ad4a07-000000@email.amazonses.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/NFPnTIz5QT5N4UdXyhM2N9-NmmE>
Subject: Re: [netmod] Alissa Cooper's Abstain on draft-ietf-netmod-artwork-folding-09: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Sep 2019 15:18:03 -0000

Kent Watsen <kent+ietf@watsen.net> wrote:
> 
> 
> >> There has been discussion about how embedding YANG models in RFCs seems like a
> >> poor fit for a number of reasons. By standardizing line-folding mechanisms and
> >> claiming them as a best practice, this document reinforces the root of that
> >> problem rather than trying to fix it.
> > 
> > Well said, I agree with Alissa's conclusion.

But the algorithm in the document isn't supposed to be used for YANG
modules.  It is supposed to be used primarily for XML and JSON
snippets (etc).

> Assuming 'a', yes, 'b' follows 'a'.  That said, the concern is nebulous
> and how to address it more so.  Proposals?
> 
> Assuming the concern is process-overhead for minor spins

I think we need to understand what the "number of reasons" Alissa
refers to really are, before we try to come up with solutions.


/martin


> , perhaps we
> could leverage the module-versioning work as follows:
> 
>   * Initial and NBC modules go thru standard RFC publishing process (i.e.,
>     there is still a need to publish YANG modules in RFCs).
> 
>   * BC modules can skip standard publishing process but, to be an "IETF"
>     product (not some random fork), they would need to be released via an
>     IETF-owned mechanism (e.g., an Git repo) with restricted write-access.
> 
> Thoughts?
> 
> Kent
>