Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

Robert Wilton <> Fri, 19 October 2018 10:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF981130EBF; Fri, 19 Oct 2018 03:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.563
X-Spam-Status: No, score=-14.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UBZ_rDuuB8xq; Fri, 19 Oct 2018 03:41:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FC99130EED; Fri, 19 Oct 2018 03:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8956; q=dns/txt; s=iport; t=1539945667; x=1541155267; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=4wq5i7B+Kq7Wr9RBxocLXL1JsCa/38SpVR370m455EE=; b=MTiSVOsIVlvoc6stI/3d1+24biVGf98+3BIqYcvrtRkb+gz+tspnXr21 n8dU599jh1/WrEpVt73XLrzonoi1X8lcEfrIV+MqaKzmTwLSLKkVAXDYM qxJgRC2nGq8vtR0nbpvOSsSP5ibTGtN5JvKgKps39SZcY0uMowFt2Yp9g c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.54,399,1534809600"; d="scan'208,217";a="7361855"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2018 10:41:05 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id w9JAf4Nl009102; Fri, 19 Oct 2018 10:41:04 GMT
To:, 'Lou Berger' <>, 'NetMod WG' <>
Cc: 'NetMod WG Chairs' <>
References: <> <09fa01d46794$3ed5b280$bc811780$>
From: Robert Wilton <>
Message-ID: <>
Date: Fri, 19 Oct 2018 11:41:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <09fa01d46794$3ed5b280$bc811780$>
Content-Type: multipart/alternative; boundary="------------B32A31832BED323DDA14A535"
Content-Language: en-US
Archived-At: <>
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Oct 2018 10:41:13 -0000

Hi Adrian, all,

What is the intended scope?

1) Is it just for examples of YANG requests/replies, or in future, 
instance data.  If so, then I think that the solution is useful for this.

2) Or should the WG consider allowing a longer line length for YANG 
modules?  Currently they are limited to something like 69 characters so 
that they can be inserted into the RFC, but possibly with line folding 
we could possibly consider increasing that, but perhaps that would make 
them harder to read/review.

3) I think that there are also cases where tree diagrams wrap and need 
to be constrained to 69 characters.  Although I don't think that 
applying the folding algorithm to tree diagrams directly is necessarily 
a great idea, it might be that tools like pyang could be modified with 
an option to generate output that is consistent with the definition of 
the folded output so that it can be unfolded if required.

To give an example of 3:

Rather than this:

    module: ietf-if-l3-vlan
      augment /if:interfaces/if:interface/if-cmn:encapsulation/
           +--rw dot1q-vlan
              +--rw outer-tag!
              |  +--rw tag-type    dot1q-tag-type
              |  +--rw vlan-id     ieee:vlanid
              +--rw second-tag!
                 +--rw tag-type    dot1q-tag-type
                 +--rw vlan-id     ieee:vlanid

the tooling could be modified to optionally generate this instead:

========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
   module: ietf-if-l3-vlan
      augment /if:interfaces/if:interface/if-cmn:encapsulation/\
           +--rw dot1q-vlan
              +--rw outer-tag!
              |  +--rw tag-type    dot1q-tag-type
              |  +--rw vlan-id     ieee:vlanid
              +--rw second-tag!
                 +--rw tag-type    dot1q-tag-type
                 +--rw vlan-id     ieee:vlanid

One other question:

How does the algorithm know it has reached the end of the artwork?  I.e. 
should there also be an end line marker?


On 19/10/2018 11:12, Adrian Farrel wrote:
> Hey Lou,
> As an author, I support adoption and would particularly welcome feedback from
> the WG to know whether this approach addresses the needs of those writing drafts
> for YANG models.
> Thanks,
> Adrian
>> -----Original Message-----
>> From: netmod [] On Behalf Of Lou Berger
>> Sent: 18 October 2018 14:04
>> To: NetMod WG
>> Cc: NetMod WG Chairs
>> Subject: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
>> All,
>> This is start of a two week poll on making
>> draft-kwatsen-netmod-artwork-folding-08 a working group
>> document. Please send email to the list indicating "yes/support" or
>> "no/do not support".  If indicating no, please state your reservations
>> with the document.  If yes, please also feel free to provide comments
>> you'd like to see addressed once the document is a WG document.
>> The poll ends Oct 1.
>> Thanks,
>> Lou (and co-chairs)
> _______________________________________________
> netmod mailing list
> .