Re: [Hipsec] regarding IANA sections in bis documents
Ben Campbell <ben@nostrum.com> Fri, 15 July 2016 07:17 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 0B1E312D8FC for <hipsec@ietfa.amsl.com>; Fri, 15 Jul 2016 00:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 fzU7yuFYtF7t for <hipsec@ietfa.amsl.com>; Fri, 15 Jul 2016 00:17:55 -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 672BA12D7EF for <hipsec@ietf.org>; Fri, 15 Jul 2016 00:17:55 -0700 (PDT)
Received: from [10.0.2.233] ([104.207.136.119]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6F7HgKr030837 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 15 Jul 2016 02:17:45 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [104.207.136.119] claimed to be [10.0.2.233]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Ben Campbell <ben@nostrum.com>
X-Mailer: iPad Mail (13F69)
In-Reply-To: <5B9D2D78-F299-4A9A-A9AF-62FB12D30777@fastmail.fm>
Date: Fri, 15 Jul 2016 09:17:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7E94AA7-1A44-4406-A4EE-1901A842EFF9@nostrum.com>
References: <alpine.LRH.2.01.1607080853140.31735@hymn01.u.washington.edu> <1D5C6666-54B6-4DFA-9E3D-D32068EF2B3C@nostrum.com> <CAE_dhjvrzMfgWRfy0jQg9XtBepT=6yMicbU5TGA2UiuVgN_b-w@mail.gmail.com> <5B9D2D78-F299-4A9A-A9AF-62FB12D30777@fastmail.fm>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/Jf9IjrelYgm-Mbplb7AOlWcWrjU>
Cc: Julien Laganier <julien.ietf@gmail.com>, HIP <hipsec@ietf.org>
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, 15 Jul 2016 07:17:57 -0000
> On Jul 15, 2016, at 8:53 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote: > > Hi Julien, > >> On 15 Jul 2016, at 02:17, Julien Laganier <julien.ietf@gmail.com> wrote: >> >> 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>. > > ... and the allocation policy. Yes, that too. > >> 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. > > Sounds good to me. Me, too. Thanks! Ben > > Thank you, > Alexey >> >> Best, >> >> --julien >> >> >> >>> On Fri, Jul 8, 2016 at 9:34 AM, Ben Campbell <ben@nostrum.com> wrote: >>> 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 >
- Re: [Hipsec] regarding IANA sections in bis docum… Ben Campbell
- [Hipsec] regarding IANA sections in bis documents Tom Henderson
- Re: [Hipsec] regarding IANA sections in bis docum… Julien Laganier
- Re: [Hipsec] regarding IANA sections in bis docum… Ben Campbell
- Re: [Hipsec] regarding IANA sections in bis docum… Alexey Melnikov
- Re: [Hipsec] regarding IANA sections in bis docum… Julien Laganier
- Re: [Hipsec] regarding IANA sections in bis docum… Terry Manderson
- Re: [Hipsec] regarding IANA sections in bis docum… Julien Laganier