Subject: Re: Last Call: draft-carpenter-rfc2026-changes (Changes to the Internet Standards Process defined by RFC 2026) to BCP

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Jan 2008 13:46:09 -0800

Short summary of my belief: a necessarily incomplete set of diffs is not
the right way to fix this problem.

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.

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.

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.

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?

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
>[email-masked] mailing lists by 2008-02-18. Exceptionally,
>comments may be sent to [email-masked] 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
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf-announce

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jan 2008 12:16:00 +1300

Hi Ted,

> the right way to fix this problem.

Are you arguing for a genuine 2026bis with the diffs applied, or for
inaction?

> real difference; issuing a STD1 that ends the practice might

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.

> construct something similar to STD 10 seems to require more

As an operational matter, yes, and the same applies to BCPs.
I'm not sure it needs more work in the formal rules.

> what my view is; I might well support a lower-weight

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.

> 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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Jan 2008 15:30:17 -0800

>Are you arguing for a genuine 2026bis with the diffs applied, or for

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