Re: [Hipsec] regarding IANA sections in bis documents

Julien Laganier <> Fri, 15 July 2016 01:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4020212B017 for <>; Thu, 14 Jul 2016 18:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oi6_iRDvtd9G for <>; Thu, 14 Jul 2016 18:17:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 760AA12D8B6 for <>; Thu, 14 Jul 2016 18:17:04 -0700 (PDT)
Received: by with SMTP id l65so57018024oib.1 for <>; Thu, 14 Jul 2016 18:17:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IKLtV9Z5bTzfqu57tIDoN0ZgR+K+zyQiRu4U7qib+Kw=; b=CJTdrBSAGAx4DJN3ONF1B8GlD1COK4WFTIONaWCxtO5x0N7byPjh7ypRnGcpTTjuIa j0ECEf+lFyWEu3wwe02OHM2EF115rcYe06H70LkmWyE326x09Ek9bSwNOJ4kGlAqqVqS VMlluHsR+hx0gRb1IvAugskE40yLZXtGFaAZIkkbvq8qOOk8RM3P3Rq4YpZvEgawrbsq Dxpj9xdTj4LyK5EtqgTcUYukUfHAVEoguOONI2F4vo7zhbouGPyre6AgrWdkYC7Zc+Bg M2TIEIoZ4VNPBjKpkVebpyyE+XNEJ1+d8Ri816TyARVwY0RrHYZqV7OtgWV/l+2g90NH dWqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IKLtV9Z5bTzfqu57tIDoN0ZgR+K+zyQiRu4U7qib+Kw=; b=RZDgwTwUcRQBAqA8oZCgLDBVoEXF3s7UDAzHzok/DNmN/laRkVGUFs17NrjzoRjK/K NCXnkF/+oeDWrJbjQV14Fn5K+dIUsK0AWKsIT7vL/6uoWNhu7UcT0Wg1srgbkZRstBoQ WqSXBX9Dflh9osSrod/enXNQv2OrsLvh8BHF3dbi+2GSLxeTA7KvA+bW7yVKBCfIy55y XoCwuguzRLJ0w9nf4UJt5CokN/eJF/afUyEfcEYXmHVl55m1q42C6sup5oEpzGwIBf0c 11Ibqwmz+WvXVeU/m34YO8PNd/9lxG1BUK2kasx3UwWEY0G+S6FKE7OqC7bS0WG3F1Tt l9NA==
X-Gm-Message-State: ALyK8tLbUzReP079pBEl1A4SMRipp/rKGh82oqDZYohMNxNpEITNEXFS3U8aILvLhpKlEbjEWVgyQbWDKq4aNQ==
X-Received: by with SMTP id 5mr10782094otb.184.1468545423674; Thu, 14 Jul 2016 18:17:03 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 14 Jul 2016 18:17:03 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Julien Laganier <>
Date: Thu, 14 Jul 2016 18:17:03 -0700
Message-ID: <>
To: Ben Campbell <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: HIP <>, Alexey Melnikov <>
Subject: Re: [Hipsec] regarding IANA sections in bis documents
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Jul 2016 01:17:06 -0000

Hi Ben & Alexey,

Thanks for clarifying. We've discussed your suggestion with Terry
Manderson from IANA and have agreed on proceeding as follows:

RFCXXXX, obsoleted by this document, made the following IANA
allocation in <insert registry name>: <describe existing allocations>.
IANA is requested to replace references to [RFCXXXX] by references to
this document in the the <insert existing registry name> registry.

This document also requests IANA to make these additional <describe
new allocation> in <insert existing or new registry>".

If this is okay with you both I will proceed with updating
draft-ietf-hip-rfc520{3,4,5}-bis accordingly.



On Fri, Jul 8, 2016 at 9:34 AM, Ben Campbell <> wrote:
> On 8 Jul 2016, at 10:53, Tom Henderson wrote:
>>> On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov <>
>>> wrote:
>>>> Alexey Melnikov has entered the following ballot position for
>>>> draft-ietf-hip-rfc5204-bis-07: 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):
>> - Tom