Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04

Bob Harold <rharolde@umich.edu> Thu, 28 June 2018 13:42 UTC

Return-Path: <rharolde@umich.edu>
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 A3553130FEE for <netmod@ietfa.amsl.com>; Thu, 28 Jun 2018 06:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 FzeqzPuQjA72 for <netmod@ietfa.amsl.com>; Thu, 28 Jun 2018 06:42:50 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D282130F93 for <netmod@ietf.org>; Thu, 28 Jun 2018 06:42:50 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id t7-v6so4546842ljj.6 for <netmod@ietf.org>; Thu, 28 Jun 2018 06:42:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IqSV30aRDQNmDtDGZiDIa966Ey7YM276T0ACm5FxIl8=; b=gZbOY+CmEA9oFIq1dBXh87Zyu7vUmangMYZ3AKdrgQnsT9b/sl4sl0jt5Woqt12shS UrewyXOput0dgqXlRn2+vY4k7Nk5Cs3Hu+W6+CmceVbi6Bw+GwCR4N4JG2ZOtWD+PAHi 3QCL//c5TOmYHW0ONJR8ksxBeaQlxDVKIAqQgZSp8nmMfZIFsASLw/PhJ4ELdPNljbDE 2W8pOo3lYzFKvjAFq/VQP7lSuee4lg4lc81R75oTu0PvPSSSFLzLIA9mI2YVtbpdistM 9SRAfB0Sly/w9QL9yuUJysyGyHGt+4JAalbMJrnXl4W1KSNQmMNYfaY/aR5ATqiZ9w7G kHHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IqSV30aRDQNmDtDGZiDIa966Ey7YM276T0ACm5FxIl8=; b=hUWMtEGlsN7JUk8b1G3PqfCVZyaks3fhJvTmc5ksBAP8Th8NZPxjraMrv4k2rJpYdC wymlgK2hvhn0aF3s1ut9UZc8xRdN2+mv1fmCBCiNcyJqkV0KxE9bprTQEnwsrJk/Zrw0 8GkkB0EH88E33zkAb1ILW5hiIBn+TAAjOl6X68Q3ZmL4iORwoop/44CqF162cIIK+pTD PXFb6LrEJV0KNoqKRB94lTO7CgxNtEeRFHJMlCxFUExzVfScvOO8s5t8raMO1ww5d1U/ k8WYRgwUUKZJ4yUWNlNrU4w0WGg8bllgCODzutjNi9HGHobXUu/a2XithFBVSfxknOFf akew==
X-Gm-Message-State: APt69E2GMm8g51fXmZrwXEQpIIZR8MGvIJSwBTLRM9BdkAfs88h8SWey Mwngfnp4NmO32uPDqmBx2w07KgqpXuGC4/aSTOfBhQ==
X-Google-Smtp-Source: AAOMgpcO1s7MIhOgn2JlWhKN/sV49DEYg3z1V7aUacEJhKnpZXKUQUOFpoxojGsK6Zz7f9i6r5DWCUzAyYwaWZQQNoo=
X-Received: by 2002:a2e:4d9d:: with SMTP id c29-v6mr5498319ljd.132.1530193368249; Thu, 28 Jun 2018 06:42:48 -0700 (PDT)
MIME-Version: 1.0
References: <B8F9A780D330094D99AF023C5877DABA9AEB4274@nkgeml513-mbx.china.huawei.com> <194df0e3-038d-d0cc-ea45-f5448fc10562@cisco.com> <70F6E49F-C83F-4C38-92CB-860631B4C050@juniper.net> <20180628.080813.2173042785762431704.mbj@tail-f.com>
In-Reply-To: <20180628.080813.2173042785762431704.mbj@tail-f.com>
From: Bob Harold <rharolde@umich.edu>
Date: Thu, 28 Jun 2018 09:42:36 -0400
Message-ID: <CA+nkc8BvdB9oZVc236PDyM4g+J2+=dtsr5vFScDn0-7MQk13hA@mail.gmail.com>
To: =?UTF-8?Q?martin_bj=C3=B6rklund?= <mbj@tail-f.com>
Cc: Kent Watsen <kwatsen@juniper.net>, netmod@ietf.org, rwilton=40cisco.com@dmarc.ietf.org
Content-Type: multipart/alternative; boundary="000000000000270a81056fb3e84d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/O6-Cp1ee-O0A-zRSn8_rz_h-11I>
Subject: Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.26
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, 28 Jun 2018 13:42:55 -0000

On Thu, Jun 28, 2018 at 2:08 AM Martin Bjorklund <mbj@tail-f.com>; wrote:

> Kent Watsen <kwatsen@juniper.net>; wrote:
> > All, I just posted -06 that addresses some comments from Rob, Martin,
> > and Jonathan.  I realize that there are still open issues, but a rapid
> > iteration for some of these things seems like it might be good:
> > https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-06.
> >
> >
> > Hi Robert,
> >
> > > A couple of comments:
> > >
> > > 1) Section 4.2 suggests using groupings to presumably avoid folding.
> I
> > > don't really support this as a strategy, since I think that groupings
> > > are overused and I think that they obfuscate the true structure of a
> > > YANG module, that can only be recovered by recompiling the module with
> > > the groupings expanded, or looking at the tree output.  Really, I
> think
> > > that an ideal solution would be to somehow have RFCs support longer
> > > lines for files like YANG - e.g. if I could choose any value without
> > > regard for backwards compatibility I would probably choose 120
> > > characters instead.
> >
> > I removed the word "grouping" from the text.  Now it says "...call outs,
> > such as functions".
> >
> >
> >
> > > 2) The proposed solution always left indents the wrapped line. Often
> for
> > > artwork (e.g. a YANG tree diagram), where whitespace is not
> significant,
> > > and the wrapping is relatively minor, then right indenting the wrapped
> > > line can make the results look more visually readable.
> > >
> > > E.g.  I think that this is slightly easier to read:
> > >
> > > module: ietf-flexible-encapsulation
> > >   augment /if:interfaces/if:interface/if-cmn:encapsulation\
> > >                                         /if-cmn:encaps-type:
> > >     +--:(flexible)
> > >        +--rw flexible
> > >           +--rw match
> > >           |  +--rw (match-type)
> > >           |     +--:(default)
> > >           |     |  +--rw default?                 empty
> > >           |     +--:(untagged)
> > >           |     |  +--rw untagged?                empty
> > >           |     +--:(dot1q-priority-tagged)
> > >           |     |  +--rw dot1q-priority-tagged
> > >           |     |     +--rw tag-type?   dot1q-types:dot1q-\
> > >                                                    tag-type
> > >           |     +--:(dot1q-vlan-tagged)
> > >           |        +--rw dot1q-vlan-tagged
> > >
> > > rather than:
> > >
> > > module: ietf-flexible-encapsulation
> > >   augment /if:interfaces/if:interface/if-cmn:encapsulation\
> > >/if-cmn:encaps-type:
> > >     +--:(flexible)
> > >        +--rw flexible
> > >           +--rw match
> > >           |  +--rw (match-type)
> > >           |     +--:(default)
> > >           |     |  +--rw default?                 empty
> > >           |     +--:(untagged)
> > >           |     |  +--rw untagged?                empty
> > >           |     +--:(dot1q-priority-tagged)
> > >           |     |  +--rw dot1q-priority-tagged
> > >           |     |     +--rw tag-type?   dot1q-types:dot1q-\
> > >tag-type
> > >           |     +--:(dot1q-vlan-tagged)
> > >           |        +--rw dot1q-vlan-tagged
> >
> >
> >
> > The placement of the indents in the example above would be impossible
> > to automate - they're too artsy ;)   However, it should be possible
> > to automate a variable indent that lines up with the first printable
> > character on the previous line.  Something like this:
> >
> >  module: ietf-flexible-encapsulation
> >    augment /if:interfaces/if:interface/if-cmn:encapsulation\
> >    /if-cmn:encaps-type:
> >      +--:(flexible)
> >         +--rw flexible
> >            +--rw match
> >            |  +--rw (match-type)
> >            |     +--:(default)
> >            |     |  +--rw default?                 empty
> >            |     +--:(untagged)
> >            |     |  +--rw untagged?                empty
> >            |     +--:(dot1q-priority-tagged)
> >            |     |  +--rw dot1q-priority-tagged
> >            |     |     +--rw tag-type?   dot1q-types:dot1q-\
> >            tag-type
> >            |     +--:(dot1q-vlan-tagged)
> >            |        +--rw dot1q-vlan-tagged
> >
> > [note: previous line indent matching is beyond what can be accomplished
> > via a simple `sed` or `awk` one-liner].
> >
> > Regardless if automated or manual, I think the indent rule needs to be
> > rather strict.  In particular, arbitrary per-line indent can lead to
> > lossy round-tripping (unfolding errors), unless we introduce a rule
> > saying that the source artwork MUST NOT have a space (' ') character
> > that occurring on a fold column.  Otherwise the following might happen.
> >
> >   ORIG:
> >
> >      example:
> >         This very long line happens to have a space character
> immediately after the fold column.";
> >
> >
> >   FOLDED:  *** doesn't matter the indentation strategy ***
> >
> >      ===== NOTE: '\' line wrapping per BCP XX (RFC XXXX) =====
> >      example:
> >         This very long line happens to have a space character\
> >         immediately after the fold column.";
> >
> >
> >   UNFOLDED (using alg that chomps all leading whitespace):
> >
> >      example:
> >         This very long line happens to have a space characterimmediately
> after the fold column.";
> >
> >
> > Note the error in the unfolded version.  I think disallowing
> > whitespace characters on the fold column in the source artwork is
> > overly limiting, spaces being so commonly used.
>
> But with variable placement of the '\' character you can do:
>
>         This very long line happens to have a space character \
>         immediately after the fold column.";
>
> or
>
>         This very long line happens to have a space \
>         character immediately after the fold column.";
>
>
>
> so I'm not sure that disallowing space at the fold column is a
> problem.
>
> Note that even with this, your original "one-liner sed" still produces
> valid results, so if you just want a simple folding program you can
> use that.
>
>
> /martin
>

The problem is that this does not work in cases where there are a lot of
spaces - particularly where there are more than 'line-length' spaces in a
row, in the middle of the line.

-- 
Bob Harold


>
> > The only way I
> > can think to preserve the space character is to have a fixed
> > indent rule (e.g., some hardcoded column number, or always use
> > the same indent as previous line, or the same as the previous
> > line plus some fixed offset).  Given a clear rule, the unfolding
> > alg can chomp just the right amount of whitespace out, leaving
> > the any remaining whitespace, so the round-trip result is loss-less.
> >
> >
> > > Rob
> >
> > Kent // contributor
>
>