Short summary of my belief: a necessarily incomplete set of diffs is not the right way to fix this problem. Short summary of my assessment of this document for the task it sets itself: not ready, even if you agree with the aim. Examples: In section 3.2, the document says: CHANGE: Delete this paragraph and all other references to STD1. There is a single reference to STD1 in the document, so I believe this might be a reference to "all other references" in other documents. But that's neither clear nor is certain that issuing this document saying this makes any real difference; issuing a STD1 that ends the practice might well be better. In the same Section, the document says: When a specification has been approved for publication on the standards track, it is assigned a Standard Number (e.g. 10) and a Standard Acronym (e.g. SMTP), independent of its RFC number and its place in the RFC series. As a specification changes status within the standards track, its Standard Number remains the same, and is associated with the most recent version of the specification, regardless of its maturity level. Historically, RFCs that document Internet Standards formed the 'STD' subseries of the RFC series [4]. This seems to ignore the fact that STDs can point to multiple documents; STD 10, which is the example, actually points to 3 documents at this point. Resolving how an STD number which was assigned to a single document can be used to construct something similar to STD 10 seems to require more work. In the same section, the document says: Not all specifications of protocols or services for the Internet should or will become Internet Standards or BCPs. The various paths to publication are defined in [RFC4844]. Non-standards track IETF specifications may be published as "Experimental" or "Informational" RFCs if approved by the IESG. When non-standards track specifications are produced within the IETF, they are subject to the rules of the IETF except those specific to Section 5 and Sections 6.1 through 6.4 of [RFC2026]. RATIONALE: IETF Experimental or Informational RFCs are distinct from independent submissions to the RFC Editor, which are now processed under [RFC4846] and [RFC3932], and from IAB [RFC4845] and IRTF documents. Also, we want all IETF documents to be subject to many of our rules, such as the IPR rules and the appeals process. The last statement, "we want all IETF documents to be subjects to many of our rules, such as the IPR rules and the appeals process" is pretty vague, and it's not clear that the community ever actually considered whether the appeals process for IETF experimental RFCs really needs the same weight as the standards track process. It's an interesting question, and I'm not sure what my view is; I might well support a lower-weight appeals process there. In Section 3.4, the document proposes the following addition: Thus a TS is not limited to defining a protocol; it may for example define an Application Programming Interface (i.e. a convention) or a data definition such as a MIB or an IANA registry (i.e. a format). However, a TS must be both implementable and testable. RATIONALE: Although clearly within the intended scope of RFC 2026, these types of TS have been a source of debate and deserve clarification. Also see later comments on implementation reports. How is an IANA registry implementable and testable? Do I need to configure my own ICANN, create registries under my IANA, and so on? The document also makes a lot of terminology changes which might actually be useful, e.g: Preliminary Standard is indeed the preliminary level. Implementors should be aware that a PS may be revised or even withdrawn. However, it is nevertheless common to use PS implementations operationally. Many documents spend their entire active life as PS. Certain types of specification, e.g. data formats such as MIBs, are likely to be recycled at PS as they evolve rather than being promoted. but which I feel have not had sufficient community discussion. Will our SDO partners, who have gotten used to Proposed Standard, actually understand a shift to "Preliminary Standard" as a terminology update only? Should they, or is it a real change? To re-iterate, I do not think this document has had enough community input to update 2026, even if you believe a series of diffs is the right way to handle the problem. The reason it has not is clearly not Brian's fault, but I think the IESG ought to take community interest and energy spent on this as an input into their decision. regards, Ted Hardie At 9:40 AM -0500 1/21/08, The IESG wrote: >The IESG has received a request from an individual submitter to consider >the following document: > >- 'Changes to the Internet Standards Process defined by RFC 2026 ' > <draft-carpenter-rfc2026-changes-02.txt> as a BCP > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@xxxxxxxx mailing lists by 2008-02-18. Exceptionally, >comments may be sent to iesg@xxxxxxxx instead. In either case, please >retain the beginning of the Subject line to allow automated sorting. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-carpenter-rfc2026-changes-02.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16166&rfc_flag=0 > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@xxxxxxxx >https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf