Re: Getting the latest version of an RFC specification
John C Klensin <john-ietf@jck.com> Wed, 29 March 2017 13:12 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B841126DD9 for <ietf@ietfa.amsl.com>; Wed, 29 Mar 2017 06:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8i9qBXqlX9t for <ietf@ietfa.amsl.com>; Wed, 29 Mar 2017 06:12:14 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9DF1294D8 for <ietf@ietf.org>; Wed, 29 Mar 2017 06:12:13 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ctDOV-000Hcz-A5; Wed, 29 Mar 2017 09:12:11 -0400
Date: Wed, 29 Mar 2017 09:12:10 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, Yoav Nir <ynir.ietf@gmail.com>
cc: IETF general list <ietf@ietf.org>
Subject: Re: Getting the latest version of an RFC specification
Message-ID: <28769B239D7982B8A4E8E932@JCK-EEE10>
In-Reply-To: <de157331-d3ff-483c-b69b-116f4d1cde0b@dcrocker.net>
References: <94f81f6a-6a34-6587-a4f7-683586c2f436@dcrocker.net> <38BC1BB4-0996-4138-BEE0-58CD4F2B867B@gmail.com> <de157331-d3ff-483c-b69b-116f4d1cde0b@dcrocker.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/csUlTstOx0_zh_iLWMdBquWEl-g>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2017 13:12:17 -0000
Dave, --On Wednesday, 29 March, 2017 07:34 -0500 Dave Crocker <dhc@dcrocker.net> wrote: > On 3/29/2017 7:19 AM, Yoav Nir wrote: >> I question how useful it is. The obsoletes/obsoletedBy >> relationship is semantically overloaded. Consider the header >> of RFC 4306: > > Yoav, > > Thanks for the thoughtful (and quick) response. Yes, the > total model and application of its details are more > complicated. But I found myself relying on a very simple > distinction: > > If someone wants to do research and explore old stuff, they > can still do that. The can still merrily wander the link > sequences. > > However "Obsoleted By" means "don't use the old stuff". Sadly, while it should, it doesn't. The community has allowed several situations to occur in which a document is obsoleted, some of its sections are not replaced with newer material, and those sections continue to be referenced, occasionally normatively, from other documents. An even more common case occurs when * RFC X is published * RFY Y is published sometime later, normatively referencing RFC X * RFC Z is published, obsoleting RFC X. It is now unclear whether, until RFC Y is replaced, whatever it specifies should be used in conjunction with the relevant parts of RFC X or with the implementer's guess as to what the specification of RFC Ybis, referencing RFC Z and modified consistently, would be. Sometime that is easy and obvious, sometimes, especially when Z changes protocol behavior or data structures from X rather than just being a clarification, it is not. To make things a bit more complicated, replacement of a document is not always one-one. We consolidate documents in updates/replacements, sometimes we split them, and more complex relationships, while not common, have happened. In some of the forking cases, we have part of RFC A replaced by RFC C and another part replaced by RFC D and, because the historical metadata doesn't make it convenient, list only C as doing the obsoleting so a simple link based on the metadata would be misleading. One can sensibly argue that we shouldn't let those kinds of entanglements happen. But it is what we do. In the extreme case, the normative reference from Y to to X should imply that the request to publish Z should go into normative reference hold in the RFC Editor queue until Ybis is ready for publication. But we don't do that. More realistically, I think the real question is "what do I need to use to properly implement this specification today?". Explorations of that question are what lead us to summary roadmap documents or associated Applicability Statements. They are also what led to to the "ISD" proposal and similar ideas, where the _standard_ (even, that WG concluded, at the Proposed level) would be a summary document independent of RFC numbers with appropriate links and, as necessary, explanation. In the past, I've argued that, if a document is published with "Obsoletes XYZ", it needs to contain a section that sorts all of those issues out. I've gotten zero traction. I fear that, unless there were a case by case analysis of each document with an "obsoletes" tag, there are enough non-obvious cases around to create significant risk that you idea would cause more harm than the added convenience it would provide. On the other hand, if the incoming IESG were convinced that this is enough of a problem, it wouldn't be hard to dig the ISD and other NEWTRK proposals up and update and re-post them. best, john
- Getting the latest version of an RFC specification Dave Crocker
- Re: Getting the latest version of an RFC specific… Yoav Nir
- Re: Getting the latest version of an RFC specific… Dave Crocker
- Re: Getting the latest version of an RFC specific… John C Klensin
- Re: Getting the latest version of an RFC specific… Dave Crocker
- Re: Getting the latest version of an RFC specific… Yoav Nir
- Re: Getting the latest version of an RFC specific… Matthew Kerwin
- Re: Getting the latest version of an RFC specific… Dave Crocker
- Re: Getting the latest version of an RFC specific… Dave Crocker
- Re: Getting the latest version of an RFC specific… Yoav Nir
- Re: Getting the latest version of an RFC specific… Yoav Nir
- Re: Getting the latest version of an RFC specific… Julian Reschke