Hi Ted, On 2008-01-22 10:46, Ted Hardie wrote: > Short summary of my belief: a necessarily incomplete set of diffs is not > the right way to fix this problem. Are you arguing for a genuine 2026bis with the diffs applied, or for inaction? > > 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. There is also a reference to [1] which is STD1 in its March 1996 version. My intention was to eliminate that too. I agree that if we go this way, we'd also want a final issue of STD1 to abolish itself. > > 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. As an operational matter, yes, and the same applies to BCPs. I'm not sure it needs more work in the formal rules. > > 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. Strictly speaking, I'm sure you're correct, but that doesn't mean that the rules are really different for a lower-weight approach - the existing rules give the IESG and IAB pretty wide discretion on how to run an appeal. > > 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? Again, I think that isn't a matter of rule-making; the proposed new text is what we've been doing for years, and we have the MIB example of how to interpret testability. I think this is exactly the area where we should make it clear that the IESG is to interpret the rules pragmatically. That was my intent, but it's tricky when working entirely via diffs. Brian > > 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 mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf