Document: draft-carpenter-rfc2026-changes-02 Reviewer: Spencer Dawkins Review Date: 2008-02-14 IETF LC End Date: 2008-02-18 IESG Telechat date: (if known) Summary: This document is a very reasonable contribution to IETF process discussion, but these changes need to be much more widely reviewed, and I'd much prefer that these changes be folded into a complete 2026bis for ease of reference. I know a BOF is being considered for this document. Comments: I know that there's been a lot of discussion about whether this draft should have been last-called, etc. but I do think it's important to provide Last Call comments at this time. I'm also trying to provide a review of the draft, rather than argue about details of specific proposals and/or support the proposals I like. Overarching - I don't agree with the use of a patching approach to BCP revision. We are already patched two layers deep on changes from 2026 on IPR. Please consider applying these changes to produce an RFC 2026-bis document. 3.1. Change to Section 1.1 Internet Standards "---------Begin Extract--------- The Internet Standards Process described in this document is concerned with all protocols, procedures, and conventions that are used in or by the Internet, whether or not they are part of the TCP/IP protocol suite. In the case of protocols developed and/or standardized by non-Internet organizations, however, the Internet Standards Process normally applies to the application of the protocol or procedure in the Internet context, not to the specification of the protocol itself. -----------End Extract---------" CHANGE: Replace the last sentence by: In the case of protocols developed and/or standardized outside the IETF, the Internet Standards Process may be applied to the use of the protocol in the Internet context. Similarly, IETF protocols may be cited in specifications developed elsewhere. The IETF will not normally modify protocols developed elsewhere, and does not normally Spencer: I don't know what "normally" means in this sentence. Is this saying that we rarely modify protocols developed outside the IETF, unless the protocol developers request that we work on these modifications and grant the IETF authority to publish the resulting modified protocols as a standards-track RFC? permit its protocols to be modified elsewhere. 3.2. Changes to Section 2.1 Requests for Comments (RFCs) "---------Begin Extract--------- The status of Internet protocol and service specifications is summarized periodically in an RFC entitled "Internet Official Protocol Standards" [1]. This RFC shows the level of maturity and other helpful information for each Internet protocol or service specification (see section 3). -----------End Extract---------" CHANGE: Delete this paragraph and all other references to STD1. Spencer: Does this document actually obsolete "STD1"? I'm not even sure what that means... :-( RATIONALE: This was written before a hyperlinked index was available on line. "---------Begin Extract--------- Some RFCs document Internet Standards. These RFCs form the 'STD' subseries of the RFC series [4]. When a specification has been adopted as an Internet Standard, it is given the additional label "STDxxx", but it keeps its RFC number and its place in the RFC series. (see section 4.1.3) -----------End Extract---------" CHANGE: Replace the last sentence by: 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]. Acronyms may comprise sub-acronyms (e.g. SMTP/Submission) in the case of multipart standards. Spencer: does it need to be stated that a STD can contain multiple specifications at varying levels of maturity, specifications can be added/deleted, etc? Spencer: how does this interact with cases like RFC 821/2821? Can more than one version of a specification be part of an STD at the same time? If 2821 is moved into the SMTP STD, does 821 have to be removed? RATIONALE: The fact that only full Standards receive an STD number, and possibly an acronym, is today a major source of confusion to users of the standards, since these numbers and acronyms are not associatd with PS and DS documents. Users do not, in fact, know where to look for the latest standard, since a DS may obsolete an STD, and a PS may obsolete either. 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). Similarly, the STD number should be assigned at PS stage for simpler tracking - thus RFC 2821 would also be known as PS10, replacing the older RFC 821 previously known as STD10. (Also see comments on section 4.1.3.) 3.5. Changes to Section 3.2 Applicability Statement (AS) "---------Begin Extract--------- An Applicability Statement specifies how, and under what circumstances, one or more TSs may be applied to support a particular Internet capability. An AS may specify uses for TSs that are not Internet Standards, as discussed in Section 7. -----------End Extract---------" CHANGE: Insert the following after this paragraph: The following description refers to an AS as if it were a separate document. In practice, the applicability information is commonly embedded in the relevant TS. RATIONALE: The community really doesn't have the habit of writing separate AS documents; it's rare, and very rare in WG charters. Such a document has more significance than an Informational document, but can only be placed on the standards track along with relevant TSs, because it can't be implemented and tested in itself. Spencer: this approach makes sense if this document does NOT result in a 2026-bis, but points to the level of confusion caused by issuing a list of changes. The point of this text would be a lot clearer if it described two kinds of descriptions, without reference to whether they appear in one document or in two - but that's a big change to carry off in a list of changes. "---------Begin Extract--------- An AS may not have a higher maturity level in the standards track than any standards-track TS on which the AS relies (see section 4.1). For example, a TS at Draft Standard level may be referenced by an AS at the Proposed Standard or Draft Standard level, but not by an AS at the Standard level. -----------End Extract---------" CHANGE: Move this paragraph to a new general section on normative reference requirements, and rewrite as: A standards-track document should not have a higher maturity level in the standards track than any standards-track document on which it relies normatively. RATIONALE: There is nothing specific to ASes in this rule; it is applied globally wherever normative references occur. See comment below on 4.2.4. Spencer: we have very little experience with downrefs beyond PS->Informational. Is it obvious to everyone but me what the procedure PS->is, if you want to promote a document to DS, if it normatively refers to a PS? If the intention is that this doesn't happen, "should not" is too weak - "will not", or something like that. 3.6. Changes to Section 3.3 Requirement Levels "---------Begin Extract--------- The "Official Protocol Standards" RFC (STD1) lists a general requirement level for each TS, using the nomenclature defined in this section. This RFC is updated periodically. In many cases, more detailed descriptions of the requirement levels of particular protocols and of individual features of the protocols will be found in appropriate ASs. -----------End Extract---------" CHANGE: Replace the first two sentences by: The RFC Editor web site displays the current maturity level of each standards track document, as well as the status of all RFCs. Spencer: this is leaving "in many cases ... will be found in appropriate ASs." Does this reflect the "AS text in TS document" theme previously? RATIONALE: Aligning with reality. 3.8. Changes to Section 4.1.2 Draft Standard CHANGE: Rename as Deployable Standard. RATIONALE: Just as "proposed" standard is effectively interpreted as "preliminary", "draft standard" is effectively interpreted as much more than a draft. Also we have the problem of confusion with "Internet-Draft." The name change reduces this risk of confusion and clarifies the factual status. Spencer: I know what you're trying to do, but as written, PS will often be deployed, so this second-stage name is misleading. Not that I can think of a better adjective that starts with the letter "D"... :-( 3.10. Changes to Section 4.2.2 Informational "---------Begin Extract--------- An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3). -----------End Extract---------" CHANGE: Add: In practice, some Informational and Experimental RFCs that are published following IESG Approval are very close to being a TS or AS and are evaluated almost as carefully. Others are more general. RATIONALE: Aligning with reality. In particular, requirements documents that will guide future work deserve more careful review by the IESG than other Informational RFCs. Spencer: I agree with this rationale and think it's worth including in the text itself. 3.12. Changes to Section 4.2.4 Historic "---------Begin Extract--------- A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. (Purists have suggested that the word should be "Historical"; however, at this point the use of "Historic" is historical.) -----------End Extract---------" CHANGE: Replace this paragraph by: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete may be assigned to the "Historic" level by the IESG. (Purists have suggested that the word should be "Historical"; however, at this point the use of "Historic" is historical.) Spencer: one question I've seen discussed repeatedly is whether it's bad for a specification to move to "Historic" - this came up several times in DECRUFT, for example. It would be nice to make a statement about this in a revised 2026. I don't think it IS bad - "Historic" can be as gentle as "no one who cares still participates in IETF" - but whether others agree or not, the document should say something about this. RATIONALE: Aligning with reality. 3.13. Change to Section 5. BEST CURRENT PRACTICE (BCP) RFCs "---------Begin Extract--------- While it is recognized that entities such as the IAB and IESG are composed of individuals who may participate, as individuals, in the technical work of the IETF, it is also recognized that the entities themselves have an existence as leaders in the community. As leaders in the Internet technical community, these entities should have an outlet to propose ideas to stimulate work in a particular area, to raise the community's sensitivity to a certain issue, to make a statement of architectural principle, or to communicate their thoughts on other matters. The BCP subseries creates a smoothly structured way for these management entities to insert proposals into the consensus-building machinery of the IETF while gauging the community's view of that issue. -----------End Extract---------" CHANGE: Add: Such BCPs are subject to the normal process of IETF review and IESG approval. Spencer: If we can decide whether the ION experiment succeeded or failed, it might be good to mention IONs here, just to be clearer about what's in a BCP vs what's in an ION. RATIONALE: Important clarification. "---------Begin Extract--------- When a standards-track specification has not reached the Internet Standard level but has remained at the same maturity level for twenty-four (24) months, and every twelve (12) months thereafter until the status is changed, the IESG shall review the viability of the standardization effort responsible for that specification and the usefulness of the technology. Following each such review, the IESG shall approve termination or continuation of the development effort, at the same time the IESG shall decide to maintain the specification at the same maturity level or to move it to Historic status. This decision shall be communicated to the IETF by electronic mail to the IETF Announce mailing list to allow the Internet community an opportunity to comment. This provision is not intended to threaten a legitimate and active Working Group effort, but rather to provide an administrative mechanism for terminating a moribund effort. -----------End Extract---------" CHANGE: Replace this by: In normal practice, the IESG may be requested to advance any standards-track specification that has been long enough in grade, or to replace or deprecate any IETF document, by the relevant Working Group if it exists, or by one or more individual participants if not. Additionally, when a standards-track specification has not reached the highest level, but has remained at the same maturity level for at least the required minimum period plus one year, any participant may request the IESG to review the viability of the standardization effort responsible for that specification and the usefulness of the technology. Such a request should include a proposed action, with a justification and suitable Internet-Drafts if appropriate. Following each such request, the IESG shall approve termination or continuation of the development effort. At the same time the IESG shall decide whether to maintain the specification at the same maturity level or to move it to Historic status. This intention shall be communicated to the IETF by electronic mail to the IETF Announce mailing list to allow the Internet community an opportunity to comment. This provision is not intended to threaten a legitimate and active Working Group effort, but rather to provide an administrative mechanism for reviving or terminating a moribund effort, and for marking obsolete Spencer: again, it will be good to decide whether obsolete is more perjorative than Historic, or vice versa, and say so. specifications as such. RATIONALE: This shifts the responsibility to initiate advancement or deprecation of specifications to the community. No IESG has ever had the cycles to initiate such actions, and it is much better practice to delegate this responsibility. It also clarifies the difference between normal advancement and the handling of moribund efforts. 3.18. Change to Section 8. NOTICES AND RECORD KEEPING "---------Begin Extract--------- As a practical matter, the formal record of all Internet Standards Process activities is maintained by the IETF Secretariat, and is the responsibility of the IETF Secretariat except that each IETF Working Group is expected to maintain their own email list archive and must make a best effort to ensure that all traffic is captured and included in the archives. -----------End Extract---------" CHANGE: Replace by: As a practical matter, the formal record of all Internet Standards Process activities is maintained by the IETF Secretariat, and is the responsibility of the IETF Secretariat. Each IETF Working Group must maintain an email list archive, which may be that maintained by the Secretariat, and must make a best effort to ensure that all relevant and applicable traffic is captured and included in the archives. It is legitimate to delete irrelevant traffic such as unsolicited commercial email. RATIONALE: Aligning with reality. Spencer: this is probably broader than your charter, but it would be nice to point out that many (what percentage?) of IETF working group mailing lists are now hosted at ietf.org, and that using a mailing list hosted at ietf.org avoids many of the "employer-hosted" transitions we've seen in the past, as well as providing consistent archives for both the working group itself and for BOF discussions that proceeded working group formation.