ietf
[Top] [All Lists]

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

2008-01-21 16:17:31
Hi Ted,

On 2008-01-22 10:46, Ted Hardie wrote:
Short summary of my belief: a necessarily incomplete set of diffs is not
the right way to fix this problem.

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


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.

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.


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.

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


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.

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.


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?

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

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
ietf(_at_)ietf(_dot_)org mailing lists by 2008-02-18. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org 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
IETF-Announce(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf-announce


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>