Subject: RE: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 16 Feb 2007 14:17:03 -0500

> -----Original Message-----
> From: The IESG [mailto:[email-masked]] 
> Sent: Friday, February 16, 2007 11:02 AM
> To: IETF-Announce
> Subject: Last Call: draft-klensin-norm-ref (Handling 
> Normative References for Standards Track Documents) to BCP 
> 
> The IESG has received a request from an individual submitter 
> to consider
> the following document:
> 
> - 'Handling Normative References for Standards Track Documents '
>    <draft-klensin-norm-ref-03.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 2007-03-16. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.

I support publishing this document as a BCP.  It became clear to me
during a recent IESG document review that more than what is specified in
RFC 3967 is needed.  The approach described in this document seems to
meet that need.  It strikes a sensible balance between the need to
recognize downrefs and the need to limit their impact on document
progression.

-Scott-

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

Date: Fri, 16 Feb 2007 14:17:03 -0500
From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Subject: RE: Last Call: draft-klensin-norm-ref (Handling Normative
	References for Standards Track Documents) to BCP 

> -----Original Message-----
> From: The IESG [mailto:[email-masked]] 
> Sent: Friday, February 16, 2007 11:02 AM
> To: IETF-Announce
> Subject: Last Call: draft-klensin-norm-ref (Handling 
> Normative References for Standards Track Documents) to BCP 
> 
> The IESG has received a request from an individual submitter 
> to consider
> the following document:
> 
> - 'Handling Normative References for Standards Track Documents '
>    <draft-klensin-norm-ref-03.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 2007-03-16. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.

I support publishing this document as a BCP.  It became clear to me
during a recent IESG document review that more than what is specified in
RFC 3967 is needed.  The approach described in this document seems to
meet that need.  It strikes a sensible balance between the need to
recognize downrefs and the need to limit their impact on document
progression.

-Scott-

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

---

From: "Tom.Petch" <[email-masked]>
Date: Fri, 23 Feb 2007 18:14:42 +0100

I have no problem with the underlying idea, in so far as I understand it, but I
do not agree that this I-D is the best way to achieve it.

I think that my problem is well illustrated by a sentence in the Abstract
' This document replaces the "hold on
   normative reference" rule will be replaced by a "note downward
   normative reference and move on" approach. '
As may be apparent, this brief - three pages plus boilerplate - I-D, aimed at
BCP status, only partly updates or replaces BCP97 (also three pages plus
boilerplate) so we will in future have to conflate two documents to understand
what is on offer.

How much simpler it would be for all wishing to use this process if we had just
one coherent document, perhaps as long as four pages, covering the whole
procedure, perhaps highlighting (for the benefit of those who in future remember
that things were once different) what was original BCP97 and what revised
BCP97.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Sent: Friday, February 16, 2007 5:02 PM
Subject: Last Call: draft-klensin-norm-ref (Handling Normative References for
Standards Track Documents) to BCP

> The IESG has received a request from an individual submitter to consider
> the following document:
>
> final comments on this action.  Please send substantive comments to the
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-klensin-norm-ref-03.txt
>
>
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14549&rf

c_flag=0
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

---

From: Sam Hartman <[email-masked]>
Date: Sat, 24 Feb 2007 16:09:10 -0500

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> I have no problem with the underlying idea, in so far as I
    Tom> understand it, but I do not agree that this I-D is the best
    Tom> way to achieve it.

    Tom> I think that my problem is well illustrated by a sentence in
    Tom> the Abstract ' This document replaces the "hold on normative
    Tom> reference" rule will be replaced by a "note downward
    Tom> normative reference and move on" approach. ' As may be
    Tom> apparent, this brief - three pages plus boilerplate - I-D,
    Tom> aimed at BCP status, only partly updates or replaces BCP97
    Tom> (also three pages plus boilerplate) so we will in future have
    Tom> to conflate two documents to understand what is on offer.

My strong preference as an individual is to approve this document as
is.  I think there's a good split between RFC 3967 and this document.
RFC 3967 will cover informational documents; this document will cover
standards track.

I'm not in principle opposed to having one document but I am opposed
to the delay it would introduce.

---

From: John C Klensin <[email-masked]>
Date: Sat, 24 Feb 2007 18:00:04 -0500

--On Saturday, February 24, 2007 4:09 PM -0500 Sam Hartman 
<[email-masked]> wrote:

>     Tom> I have no problem with the underlying idea, in so far
> as I     Tom> understand it, but I do not agree that this I-D
> is the best     Tom> way to achieve it.
>
>     Tom> I think that my problem is well illustrated by a
> sentence in     Tom> the Abstract ' This document replaces the
> "hold on normative     Tom> reference" rule will be replaced
> by a "note downward     Tom> normative reference and move on"
> approach. ' As may be     Tom> apparent, this brief - three
> pages plus boilerplate - I-D,     Tom> aimed at BCP status,
> only partly updates or replaces BCP97     Tom> (also three
> pages plus boilerplate) so we will in future have     Tom> to
> conflate two documents to understand what is on offer.
>
> My strong preference as an individual is to approve this
> document as is.  I think there's a good split between RFC 3967
> and this document. RFC 3967 will cover informational
> documents; this document will cover standards track.
>
> I'm not in principle opposed to having one document but I am
> opposed to the delay it would introduce.

Tom,

This is very much up to the IESG, but my personal opinion is 
that we are better off putting this draft through as is and then 
coming back and revisiting the situation in a year or so, once 
we have gotten some experience with the combination.  My guess 
-- harking back to the original "process experiment" theory -- 
is that some tuning is going to be needed and that there is no 
point in tangling 3967 up with the tuning process.  That 
assumption is particularly important because Sam's observation 
of 3967 for informational (and experimental) documents and this 
for standards-track is what I'm expecting too... but it is an 
assumption.  One can imagine the community responding to a 
downref under this procedure for a particular document by saying 
"just too dangerous to do it that way; let's use the 3967 
procedure in that case".   We might be willing to eliminate that 
possibility once we have some more experience, but I'd think it 
would be dangerous to do so right now.  So, for the present, we 
have this procedure for standards-track documents when it seems 
appropriate and 3967 for everything else.

In a year or two, if anyone cares, we can fold the two together 
on the basis of actual experience (or fold both into the 
long-avoided 2026bis).

    john

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Feb 2007 11:21:58 +0100

I believe that if we follow the authors' suggestion
to proceed rapidly, Tom's concern could be met by
a simple informational note summarizing how to deal
with downrefs in practice. Such a note could be input to
an eventual combined document after some experience,
as John suggests.

     Brian

On 2007-02-25 00:00, John C Klensin wrote:
> This is very much up to the IESG, but my personal opinion is that we are 
> better off putting this draft through as is and then coming back and 
> revisiting the situation in a year or so, once we have gotten some 
> experience with the combination.  My guess -- harking back to the 
> original "process experiment" theory -- is that some tuning is going to 
> be needed and that there is no point in tangling 3967 up with the tuning 
> process.  That assumption is particularly important because Sam's 
> observation of 3967 for informational (and experimental) documents and 
> this for standards-track is what I'm expecting too... but it is an 
> assumption.  One can imagine the community responding to a downref under 
> this procedure for a particular document by saying "just too dangerous 
> to do it that way; let's use the 3967 procedure in that case".   We 
> might be willing to eliminate that possibility once we have some more 
> experience, but I'd think it would be dangerous to do so right now.  So, 
> for the present, we have this procedure for standards-track documents 
> when it seems appropriate and 3967 for everything else.
> 
> In a year or two, if anyone cares, we can fold the two together on the 
> basis of actual experience (or fold both into the long-avoided 2026bis).
> 
>    john
> 
>

---

From: "Bill Fenner" <[email-masked]>
Date: Sun, 25 Feb 2007 21:13:49 -0800

On 2/24/07, Sam Hartman <[email-masked]> wrote:
> I think there's a good split between RFC 3967 and this document.

I have to admit that when I was reading this document I was confused
by section 4; I thought for a while that the draft-klensin-norm-ref
rules could be applied to informational references, but then the first
paragraph of section 5 says it can't.  It took me a while to
understand that section 4 actually refers to annotating downrefs
approved under the existing rules.

  Bill

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Feb 2007 07:51:05 +0100

> to the delay it would introduce.

It's not just one more document.  We're working on at least a dozen, 
starting with RFC 2026, going on to various "IOPs", the boiler plate 
documents, IESG sponsorship documents, IRTF rules, and more.  One has to 
be an Internet lawyer to understand the system.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Feb 2007 14:13:14 +0100

> be an Internet lawyer to understand the system.

Which is why we have the Tao and
http://www.ietf.org/IESG/content/ions/ion-procdocs.html

    Brian

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Feb 2007 10:27:41 -0500

>>>>> "Bill" == Bill Fenner <[email-masked]> writes:

    Bill> On 2/24/07, Sam Hartman <[email-masked]> wrote:
    >> I think there's a good split between RFC 3967 and this
    >> document.  RFC 3967 will cover informational documents; this
    >> document will cover standards track.

    Bill> I have to admit that when I was reading this document I was
    Bill> confused by section 4; I thought for a while that the
    Bill> draft-klensin-norm-ref rules could be applied to
    Bill> informational references, but then the first paragraph of
    Bill> section 5 says it can't.  It took me a while to understand
    Bill> that section 4 actually refers to annotating downrefs
    Bill> approved under the existing rules.

Clarifications small enough that they do not require a new last call
are very welcome.

---

From: "Tom.Petch" <[email-masked]>
Date: Mon, 26 Feb 2007 18:12:44 +0100

<inline>
Tom Petch

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: "Sam Hartman" <[email-masked]>; "Tom.Petch" <[email-masked]>
Cc: "ietf" <[email-masked]>
Sent: Sunday, February 25, 2007 12:00 AM
Subject: Re: Last Call: draft-klensin-norm-ref (Handling Normative References
for Standards Track Documents) to BCP
> In a year or two, if anyone cares,

I care:-(

I care because I already have a corpus of 47 documents which provide
(incomplete) procedures, rules or guidance on how to get something to be an RFC,
and regard that as too many, perhaps an order of magnitude so(**).

Until RFC3967 is rewritten, or, better still, RFC2026, there will be nothing
in RFC3967 to show which parts remain current and, as this I-D stands, there is
nothing in the title or abstract to say that either.  I have to get into the
Introduction
before I read
" This document replaces the long-standing rule for downward references
   to standards-track documents (including BCPs) that are already
   published."
and even that I had to read several times before I thought I understand it ie
that this I-D is about references from any type of document to a Standards Track
document.

This should be made clear in the Abstract and, I think, in the title eg .

" Handling Normative References to Standards Track Documents"
instead of
 "Handling Normative References for Standards Track Documents"

Tom Petch

** In a well-established mailing list recently, a debate arose over the need to
rewrite code if IANA did not allocate the same code point as the editor of the
I-D had taken upon themselves to allocate; it would seem an entire WG is
unfamiliar with RFC4020; but then again, why should they be?  There is an ever
increasing number of documents in various categories and only a process geek
could hope to know them all (and I would regard process geekery as a
pre-requisite for the task of RFC Editor:-).

we can fold the two together

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Feb 2007 13:45:10 -0500

I'd be happy with this title change.  Does anyone object?

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Feb 2007 14:54:18 -0500

> I'd be happy with this title change.  Does anyone object?

No.

And, while I sympathize with the problem Tom discusses, the
solution lies, IMO, in at least a 2026 replacement and probably
some rethinking of the standards process, not in tuning this
document or its direct predecessor.   I proposed just such a
rethinking with ISDs, which would have made this whole
conversation irrelevant, but have been convinced to go out of
that business.

    john

---

From: "Tom.Petch" <[email-masked]>
Date: Wed, 28 Feb 2007 20:18:00 +0100

----- Original Message -----
From: "Sam Hartman" <[email-masked]>
To: "Tom.Petch" <[email-masked]>
Cc: "ietf" <[email-masked]>
Sent: Saturday, February 24, 2007 10:09 PM
Subject: Re: Last Call: draft-klensin-norm-ref (Handling Normative References
> RFC 3967 will cover informational documents; this document will cover

In which case, this should be clear from the Abstract and I do not think that
that is currently the case.  I suggest replacing

"This document replaces the "hold on
   normative reference" rule will be replaced by a "note downward
   normative reference and move on" approach.  RFC 3967 is also updated
   to encourage annotations to be added when that procedure is applied."

with

"This document describes a simpler procedure for downward references to
Standards track and BCP documents, namely "note and move on".  The procedure in
RFC3967 still applies for downward references to other classes of document.  In
both cases, annotations should be added to such References."

Tom Petch

---

From: Eric Rosen <[email-masked]>
Date: Wed, 28 Feb 2007 15:56:44 -0500

This document has a reasonable goal, but the implementation is objectionable.

The reasonable goal (from the introduction): 

    This document replaces the "hold on normative reference" rule with a
    "note downward normative reference and move on" approach for
    normative references to standards-track documents and BCPs.

The objectionable implementation: 

      A note is included in the reference text that indicates that the
      reference is to a target document of a lower maturity level, that
      some caution should be used since it may be less stable than the
      document from which it is being referenced

In many  cases (probably  the vast majority)  where a document  is advancing
despite a "downward normative reference", the referenced document (and the
technology  described  therein)  is  no  less stable  than  the  referencing
document, and  no "caution" is required.  It's  great to be able  to "make a
downward reference and move on", but  we should not be required to tell lies
and spread FUD.  

An acceptable implementation would be: 

      A note is included in the reference text that indicates that the
      reference is to a target document which is at a prior step in the
      official IETF standardization process.

That statement adequately captures the facts, and does not require the WG to
make dishonest statements or to spread FUD.

Another alternative, probably a better one, is simply to annotate each
reference with its standards status, and make no editorial comment about it
at all.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Feb 2007 16:10:13 -0500

On Wednesday, February 28, 2007 03:56:44 PM -0500 Eric Rosen 
<[email-masked]> wrote:

> In many  cases (probably  the vast majority)  where a document  is
> advancing despite a "downward normative reference", the referenced
> document (and the technology  described  therein)  is  no  less stable
> than  the  referencing document, and  no "caution" is required.  It's
> great to be able  to "make a downward reference and move on", but  we
> should not be required to tell lies and spread FUD.

Inflammatory language aside, I agree.

> reference with its standards status, and make no editorial comment about
> it at all.

This sounds like a fine approach to me, for cases where in fact no special 
caution is required.  For the remaining cases, someone can always object to 
approving the document on the basis of an unstable downref and/or ask that 
a warning be inserted.  On the other hand, I don't think any change to the 
document is needed to achieve this.  The next two paragraphs after the one 
you quote say:

   The IESG may, at its discretion, specify the exact text to be used,
   establish procedures regarding the text to use, or give guidance on
   this text.  When establishing procedures the IESG should seek
   appropriate community review.

   These annotations are part of the source document.  If members of the
   community consider either the downward reference or the annotation
   text to be inappropriate, those issues can be raised at any time in
   the document life cycle, just as with any other text in the document.
   There is no separate review on these references.

Also, while I don't think the document necessarily needs to be changed to 
REQUIRE this, I think it would be good if last call announcements continued 
to call out normative downrefs, for two reasons:

(1) To make it easier to catch potentially problematic downrefs
(2) To encourage the advancement of frequently-referenced documents
    along the standards track.

-- Jeff