Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.

[Mahesh Jethanandani]

Hi Dmytro,

First of all, I find the discussion within the netmod WG as just the wrong 
place to have this discussion. You will be hard pressed to find too many people 
who can give you critical feedback on the model in this WG.

See inline with [mj]

> On Sep 5, 2019, at 2:03 PM, Dmytro Shytyi  wrote:
> 
> [Dmytro]
> Hello Mahesh Jethanandani,
> Thank you for your comment.
> Please find answers inline.
> 
> >I find the representation of a service model in this draft for a uCPE as too 
> >simple. In reality, on a uCPE, you could be running a Network Service (NS), 
> >which is composed of multiple VNFs interconnected together. This service 
> >model does not address such a configuration.
> [Dmytro]
> This service model presented in the draft supports N VMs in the NS and 
> addreses configuration with multiple VMs and switches with plenty of links. 
> It is well tested (with service chained VMs) on equipent from different well 
> known suppliers. The idea to have complex flexible service in the network 
> service orchestrator for uCPE.
> in the yang model we have list (marked by pyang with "*") of VMs where the 
> key is name of the vm, thus you may define as much VM as you wish.

[mj] You have introduced concept of interfaces, ports, and switches that does 
not exist in the NFV world. VNFs have virtual links and connection points. 
There is no (physical) port or interface that one connects to in a VNF. It 
might exist on the server on which the VM runs but not in a VNF or a 
virtualization instance.

> 
> Example of 2 VMs that are service chained (swLAN-VM1-swService-VM2-swWAN)
> 
>   +--rw vms* [vm]
>   +--rw vm string
>   +--rw ports* [port]
>   |  +--rw portstring
>   |  +--rw name?   string
>   |  +--rw link?   -> ../../../links/link
>   +--rw ram?   string
>   +--rw cpu?   string
>   +--rw storages* [id]
>   |  +--rw id  string
>   |  +--rw location?   string
>   +--rw day0-config
>  +--rw location?string
>  +--rw day0-var-path?   string
>  +--rw variable* [name]
> +--rw name string
> +--rw value?   string
> 
> 
> So basically  the list "+--rw wms* [vm]" can be represented/"expanded" in 
> this way where the names and number ov vms(N) is set by user:
> 
>  >   +--rw vm1 string
>| +--rw ports* [port]
>| |  +--rw portstring
>| |  +--rw name?   string
>| |  +--rw link?   -> ../../../links/link
>| +--rw ram?   string
>| +--rw cpu?   string
>| +--rw storages* [id]
>| |  +--rw id  string
>| |  +--rw location?   string
>| +--rw day0-config
>| |  +--rw location?string
>| |  +--rw day0-var-path?   string
>| |  +--rw variable* [name]
>| | +--rw name string
>| | +--rw value?   string
> >+--rw vm2 string
>| +--rw ports* [port]
>| |  +--rw portstring
>| |  +--rw name?   string
>| |  +--rw link?   -> ../../../links/link
>| +--rw ram?   string
>| +--rw cpu?   string
>| +--rw storages* [id]
>| |+--rw id  string
>| |  +--rw location?   string
>| +--rw day0-config
>| |+--rw location?string
>| |  +--rw day0-var-path?   string
>| |  +--rw variable* [name]
>| | +--rw name string
>| | +--rw value?   string
> 
>   |  
>  >   +--rw vmN string
> +--rw ports* [port]
> |  +--rw portstring
> |  +--rw name?   string
> |  +--rw link?   -> ../../../links/link
> +--rw ram?   string
> +--rw cpu?   string
> +--rw storages* [id]
> |  +--rw id

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-artwork-folding-09: (with DISCUSS and COMMENT)

[Kent Watsen]

Hi Suresh, 

Please see https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-10 
 for updates. 
 It's now Informational.

Kent // as co-author




> On Sep 5, 2019, at 1:08 PM, Kent Watsen  wrote:
> 
> Hi Suresh,
> 
> Thank you for your review.  Comments below.
> 
> Kent // as co-author
> 
> 
>> On Sep 5, 2019, at 10:41 AM, Suresh Krishnan via Datatracker 
>> mailto:nore...@ietf.org>> wrote:
>> 
>> Suresh Krishnan has entered the following ballot position for
>> draft-ietf-netmod-artwork-folding-09: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html 
>> 
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ 
>> 
>> 
>> 
>> 
>> --
>> DISCUSS:
>> --
>> 
>> After some thought I think there are two things about this document that make
>> me uncomfortable enough to ballot Discuss.
>> 
>> a) Due to its home in the netmod WG it is highly likely that people outside 
>> the
>> yang community have not paid enough attention to this work. Since this is
>> applicable to code fragments of all kinds, I think the home chosen for this 
>> RFC
>> might have inadvertently limited input from the broader community.
> 
> Agreed.  The original I-D was targeted for IAB stream.  It wasn't going to be 
> presented in NETMOD, but did (by coercion).  During the presentation I 
> mentioned that its applicability was more than NETMOD and that it should go 
> thru IAB, just like the "xml2rfc" RFCs (7749 and 7991).  The working group 
> felt that it should stay in the WG and hence here we are.  :sigh:
> 
> 
>> b) Given a) I think it is better that this document go forward as an
>> Informational document rather than a BCP so that use of this technique 
>> becomes
>> optional, without the force of a BCP behind it.
> 
> I'm okay with this, modulo my comment to Alissa.   Actually, if we only view 
> the RFC as specifying a format then, in my mind, it doesn't actually contain 
> the "best practice".  FWIW, SHOULD appears only once, in a sentence stating 
> that folding SHOULD be automated, in a section titled "Goals".  That said, if 
> not a BCP, then how to encourage people to use it, so that automation works?  
> For this reason alone, it seems that either the draft should be a BCP or 
> Datatracker is updated to auto-fold as needed.  Perhaps  the right answer is 
> to do Informational now and hope that Datatracker is updated in time?
> 
> 
> 
>> --
>> COMMENT:
>> --
>> 
>> I do agree with my Abstaining colleagues that this should probably not be on
>> the IETF stream but I think the work is useful enough to go forward.
> 
> It should've been on the IAB stream.  Whether it should go forward, after 
> having the BCP attribute removed, or re-run via the IAB stream is up to the 
> IESG.
> 
> 
> Kent // as co-author
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-artwork-folding-09: (with COMMENT)

[Kent Watsen]

Hi Adam,

Thank you for your review.  Comments below.

Update @ https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-10 


Kent // as co-author


> On Sep 3, 2019, at 8:34 PM, Adam Roach via Datatracker  
> wrote:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-netmod-artwork-folding-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for taking on this work to fill a hole in the tools that
> we have for production of RFCs. I have one fairly major comment
> and several editorial suggestions.
> 
> ---
> 
> Abstract:
> 
>> This document defines two strategies for handling long lines in
>> width-bounded text content.  One strategy is based on the historic
>> use of a single backslash ('\') character to indicate where line-
> 
> Nit: "historical"

Fixed.


> ---
> 
> §1:
> 
>> According to the RFC Editor,
>> there is currently no convention in place for how to handle long
>> lines in such inclusions, other than advising authors to clearly
>> indicate what manipulation has occurred.
> 
> This won't age well. Perhaps "Historically, there has been no
> RFC-Editor-recommended convention in place for how to handle..."

Suggested text incorporated.


> ---
>> This document defines two strategies for handling long lines in
>> width-bounded text content.  One strategy is based on the historic
>> use of a single backslash ('\') character to indicate where line-
> 
> Nit: "historical"

Fixed.


> ---
> 
> §7.1.1:
> 
>>  NOTE: '\' line wrapping per BCP XXX (RFC )
> 
> Using this string as the start of the specially-wrapped section
> seems somewhat problematic, as it forecloses on the possibility
> of also *citing* this BCP at that point in the document. For example,
> if I were to use this format, I would definitely want to use a string
> more of the format:
> 
>NOTE: '\' line wrapping per BCP XXX ([RFC ])
> 
> (taking note of the added brackets).
> 
> If this has already been debated in the working group and the current text
> is the result of carefully considering this issue and deciding that the
> use of the specified string has benefits that outweigh the drawback of
> not being able to cite the document per ordinary convention, then don't afford
> my suggestion any undue weight. I'm not trying to change a consensus decision.
> 
> But if this is a simple oversight, I think it does need to be given
> significant thought. For example, I personally am rather likely to elect to do
> things "the old way" in my own documents rather than using this format because
> of the awkwardness of properly citing a normative reference.
> 
> This same comment applies to §8.1.1, of course.

Unsure.  To provide context, YANG modules many times include references to RFCs 
in artwork sections.  I used to put these references inside square brackets, 
but the RFC Editors would convert them to parentheses.  I have since moved to 
using parentheses, e.g., "(RFC )", in artwork and haven't experienced any 
corrections since.

Leaving as is for now.



> ---
> 
>> Appendix A.  POSIX Shell Script: rfcfold
> 
> Please add [POSIX.1-2017] as a reference.

I've replaced "POSIX" with "Bash", and added a reference for Bash.


Kent // as co-author







___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-09: (with DISCUSS and COMMENT)

[Kent Watsen]

Hi Ben,

Thank you for your review.  Comments below.

Update @ https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-10 


Kent // as co-author


> On Sep 5, 2019, at 2:07 AM, Benjamin Kaduk via Datatracker  
> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-netmod-artwork-folding-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> I think the procedures described herein are incomplete without a footer
> to terminate the un-folding process.  Otherwise, it seems that the
> described algorithms would leave the two-line header for the second and
> subsequent instances of folded text in a single document.  (If we tried
> to just blindly remove all instances of the header without seeking
> boundaries, then we would misreconstruct content when different folding
> algorithms are used in the same document with the single-backslash
> algorithm occurring first.)

Are you referring to when an RFC contains multiple inclusions and one is trying 
to unfold them all at once?   That's not the intention here, as noted in 
paragraph 3 in both sections 7.2 and 8.2.  FWIW, this sounds like the framing 
problem that the WG discussed with the conclusion that extracting from 
plain-text is dead, now that XML is the required submission format, and XML 
provides a superior framing mechanism than any footer we could add.

BTW, yes, each text inclusion in a single RFC may independently be folded using 
either the '\' or '\\' strategy, with the recommendation that '\' always be 
tried first and '\\' only used when '\' fails.

If referring to a single text content instance, could you provide an example 
illustrating the concern?




> I don't think it's proper to refer to a script that requires bash
> specifically as a "POSIX shell script".  I did not attmept to check
> whether any bash-specific features are used or this requirements stems
> solely from the shebang line, though.

I just changed "POSIX" to "Bash" in the title for Appendix A.

Not that it matters, but "--posix" is passed into `bash` on the first line of 
the script  ;)



> I think the shell script does need to use double-quotes around some
> variable expansions, especially "$infile" and "$outfile", to work
> properly for filenames containing spaces.  We do quote "$infile" when
> we're checking that it exists, just not (most of the time) when we
> actually use it!

Updated.



> In addition to the above, I also share Alissa's (and Mirja's) concerns,
> but feel that Discuss is more appropriate than Abstain, so we can discuss
> what the best way to get this content published is.  For it's fine
> content, and we should see it published; it's just not immediately clear
> to me what the right way to do so is.

Agreed.   For now, I've changed it to Informational, but I think there remains 
a discussion around if the draft should be re-rerun through the IAB stream.   
My responses today to Alissa's Abstain and Suresh Discuss dig into this.  Is it 
okay to use those threads for this item?


> --
> COMMENT:
> --
> 
> Section 4.1
> 
>   Automated folding of long lines is needed in order to support draft
>   compilations that entail a) validation of source input files (e.g.,
>   XML, JSON, ABNF, ASN.1) and/or b) dynamic generation of output, using
>   a tool that doesn't observe line lengths, that is stitched into the
>   final document to be submitted.
> 
> I don't think the intended meaning of "source input files" will be clear
> to all readers just from this text.  Some discussion of how RFCs can
> consider source code, data structures, generated output, etc., that have
> standalone representations and natural formats, and the need to display
> their contents in the RFC format that has different requirements might
> be helpful context for this paragraph and the next.

Is the updated text more understandable?



> Section 7.1.2
> 
> For some reason my mental model of "RFC style" does not use the word
> "really" in this way, and prefers alternatives like "very" or
> "exceptionally".  (Also in Section 8.1.2.)

s/Really/Exceptionally/ in both cases.


> Section 7.2.1
> 
>   1.  Determine where the fold will occur.  This location MUST be
>   

[netmod] I-D Action: draft-ietf-netmod-artwork-folding-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Handling Long Lines in Inclusions in Internet-Drafts 
and RFCs
Authors : Kent Watsen
  Adrian Farrel
  Qin Wu
Filename: draft-ietf-netmod-artwork-folding-10.txt
Pages   : 30
Date: 2019-09-05

Abstract:
   This document defines two strategies for handling long lines in
   width-bounded text content.  One strategy is based on the historical
   use of a single backslash ('\') character to indicate where line-
   folding has occurred, with the continuation occurring with the first
   non-space (' ') character on the next line.  The second strategy
   extends the first strategy by adding a second backslash character to
   identify where the continuation begins and thereby able to handle
   cases not supported by the first strategy.  Both strategies use a
   self-describing header enabling automated reconstitution of the
   original content.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-10
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-artwork-folding-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-artwork-folding-09: (with DISCUSS and COMMENT)

[Andy Bierman]

On Thu, Sep 5, 2019 at 10:08 AM Kent Watsen  wrote:

> Hi Suresh,
>
> Thank you for your review.  Comments below.
>
> Kent // as co-author
>
>
> On Sep 5, 2019, at 10:41 AM, Suresh Krishnan via Datatracker <
> nore...@ietf.org> wrote:
>
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-netmod-artwork-folding-09: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/
>
>
>
> --
> DISCUSS:
> --
>
> After some thought I think there are two things about this document that
> make
> me uncomfortable enough to ballot Discuss.
>
> a) Due to its home in the netmod WG it is highly likely that people
> outside the
> yang community have not paid enough attention to this work. Since this is
> applicable to code fragments of all kinds, I think the home chosen for
> this RFC
> might have inadvertently limited input from the broader community.
>
>
> Agreed.  The original I-D was targeted for IAB stream.  It wasn't going to
> be presented in NETMOD, but did (by coercion).  During the presentation I
> mentioned that its applicability was more than NETMOD and that it should go
> thru IAB, just like the "xml2rfc" RFCs (7749 and 7991).  The working group
> felt that it should stay in the WG and hence here we are.  :sigh:
>
>
It seemed self-evident that the scope of this draft did not fit the NETMOD
WG charter.
I assumed the work was permitted to start because (1) nobody else was
willing to
work on it and (2) nowhere else to put it.


>
> b) Given a) I think it is better that this document go forward as an
> Informational document rather than a BCP so that use of this technique
> becomes
> optional, without the force of a BCP behind it.
>
>
> I'm okay with this, modulo my comment to Alissa.   Actually, if we only
> view the RFC as specifying a format then, in my mind, it doesn't actually
> contain the "best practice".  FWIW, SHOULD appears only once, in a sentence
> stating that folding SHOULD be automated, in a section titled "Goals".
> That said, if not a BCP, then how to encourage people to use it, so that
> automation works?  For this reason alone, it seems that either the draft
> should be a BCP or Datatracker is updated to auto-fold as needed.  Perhaps
>  the right answer is to do Informational now and hope that Datatracker is
> updated in time?
>
>
>
IMO Informational status is the only option.
There is a simple solution that solves applicability:

Add some text in this draft that UPDATES RFC 8407 so that only RFCs
that contain YANG modules are required to use this line-wrap solution.


Andy


> --
> COMMENT:
> --
>
> I do agree with my Abstaining colleagues that this should probably not be
> on
> the IETF stream but I think the work is useful enough to go forward.
>
>
> It should've been on the IAB stream.  Whether it should go forward, after
> having the BCP attribute removed, or re-run via the IAB stream is up to the
> IESG.
>
>
> Kent // as co-author
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.

[Dmytro Shytyi]

[Dmytro]
Hello Mahesh Jethanandani,

Thank you for your comment.

Please find answers inline.


>I find the representation of a service model in this draft for a uCPE as too 
>simple. In reality, on a uCPE, you could be running a Network Service (NS), 
>which is composed of multiple VNFs interconnected together. This service model 
>does not address such a configuration.

[Dmytro]


This service model presented in the draft supports N VMs in the NS and addreses 
configuration with multiple VMs and switches with plenty of links. It is well 
tested (with service chained VMs) on equipent from different well known 
suppliers. The idea to have complex flexible service in the network service 
orchestrator for uCPE.

in the yang model we have list (marked by pyang with "*") of VMs where the key 
is name of the vm, thus you may define as much VM as you wish.



Example of 2 VMs that are service chained (swLAN-VM1-swService-VM2-swWAN)



  +--rw vms* [vm]

  +--rw vm string

  +--rw ports* [port]

  |  +--rw port    string

  |  +--rw name?   string

  |  +--rw link?   -> ../../../links/link

  +--rw ram?   string

  +--rw cpu?   string

  +--rw storages* [id]

  |  +--rw id  string

  |  +--rw location?   string

  +--rw day0-config

 +--rw location?    string

 +--rw day0-var-path?   string

 +--rw variable* [name]

    +--rw name string

    +--rw value?   string





So basically  the list "+--rw wms* [vm]" can be represented/"expanded" in this 
way where the names and number ov vms(N) is set by user:



 >   +--rw vm1 string

                       |     +--rw ports* [port]

                       |     |  +--rw port    string

                       |     |  +--rw name?   string

                       |     |  +--rw link?   -> ../../../links/link

                       |     +--rw ram?   string

                       |     +--rw cpu?   string

                       |     +--rw storages* [id]

                       |     |  +--rw id  string

                       |     |  +--rw location?   string

                       |     +--rw day0-config

                       |     |  +--rw location?    string

                       |     |  +--rw day0-var-path?   string

                       |     |  +--rw variable* [name]

                       |     | +--rw name string

                       |     | +--rw value?   string

>        +--rw vm2 string

                       |     +--rw ports* [port]

                       |     |  +--rw port    string

                       |     |  +--rw name?   string

                       |     |  +--rw link?   -> ../../../links/link

                       |     +--rw ram?   string

                       |     +--rw cpu?   string

                       |     +--rw storages* [id]

                       |     |    +--rw id  string

                       |     |  +--rw location?   string

                       |     +--rw day0-config

                       |     |    +--rw location?    string

                       |     |  +--rw day0-var-path?   string

                       |     |  +--rw variable* [name]

                       |     | +--rw name string

                       |     | +--rw value?   string



                      |                      

 >   +--rw vmN string

    +--rw ports* [port]

    |  +--rw port    string

    |  +--rw name?   string

    |  +--rw link?   -> ../../../links/link

    +--rw ram?   string

    +--rw cpu?   string

    +--rw storages* [id]

    |  +--rw id  string

    |  +--rw location?   string

    +--rw day0-config

   +--rw location?    string

   +--rw day0-var-path?   string

   +--rw variable* [name]

      +--rw name string

      +--rw value?   string



>Besides, how is the configuration of a uCPE device for a VNF different from 
>configuration of a VNF in a provider Network Function Virtualization 
>Infrastructure (NFVI) like OpenStack or VMware VIO?

[Dmytro]


Modern uCPE support netconf. And if you go to the YANG RFC6020 you will find 
the next statement:

   

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

[Ladislav Lhotka]

On Thu, 2019-09-05 at 17:17 +0200, Martin Bjorklund wrote:
> Kent Watsen  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).

My main concern is YANG, or any other code that is supposed to be both read in
the RFC and extracted from it.

Lada

> 
> > 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
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

On Thu, 2019-09-05 at 15:08 +, Kent Watsen 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.
> 
> Assuming 'a', yes, 'b' follows 'a'.  That said, the concern is nebulous
> and how to address it more so.  Proposals?

First, one can ask whether it is a good idea to have RFCs as the authoritative
source of YANG modules. I don't think so.

Otherwise, if the practice of including YANG modules in RFCs continues, I would
suggest to include YANG modules unchanged in xml2rfc and leave the presentation
issues to the RFC Editor (or their tools). With the upcoming RFC format change
there will be more publication formats (HTML, TXT, PDF, EPUB), so it is IMO
ridiculous to modify the source code in order to suit one of them. For example,
I don't want to see folded lines in HTML-formatted RFCs.

> 
>   * Initial and NBC modules go thru standard RFC publishing process (i.e.,
> there is still a need to publish YANG modules in RFCs).

Why? The RFC could include a link to an external module resource (possibly with
a hash to guarantee that the referred resource hasn't been modified).

Lada

> 
>   * 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
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.

[Mahesh Jethanandani]

I find the representation of a service model in this draft for a uCPE as too 
simple. In reality, on a uCPE, you could be running a Network Service (NS), 
which is composed of multiple VNFs interconnected together. This service model 
does not address such a configuration. Besides, how is the configuration of a 
uCPE device for a VNF different from configuration of a VNF in a provider 
Network Function Virtualization Infrastructure (NFVI) like OpenStack or VMware 
VIO? And would you not need to enable the service on the provider side to make 
the services running on the uCPE functional?

There is significant amount of work that has been done in ETSI on the 
configuration and management of VNF and NS. Authors should spend some time 
going through the specifications specified by ETSI to make sure they are not 
re-specifying work that has been done there, and instead see how they could 
augment the work that has already been defined.

Authors can start by going through IFA010 
,
  IFA011 
,
 IFA014 
,
 and its YANG specification in SOL006 
.

Cheers.

> On Sep 5, 2019, at 9:02 AM, Dmytro Shytyi  wrote:
> 
> Dear All,
> 
> Please find the updated version of the VYSM Internet Draft(v0.2).
> The new version of draft introduces an extension of the yang model defined in 
> previous version. From now the VYSM supports (0day configuration)/(bootstrap) 
> of the VNFs hosted in the uCPE.
> With 0day configuration in the uCPE we can setup minimal required 
> configuration of vRouter (such as ip address, hostname,etc..), SD-WAN 
> (address of the SD-WAN manager, dhcp activation, etc..), etc..
> 
> 
> Details:
> A new version of I-D, draft-shytyi-netmod-vysm-02.txt 
> has been successfully submitted by Dmytro Shytyi and posted to the 
> IETF repository. 
> 
> Name:draft-shytyi-netmod-vysm 
> Revision:02 
> Title:Virtualization YANG Servise Model (VYSM) 
> Document date:2019-09-04 
> Group:Individual Submission 
> Pages:10 
> URL: https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-02.txt 
>  
> Status: https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm/ 
>  
> Htmlized: https://tools.ietf.org/html/draft-shytyi-netmod-vysm-02 
>  
> Htmlized: https://datatracker.ietf.org/doc/html/draft-shytyi-netmod-vysm 
>  
> Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-netmod-vysm-02 
>  
> 
> Abstract: 
> This document provides a specification of the Virtual Network 
> Functions YANG Service Model (VYSM). The VNF YANG Service Model 
> serves as a base framework for managing an universal Customer- 
> Premises Equipment (uCPE) NFV subsystem from the Orchestrator. 
>  
> >>
> >># # # : Dmytro Shytyi [mailto:ietf.dmy...@shytyi.net 
> >>]
> >># # # # : 2019# 8# 28#  21:46
> >># # # : Robert Varga mailto:n...@hq.sk>>; Qin Wu 
> >>mailto:bill...@huawei.com>>
> >># # : netmod mailto:netmod@ietf.org>>
> >># # : Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working 
> >>Group document.
> >>
> >>Hello,
> >>
> >>Please find comments inline.
> >>>On 27/08/2019 18:03, Dmytro Shytyi wrote:
>  Dear All,
>  
>  I am one of the authors of ID VYSM and I would like to draw your
>  attention to the evolution of the
>  draft 
>  https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt 
>  .
>  Recently we produced (but did not submitted yet) a new version of ID
>  (02) and I beleive it fits the netmod working group.
>  
>  We would be gratefull if you could suggest if the new version(02) of the
>  document  could become an official work item of the WG?
>    If yes, could you please indicate which modifications must be done
>  in the document before submition.
> >>> 
> >>>Hmm, looking over the model, it would seem there is quite a bit of
> >>>overlap with RFC8345 -- to the point I believe the model could be
> >>>formulated in terms of RFC8345 specialization:
> >>First of all I would like to thank you for this comment. 
> >>-Dmytro
> >>>virtualization -> networks/network
> >>> 
> >>>device/links/interfaces/switches/vms are probably a mix of
> 

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-artwork-folding-09: (with DISCUSS and COMMENT)

[Kent Watsen]

Hi Suresh,

Thank you for your review.  Comments below.

Kent // as co-author


> On Sep 5, 2019, at 10:41 AM, Suresh Krishnan via Datatracker 
>  wrote:
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-netmod-artwork-folding-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> After some thought I think there are two things about this document that make
> me uncomfortable enough to ballot Discuss.
> 
> a) Due to its home in the netmod WG it is highly likely that people outside 
> the
> yang community have not paid enough attention to this work. Since this is
> applicable to code fragments of all kinds, I think the home chosen for this 
> RFC
> might have inadvertently limited input from the broader community.

Agreed.  The original I-D was targeted for IAB stream.  It wasn't going to be 
presented in NETMOD, but did (by coercion).  During the presentation I 
mentioned that its applicability was more than NETMOD and that it should go 
thru IAB, just like the "xml2rfc" RFCs (7749 and 7991).  The working group felt 
that it should stay in the WG and hence here we are.  :sigh:


> b) Given a) I think it is better that this document go forward as an
> Informational document rather than a BCP so that use of this technique becomes
> optional, without the force of a BCP behind it.

I'm okay with this, modulo my comment to Alissa.   Actually, if we only view 
the RFC as specifying a format then, in my mind, it doesn't actually contain 
the "best practice".  FWIW, SHOULD appears only once, in a sentence stating 
that folding SHOULD be automated, in a section titled "Goals".  That said, if 
not a BCP, then how to encourage people to use it, so that automation works?  
For this reason alone, it seems that either the draft should be a BCP or 
Datatracker is updated to auto-fold as needed.  Perhaps  the right answer is to 
do Informational now and hope that Datatracker is updated in time?



> --
> COMMENT:
> --
> 
> I do agree with my Abstaining colleagues that this should probably not be on
> the IETF stream but I think the work is useful enough to go forward.

It should've been on the IAB stream.  Whether it should go forward, after 
having the BCP attribute removed, or re-run via the IAB stream is up to the 
IESG.


Kent // as co-author


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

Hi Alissa,

Thank you for your review.  Comments below.

Kent // as co-author


> On Sep 4, 2019, at 2:56 PM, Alissa Cooper via Datatracker  
> wrote:
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-netmod-artwork-folding-09: Abstain
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/
> 
> 
> 
> --
> COMMENT:
> --
> 
> RFC 7994 is not a product of IETF consensus, so it seems inappropriate to
> publish a consensus BCP predicated on requirements defined in RFC 7994 which
> themselves do not have IETF consensus. This would be the only document related
> to the RFC format in the last 10 years that I'm aware of that would be
> published on the IETF stream.

Agreed.   Should the draft re-run through the IAB stream?


> 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.

FWIW, YANG modules are themselves never expected to be folded.  Per Section 5.2 
of the draft, authors should do as much as possible within the YANG format to 
avoid long lines.  From the NETMOD WG's perspective, this draft is primarily 
targeting the XML and JSON examples that should accompany a draft publishing a 
YANG module.

That said, while I'm aware of the concern, it remains unclear, and how to 
address it more so.  In the meanwhile, there are real and immediate issues with 
the ability to use automation to validate structural content in drafts (e.g.,  
https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-01#section-6 
).  
This is not just a YANG issue, it is an issue that spans the IETF, and a 
solution for it might be considered best practice.

Regarding the BCP attribution, I don't have a preference.  Actually, I think it 
was the WG that pushed for it.  I only think the IETF should label it right, 
re-running it thru IAB stream if need be.   As I see it, the "best practice" is 
that draft authors SHOULD stitch pre-folded inclusions so as to enable 
automated verification.  The format itself is not best practice.  That said, a 
better solution would be for IETF to 1) only support XML-based uploads and 2) 
have Datatracker auto-fold inclusions as needed for plain-text and PDF outputs 
(note that folding is NOT needed, or desired, for HTML output).

Kent // as co-author






___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Erik Auerswald]

Hi Martin,

On Thu, Sep 05, 2019 at 05:17:30PM +0200, Martin Bjorklund wrote:
> Kent Watsen  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).

Technically, XML and JSON are whitespace-agnostic and often can be
"folded" manually without any folding indicators.  That seems to be
true for YANG as well.  Even Python code usually can be kept under any
reasonable line length.

Very long names or values could require algorithmic folding, i.e.,
a generic line-folding mechanism.

I personally would try to keep the line length of any code inside an
RFC short enough to not need additional algorithmic folding.  But if
this does not work, e.g., because some name or value is just too long,
having a recommended algorithm seems to be better than every author
making up another ad-hoc folding scheme.

The I-D.ietf-netmod-artwork-folding seems to try to provide a recommended
algorithm for the case where a generic line-folding mechanism is needed.

Overly long lines sometimes result in lost information in HTML or PDF
documents, if a complex layout is used, but no mechanism for dealing with
unexpectedly long lines is included.  I have seen too many examples of
this to believe that this cannot happen with RFCs.

Thanks,
Erik

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.

[Dmytro Shytyi]

Dear All,



Please find the updated version of the VYSM Internet Draft(v0.2).

The new version of draft introduces an extension of the yang model defined in 
previous version. From now the VYSM supports (0day configuration)/(bootstrap) 
of the VNFs hosted in the uCPE.

With 0day configuration in the uCPE we can setup minimal required configuration 
of vRouter (such as ip address, hostname,etc..), SD-WAN (address of the SD-WAN 
manager, dhcp activation, etc..), etc..





Details:

A new version of I-D, draft-shytyi-netmod-vysm-02.txt 

has been successfully submitted by Dmytro Shytyi and posted to the 

IETF repository. 



Name:draft-shytyi-netmod-vysm 

Revision:02 

Title:Virtualization YANG Servise Model (VYSM) 

Document date:2019-09-04 

Group:Individual Submission 

Pages:10 

URL: https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-02.txt 

Status: https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm/ 

Htmlized: https://tools.ietf.org/html/draft-shytyi-netmod-vysm-02 

Htmlized: https://datatracker.ietf.org/doc/html/draft-shytyi-netmod-vysm 

Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-netmod-vysm-02 



Abstract: 

This document provides a specification of the Virtual Network 

Functions YANG Service Model (VYSM). The VNF YANG Service Model 

serves as a base framework for managing an universal Customer- 

Premises Equipment (uCPE) NFV subsystem from the Orchestrator. 

 

>>

>># # # : Dmytro Shytyi [mailto:mailto:ietf.dmy...@shytyi.net]

>># # # # : 2019# 8# 28#  21:46

>># # # : Robert Varga ; Qin Wu 

>># # : netmod 

>># # : Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working 
>>Group document.

>>

>>Hello,

>>

>>Please find comments inline.

>>>On 27/08/2019 18:03, Dmytro Shytyi wrote:

 Dear All,

 

 I am one of the authors of ID VYSM and I would like to draw your

 attention to the evolution of the

 draft https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt.

 Recently we produced (but did not submitted yet) a new version of ID

 (02) and I beleive it fits the netmod working group.

 

 We would be gratefull if you could suggest if the new version(02) of the

 document  could become an official work item of the WG?

       If yes, could you please indicate which modifications must be done

 in the document before submition.

>>> 

>>>Hmm, looking over the model, it would seem there is quite a bit of

>>>overlap with RFC8345 -- to the point I believe the model could be

>>>formulated in terms of RFC8345 specialization:

>>First of all I would like to thank you for this comment. 

>>-Dmytro

>>>virtualization -> networks/network

>>> 

>>>device/links/interfaces/switches/vms are probably a mix of

>>>node/termmination-point/link extensions with conjunction with

>>>supporting-{topology,node,link}.

>>I can imagine mapping:

>>virtualization (ID) -> networks/network (RFC 8345)

>>links (ID)- >link;(RFC 8345)

>>ports (ID)-> termination points;(RFC 8345)

>>But still.. it seems here we have to create extension of the model proposed 
>>in RFC 8345.

>>Precisely for node (RFC 8345) we may add types (switches, vms) and futer add 
>>leafs /listsfor type if required (ex: #RAM,#vCPUs and other leafs for VMs)

>>-Dmytro

>>>How would the draft relate to RFC8345? Should it perhaps call out it is

>>>a different take on the similar problem, specialized to a particular

>>>use-case?

>>One can suggest that  in the RFC8345 Figure 1, the block "service Topology 
>>model" can include the proposed in the draft network service descriptor with 
>>appropriate modification of mapping according to the RFC8345.

>>

>>Meanwhile I find that the proposed solution(ID) try to solve the problem 
>>descibed below:

>>

>>The uCPE management mechanism may involve not only YANG modules but  also the 
>>speficif logic written in programming languages. The proposed organisation of 
>>yang model is an attempt to find the best fit  for combination (YANG modules 
>>+ specific logic written in python for example )  to manage different 
>>existing NFVIs in the uCPE (by the orchestrator).

>>

>>In the case of uCPE, the mapping (w/wo additinal logic) of "variables " 
>>between service yang modules (in the orchestrator) and NETCONF payload(that 
>>is sent to the uCPE) will be more complex (requires additional 
>>transformations in the logic) with generic approach, then the solution 
>>presented in the ID, that is tailored to the uCPE. 

>>

>>Therefore I find the proposed solution as a stadalone generic approach to 
>>manage multiple vendor uCPE that appears to be a particular case tailored for 
>>uCPE NFVIs that may be not nesseraly follows RFC8345. I would be pleased if 
>>you could comment this.

>>

>>-Dmytro

>>>Regards,

>>>Robert (with RFC8345 co-author hat on)

>>>+1, in addition, I am wondering whether 

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

[Martin Bjorklund]

Kent Watsen  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
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

>> 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.


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, 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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-artwork-folding-09: (with DISCUSS and COMMENT)

[Suresh Krishnan via Datatracker]

Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-artwork-folding-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/



--
DISCUSS:
--

After some thought I think there are two things about this document that make
me uncomfortable enough to ballot Discuss.

a) Due to its home in the netmod WG it is highly likely that people outside the
yang community have not paid enough attention to this work. Since this is
applicable to code fragments of all kinds, I think the home chosen for this RFC
might have inadvertently limited input from the broader community.

b) Given a) I think it is better that this document go forward as an
Informational document rather than a BCP so that use of this technique becomes
optional, without the force of a BCP behind it.


--
COMMENT:
--

I do agree with my Abstaining colleagues that this should probably not be on
the IETF stream but I think the work is useful enough to go forward.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-09: (with DISCUSS and COMMENT)

[Erik Auerswald]

Hi Benjamin,

On Wed, Sep 04, 2019 at 11:07:46PM -0700, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-netmod-artwork-folding-09: Discuss
> [...]
> --
> COMMENT:
> --
> [...]
>  "$SED" '{H;$!d};x;s/^\n//;s/\\\n *//g' $temp_dir/wip > $outfile
> 
> [I don't remember why the s/^\n// is needed; similarly for the
> unfold_it_2() case.]

This is an artifact of how sed's H command works: it adds a newline to
the hold space, then appends the pattern space (which does not contain
a newline) to the hold space. Thus an extra newline is added before the
first line of the input data. This extra newline needs to be removed.

> [...]

Thanks,
Erik

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

On Wed, 2019-09-04 at 11:56 -0700, Alissa Cooper via Datatracker wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-netmod-artwork-folding-09: Abstain
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/
> 
> 
> 
> --
> COMMENT:
> --
> 
> RFC 7994 is not a product of IETF consensus, so it seems inappropriate to
> publish a consensus BCP predicated on requirements defined in RFC 7994 which
> themselves do not have IETF consensus. This would be the only document related
> to the RFC format in the last 10 years that I'm aware of that would be
> published on the IETF stream.
> 
> 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.

Lada

> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-09: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-artwork-folding-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/



--
DISCUSS:
--

I think the procedures described herein are incomplete without a footer
to terminate the un-folding process.  Otherwise, it seems that the
described algorithms would leave the two-line header for the second and
subsequent instances of folded text in a single document.  (If we tried
to just blindly remove all instances of the header without seeking
boundaries, then we would misreconstruct content when different folding
algorithms are used in the same document with the single-backslash
algorithm occurring first.)

I don't think it's proper to refer to a script that requires bash
specifically as a "POSIX shell script".  I did not attmept to check
whether any bash-specific features are used or this requirements stems
solely from the shebang line, though.

I think the shell script does need to use double-quotes around some
variable expansions, especially "$infile" and "$outfile", to work
properly for filenames containing spaces.  We do quote "$infile" when
we're checking that it exists, just not (most of the time) when we
actually use it!

In addition to the above, I also share Alissa's (and Mirja's) concerns,
but feel that Discuss is more appropriate than Abstain, so we can discuss
what the best way to get this content published is.  For it's fine
content, and we should see it published; it's just not immediately clear
to me what the right way to do so is.


--
COMMENT:
--

Section 4.1

   Automated folding of long lines is needed in order to support draft
   compilations that entail a) validation of source input files (e.g.,
   XML, JSON, ABNF, ASN.1) and/or b) dynamic generation of output, using
   a tool that doesn't observe line lengths, that is stitched into the
   final document to be submitted.

I don't think the intended meaning of "source input files" will be clear
to all readers just from this text.  Some discussion of how RFCs can
consider source code, data structures, generated output, etc., that have
standalone representations and natural formats, and the need to display
their contents in the RFC format that has different requirements might
be helpful context for this paragraph and the next.

Section 7.1.2

For some reason my mental model of "RFC style" does not use the word
"really" in this way, and prefers alternatives like "very" or
"exceptionally".  (Also in Section 8.1.2.)

Section 7.2.1

   1.  Determine where the fold will occur.  This location MUST be
   before or at the desired maximum column, and MUST NOT be chosen
   such that the character immediately after the fold is a space ('
   ') character.  For forced foldings, the location is between the

This is a rather awkward natural line break.  I suggest an RFC Editor
note to make sure that the punctuation around the space character all
appears on the same line.

   3.  On the following line, insert any number of space (' ')
   characters.

I'm not sure I'd characterize the procedure as "complete" when it leaves
the value of the output subject to implementation choice such as this.
(Note that the next paragraph talks about the resulting "arbitrary
number of space" characters, and would presumably also need to be
adjusted if this text was adjusted.)
We also don't seem to bound this number of spaces to be fewer than the
target line length, which only matters in some weirdly pedantic sense.

Section 7.2.2

   Scan the beginning of the text content for the header described in
   Section 7.1.1.  If the header is not present, starting on the first
   line of the text content, exit (this text contents does not need to
   be unfolded).

I'm not sure I understand what "starting on the first line of the text
content" is intended to mean.  (Also in 8.2.2.)

Section 8.2.1

   If this text content needs to and can be folded, insert the header
   described in Section 8.1.1, ensuring that any additional printable
   characters surrounding the header do not result in a line exceeding
   the desired maximum.

We discussed above some cases when text could not be folded using the
algorithm from Section 7.2.1; in what case could text not be folded with
this algorithm?  Just the case when the implementation