Subject: Re: As Promised, an attempt at 2026bis

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Oct 2006 13:00:14 +0200

>>If that's indeed the case, the first order of business needs to
>>be to document current practice. I see no chance of making
>>forward progress on actual changes without first having a
>>consensus as to what our current state is.
> 
> 
> Brian Carpenter has written draft-carpenter-rfc2026-critique-02.txt
> which does exactly that, and he has repeatedly solicited comments on
> it.  If you think that it would be helpful to have it published as
> an informational RFC before undertaking to make normative changes
> to our standards procedures, please say so.

Thanks for the plug, Mike :-)

Quite seriously - am I to conclude from the absence of comments
on that draft that everyone agrees that it correctly describes
current practice? If so, I'll look for an AD to sponsor it.

    Brian

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

---

From: [email-masked]
Date: Tue, 3 Oct 2006 11:09:30 +0000

> current practice? If so, I'll look for an AD to sponsor it.

	silence is NOT consent.  Its silence.   
	to be SURE, i'd wait till you had actually
	expressions of support.  but, i'm not you am i? :)

--bill

---

From: Eliot Lear <[email-masked]>
Date: Tue, 03 Oct 2006 15:23:46 +0200

> current practice? If so, I'll look for an AD to sponsor it.

You asked.

Your critique itself has its pluses and minuses. 

On the plus side you've at least identified some of the issues that have
made the document a little long in the tooth, like ASes, RFC Editor
text, standard levels, interoperability reports, IPR etc. 

However, you have missed the forest from the trees.  The fundamental
description of how we behave as an organization is lost in a section by
section critique.  It would have been better for you to update RFC 2026
with an appendix explaining the changes and why they are necessary to
reflect reality. 

Oh wait.  I've done (or at least begun) that.

Here are specific comments about your section by section critique:

I think you've misinterpreted section 3.3, which discusses levels of
requirements for standards themselves, not individual components of TS
documents.  But beyond this one has to question the whole notion of
requirement levels such as those in that section.  Why should they be
there at all?  The IETF has no force of authority other than moral, and
people are not going to write code -- or support it -- for the sake of
the IETF's moral authority.  Similarly the discussion regarding
Independent RFCs.  We don't need to critique the words since the IAB &
RFC Editor are working on an update.  Let's go critique THOSE words.

You document the broken rather than fix it.  See, for instance, your
commentary about PS.  You yourself call out confusion regarding STDs
only being assigned at PS.  However, at least RFC2026 is self consistent.

In addition, I would actually affirm some of the general intent that "A
Technical Specification is any description of a protocol, service,
procedure, convention, or format."  I think "implementable and testable"
are laudable goals (;-) but the way we test both is through operational
experience, which is why we had the standards levels in the first
place.  IN PRACTICE, many standards are implemented well before they get
through the IESG process, and so Internet-Drafts are largely serving the
purpose of PS.

Although STD1 is rarely updated it should still be so.  One reason is
that the web is a horrible historical medium for determining what the
status of a standard WAS at in a particular time period.

Eliot

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 3 Oct 2006 06:45:48 -0700 (PDT)

> current practice? If so, I'll look for an AD to sponsor it.

I've read the document a couple of times, and it appears to me
to be reasonably accurate.  

> Oh wait.  I've done (or at least begun) that.

I, too, would prefer to see an update to 2026 that brings it into
conformance to current practice.  However, Eliot's draft goes well
beyond that by proposing substantive changes to current practice,
and those proposed changes seem to be quite controversial.

In the absence of an update proposal that has community consensus,
I think it would be useful to have a description of how 2026 diverges
from current practice.  So I would encourage Brian to attempt to
publish draft-carpenter-rfc2026-critique-02.txt as an information RFC.

Mike

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Oct 2006 11:02:53 -0400

--On Tuesday, 03 October, 2006 13:00 +0200 Brian E Carpenter
<[email-masked]> wrote:

> Quite seriously - am I to conclude from the absence of
> comments on that draft that everyone agrees that it
> correctly describes current practice? If so, I'll look for
> an AD to sponsor it.

Brian,

As I suggested at the Montreal plenary, I believe that the
majority of the community has reached a state of exhaustion on
all but the most critical and pressing process issues (and maybe
on those).  If that hypothesis is correct, real consensus
(positive or negative) about such proposals is likely to be
impossible.  The folks who still care about process issues and
are not burned out will speak up and the folks who are afraid of
unintended consequences despite being exhausted will speak up
(but perhaps only on Last Call).  The vast majority of the
community will be silent, not because they are not impacted or
don't care (although some will fall into both of those
categoris) but, for the rest, because of general exhaustion with
one process battle after another.

The reactions to both Eliot's and Scott's 2026bis draft
(in-depth comments and discussion from the usual process
activists, plus comments from others when something they
consider outrageous is said) and to your 2026 critique (mostly
silence) could be attributed, not to agreement by everyone else,
but to that exhaustion factor.  

Or, perhaps I'm completely wrong about the sense of the
community.  But I would suggest and ask that, before any more of
these documents are pushed or Last Called, you try to determine
the degree to which the community just does not want to deal
with these issues for a while.

regards,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Oct 2006 17:21:55 +0200

John,

> with these issues for a while.

As said in my note sent on 2006-08-10, my conclusion after Montreal
was essentially the same as yours:

> 1.1. There is insufficient pressure and energy in the community
> to justify the effort of reaching consensus on formal changes
> to the standards process at this time. 

My intention is to use the current list discussion to confirm
or refute this conclusion.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Oct 2006 11:27:36 -0400

--On Tuesday, 03 October, 2006 17:21 +0200 Brian E Carpenter
<[email-masked]> wrote:

>> community.  But I would suggest and ask that, before any more
>> of these documents are pushed or Last Called, you try to
>> determine the degree to which the community just does not
>> want to deal with these issues for a while.
> 
>> 1.1. There is insufficient pressure and energy in the
>> community to justify the effort of reaching consensus on
>> formal changes to the standards process at this time. 

And that was why I was a bit surprised to see you suggesting
finding an AD to sponsor, and presumably Last Call, your draft.
 
> or refute this conclusion.

Good.  If we disagree, it is only on what a "formal change"
constitutes.  I would consider an in-depth summary of what is
wrong with 2026 (at least on any basis other than a personal
informational opinion piece) and any attempt to replace 2026
with a version that reflects current practice to be such formal
changes, if only because they would require almost the same
level of effort in review and consensus-finding as actually
changing the process.  But some might disagree.

thanks,
   john

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Oct 2006 13:00:13 -0400

> changing the process.  But some might disagree.

As I start to write this, I've read through a little more than half of 
Brian's draft; I stopped when I found something to comment on.  What I'm 
seeing is descriptive, not prescriptive - it describes ways in which 
RFC2026 differs from what we actually do, offers interpretation based on 
current practice, and so on.  I think a document like that, taken as a 
non-normative description rather than a specification, could be useful 
operationally.  People who read RFC2026 without being familiar with current 
practice are likely to be rather confused, and Brian's draft clears up many 
of the possible confusions and offers additional commentary that may be 
useful in understanding what goes on.

I assume that a document like this would be published as an informational 
document, without the benefit of IETF consensus and possibly without even a 
Last Call (there is _nothing_ that says Informational documents need a last 
call, and they are frequently published without one).  I wouldn't have a 
problem with that, and in fact, it's probably best that this _not_ be an 
IETF consensus document if it is to serve a useful purpose.

Now, the thing I found to comment on.  Brian writes the following about the 
last paragraph of section 4.2.2:

   This presumably means "outside of the IETF process" not "outside of
   the Internet community."  As part of this year's RFC Editor RFP
   process, clarity is being sought about the independent submissions
   track, which should probably not be discussed at all in the basic
   definition of the standards process.  See
   [I-D.klensin-rfc-independent] for a more current description.

Actually, I think the section means what it says, and is referring _not_ to 
independent submissions but to cases where a specification developed 
elsewhere is republished as an RFC to make it more readily available to the 
Internet community.  For example, we do this on a fairly regular basis with 
the specifications of cryptographic hash functions.

-- Jeff

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Oct 2006 14:26:04 +0200

Eliot,

The goal of draft-carpenter-rfc2026-critique-02 is
rather different from the goal of the two previous versions,
and it might have been better to change the file name
as well as removing 'critique' from the document title.

The intent of the -02 version is "to document, for information
only, how actual practice interprets the formal rules." I'm not
sure you've read it in that spirit.

     Brian

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Oct 2006 09:03:59 -0700

On Oct 3, 2006, at 4:00 AM, Brian E Carpenter wrote:

>> Brian Carpenter has written draft-carpenter-rfc2026- 
>> critique-02.txt which does exactly that, and he has repeatedly  
>> solicited comments on it.  If you think that it would be helpful  
>> to have it published as an informational RFC before undertaking to  
>> make normative changes to our standards procedures, please say so.
>
> Quite seriously - am I to conclude from the absence of comments on  
> that draft that everyone agrees that it correctly describes current  
> practice? If so, I'll look for an AD to sponsor it.

Please do.

-Doug