At 12:16 PM +1300 1/22/08, Brian E Carpenter wrote: >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? I believe a 2026bis would be needed to achieve real internal consistency, and to allow the community to actually understand the whole. I also believe that there is almost no community interest in creating, reviewing, and flogging the benefits of 2026bis to the outside world. As I said in my original message: this is not your fault. But I believe that it is a realistic assessment of the state of play. I have not gone through the issues you replied to below, because I was just trying to raise the general issue that the community hasn't really reviewed the document at a level that makes it ready for a Last Call. Sorry if that wasn't clear. regards, Ted Hardie > > >> 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 mailing list >Ietf@xxxxxxxx >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf