Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum-trailer-01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt)

[Danny Mayer <[e-mail]>]

On 6/30/2015 1:29 PM, Anil Kumar wrote:
> If issue is backward compatibility I will prove it, if new extensions
> Field type is not conflicting with autokey. It has no issues.
> 

How are you intending to check ntpd, sntp, ntpdate, ntimed, Windows
Time, chrony, and a vast number of clients?

Let us solve the real problem rather than coming up with hacks that will
be almost impossible to do right.

Danny
> 
> On Tue, Jun 30, 2015, 10:55 PMÂ Danny Mayer <[e-mail]
> <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     http://lists.ntp.org/listinfo/ntpwg
> 

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg