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

["Tom.Petch" <[e-mail]>]

<inline>
Tom Petch

----- Original Message -----
From: "John C Klensin" <[e-mail]>
To: "Sam Hartman" <[e-mail]>; "Tom.Petch" <[e-mail]>
Cc: "ietf" <[e-mail]>
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
> <[e-mail]> wrote:
>
> >>>>>> "Tom" == Tom Petch <[e-mail]> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf