IETF Logo Mail Archive

Re: RFC 4861 missing updated-by

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 August 2017 21:38 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA88132744 for <ipv6@ietfa.amsl.com>; Wed, 16 Aug 2017 14:38:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 Ncr6ojdkZ7ZC for <ipv6@ietfa.amsl.com>; Wed, 16 Aug 2017 14:38:05 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586BF132742 for <ipv6@ietf.org>; Wed, 16 Aug 2017 14:38:02 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 54FFF20599; Wed, 16 Aug 2017 17:40:41 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7D4A58076D; Wed, 16 Aug 2017 17:38:01 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Subject: Re: RFC 4861 missing updated-by
In-Reply-To: <alpine.DEB.2.20.1708151234491.3655@uplift.swm.pp.se>
References: <alpine.DEB.2.02.1708100947130.2261@uplift.swm.pp.se> <8447.1502388439@obiwan.sandelman.ca> <a3ed97e2-e907-6a20-0d00-6de532784f0c@nostrum.com> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <alpine.DEB.2.02.1708110743410.2261@uplift.swm.pp.se> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <alpine.DEB.2.20.1708130754510.3655@uplift.swm.pp.se> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <alpine.DEB.2.20.1708151234491.3655@uplift.swm.pp.se>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 16 Aug 2017 17:38:01 -0400
Message-ID: <4864.1502919481@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/23E75l0W8_yYVlgKRoRFmADSukQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Aug 2017 21:38:07 -0000

Mikael Abrahamsson <swmike@swm.pp.se> wrote:
    >> I don't think adding a new flag in a "Reserved" field qualifies as
    >> updating an RFC.
    >> That's what we have IANA registries for.

    > So where is the IANA registry for the bit fields that RFC4861
    > standardises?

Right. So either way, 4861 has errata.
Either it's missing a registry, or it's missing a forward reference :-)

    > 1. If you move reserved bits to in-use, you update the original RFC that
    > defined these bits as reserved. Metadata is added to the original RFC
    > so this can be found.

    > 2. There must be IANA registries for all bit fields, and if you change
    > reserved bits to in-use, this must be reflected in the IANA registry.

I suggest the following policy, and maybe I'm signing up to write a BCP here.

a) Reserved, (Send as zero, do not examine on receive) fields are simply
   noted as they are now.

b) The first document to do anything with that Reserved area, if it's creating
   new bits, or putting some new field there, Updates the original document,
   and creates the IANA Registry.

c) Additional documents cite the Registry rather that Updates.

Ole, could you get on board with that?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email