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

>>> Harlan Stenn <stenn@nwtime.org> schrieb am 24.08.2020 um 13:41 in
Nachricht
<ce2502e7-affa-5c38-6d18-69489f759e91@nwtime.org>:

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

Hi!

it's about "Mode 7 is for vendor-specific operations.". I read it that
different implementation may use mode-7 to implement arbitrary protocols with
that, while currently there's (AFAIK) exactly one "vendor" that had an
implementation. So not to make matters worse, I'd make this obsolete now,
allowing to redefince that in a useful way later for NTP version 6 or so.

Regards,
Ulrich

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