Re: Review of: Characterization of Proposed Standards

Dave Crocker <> Thu, 31 October 2013 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96C5E11E8281 for <>; Thu, 31 Oct 2013 11:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dnPNZVa+mMRP for <>; Thu, 31 Oct 2013 11:06:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BB7C311E817F for <>; Thu, 31 Oct 2013 11:06:41 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id r9VI6ZsG013018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Oct 2013 11:06:39 -0700
Message-ID: <>
Date: Thu, 31 Oct 2013 11:06:21 -0700
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Olaf Kolkman <>
Subject: Re: Review of: Characterization of Proposed Standards
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Thu, 31 Oct 2013 11:06:40 -0700 (PDT)
Cc: "<>" <>, IETF Discussion <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2013 18:07:36 -0000


Thanks to Olaf, et al for putting up with my after-the-deadline 
feedback.  However this document goes to the core of the IETF and it's 
likely to stand for some decades.  So I think we all need to be 
particularly diligent at considering its uses and the opportunities for 
problems with it.  In other words, this is a good document for being 
fussy about fine points.

Note that the motivation for Olaf's draft is the misunderstanding by 
others of the nature and worth of Proposed Standards documents.  We do 
not have complaints about the actual /quality/ of the specifications, 
but of the language describing their formal status.

In effect, such folk are distracted by some of the words in RFC 2026. 
We can't fix their style of reading or limitations in how they integrate 
information and also we cannot ignore such folk.

What we /can/ do is try to have the draft anticipate problems with how 
such folk will read the text.  This requires a very different style of 
draft analysis than we typically expect.  Rather than looking for 
clarity, we need to look for opportunities to misunderstand.  (I call 
that necessary kind of language 'political' speech, since the author 
must worry about active misinterpretation and misrepresentation...)

That's what has motivated much of my feedback, including the additional 
points below...

And by the way...

      1.  For a document that goes to the very heart of the IETF's 
reason for being and especially given how long-lasting its effect is 
likely to be, it has received astonishingly little active, public 
review, based on the public record.

      2.  I also wonder whether we shouldn't circulate the draft more 
broadly, outside of the IETF, to request the comments.  Will it 
accomplish what we want it to accomplish?

Into some details...

On 10/31/2013 9:34 AM, Olaf Kolkman wrote:
 >  There was a suggestion to remove the characterization of Internet
 > Standard (for completeness) I think that is a matter of taste and not
 > of content.

When there is more than one source for something as basic as 
"characterization of Internet Standard" the different copies will, over 
time, diverge and create an opportunity for confusion.  This draft seeks 
to be a normative document.  It needs to stay within its scope.  Its 
scope does not include characterization of Internet Standard.  It 
should, therefore, merely cite the proper text contained elsewhere.

By way of making offering a typical example:  Keep this redundant text 
in the current draft.  Years from now, change the related text in RFC 
2026, in ways that are significantly different from what is in this 
current draft.  There will be no synchronization effort to ensure that 
this draft is fixed to match the new, official text, because there is no 
formal linking of the text.  Anyone reading the RFC version of this 
current draft will therefore be reading an incorrect characterization.

 > More a matter of content is Dave’s (off-list) suggestion to remove
 > section 4: That section is result of a discussion on the IETF list
 > between Sep 3 and 13 and addresses the worries about setting the bar
 > to high for publication.

My concern about section 4 is that it only serves to invite criticism of 
IETF documents.  The statements in Section 4 really apply to all 
technical specifications and all organizations that publish them.  We 
never achieve perfection and we always reserve the right to produce a 
better version.

So including text that says nothing distinctive but has language about 
likely flaws invites criticism; it mostly serves as material for those 
looking for the opportunity.

Again, my apologies for the added round of late-stage effort I've 
triggered and many thanks to Olaf et al for responding so helpfully.


Dave Crocker
Brandenburg InternetWorking