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

[Harlan Stenn <[e-mail]>]

On 9/28/18 8:41 PM, Hal Murray wrote:
> 
> [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.

And what happens if the remote version of NTP changes between the time
an admin reads whatever happens to be on that external mechanism and "now"?

And what assurance do you have that the external mechanism has correct
information even at the moment you read it?

>> 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.

The absence of I-DO should be regarded as I-DONT.

> 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.

What does leap smearing have to do with the overall structure of
extension fields?

>> Have you actually implemented your idea?
> 
> No.  Miroslav Lichvar's comment about updating a Correction EF complicates 
> things.

I don't see it.  What do you mean, and how does it apply to my proposal?

>> 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.
I've already implemented this and it works just great.  It's not
complicated at all.

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

I don't see your point here.  Would you please expand?

>> 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.

You're still not reading it.  If there is no payload, the minimum EF
length is 4 octets.  If there is a payload, the minimum EF 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.

I submit the only interesting bit here is does the new text make sense,
and can an implementor be expected to be able to write working code
based on it.

The introduction of the document clearly says what the purpose of this
proposal is.

Every other time I've added explanatory text to a proposal I'm told that
I should remove that text because it's not useful long-term.

>> 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.

Then we disagree.  An R bit of 0 is clearly 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.

It might make more sense to you if you were implementing it, and your
code had to deal with legacy and new NTP instances.

> 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.

The way to get rid of bare MACs is to use a MAC-EF, or some other
mechanism.  But that won't work when talking to a legacy client, so you
can either dance thru hoops or use I-DO.

The MAC-EF takes 8 octets because it is preparing for the case where
multiple MACs are allowed.

It would not be hard to have a MAC-EF that only encapsulated a single
legacy MAC.  I'm not sure it's worth saving 4 octets for this case.

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

OK.

>>> 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.

Of course it's in the new document.  The proposal is to add that new
content.

> 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

If the proposal is adopted, then the link will work.

I don't see the value in breaking the xref now, and then fixing it if
the proposal is passed.

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!