Brian E Carpenter wrote: > Comments on draft-carpenter-rfc2026-changes-01.txt are welcome. | Formally abolishing the now pointless "STD 1" RFCs. NAK - I hope we get a new STD 1 soon, ideally after 4234bis got its STD number. | The IETF will not normally modify protocols developed elsewhere, IMO the IETF must be able to adopt specific versions of a standard developed elsewhere. E.g. UTF-8 is what STD 63 says, it can't be modified "elsewhere". | It would be much less confusing if a new or existing acronym was | assigned as part of the initial standards action (thus RFC 2821 | would have been associated with SMTP). IMO more with ESMTP than with SMTP, I think you need a better example here. | Similarly, the STD number should be assigned at PS stage for | simpler tracking - thus RFC 2821 would also be known as PS10, | for example. NAK, adding a "PS10" alias to "RFC 2821" doesn't help. Many PS don't deserve a separate STD number, unless they actually make it to this level. Some PS even don't need a nice acronym. It might be different when a PS tries to update an existing STD, as it's the case for RFC 2821. | Rename PS as Preliminary Standard. Some PS really are "proposed standards" as defined in 2026, i.e. "immature specifications". Or mature protocols where the specification needs a thorough cleanup, e.g. RFC 2616. [2026] | A standards action is initiated [...] | in the case of a specification not associated with a Working Group, a | recommendation by an individual to the IESG. [your text] | A standards action is initiated [...] | in the case of a specification not associated with a Working Group, an | agreement by an Area Director to recommend a specification to the | IESG. The IESG is empowered to define the procedures for this. | RATIONALE: Aligning with reality. JFTR, in reality I used the "recommendation by an individual" loophole in two cases, for 4234bis and Archived-At. We had a similar debate about the shepherd-ION some months ago. I need an appealable offense if the IESG refuses a "standards action" for frivolous reasons. The RFC 2026 text offers this, I'm not sure about your text. | Remove the reference to gopher. Sigh. I kind of like RFC 4266, is that "PS gopher" in your terminology ? | Add a note that the RFC Editor maintains errata for published RFCs. <joke> Also add a note that they maintain a pending errata mailbox with a submission from February 2005 waiting for publication. </joke> Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf