IETF Logo Mail Archive

Re: RFC 4861 missing updated-by

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 August 2017 12:35 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 8569F1326AF for <ipv6@ietfa.amsl.com>; Wed, 16 Aug 2017 05:35:55 -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 YQEDf_DfRVZb for <ipv6@ietfa.amsl.com>; Wed, 16 Aug 2017 05:35:54 -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 487931326AE for <ipv6@ietf.org>; Wed, 16 Aug 2017 05:35:54 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2494AE1DB; Wed, 16 Aug 2017 08:38:32 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8B0228076D; Wed, 16 Aug 2017 08:35:53 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Mikael Abrahamsson <swmike@swm.pp.se>
cc: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Subject: Re: RFC 4861 missing updated-by
In-Reply-To: <alpine.DEB.2.20.1708161041140.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> <alpine.DEB.2.20.1708152330150.3655@uplift.swm.pp.se> <D3A540FC-E197-41D1-B3FB-B8CB530EB152@employees.org> <alpine.DEB.2.20.1708160721130.3655@uplift.swm.pp.se> <B31EA17B-E431-4892-87DE-AE665D04E024@employees.org> <alpine.DEB.2.20.1708161041140.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 08:35:53 -0400
Message-ID: <4454.1502886953@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/3cRs9GFMfc3gO1w0K_j-S1Tt8sQ>
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:35:55 -0000

Mikael Abrahamsson <swmike@swm.pp.se> wrote:
    >> If an 4861 implementation is not affected by the other specification (6275)
    >> then I think using update is wrong. (I don't think you should make too many
    >> assumptions about the level of darkness that implementors live in...)

    > I still think there should be some kind of forward reference to the document
    > that has assigned or changed bits. If we can't use updated-by, then we need
    > to invent some other kind of reference.

+1.
I don't care how we cause the forward references to be created, but they need
to be created.  Updates: is appropriate.  6275 may not FORCE an 4861
implementation to change, but a 4861 implementation might WANT to change.


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

v2.23.0 | Report a Bug | By Email