Subject: Re: [Ntp] WG Call for Adoption: draft-stenn-ntp-extension-fields

From: "[email-masked]" <[email-masked]>
Date: Thu, 26 Jul 2018 16:52:30 +0300

Aggreed the complexity and open ambiguity will create problems

Sent from my HTC, so please excuse any typos this keyboard sucks!

----- Reply message -----
From: "Daniel Franke" <[email-masked]>
To: "Karen O'Donoghue" <[email-masked]>
Cc: <[email-masked]>
Subject: [Ntp] WG Call for Adoption: draft-stenn-ntp-extension-fields
Date: Wed, Jul 25, 2018 22:37

I oppose adoption of this draft or any variant thereof; RFC 7822 should stand.

The parsing changes it proposes will make a sufficient mess of the
extension mechanism as to render it essentially unusable, and the
damage will be irreparable short of starting fresh with NTPv5 and
possibly also abandoning port 123. Creating syntactic ambiguity that
it is left to the implementation how to resolve is simply
unacceptable. It is essential to any protocol that correctly-formed
packets have exactly one possible meaning, and that incorrectly-formed
packets can be reliably rejected as such.

The added of the flag bits, in addition to obviously being
backward-incompatible (insert "flag day" pun here), make no sense
outside the context of Autokey. Other extensions have no use for them.
To the extent that Autokey relies on these flag bits for its
semantics, it can simply allocate all combinations thereof as
Autokey-related extension codes, and apply interpretation of the flags
only once the extension field has already been identified by its code
as an Autokey extension.

RFC 5906 is Informational, and Autokey is not a standard in any sense
of the word. Only the NTF implementation supports it and only the NTF
implementation ever will. Furthermore, as soon as NTS goes to the
IESG, I'm going to be submitting a
"draft-franke-ntp-autokey-diediedie" draft for WG adoption. The intent
of this draft will be to reclassify RFC 5906 as Historical, discuss
the problems with the protocol, and address the discrepancy between
the IANA EF codes and the ones used by NTF by leaving the current
registrations in place but flagging the squatted codes as Reserved so
that they will not be accidentally allocated to anything else.

So far I have not seen a call for adoption for
draft-stenn-ntp-mac-last-ef-02, but since the two drafts are
inextricably dependent on each other I will remark here that I oppose
adoption of that one as well, because the new extensions it proposes
serve no purpose when RFC 7822 is correctly followed. On the other
hand, at such time we decide to take up NTPv5 (which doesn't have to
be syntactically backward-compatible with v4 in anything after the
version field), I agree that it will then make sense to abandon the
legacy MAC field and replace it with an EF.
On Tue, Jul 24, 2018 at 10:16 PM Karen O'Donoghue <[email-masked]> wrote:
>
> Folks,
>
> As per the discussion at IETF 101 in Montreal, this email starts a WG Call for Adoption for:
> https://datatracker.ietf.org/doc/draft-stenn-ntp-extension-fields/
>
> This document has been around since Nov 2016. The intent of this document is to make changes to the extension field mechanism specified in RFC 5905 and 5906 and clarified in RFC 7822.
>
> Anyone opposed to its adoption as a working group draft please speak up by Friday 22 June.
>
> Thanks!
> Karen
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp