IETF Logo Mail Archive

Re: RFC 4861 missing updated-by

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 15 August 2017 21:33 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 3E084132428 for <ipv6@ietfa.amsl.com>; Tue, 15 Aug 2017 14:33:14 -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 r7gv7mknfm8Q for <ipv6@ietfa.amsl.com>; Tue, 15 Aug 2017 14:33:12 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 2563613219E for <ipv6@ietf.org>; Tue, 15 Aug 2017 14:33:12 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id F1453AF; Tue, 15 Aug 2017 23:33:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502832789; bh=Iv6HT722b8Lp9lwnJMw4xhxAUCv4HxyVkTJlhRKLQ2g=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=iwJSvAYeLtX3frjTevhp6j6BAqEKLI0KohdCIWGb1J1ChljP5vEm92P6Qky54gXo9 dOmF1NU7vHsXIpTL+WA4BZkZvEJY1CoJ4/zMIgj0/IcCF9tTuNk2zM7tMKhhF5tW6B lo0P3I/1mHwfBm6rsFs7ldNP+24f/X5Q3TGp0JuY=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EE9EE84; Tue, 15 Aug 2017 23:33:09 +0200 (CEST)
Date: Tue, 15 Aug 2017 23:33:09 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ole Troan <otroan@employees.org>
cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
Subject: Re: RFC 4861 missing updated-by
In-Reply-To: <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org>
Message-ID: <alpine.DEB.2.20.1708152330150.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> <F7C3A4FB-24A4-4A94-9262-FC4C1BF302B7@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@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/P9FDaAwki6BKcPlrR2vOXp8S0w0>
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 21:33:14 -0000

On Tue, 15 Aug 2017, Ole Troan wrote:

> How can using that extensibility (which as you state is specified as MBZ 
> specifically to be forward compatible) be a substantive change to the 
> RFC that reserved it??

Because the reserved bits are no longer reserved if another RFC now says 
they're used for something.

So for this I-D you wanted me to write. Is the request to IANA to go over 
4861 and create registries for all bit fields? What other RFCs should we 
include in this request?

Because if someone (I don't know who, IETF leadership?) has decided that 
"taking" bits is not an substantitive change to an RFC and that there 
should be no metadata updates when reserved bits are "taken", then the 
IANA registry is crucial for all bit fields, not just the PIO bits I was 
talking about here.

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

v2.23.0 | Report a Bug | By Email