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

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.

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.

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.

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.