[ntpwg] Pending NTP WG Last Call on Autokey

[David L. Mills]

Danny,

We are having a violent disagreement. The disagreement will continue 
with enthusiasm. Stay out of the length field. Leave things as they are 
and get this damn puppy out the door. When a new appliation surfaces for 
the extension fields, consider a revised format and junk the existing 
format.

Dave

Danny Mayer wrote:

> Dave,
>
> I'm not buying it. I don't give a hoot about prior art. I'm trying to 
> fix the original problem of your overloading the type field with 
> private  codes. This is a workaround to allow the old usage to 
> continue to work while the code is upgraded to the correct usage and 
> to allow interoperation between the old and the new. The old will be 
> obsoleted after several releases.
>
> Danny
> David L. Mills wrote:
>
>> Danny,
>>
>> No sell. There are numeous examples of prior art in the use of a 
>> 16-bit length field in IP and UDP. I do not think it clean at all to 
>> poach on the length field. In any case, it doesn't really make much 
>> difference. What you see is what you get unless you have a specific 
>> proposal for a competitive protocol. Right now I don't hear anything.
>>
>> Dave
>>
>> Danny Mayer wrote:
>>
>>> Dave,
>>>
>>>
>>> You misunderstand me. I'm proposing that autokey complies as well. 
>>> conformance bit set to 1 indicates that you are conforming to the 
>>> protocol while conformance bit 0 (which it would have to be in order 
>>> to be the top bit of the length field) would mean the old format and 
>>> would be non-compliant with the autokey protocol and the NTPv4 spec. 
>>> The old autokey usage of the field type would go away.
>>>
>>>
>>> I'll send you the layout at little layer.
>>>
>>>
>>> Danny
>>>
>>>
>>> David L. Mills wrote:
>>>
>>>> Dannt,
>>>>
>>>>
>>>> Each of us has proposed stealing bits from the length field or the 
>>>> code fields. I find stealing from the length field inelegant, while 
>>>> you might find theft of code bits crude. Your proposal cleaves 
>>>> Autokey from any other and does not necessarily provide for 
>>>> multiple others. I prefer my proposal.
>>>>
>>>>
>>>> Dave
>>>>
>>>>
>>>> Danny Mayer wrote:
>>>>
>>>>
>>>>> Dave,
>>>>>
>>>>>
>>>>> My proposal that I sent out quite a long time ago was to steal a 
>>>>> bit from the length field and set it to 1 for the updated protocol 
>>>>> so that the particulars of the autokey protocol remains private 
>>>>> inside the header extension itself and keeps it outside the field 
>>>>> type. That way the servers (including those of NIST, USNO, etc.) 
>>>>> can continue to work with both versions (the old and the new). The 
>>>>> old clients (servers) will continue to work. Taking away one bit 
>>>>> from the length field reduces the maximum extension length from 
>>>>> 65535 to 32767 which I don't think we will ever need or can use.
>>>>>
>>>>>
>>>>> It's this lack of privacy of this data that causes 
>>>>> interoperability problems between Autokey and Microsoft's MS-SNTP 
>>>>> protocols, otherwise this issue would never have arisen.
>>>>>
>>>>>
>>>>> Danny
>>>>>
>>>>>
>>>>> David L. Mills wrote:
>>>>>
>>>>>
>>>>>> Danny,
>>>>>>
>>>>>>
>>>>>> I hear no proposals about extension fields other than my last 
>>>>>> proposed rewrite of that section. There really is no wiggle room 
>>>>>> other than deprecating Autokey in its present form and 
>>>>>> reformatting the headers. I am not opposed to that in principle, 
>>>>>> but others, specificlly USNO, have not been heard from.
>>>>>>
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>>
>>>> ntpwg mailing list
>>>>
>>>> ntpwg at lists.ntp.org
>>>>
>>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>>
>>>>
>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwg at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>
>