Re: [Ntp] I-D Action: draft-ietf-ntp-update-registries-09.txt

[Danny Mayer <[e-mail]>]

Sorry for no responding sooner.

On 12/3/23 7:57 PM, Hal Murray wrote:
> [e-mail] said:
>> Is it an extension or is the digest?  Looking at figure 8, for example, where
>> does it appear?  The text says it's a normal "section 8" (heh) packet, but
>> are all the fields present?
> It's not an extension.
RFC 5905 doesn't call it an extension field. However it has all of the 
characteristics of an extension with an ID of 0 and the length of the 
extension is 0 which matches. So I am suggesting that in the registry we 
call the extension with the ID of 0 to be a crypto-NAK extension field. 
Nothing else should use it.
>
>> I'm trying to figure out how to explain it since what you're proposing is
>> different from how I read the RFC.
> It's a non-extension.  I don't think you want to explain it.
See above. It has all of the characteristics of an extension field.
>
> You should probably add a paragraph pointing out that RFC 5905 describes a packet format that has a key ID word with a 32 bit field where the type field and length for extensions would go -- with a reference to RFC 7882.
I think you mean RFC 7822 but that's not relevant here.
> Can that paragraph be added to the IANA registry?
>
> This paragraph from your draft should also be added to the IANA registry:
>
>    *The "Reserved for historic reasons" is for differences between
>    the original documentation and implementation of Autokey and
>    marks the erroneous values as reserved, in case there is an
>    implementation that used the registered values instead of what
>    the original implementation used.
>
> Would it be appropriate to add an * to those slots?

Yes, that's probably necessary.

Danny