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

[Benoit Lourdelet (blourdel)]

Bernie,
 
You are beating a dead horse here. A 200 e-mail discussion lead to the
consensus that we needed FQDN and IP address.


Regards

Benoit


-----Original Message-----
From: Bernie Volz (volz) 
Sent: Sunday, March 16, 2008 4:19 AM
To: mayer at ntp.isc.org
Cc: Benoit Lourdelet (blourdel); ntpwg at lists.ntp.isc.org; DHC WG
Subject: RE: [dhcwg] draft-gayraud-dhcpv6-ntp-opt-01.txt

>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?
 
I think the general thought is that domain names can get you an address
or addresses. So, why can't an NTP client (or server) make use of DNS to
lookup the domain name (FQDN) and make use of the addresses? [While a
perfect user of a domain name would adhere to the TTL of the information
and re-query when the TTL is up to obtain the newest information, this
rarely happens - the application is more likely to look up the name once
and then use the address it found.]

Or, are you saying that NTP servers (or SNTP servers if any exists)
aren't ever entered in the DNS?

- Bernie

-----Original Message-----
From: Danny Mayer [mailto:mayer at ntp.isc.org]
Sent: Saturday, March 15, 2008 10:38 PM
To: Bernie Volz (volz)
Cc: Benoit Lourdelet (blourdel); ntpwg at lists.ntp.isc.org; DHC WG
Subject: Re: [dhcwg] draft-gayraud-dhcpv6-ntp-opt-01.txt

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

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.

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.

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?

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
>