Thanks for the review, Spencer. A few comments below...
...
> 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.
For me, that is just a matter of keystrokes and I will do it
the community asks for it (preferably with the help of Scott Bradner
as the original author). However, I wouldn't want that to be
an excuse for doing anything *except* aligning 2026bis with
current practice, since we have consistently failed to find
consensus for major changes to current practice.
>
> 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?
My motivation for "normally" was to provide wiggle room. There are cases
where we mutually agree with another SDO to hand over an IETF standard
to them or to take over a non-IETF standard.
>
> 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... :-(
I think others have pointed out that a final issue of STD1 would be needed
to obsolete itself.
>
> 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?
Yes, probably. That is reality, after all.
>
> 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.
Agreed.
>
> "---------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 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.
Well, our current practice is that if the appropriate Last Call
procedure is followed, the IESG can approve such a downref. I think
the text should say this, to explain the "should".
>
> 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?
Probably not. I think that sentence is a bit unrealistic.
>
> 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"... :-(
Me neither. I'm personally inclined to drop the name changes, since
several objections have been made.
>
>
> 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.
Ack
>
> 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.
Maybe. Personally I don't want to see a hard rule, however.
>
> 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.
Well, let's see what the consensus is about IONs first...
>
> 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.
Don't we use Historic for standards that we no longer want to
encourage, but which haven't been updated? For example, wouldn't
1055 be a candidate for Historic, whereas 822 is obsolete?
>
> 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.
I think that's an operational matter, whereas the archive is a matter
of process.
Brian
_______________________________________________
Ietf@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf