[ntpwg] [dhcwg] draft-gayraud-dhcpv6-ntp-opt-01.txt

[TS Glassey]

Benoit... Bernie - The people who have to sign off on the use of DHCP's NTP 
service model are the auditor community so it would be easier if the 
terminology was more specific to their use than ours IMHO...

More commentary inline below.

todd glassey//

----- Original Message ----- > Bernie Volz (volz) wrote:
>> In addition after attending today's NTP session, I think you'd be far
>> better to:
>>
>> 1. Make use of the existing OPTION_SNTP_SERVERS (RFC4075) but request
>> that IANA rename this to OPTION_NTP_SERVERS and explain why (that SNTP
>
>> refers to a client implementation, not the server and thus it should
>> be NTP_SERVERS which can be used by either NTP or SNTP clients).

But there is another trust/use issue from the evidence gathering side, and 
that is that NTP and SNTP Sources need to be known independantly, especially 
since in a secured environment it may be necessary to pass a AutoKEY token 
with the DHCP response to allow for use of Time in an environment where all 
access is controlled and logged.

>>
>
> That's not quite right. Yes, I'm being picky. There are SNTP servers
> defined in RFC4330 and in the NTPv4 draft, but they can be used by
> either NTP servers (on their client side) as well as by SNTP clients.
> NTP servers can be used by either NTP servers (on their client side) as
> well as by SNTP clients.

You mean "used in SNTP Mode" and that is OK as long as that server is setup 
for use in that manner, i.e. doesnt have AutoKEY setup for all Unicast & 
Multicast requests one would think eh?

>
> That said I know of no SNTP servers in existence unless the time
> standards agencies (NIST in Boulder, Colorado), US Navy, NPL
> (Teddington, England), etc. have them. Most use NTP servers.

Agreed.

>
> That said, I agree that renaming these options is the right thing to do,
> either that or obsoleting them.
>
>> Note: As the option usage is not changing, this is the correct to do.
>> It would be a very bad idea to request a new option because then many
>> servers will need to have both the OPTION_SNTP_SERVERS and the new
>> option configured with the same list of servers which is kind of
>> useless.
>>
>> 2. Define a new OPTION_NTP_DOMAIN_NAME option that is used to specify
>> the domain name of an NTP server. You can allow multiple of these
>> options if the ability to provide multiple domain names is desired.
>> See RFC 3898 which defines the NIS/NISP "servers" and "domain name"
> options.
>>
>
> What would be the use of this? It doesn't have anythnig to do with NTP
> since NTP doesn't care about domains. Can you clarify?

Yes - Many DOMAIN NAME stratification's may call for differing levels of 
evidentiary colleciton of data from, and so this does indeed make sense.

Todd Glassey

>
> Danny
>> - Bernie
>>
>> -----Original Message-----
>> From: Bernie Volz (volz)
>> Sent: Wednesday, March 12, 2008 2:20 PM
>> To: Benoit Lourdelet (blourdel); 'ntpwg at lists.ntp.isc.org'
>> Cc: DHC WG
>> Subject: draft-gayraud-dhcpv6-ntp-opt-01.txt
>>
>> One issue in draft-gayraud-dhcpv6-ntp-opt-01.txt is that the
>> NTP_SUBOPTION_SRV_FQDN suboption "fqdn" data must be DNS wire encoded
>> as described in RFC 3315, Section 8 (Representation and Use of Domain
>> Names).
>>
>> Thus:
>>
>>       0                   1                   2                   3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |    NTP_SUBOPTION_SRV_FQDN     |        suboption-len = 15     |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |      'n'      |      't'      |      'p'      |      '.'      |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |      'e'      |      'x'      |      'a'      |      'm'      |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |      'p'      |      'l'      |      'e'      |      '.'      |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |      'c'      |      'o'      |      'm'      |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>        sub-option-code: NTP_SUBOPTION_SRV_FQDN  (2)
>>
>>        sub-option-len:  length of the included FQDN (15)
>>
>> Would actually be:
>>
>>       0                   1                   2                   3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |    NTP_SUBOPTION_SRV_FQDN     |        suboption-len = 17     |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |       3       |      'n'      |      't'      |      'p'      |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |       7       |      'e'      |      'x'      |      'a'      |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |      'm'      |      'p'      |      'l'      |      'e'      |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |       3       |      'c'      |      'o'      |      'm'      |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |       0       |
>>      +-+-+-+-+-+-+-+-+
>>
>>        sub-option-code: NTP_SUBOPTION_SRV_FQDN  (2)
>>
>>        sub-option-len:  length of the included FQDN (17)
>>
>> Also, usually DHCP option definitions just define the option format
>> without giving a specific example.
>>
>> - Bernie
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg at ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg