Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
John C Klensin <john-ietf@jck.com> Sat, 24 February 2007 23:00 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL5sH-0007nr-Uo; Sat, 24 Feb 2007 18:00:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL5sG-0007nk-2k for ietf@ietf.org; Sat, 24 Feb 2007 18:00:16 -0500
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HL5sE-0001I4-LO for ietf@ietf.org; Sat, 24 Feb 2007 18:00:16 -0500
Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1HL5s5-000KeD-V0; Sat, 24 Feb 2007 18:00:06 -0500
Date: Sat, 24 Feb 2007 18:00:04 -0500
From: John C Klensin <john-ietf@jck.com>
To: Sam Hartman <hartmans-ietf@mit.edu>, "Tom.Petch" <sisyphus@dial.pipex.com>
Message-ID: <5B03ECFB5535D3618C3C2785@[192.168.1.110]>
In-Reply-To: <tsl649rtg95.fsf@cz.mit.edu>
References: <E1HI5XU-0007M1-72@stiedprstage1.ietf.org> <001401c75775$1dbd8be0$0601a8c0@pc6> <tsl649rtg95.fsf@cz.mit.edu>
X-Mailer: Mulberry/4.0.7 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: ietf <ietf@ietf.org>
Subject: Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
--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
- RE: Last Call: draft-klensin-norm-ref (Handling N… Hollenbeck, Scott
- Re: Last Call: draft-klensin-norm-ref (Handling N… Tom.Petch
- Re: Last Call: draft-klensin-norm-ref (Handling N… Sam Hartman
- Re: Last Call: draft-klensin-norm-ref (Handling N… John C Klensin
- Re: Last Call: draft-klensin-norm-ref (Handling N… Brian E Carpenter
- Re: Last Call: draft-klensin-norm-ref (Handling N… Bill Fenner
- Re: Last Call: draft-klensin-norm-ref (Handling N… Eliot Lear
- Re: Last Call: draft-klensin-norm-ref (Handling N… Brian E Carpenter
- Re: Last Call: draft-klensin-norm-ref (Handling N… Sam Hartman
- Re: Last Call: draft-klensin-norm-ref (Handling N… Tom.Petch
- Re: Last Call: draft-klensin-norm-ref (Handling N… Sam Hartman
- Re: Last Call: draft-klensin-norm-ref (Handling N… John C Klensin
- Re: Last Call: draft-klensin-norm-ref (Handling N… Tom.Petch
- Re: Last Call: draft-klensin-norm-ref (Handling N… Eric Rosen
- Re: Last Call: draft-klensin-norm-ref (Handling N… Jeffrey Hutzelman
- Re: Last Call: draft-klensin-norm-ref (Handling N… Frank Ellermann