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

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