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

Donald Eastlake <d3e3e3@gmail.com> Fri, 03 June 2016 17:13 UTC

Return-Path: <d3e3e3@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 9253612D74B for <ietf@ietfa.amsl.com>; Fri, 3 Jun 2016 10:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 0oSayeOsMNfw for <ietf@ietfa.amsl.com>; Fri, 3 Jun 2016 10:13:40 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 B417F12D758 for <ietf@ietf.org>; Fri, 3 Jun 2016 10:13:40 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id j1so136482966oih.3 for <ietf@ietf.org>; Fri, 03 Jun 2016 10:13:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5LECHLyZ2zKInCR5orjZpcdzk39IxcM1bfek2SNNwGU=; b=WHltoz4BfHySEinv76kixC3AOSMz39nkW+jpNd2kD9hEycHip/R6cxAsbnPUlo5kNK iPpU3q2EcPFMnpNrht4xa4zYC3Fr8Qz5ESaAKjE7H0MJmJtMd8btZLj4Wjs3XyI4kvmn nnHC7u45owg2rRJ3/g+uz85aYAejI/wuiK4rVsQZ62QZxxzOo76zOX/3OLzmIc3/0QWm yiD2a37Rg1/XCyDPIJlI5igs9jqRJ1MPdR9JlX79pdTWog2j0+8JZf5fdhP5MV9UFoLj OLZvh4chTF5PxE/mHty1EbmReBFtqLYg8gxlJH7i+KPcthHA9XMRVlRRx59f+EAxsS+p zxCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5LECHLyZ2zKInCR5orjZpcdzk39IxcM1bfek2SNNwGU=; b=WHAr+DwqrzL4zXTld8i/7wX30A7RlvpmQ8VF2HJLs0bNACMAH0alpIwa1Dyrk1ImGP RHwNz+tA0pOtzNW1Ri3RWwxb9Et3U6WdacORY3z1U89SKIncxUQFAZbhQMS5ELs8igFh L3TeBrKwM5Gh8ZkY5m67ZqshavRJr6k7utTPJssGsnnmbSqcyh64H/7FPqxg5IGydkXH Y+j+kre+FIvMthZj31K5MyGzqeBFbQ4mj49mOTZ9lU9bR6MVKgLP2fx5PrKli+2zwp7N dWWL9vpbvRgTbL97YaQVNc3/N8K8Hxrfhr2um1fNcfbeqXeXpaiJwojl/g3jSUnryaWc +dZw==
X-Gm-Message-State: ALyK8tIBmrYGaGV0zRtO1cskQFAAyGJu26XqqsKtoWMnBFjUroh3x9xh8u4e7o/ZfKxDQkGYmVxV5WrAYe2o2A==
X-Received: by 10.202.205.23 with SMTP id d23mr2497632oig.102.1464974020072; Fri, 03 Jun 2016 10:13:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.38.66 with HTTP; Fri, 3 Jun 2016 10:13:25 -0700 (PDT)
In-Reply-To: <CAC4RtVBngkPc-yQ8P0qyvwsG9L4qjDMDPZ5xwa4gR84=ov4iUg@mail.gmail.com>
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>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 3 Jun 2016 13:13:25 -0400
Message-ID: <CAF4+nEHzvVOq_1L2ukX-OcPGkVFgR2OOD5puLMBJGif3a=Hzaw@mail.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
To: Barry Leiba <barryleiba@computer.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/4q7v9A1hPWKhrZi_GSgq3W4exN4>
Cc: 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: Fri, 03 Jun 2016 17:13:42 -0000

It is also possible that a code point is being obsoleted by an RFC bis
document but is retained in the registry, in which case you want the
reference for that value to be to the obsolete RFC where it is
specified. Also, the IANA Considerations initially creating the
registry are not normally copied forward into a bis version, although
they can. So, the answer is that it depends. The only constant
principle, I think, is that the reference(s) for the registry and for
the code points in that registry should be the best references
reasonably available...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Fri, Jun 3, 2016 at 10:31 AM, Barry Leiba <barryleiba@computer.org>; wrote:
>>> The issue iirc is that if say RFCxxxx is obsoleting RFCyyyy
>>> must the IANA considerations in RFCxxxx say that all the
>>> registries that used point at RFCyyyy need to be updated to
>>> point at RFCxxxx? I don't think that needs to be done (but
>>> it can be done). I think Barry's position, and the text of
>>> the 5226bis draft say that it has to be done.
>>
>> seems like a good make-work requirement with little actual benefit
>>
>> of course, if the details of the registry changed with the replacement
>> RFC that is a different case
>
> Well, the point is that RFCyyyy defined the BANANA option for protocol
> LMNOP, so it registered the BANANA option in the "LMNOP Options"
> registry, with a reference that points to RFCyyyy.
>
> Now we have a "yyyy-bis" that becomes RFCxxxx, and that is now the
> current definition of the BANANA option -- RFCyyyy is now obsolete.
>
> What is the point of having the reference in the registry?  If it's
> needed at all, it should be kept current.  Is it OK that it's left to
> point to the obsolete definition of the BANANA option?  Is it better
> to change it to point to the current definition in RFCxxxx?  Is it
> important to do that?  Is it necessary to do that?  What should BCP 26
> say about that?
>
> Barry
>