RE: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
> -Original Message- > From: The IESG [mailto:[EMAIL PROTECTED] > 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 ' > 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@ietf.org mailing lists by 2007-03-16. Exceptionally, > comments may be sent to iesg@ietf.org 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
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 PROTECTED]> To: "IETF-Announce" 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: > > - 'Handling Normative References for Standards Track Documents ' > 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@ietf.org mailing lists by 2007-03-16. Exceptionally, > comments may be sent to iesg@ietf.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-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 > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
> "Tom" == Tom Petch <[EMAIL PROTECTED]> 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
--On Saturday, February 24, 2007 4:09 PM -0500 Sam Hartman <[EMAIL PROTECTED]> wrote: "Tom" == Tom Petch <[EMAIL PROTECTED]> 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
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: --On Saturday, February 24, 2007 4:09 PM -0500 Sam Hartman <[EMAIL PROTECTED]> wrote: "Tom" == Tom Petch <[EMAIL PROTECTED]> 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
On 2/24/07, Sam Hartman <[EMAIL PROTECTED]> 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
Sam Hartman wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
On 2007-02-26 07:51, Eliot Lear wrote: Sam Hartman wrote: 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. 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. Which is why we have the Tao and http://www.ietf.org/IESG/content/ions/ion-procdocs.html Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
> "Bill" == Bill Fenner <[EMAIL PROTECTED]> writes: Bill> On 2/24/07, Sam Hartman <[EMAIL PROTECTED]> 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
Tom Petch - Original Message - From: "John C Klensin" <[EMAIL PROTECTED]> To: "Sam Hartman" <[EMAIL PROTECTED]>; "Tom.Petch" <[EMAIL PROTECTED]> Cc: "ietf" 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 > > --On Saturday, February 24, 2007 4:09 PM -0500 Sam Hartman > <[EMAIL PROTECTED]> wrote: > > >>>>>> "Tom" == Tom Petch <[EMAIL PROTECTED]> 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. > > 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, 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 > on the basis of actual experience (or fold both into the > long-avoided 2026bis). > > john > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
I'd be happy with this title change. Does anyone object? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
--On Monday, 26 February, 2007 13:45 -0500 Sam Hartman <[EMAIL PROTECTED]> wrote: > 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
- Original Message - From: "Sam Hartman" <[EMAIL PROTECTED]> To: "Tom.Petch" <[EMAIL PROTECTED]> Cc: "ietf" Sent: Saturday, February 24, 2007 10:09 PM Subject: Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP > > 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. > 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
On Wednesday, February 28, 2007 03:56:44 PM -0500 Eric Rosen <[EMAIL PROTECTED]> 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
Jeffrey Hutzelman wrote: > 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. Yes. For your 2nd goal maybe some of Bill's cute scripts could help to identify "popular" standard tracks documents. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
