Re: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries

[Harlan Stenn <[e-mail]>]

Hi Heiko,

On 8/14/2022 11:59 PM, Heiko Gerstung wrote:
> Hi all,
> 
> quick idea (I know! Those are the best ;-) ..
> Would it be possible to define mode 7 = version specific? This way all V4 Mode 7 packets would continue to work, and for V5 we could  introduce an additional field in the header that allows for more "modes" (i.e. packet types) in addition to the ones currently defined (and RFC5905 specifies mode 7 = reserved).

Mode 7 is already "vendor specific" control packets.

 From Dave's POV, mode 6 contained ASCII data, and mode 7 contained 
binary data.

We already have a problem with "shifting sands" and both mode 6 and mode 7.

I've long had an item on my TODO list that would let us "figure out" 
what command set (for lack of a better word) was supported by v6 and v7.

I believe your intent could also be satisfied with our I-DO EF proposal.

I do kinda like that mode 7 is vendor-specific commands.  It leaves a 
way to do things that stay out of the way of mode 6 commands (which are 
expected to be "general").

I also think we would benefit from put time and effort into fleshing out 
mode 6 commands, and I believe that is an area where we would also want 
version-specific commands, which would also imply experimental and 
vendor-specific values.

We have choices here, and it's not clear to me where it's safe to change 
things up, and where we need to be more careful.

It may well be that we would reserve one or more of the current mode 6 
opcodes to "extend" things, but it's also not yet clear to me that we 
might need this.  The current opcode list seems pretty complete, and 
only half of the 32 opcodes are currently assigned.

I think draft-ietf-ntp-mode-6-cmds needs additional work, but do enough 
folks here care enough about it?

> Most things in the wild would not try to decode and (mis)understand such a packet. With this approach we could avoid that a V5 request (with a different packet format) is misunderstood by a V4 server for example (because V5 would always use Mode = 7 and distinguish between client requests, server responses etc. etc. by using a new field - this way we could increase the number of potential packet types and more easily introduce new ones without the risk of breaking an older version implementation misunderstanding a packet).
> 
> Best Regards,
>    Heiko
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!