On 6/13/2020 9:10 PM, Karen O'Donoghue wrote:
> Folks,
>
> All of this was discussed during the development of this document. There was strong working group consensus to not publish as Standards Track.
I recall discussion about this in the WG meetings I attended.
Was the "final" decision made at the WG meeting I was unable to attend,
the meeting where all of the other proposals I had in various stages of
adoption were ... removed from consideration by the WG?
> As described, there were concerns about the solution.
I don't know what you mean by "the solution" - please clarify?
I also don't know what these "concerns" are. Please clarify.
> The working group has gone back and forth between historic and informational.
It should be Standards track, and optional implementation.
H
--
> Regards,
> Karen
>
>> On Jun 13, 2020, at 8:27 PM, Harlan Stenn <stenn@xxxxxxxxxx> wrote:
>>
>> On 6/13/2020 11:15 AM, Brian Haberman wrote:
>>> Thanks for the review, Daniel. A quick follow-up below for those of you
>>> playing along at home...
>>>
>>>> On 6/13/20 11:18 AM, Daniel Franke via Datatracker wrote:
>>>> Reviewer: Daniel Franke
>>>> Review result: Ready
>>>>
>>>> I have reviewed this document as part of the security directorate's ongoing
>>>> effort to review all IETF documents being processed by the IESG. These
>>>> comments were written with the intent of improving security requirements and
>>>> considerations in IETF drafts. Comments not addressed in last call may be
>>>> included in AD reviews during the IESG review. Document editors and WG chairs
>>>> should treat these comments just like any other last call comments.
>>>>
>>>> This document describes a historic protocol whose design falls far short of
>>>> modern IETF standards. Its myriad issues are well-described in the Security
>>>> Considerations section.
>>>>
>>>> There has been some debate as to whether the appropriate status for this
>>>> document is Historic or Informational. I believe the currently-intended
>>>> Historic status is more appropriate. The argument I have heard repeatedly in
>>>> favor of Informational status is that it is not appropriate to classify a
>>>> protocol as Historic until a better alternative exists with a published
>>>> specification. I believe that better alternative exists, which is to have no
>>>> standard at all. It's perfectly fine for NTP monitoring and management
>>>> protocols to be vendor-specific. In virtually all legitimate uses ("legitimate"
>>>> so as to exclude RDoS attacks), both sides of the protocol run on systems
>>>> managed by the same organization and the need for vendor-specific tools is not
>>>> a practical issue. Lack of standardization is the already the status quo, since
>>>> there are many widely-used NTP implementations out there but only the Network
>>>> Time Foundation implementation and its derivatives (such as NTPsec) support
>>>> this protocol. I know of nobody who has ever been inconvenienced by this;
>>>> standardization is a solution in search of a problem.
>>>>
>>>>
>>>
>>> Interestingly enough, RFC 1305 actually says this...
>>>
>>> "Ordinarily, these functions can be implemented using a
>>> network-management protocol such as SNMP and suitable extensions to the
>>> MIB database. However, in those cases where such facilities are not
>>> available, these functions can be implemented using special NTP control
>>> messages described herein."
>>
>> Why is RFC 1305 even being brought up in this situation?
>>
>> NTPv3 was updated to NTPv4.
>>
>> During that update, mode 6 and mode 7 were inadvertently not included.
>>
>> RFC 5905 was developed, as was 5906 and 5907. But mode 6 is still in
>> active use and deserves a proper, updated specification.
>>
>>> SNMP exists and the NTP WG published RFC 5907 to cover the MIB support
>>> needed by NTP. I believe that also counts as a better alternative.
>>
>> Unbelievable.
>>
>> TTBOMK, the only implementation of 5907 is the one in the reference
>> implementation, and in the 12 years it has been out there we have had NO
>> reports of it being used. Furthermore, it was implemented USING MODE 6
>> PACKETS!
>>
>> The only known SNMP interface to ntpd, ntpsnmpd has not seen significant
>> updates since 2010.
>>
>> The mode 6 interface to ntpd, ntpq, remains in continuous development
>> and evolution.
>>
>> Please identify any other implementations of 5907. If you find any, how
>> significant are they? Are they proprietary 5907 implementations? What
>> implementations to they work on?
>>
>> Please show how SNMP is a better way to monitor and control NTP than ntpq.
>>
>> Please show me a working deployment of SNMP controlling NTP, and then
>> please compare the number and quality of these deployments with those
>> that do the same with ntpq.
>>
>>> Regards,
>>> Brian
>>>
>>>
>>> _______________________________________________
>>> ntp mailing list
>>> ntp@xxxxxxxx
>>> https://www.ietf.org/mailman/listinfo/ntp
>>>
>>
>> --
>> Harlan Stenn <stenn@xxxxxxxxxx>
>> http://networktimefoundation.org - be a member!
>>
>> _______________________________________________
>> ntp mailing list
>> ntp@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/ntp
>
--
Harlan Stenn <stenn@xxxxxxxxxx>
http://networktimefoundation.org - be a member!
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
