Handling Long Lines in Inclusions in Internet-Drafts and RFCs
draft-ietf-netmod-artwork-folding-12

Note: This ballot was opened for revision 08 and is now closed.

(Ignas Bagdonas) Yes

Deborah Brungard No Objection

Roman Danyliw No Objection

Comment (2019-09-04 for -09)
(1) Section 1.  To make this document more enduring, I’d recommend qualifying the capabilities of xml2rfc  (i.e., no line wrapping is done) to a version number.

(2) Section 2. Is it worth saying that in addition to the primary target being <sourcecode> and <artwork> (xml2rfc tags), it is also anything authors currently put between “<CODE BEGINS> … <CODE ENDS>” (sometimes even when not using xml tooling for rendering the draft)?  

(3) Editorial nits:
-- Section 2.  Editorial. s/This work may be also be used/This work may also be used/.

-- Section 4.2. Editorial.  s/already YANG [RFC7950] modules are extracted/YANG [RFC7950] modules are already extracted/.

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-01-20)
No email
send info
Thank you for addressing my Discuss points!

(Suresh Krishnan) (was Discuss, No Objection) No Objection

Comment (2019-11-02 for -10)
I am happy with this progressing as an Informational document.

Barry Leiba No Objection

Comment (2019-08-21 for -08)
— Section 4.1 —

I find the BCP 14 “SHOULD” in this section to be odd, and would lower-case them.

   When needed, this effort again
   SHOULD be automated to reduce effort and errors resulting from manual
   processing.

This sentence is really awkward: “when needed”, the use of “effort” twice, and the uncertainty of whether the clause “resulting from manual processing” applies to both effort and errors, or only to the latter.  I would say it this way:

NEW
This work should also be automated to reduce the effort and to reduce errors resulting from manual processing.
END

— Section 6 —

         assumes that the continuation begins at the character that is
         not a space character (' ') on the following line.

Should be “at the first character”.

— Section 7.1.1 —

   The second line is a blank line.

The code in the appendix generates an *empty* line (no text).  Is that what you mean by “blank line”?  Will a line that contains only space characters (*looks* the same) work also?  The code in the appendix appears to discard the second line without checking its content at all.  I think you should be clearer about what qualifies as a “blank line”.  (This also applies to Section 8.1.1.)

— Section 7.2.1 —

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

Should be “do not result” (to match the plural “printable characters”).

(Alexey Melnikov) (was Discuss) No Objection

Comment (2019-08-29 for -08)
No email
send info
Thank you for explaining how escaping of trailing \ is possible.

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2019-08-26 for -08)
Sometimes a small problem (like line folding) can be annoying... so thank you for authoring this document.

Just a minor comment:
- should 'pyang' and 'yanglint' be added to the references ?

-éric

Magnus Westerlund No Objection

Alissa Cooper Abstain

Comment (2019-09-04 for -09)
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.

(Mirja Kühlewind) Abstain

Comment (2019-08-29 for -08)
I don't think this draft is in scope of the charter of the netmod working group. I've seen in the shepherd write-up that input from the RSE was received, therefore I don't necessarily assume that a different publication path would have produced a different outcome and I decided not to block publication, however, given the publication path taken it is  not visible to me if sufficient feedback from the right people that are impacted or targeted by this document has been received. 

In general I don't think it is okay to publish a document that is out-of scope for a working group, especially when the scope of the document impacts other work in the IETF so broadly (while I do understand that this was written with main focus on YANG). Given the current situation I would eventually rather go for informational than BCP.

Alvaro Retana Abstain

Comment (2019-09-04 for -09)
I agree with Alissa on her concern of work related to the RFC format being published in the IETF Stream.  I am then also ABSTAINing.

The text mentions that the RFC Editor has confirmed that "there is currently no convention in place for how to handle long lines", but there is no mention, and I couldn't find a related conversation in the archive, about the RFC Editor's opinion of the proposed solution.  Because "this work primarily targets" elements in xml2rfc, I encourage the Shepherd/AD to explicitly discuss the solution with the RFC Editor.  I also strongly believe that a conversation should take place with the RFC Editor/IAB about the appropriate publication stream.  Both conversations should happen before this document is approved for publication.

(Adam Roach) (was No Objection) Abstain

Comment (2019-09-05 for -09)
No email
send info
I've updated my position to an Abstain based on the telechat
discussion. I find the arguments regarding BCP versus Informational
to be compelling, and am sympathetic to the concerns about
both stream and charter. All of that said, I do want to see this
document published, and I hope we can rearrange things in a
way that allows that to happen.

---------------------------------------------------------------------------

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"

---------------------------------------------------------------------------

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

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

---------------------------------------------------------------------------

§7.1.1:

>   NOTE: '\' line wrapping per BCP XXX (RFC XXXX)

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 XXXX])

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

---------------------------------------------------------------------------

> Appendix A.  POSIX Shell Script: rfcfold

Please add [POSIX.1-2017] as a reference.