Re: [Ntp] I-D Action: draft-ietf-ntp-roughtime-08.txt

[Hal Murray <[e-mail]>]

I think there are two ideas tangled up in here.  One is how to get NTS off the 
ground if you don't know the time.  (NTS needs time to check certificates.)  
The other is a way to prove that a server is lying or busted.

I'm interested in the first one.  It's really hard to figure out what you have 
in mind.

The introduction says "Roughtime uses a list of keys and servers to resolve 
this issue."

Section 10 has a list of 4 servers with a note to the RFC editor to delete 
that section.  So how is a client going to find servers?

Whatever your plan is for distributing that list, why is Roughtime better than 
just distributing a list of root-certs for trusted NTS servers?

You didn't say anything about the life time of your list.  I think the getting 
off the ground area is worth some serious thought and discussion.  The simple 
case is something like a Raspberry Pi that doesn't have a RTC.  The nastiest 
case I know of is hot standby modules for Telco or SCADA applications that may 
sit on the shelf for 10s of years.

Are there other IETF groups working on getting off the ground and/or updating 
things like root certificates?


Section 7 discusses Integration Into NTP

I'd be happy if you drop this section.  I assume it's obvious how to use 
Roughtime to get a time that NTS can use for checking certifictes.  That's all 
NTP needs.


You don't say where your delta or sigma come from.  (They are probably 
leftover from the part I didn't read.)

Getting a useful PHI might be tough.  Have you worked through any numbers?  
(I'll say more if you want.)  I think you need another parameter -- how 
accurate do you expect your clock to be.

Your "MUST use Roughtime" when stepping the clock is not reasonable.  ntpd can 
make small steps.  (I had a reproducable test case.  Downloading a big file on 
my old, slow DSL line had enough bufferbloat to kick ntpd over the 128ms step 
threshold.)

My reading of "MUST use Roughtime" is to run it again, but you didn't actually 
say that.  If a small step is still close enough you could use the previous 
Roughtime.

My thinking has been assuming that I'm using NTS.  If so, why are your 
Roughtime servers going to be any better than my authenticated NTP servers?

That gets into the whole area of which servers to trust.  I think that would 
be a good discussion.


So on to proving that a server is busted.  Why is the proof part important?  
How would that fit into a program for monitoring NTP servers?

The pool has a monitoring setup.  Do you have any data from Ask?  How often 
does he kick out buggy servers?  (as compared to ones that don't respond)

---------

I'm working from a printed version of the PDF.
There are no page numbers.
The Table of Contents (second sheet) doesn't have page numbers.


Typo:
   Section 7:  "fall to far otside"
   "to" => "too"

End of Section 7:  "may wish to" (at end)
  May wish to what?

Section 3:
  "absolutely confident"
Absolute is pretty strong.  I get suspicious when I see things like that.

Section 8: Grease
  I'm not familiar with the use of that term in this context.


-- 
These are my opinions.  I hate spam.