Re: [Hipsec] regarding IANA sections in bis documents

"Ben Campbell" <ben@nostrum.com> Fri, 08 July 2016 16:34 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6312D0B0 for <hipsec@ietfa.amsl.com>; Fri, 8 Jul 2016 09:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 SKLh48fY6_u9 for <hipsec@ietfa.amsl.com>; Fri, 8 Jul 2016 09:34:37 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2AC0D12D0A8 for <hipsec@ietf.org>; Fri, 8 Jul 2016 09:34:30 -0700 (PDT)
Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u68GYPep047607 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 8 Jul 2016 11:34:26 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4]
From: Ben Campbell <ben@nostrum.com>
To: Tom Henderson <tomhend@u.washington.edu>
Date: Fri, 08 Jul 2016 11:34:24 -0500
Message-ID: <1D5C6666-54B6-4DFA-9E3D-D32068EF2B3C@nostrum.com>
In-Reply-To: <alpine.LRH.2.01.1607080853140.31735@hymn01.u.washington.edu>
References: <alpine.LRH.2.01.1607080853140.31735@hymn01.u.washington.edu>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/vW3__7Uj49a5iA9UStJTxLQTz2Y>
Cc: hipsec@ietf.org, aamelnikov@fastmail.fm, Julien Laganier <julien.ietf@gmail.com>
Subject: Re: [Hipsec] regarding IANA sections in bis documents
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2016 16:34:39 -0000

On 8 Jul 2016, at 10:53, Tom Henderson wrote:

>> On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov 
>> <aamelnikov@fastmail.fm> wrote:
>>> Alexey Melnikov has entered the following ballot position for
>>> draft-ietf-hip-rfc5204-bis-07: Discuss
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> The IANA considerations section does not seem to stand alone without
>>> reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't 
>>> be
>>> expected to read it in order to discover original IANA instructions.
>>> I think you should copy information from RFC 5204.
>>>
>
> On 07/08/2016 07:17 AM, Julien Laganier wrote:
>> Hi Alexey,
>>
>> The IANA Considerations used to be a copy of RFC 5204 but someone
>> asked that it be cleaned up. I will copy it back in the next 
>> revision.
>>
>> Thanks.
>>
>> --julien
>
> I was probably the person suggesting the current writeup, based on my 
> previous interaction with IANA regarding RFC 7401 publication.
>
> Before making any IANA section changes, I would like to ask for 
> further clarification, because it seems to me that the guidance being 
> given now conflicts with instructions we received from IANA when 
> revising RFC 5201 to become RFC 7401.
>
> When RFC 5201 was updated to RFC 7401, we originally followed the 
> "copy forward the IANA section" approach, but were told by IANA that 
> they preferred that we instead state the updates to be taken on 
> existing registries rather than repeating earlier actions that were 
> already taken to create the registries.

In my opinion, you need both. The text needs to make it clear what 
actions IANA needs to take _now_. But it also needs to fully document 
any registries/registrations so that other readers can find it, keeping 
in mind that an obsoleted RFC is, well, obsolete. Note that this is 
usually at least somewhat different from simply copying the old text 
forward. This is especially true when updating the reference for a 
registry or registration to point to the bis document; this only makes 
sense if the bis draft actually describes that registry or registration.

I think it's perfectly reasonable to say something of the form of 
"RFCXXXX, obsoleted by this document, made these requests of IANA: 
<old-stuff>. This document mades these additional requests: <new-stuff>"

>
> That led to the following revisions (where you can see, when using the 
> IETF rfcdiff tool, in version 14 it is a copy forward while version 15 
> it updates the existing registries):
>
> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-14.txt
> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-15.txt
>
> - Tom