[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: RFC 4861 missing updated-by
From:       Michael Richardson <mcr+ietf () sandelman ! ca>
Date:       2017-08-17 2:34:58
Message-ID: 7409.1502937298 () obiwan ! sandelman ! ca
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Carsten Bormann <cabo@tzi.org> wrote:
    >> 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)

    > If you think that is what "Reserved" means, more power to you, but a
    > rather common understanding of "Reserved" is "We may define those bits
    > later", with the implied conclusion that a receiving implementation
    > simply gives up and croaks when finding a reserved bit set.

https://tools.ietf.org/html/rfc6709#section-4.2

says exactly that.

    > Having these "could be used later for extension points" bits in a
    > protocol is fine, even without a registry, because you cannot define
    > the registry if you don't know what the structure of these bits is
    > going to be.

Exactly.

    >> 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.

    > Well, any document that starts eating bits for extension points needs
    > to do that.

yes, but in this case, it didn't.

    > The registry created for the first document that comes up may not be
    > the right one for the second document.

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




["signature.asc" (application/pgp-signature)]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]