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

[Hal Murray <[e-mail]>]

[e-mail] said:
> In an operational setting, how is external information about what is or is
> not supported useful? 

It helps an admin decide if they want to use that server or not.


> The whole point of I-DO is that it provides a way for a newer instance of the
> code to operationally detect what the other side can handle.

It doesn't (yet) handle the I-DONT case.

There is still the problem of old servers that do/don't do leap smearing, so 
the idea of checking a web page or similar shouldn't be strange.


> Have you actually implemented your idea?

No.  Miroslav Lichvar's comment about updating a Correction EF complicates 
things.

> What does it get you?  What does it *not* get you?

What it gets me, is simplification of the EF/MAC handling.  I don't have to 
worry about all the kludgery to dance around MACs that might get confused with 
EFs.

More importantly, I don't have to think about it.




> Where do you see that the minimum length is 8?  Section 4.2 (the new section
> 7.5) says: 

I was reading quickly.
>    While the minimum field length of an EF that contains no value or
>    padding fields is one word (four octets), and the minimum field
>    length of an EF that contains required fields is two words (8
>    octets), ...
I saw the second half which says "required fields".  If they are required, 
then they must be there so the min length is 8.


> The text of the old and new stuff is pretty small, and it's pretty easy to
> see what changed.  Are you saying you have tried to implement this and you
> had difficulty? 
I was trying to find what it said about the minimum length.  That could be a 
simple sentence.  Instead, I have to do a manual diff.  The old section 7.5 is 
a half page.  The new is a page and a half.  Somebody could easily focus on 
the new stuff without noticing the length change.


> As for your second, would you be happier with:
>  R: 0 for "Information/Query", 1 for a "Response" 
I think what's missing is the idea that the Request/Response bit only applies 
to some uses.  As written, it doesn't allow for unsolicited information.


> https://www.ietf.org/archive/id/draft-stenn-ntp-mac-last-ef-02.txt

Thanks.  That seems overly complicated, but I admit I haven't thought about 
this area a lot.

Your last EF adds 4 bytes, but leaves a bare MAC.  I've been trying to think 
of ways to get rid of bare MACs.  Your MAC-EF takes 8 more bytes for a single 
MAC.

I think I'd prefer a single MAC-EF - same layout as your LAST-EF except the 
length includes the MAC.

>> The link behind "NEW: 'RFC5905 Section 7.5.1 - Extension Fields and MACs'" 
in
>> the Table of Contents doesn't work.  (It's a new section.  There is no 
place
>> to link to.  I think the link should be removed.)
> There is a place to link to - it's on the top of page 8.

Your "top of page 8" is in the new document.

Here is the link I was referring to:
  https://tools.ietf.org/html/rfc5905#section-7.5.1
It goes to the old RFC.  There is no section 7.5.1 in the old RFC.
There are actually 2 occurrences of that link.  One in the Table of Contents 
and a second  at the top of page 8, the header for section 4.3


-- 
These are my opinions.  I hate spam.