Re: draft-klensin-newtrk-8540style-harmful (and (and draft-roach-bis-documents-, etc.)

[Carsten Bormann <[e-mail]>]

Another example to consider: RFC 4815.
This was not a weather report.  It was addressing a similar need:
Getting small corrections and clarifications out that came from experience gathered in half a decade of deployment of a very new protocol and framework.

It did stay at I-D stage (draft-ietf-rohc-rtp-impl-guide-00 was Feb 2002) for most of that time, until we decided it was time to wrap it up.

For RFC 4815, we ultimately went for standards-track, and with hindsight I have no idea why one would do otherwise.

I’m currently proposing to do a similar document for CoRE.

Grüße, Carsten


https://datatracker.ietf.org/doc/rfc4815/

4815 RObust Header Compression (ROHC): Corrections and Clarifications to
     RFC 3095. L-E. Jonsson, K. Sandlund, G. Pelletier, P. Kremer.
     February 2007. (Format: TXT=74819, HTML=0 bytes) (Updates RFC3095,
     RFC3241, RFC3843, RFC4019, RFC4362) (Status: PROPOSED STANDARD)
     (DOI: 10.17487/RFC4815) 


> On Jun 8, 2019, at 02:02, Brian E Carpenter <[e-mail]> wrote:
> 
> On 08-Jun-19 06:51, Michael Richardson wrote:
>> 
>> John, I haven't read your whole document, and you mention
>> RFC 8540 specifically.  I'm guessing that this is the document that pushed
>> you to think about this?
>> 
>>>  The WG suggested in its summary for IETF
>>>  Last Call for what became RFC 8540 that an errata listing like that
>>>  provided by RFCs 4460 and 8540 is helpful in producing replacements
>>>  for the original documents [LC8540-Statement] but there is no
>>>  evidence that the same purpose could not be served by retaining the
>>>  same list as an Internet-Draft until the actual replacement document
>>>  is ready to be published and then either discarding that I-D or, if
>>>  the WG felt a need to do so, incorporating the errata listing as an
>>>  appendix in the final document.
>> 
>> As far as I can see, 8540 was produced by the tsvwg, and went through IETF
>> process. Yes, it's informational, rather than standards track ("Updates"),
>> but that seems somewhat immaterial to me.
>> 
>> I am not an expert in SCTP or the issues reported, but my guess is that the
>> situation is that the issues reported do not affect all users, but that they
>> affect enough that having some clear text is useful.
>> 
>> What you suggest, that it remain an ID would seem to me, to elevate IDs to be
>> equivalent to RFCs.
>> 
>> I couldn't puzzle out what your Conclusion was.  Maybe if you'd dealt with
>> another example, it would help.    I was involved in NEWTRK, and I think you
>> probably need to hit the reader over the head harder here.
>> 
>> ||ugh Daniel's once lamented that it every software release needs a label so
>> that one can refer to it properly, but that it's often hard to know which
>> releases are good ones until after they get a label.   He described what he
>> wanted was a kind of "weather report", which tells you how things worked out
>> earlier in the "day".   I think that you (and NEWTRK) are really asking for
>> this.
>> 
>> It seems to me that RFC8540 needs to be a weather report, and that we really
>> need a new kind of document for this.
> 
> For me a big question is whether weather reports should use RFC2119 language,
> which makes it easy for an outsider to mistake them for standards.
> 
> But yes, https://tools.ietf.org/html/draft-klensin-isdbis-00
> I don't think that ignoring that idea has served the IETF well.
> 
>   Brian