If issue is backward compatibility I will prove it, if new extensions Field type is not conflicting with autokey. It has no issues.
On Tue, Jun 30, 2015, 10:55 PM Danny Mayer <[email protected]> wrote: > On 6/30/2015 9:15 AM, Tal Mizrahi wrote: > > Hi Anil, > > > > Thanks for the prompt response. > > > >> I support this draft, But how about more Bit incorporating in field > type, Tal let me know your view. > > > > The checksum trailer draft requests IANA to allocate an extension field > type. > > Note that: > > (1) In unauthenticated mode, the checksum trailer extension field is the > last one. > > (2) In authenticated mode, the checksum trailer extension field is > followed by the MAC / Autokey extension field. > > > > The suggested M-bit in > draft-choudharykumar-ntp-ntpv4-extended-extensions indicates whether the > current extension field is the last or not. > > So once the checksum trailer draft has an allocated extension field > type, its most significant bit will be fixed to either 0 or 1, but cannot > cover both case (1) and case (2) above. > > > > A possible way to resolve this is to have two types allocated in the > checksum trailer draft, one for case (1), and another for case (2). The two > types would be identical, except for the most significant bit. This would > allow future compatibility with the M-bit, if adopted. > > > > A question to the WG: do we want to provision for the potential adoption > of the M-bit? > > > > No. It doesn't solve the problem for which they want it in a backward > compatible way. > > Danny > > > _______________________________________________ > ntpwg mailing list > [email protected] > http://lists.ntp.org/listinfo/ntpwg >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
