Re: RFC 4861 missing updated-by

[Carsten Bormann <[e-mail]>]

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

So don’t use the term “reserved” without qualification (or, better, not at all).

> fields are simply
>   noted as they are now.

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.

> 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.
The registry created for the first document that comes up may not be the right one for the second document.

(The bug here was that 4861 should have foreseen that these bits were going to be allocated.
So here, the first document would indeed simply repair that defect.
But that is not true in the general case where you have scattered random unused bits in your packet.)

> c) Additional documents cite the Registry rather that Updates.

Right.  Once you have the right structure for the registries.

Grüße, Carsten