Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice

Gmail <stewart.bryant@gmail.com> Sat, 04 June 2016 06:30 UTC

Return-Path: <stewart.bryant@gmail.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 787BD12B037 for <ietf@ietfa.amsl.com>; Fri, 3 Jun 2016 23:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 8OLe2jj6xF6J for <ietf@ietfa.amsl.com>; Fri, 3 Jun 2016 23:30:42 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A9A12B030 for <ietf@ietf.org>; Fri, 3 Jun 2016 23:30:42 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id a136so23024613wme.0 for <ietf@ietf.org>; Fri, 03 Jun 2016 23:30:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=uWc6thvqEuSIHSDtwnpBF6pKl6FFpfeM3FtjJ129WP8=; b=ldf6iGVaU3xee3jvlpRI4ZQLxq7Xtr7za4U7uiTwF2eZKExhwFHITW4zLuXJCf3Y0I Mv8CCIJFG0MeYxaxWmq8Q3347lb6qKOPjob6WoB6k8XFaM8kpakHGQfrQZc00RQtpaEt rXF/7anvhLTMnjhW3XdkXU2tkA/9SqvBNFXFJj3qxlCeDz+d/TI0rAfh13+J+ZwYqrm1 T0VSVWtriz9D3mcW6UgK4ktMGt5MbAbhaZgFJ9xABghF/UPSac3GcE5tqVY2cvqaCPEs dXqzr0FmshkGIexztYP0E2KYRc2bN7nyISD/Zd6V9QsRmAbHlm1/LlVHZQ339B5mGZVy Yv2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=uWc6thvqEuSIHSDtwnpBF6pKl6FFpfeM3FtjJ129WP8=; b=VM0O9qxjqwcW1z76hJdgg3Nkmfi97B6aSc0umXAcmDJPJeqRYjvZZpJpA30ME7OLPy eMYPnEeB/hVUlhgTN4F8pa5xU9PKhzYCEAqu8FnaGw2IOlhgXzYCqQ/OvZ08a5fWl0GM AXJTWJknVsGSd8tAKg0Z8MrgM5Y9A0CEwBLaogO+FLgcdUrVGtNRQUl8mliLtr0LuiDJ dqJ4c6xVQbGLNmAR5OORmvjdWFcU3mVwTZq6581xSbn3yxA4n0ZifH5z5/zX/40xN+aM 11u8mBZeq1n5SZGcmAqPktDQ0PxZXBWO0n3bjU2bZzyDUjSppv3qECAd8/3NdlLwUxwS 20tQ==
X-Gm-Message-State: ALyK8tKm4rrJ2eyAfQeFH8QcRVCE5Ox+MZWv3xLgNbx/JzAhEcGPY4Xn2DU1A7aEhYY5xA==
X-Received: by 10.28.17.3 with SMTP id 3mr2783940wmr.94.1465021840535; Fri, 03 Jun 2016 23:30:40 -0700 (PDT)
Received: from [192.168.1.106] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id o76sm2987054wme.0.2016.06.03.23.30.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2016 23:30:38 -0700 (PDT)
References: <20160419141640.31545.54742.idtracker@ietfa.amsl.com> <575185A2.70908@cs.tcd.ie> <EDA3CD0D-BDCA-4AC6-AA67-318670080338@sobco.com> <CAC4RtVBngkPc-yQ8P0qyvwsG9L4qjDMDPZ5xwa4gR84=ov4iUg@mail.gmail.com> <CAF4+nEHzvVOq_1L2ukX-OcPGkVFgR2OOD5puLMBJGif3a=Hzaw@mail.gmail.com> <CAC4RtVC6sKnYQS3mOay8-rSLQ0+U5mYGVhBbSSD=0xNX6dt2ng@mail.gmail.com> <5751D5E8.6030803@cs.tcd.ie> <CALaySJ+3jorRopPKNHjy19fo1v1=dZEHarMJ1-gB89vNbkFxaw@mail.gmail.com> <5751ED8B.4020508@isi.edu> <9b7a1b04-f767-517a-bd84-28c030695dfc@gmail.com>
In-Reply-To: <9b7a1b04-f767-517a-bd84-28c030695dfc@gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <201D5426-3064-454B-9E1F-32891715575E@gmail.com>
X-Mailer: iPad Mail (13F69)
From: Gmail <stewart.bryant@gmail.com>
Subject: Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice
Date: Sat, 4 Jun 2016 07:30:47 +0100
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Hlpyc7on9CkzEXwv8LbeItRWE3E>
Cc: Barry Leiba <barryleiba@computer.org>, IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 04 Jun 2016 06:30:44 -0000

Perhaps the registry should hold the history of the code point?

If the code point was created by RFCabc, then any equipment that correctly implemented RFCabc will always be a correct implementation of that specification, even if the definition changes as a result of RFCxyz.

This will hopefully cause Brian's programmer to look at both RFCs and if necessary ask which of these behaviours the product is supposed to implement.

Stewart

Sent from my iPad

> On 4 Jun 2016, at 00:35, Brian E Carpenter <brian.e.carpenter@gmail.com>; wrote:
> 
>> On 04/06/2016 08:50, Joe Touch wrote:
>> FWIW, IMO this is all make-work.
> 
> Disagree. Misleading pointers on the IANA site will mislead some
> junior programmer sometime in the future, by a simple application
> of Murphy's law.
> 
>> IANA pointers to the old doc should turn up "obsoleted by" notices. That
>> ought to be enough to trigger the user to follow the right path.
> 
> That's not realistic. If IANA refers to RFC822, and the programmer has a
> copy of RFC822 on her disk, that's what she will follow, because RFC text
> never changes and does not say "I am obsolete".
> 
> I'm for Barry's last proposed text.
> 
> (BTW, this could be semi-automated. It shouldn't be hard to do a scan of
> the entire IANA registry to flag obsoleted RFCs; then it's a human job to
> decide which references need to be updated.)
> 
>   Brian
> 
>> 
>> Otherwise, IMO, this doc should basically say "IANA pointers should be
>> updated as deemed useful". In some cases, there's a benefit, but not in
>> all cases. E.g., we have docs that obsolete protocols but IANA still
>> keeps a pointer to the codepoint. I don't want the new pointer to be to
>> the doc that obsoletes them; I would want the pointer to be to the
>> original spec.
>> 
>> I.e., remember that "obsoleted by" can also effectively mean "moved to
>> Historic by". I.e., nobody looking at TCP-MD5 should necessarily get the
>> RFC to TCP-AO. And there's no way to know what's in active use *somewhere*.
>> 
>> I'd prefer to trust the author to do the right thing that to engineer
>> this document with an algorithm.
>> 
>> Joe
>> 
>> On 6/3/2016 12:47 PM, Barry Leiba wrote:
>>>>> Would anyone object, and would this address your concern, Stephen, if
>>>>> I should change the text like this:
>>>>> 
>>>>> OLD
>>>>>   If information for registered items has been or is being moved to
>>>>>   other documents, then, of course, the registration information should
>>>>>   be changed to point to those other documents. In no case is it
>>>>>   reasonable to leave documentation pointers to the obsoleted document
>>>>>   for any registries or registered items that are still in current use.
>>>>> NEW
>>>>>   If information for registered items has been or is being moved to
>>>>>   other documents, then the registration information should be changed
>>>>>   to point to those other documents. In most cases, documentation
>>>>>   references should not be left pointing to the obsoleted document
>>>>>   for registries or registered items that are still in current use.
>>>>> END
>>>> That is better, but I'm still worried that it'd be used by well meaning
>>>> folk to force authors to do more work than is needed for no real gain.
>>>> 
>>>> My preferred OLD/NEW would be:
>>>> 
>>>> OLD
>>>>   If information for registered items has been or is being moved to
>>>>   other documents, then, of course, the registration information should
>>>>   be changed to point to those other documents. In no case is it
>>>>   reasonable to leave documentation pointers to the obsoleted document
>>>>   for any registries or registered items that are still in current use.
>>>> NEW
>>>>   If information for registered items has been or is being moved to
>>>>   other documents, then the registration information should be changed
>>>>   to point to those other documents. Ensuring that registry entries
>>>>   point to the most recent document as their definition is encouraged
>>>>   but not necessary as the RFC series meta-data documents the relevant
>>>>   relationships (OBSOLETED by etc) so readers will not be misled.
>>>> END
>>> Well, and *that* is so fluffy that I strongly object to it.  I think
>>> it's bizarre to directly say that it's unnecessary and you don't need
>>> to worry about it.  I can't think of any other place where we so
>>> casually accept stale references.  For example, we flag I-Ds that
>>> point to obsolete references and ask for justification to leave them
>>> in... otherwise, they're updated before or by the RFC Editor (usually
>>> before).
>>> 
>>> I think the change I've already proposed is a reasonable compromise.
>>> "In most cases" isn't "in all cases".
>>> 
>>> Barry
>