[dhcwg] Network Time Protocol (NTP) Server Option for DHCPv6 WG item updated

["Benoit Lourdelet (blourdel)" <blourdel at cisco.com>]

Hello,

Based on the comment mentioned in the previous e-mail (in copy), we
modified the working group item and re-published it here as version 2 :

http://www.ietf.org/internet-drafts/draft-ietf-ntp-dhcpv6-ntp-opt-02.txt


Section 3 has been updated to remove the requirement on the order of
appearance of suboptions in the option.
Regards

Benoit



-----Original Message-----
From: Benoit Lourdelet (blourdel)
Sent: Friday, May 30, 2008 1:41 PM
To: dhcwg at ietf.org; ntpwg at lists.ntp.isc.org
Cc: Richard Gayraud (rgayraud); Benoit Lourdelet (blourdel)
Subject: draft-ietf-ntp-dhcpv6-ntp-opt-00 is now a WG item


A new version of I-D, draft-ietf-ntp-dhcpv6-ntp-opt-02.txt has been
successfuly submitted by Benoit Lourdelet and posted to the IETF
repository.

Filename:	 draft-ietf-ntp-dhcpv6-ntp-opt
Revision:	 02
Title:		 Network Time Protocol (NTP) Server Option for DHCPv6
Creation_date:	 2008-07-11
WG ID:		 ntp
Number_of_pages: 11

Abstract:
The NTP Server Option for DHCPv6 provides NTP (Network Time Protocol
version 4) configuration information to DHCPv6 hosts.
 



The IETF Secretariat.


> The purpose of having the server location first is that:
>
>  1. it normalizes the fact that you must have one and only
>     one server location sub-option per option. If we allow it
>     to appear in any position, then we have to explain there
>     must be exactly one of them, that these sub-options are
>     mutually exclusive (between them and also with any future
>     sub-option that falls into the 'server location' category).
>
>     For simplicity, it seems easier to specify that it must
>     appear first,
>
>  2. the parameters that may be added later will qualify the
>     server. So it seems "natural" to have the server identity
>     first, and then, the parameters qualifying it,
>
>  3. a client implementation will be simpler if the order is
>     predefined : basically, it can generate an NTP config file
>     statelessly from the DHCP message. Otherwise, it would
>     have to store the parameters and wait for the server name
>     to appear.
>
> This is why I would be in favor of keeping this constraint, except if 
> there is a bigger issue on server side ?

If you specify an order for the appearance of the suboptions, it
obviously requires special code in a place where a server normally
wouldn't have any special code, since no such constraints exist on other
options.   So this in itself is a good reason not to do it.

[snip]
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg