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

[Brian E Carpenter <brc at zurich.ibm.com>]

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 
> <hartmans-ietf at mit.edu> wrote:
>
> > > > > > > "Tom" == Tom Petch <sisyphus at dial.pipex.com> 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 at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf