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 mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf