IETF Logo Mail Archive

Re: RFC 4861 missing updated-by

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 August 2017 12:33 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 1ED6B13265D for <ipv6@ietfa.amsl.com>; Wed, 16 Aug 2017 05:33:21 -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 4Lao5GrRALQS for <ipv6@ietfa.amsl.com>; Wed, 16 Aug 2017 05:33:19 -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 CDD4E1320BE for <ipv6@ietf.org>; Wed, 16 Aug 2017 05:33:18 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 365E6E1DB for <ipv6@ietf.org>; Wed, 16 Aug 2017 08:35:56 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A3B448076D for <ipv6@ietf.org>; Wed, 16 Aug 2017 08:33:17 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6man WG <ipv6@ietf.org>
Subject: Re: RFC 4861 missing updated-by
In-Reply-To: <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org>
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>
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 08:33:17 -0400
Message-ID: <3843.1502886797@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RPNAZqo-AuaEO6rQZ7wqg6dkt4o>
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 12:33:21 -0000

Ole Troan <otroan@employees.org> wrote:
    > A reserved field is there for forward extensibility...
    > 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??

The point is that it deserves an "Updates".
Someone reason 4861 should be directed to read the update so that they see
why the reserved bits might not be zero anymore.  It might be functionality
that they actually want to implement.  Or not.


("MBZ" is the wrong sense, because it "security" devices get it wrong.
Must send as zero and ignore upon receipt is the functionality that we want.
I wish that our compliance testing suites actually checked that these
reserved fields are ignored properly)

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

v2.23.0 | Report a Bug | By Email