Re: [Ntp] Antw: Re: Antw: [EXT] Éric Vyncke's No Objection on draft-ietf-ntp-mode-6-cmds-09: (with COMMENT)

On 8/24/2020 3:34 AM, Ulrich Windl wrote:
>>>> Harlan Stenn <stenn@nwtime.org> schrieb am 24.08.2020 um 10:52 in
> Nachricht
> <d3ea413d-c2f6-3168-cfba-54f5a27a2b22@nwtime.org>:
>> On 8/23/2020 10:52 PM, Ulrich Windl wrote:
>>>>>> Éric Vyncke via Datatracker <noreply@ietf.org> schrieb am 21.08.2020 um
>>> 16:32
>>> in Nachricht <159802037308.10371.11780852739141456472@ietfa.amsl.com>:
>>> ...
>>>>
>>>> -- Appendix A --
>>>> Is there a reason why the mode 7 is in the appendix and not in the main
> body
>>>
>>>> ?
>>>
>>> Because it's a different (and really obsolete) protocol. At least per
>>> specification, maybe not by implementation.
>>
>> No, it is not obsolete.  Mode 7 is for vendor-specific operations.
> 
> You mean mode 7 has been "reassigned"? Otherwise you contradict to what you
> were postulating many times before.
> It seems I don't quite understand: If leaving mode-7 to solely
> vendor-implementation, there will be a true protocol mess.
> At least some framework to implement vendor-specific operations is needed
> IMHO.
> So a server would hopefully recognize at least that it does not understand the
> command being received and return an error message that the client can
> decode...

Sorry, Ulrich - I don't know what you're talking about.

Mode 6 has always been "control mode", and has been expected to have
standard/common assignments.  I believe the document could/should cover
more than it does, just like I expect a lot more from the NTP Yang Data
Model document.  I continue to believe that there needs to be a
standardized way to exchange minimally-expected "control mode" data with
an NTP server via mode 6, and there needs to be a good way for
implementations to augment the minimal set of mode 6 subcommands.

Mode 7 has always been "private mode", and is expected to be
vendor/implementation specific.

This is all described in RFC-1305, Appendix D, section 2.

The document we're talking about here is the WG's attempt to fix at
least the oversight of 5905 not talking about mode 6.

Folks should be able to infer the NTP Project's position of this
document by my vote on the document.

With regard to mode 7, I'm not aware of any attempts by the WG to
document anything beyond what RFC5905 contains in 7.3 Packet Header
Variables beyond that in Figure 10, Association Modes, and given that
mode 7 is "reserved for private use", I'm not sure what anybody might
want for that.  Mode 7 has and continues to be a control message for
vendor/implementation specific use.

>>
>> It is there to carve a space for implementation/vendor-specific stuff.
>>
>> -- 
>> Harlan Stenn <stenn@nwtime.org>
>> http://networktimefoundation.org - be a member!
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!