Hi Pete,
While I am responding to your note, I will capture thoughts related
to what others have said so far...
On 6/2/20 1:17 PM, Pete Resnick wrote:
> This use of the "Historic" status seems utterly bizarre to me. It's
> certainly not how it's described in 2026.
>
It is a bit strange, but was done for a reason...
> 1305 has already been obsoleted by 5905. This document simply gives
> information about what those control messages were and indicates that
> they ought no longer be used. This sounds like a fine candidate for
> Informational status. When 5905 (or it's successors) advance to
> Standard, this document can be included in the STD.
>
> If eventually you want to move a document to Historic, it would be 1305.
>
> I don't think publishing this straight to Historic makes sense.
>
There are two intents with this document.
The first is to capture mode 6 commands that were not defined within RFC
1305, Appendix B. If you compare the command sets, you will see several
additions in this draft. Several people have asked since the publication
of 5905 about some of those commands as they were not documented anywhere.
The second intent is to signal that mode 6/7 commands aren't/shouldn't
be used going forward. If you do a quick search for NTP vulnerabilities,
you will find many that relate to abuse of these commands. Additionally,
I/we received input (e.g., chronyd) no longer use these commands to
accomplish their stated function. That is where making the document
Historic seemed to make sense.
In the grand scheme of things, either Historic or Informational is a
viable document status. I (as document author) did not see consensus for
Standards Track, but that is not my call.
Regards,
Brian
Attachment:
signature.asc
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
