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

[Anil Kumar <[e-mail]>]

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 <[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]
> http://lists.ntp.org/listinfo/ntpwg
>

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