IETF Logo Mail Archive

Re: RFC 4861 missing updated-by

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 15 August 2017 10:41 UTC

Return-Path: <swmike@swm.pp.se>
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 D8420132026 for <ipv6@ietfa.amsl.com>; Tue, 15 Aug 2017 03:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 LaSZUM0JIAw6 for <ipv6@ietfa.amsl.com>; Tue, 15 Aug 2017 03:41:30 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF89B120721 for <ipv6@ietf.org>; Tue, 15 Aug 2017 03:41:30 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 79A72AF; Tue, 15 Aug 2017 12:41:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502793687; bh=KlmPuk5Eo+qNraWL870aO+bblAzOBNTsSpM+vhLJzOc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TdipqCeu1XLY8TbAfJfus/UYeLjVvalbqS6NdRMumYWmj6JQ1aow0FHSQ0qnTeRj5 3LI82wzVGuTl+Sp3VqMz9tn/WCV6E0iGG9RmRbO+mT01/C7keSy4zyAvwPbAp5R/2y Y1xYJh3SHzVm6gjVjn1d5AantOtNa5zMT7FcMYCI=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 74F8484; Tue, 15 Aug 2017 12:41:27 +0200 (CEST)
Date: Tue, 15 Aug 2017 12:41:27 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ole Troan <otroan@employees.org>
cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
Subject: Re: RFC 4861 missing updated-by
In-Reply-To: <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org>
Message-ID: <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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/dtnJl13MFxnbsUSP01rz_VnH5HI>
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: Tue, 15 Aug 2017 10:41:33 -0000

On Tue, 15 Aug 2017, Ole Troan 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?

Or so say it another way:

If I want to use a new bit field that for instance RFC4861 specifies, how 
am I going to find what other RFCs has touched this, if there is no IANA 
registry (as far as I know there isn't, I can't find one).

Someone (IETF leadership) has to put their foot down and say one of two 
things (or something completely different):

1. If you move reserved bits to in-sure, 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.

The way we do things now by not having IANA registries and not updating 
RFCs when changing reserved bits to in-use is extremely prone to mistakes. 
We missed this completely when we wrote PIO-X and it was caught because 
someone happened to notice it and who was into MIPv6.

Or what am I missing?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email