Subject: Gen-ART Last Call review of draft-carpenter-rfc2026-changes-02

From: Spencer Dawkins <[email-masked]>
Date: Thu, 14 Feb 2008 15:42:53 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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 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. 

_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 14 Feb 2008 23:54:12 +0100

Spencer Dawkins wrote:

> Does this document actually obsolete "STD1"? I'm not even sure what 
> that means... :-(

Good question.  Guessing, it means that the status of STD 68 claims
that there is an STD 1, while STD 1 claims that there is no STD 66,
let alone any STD 68.  Go figure... :-|

> If 2821 is moved into the SMTP STD, does 821 have to be removed?

For STD 10, yes.  I hope also for Brian's proposal, but I think we
need an example for this acronym business, using all existing STDs,
determined by some appropriate way (i.e. not limited to RFC 3700).

> Not that I can think of a better adjective that starts with the
> letter "D"... :-(

How about "distinguished standard", or is that too ridiculous ?

> 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.

Historic RFCs can be brilliant, but nevertheless they are historic.

IMO "historic" does not necessarily mean "no one cares".  Actually
somebody cared enough to trigger the reclassification.  And it does
not mean that the historic RFC "was always a bad idea".  It might
have been a very good idea, later turning out to be not good enough
for today's needs, e.g., UTF-7 (not yet historic, but a candidate).

> it will be good to decide whether obsolete is more perjorative than
> Historic, or vice versa, and say so.

Tricky.  As an example RFC 2821 claims to obsolete RFC 821, but IMO
a PS cannot obsolete a STD, it might grow into a position where it 
replaces the old RFC as STD.  Maybe 2821ter will finish off RFC 821.

In theory, because RFC 821 is really already "historic", this could
be made explicit.  But then we'd have a STD 10 without SMTP for some
years until 2821ter (or another successor of RFC 2821, this could be
2821bis promoted to STD "as is" in 2011) is ready to take over.

 Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Feb 2008 10:44:21 +1300

Thanks for the review, Spencer. A few comments below...

...
> IPR. Please consider applying these changes to produce an RFC 2026-bis 

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.

> the IETF authority to publish the resulting modified protocols as a

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.

> Spencer: Does this document actually obsolete "STD1"? I'm not even sure what 

I think others have pointed out that a final issue of STD1 would be needed
to obsolete itself.

> specifications at varying levels of maturity, specifications can be

Yes, probably. That is reality, after all.

> document or in two - but that's a big change to carry off in a list of 

Agreed.

> "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".

> ASs." Does this reflect the "AS text in TS document" theme previously?

Probably not. I think that sentence is a bit unrealistic.

> 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.
> Spencer: I agree with this rationale and think it's worth including in the 

Ack

> the document should say something about this.

Maybe. Personally I don't want to see a hard rule, however.
> might be good to mention IONs here, just to be clearer about what's in a BCP 

Well, let's see what the consensus is about IONs first...
> 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?

> for BOF discussions that proceeded working group formation. 

I think that's an operational matter, whereas the archive is a matter
of process.

     Brian