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 <brian.e.carpenter@xxxxxxxxx> 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
