Subject: [ntpwg] Network Time Protocol (NTP) Server Option for DHCPv6 WG item updated

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Fri, 4 Jul 2008 14:17:06 +0200

Hello,

Based on the comments mentioned in the previous e-mail (in copy), we
modified the working group item and republished it here as version 1 :

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

Regards

Benoit

-----Original Message-----
From: Benoit Lourdelet (blourdel) 
Sent: Wednesday, June 11, 2008 12:09 PM
To: [email-masked]'; [email-masked]'
Cc: Richard Gayraud (rgayraud); Benoit Lourdelet (blourdel)
Subject: RE: draft-ietf-ntp-dhcpv6-ntp-opt-00 is now a WG item

 Hello,

As authors, we received the following comments from Alfred Hines with
request to publish it on his behalf :

"(1)  Layering / Semantic Overloading

Sections 3 and 4 indicate that the NTP Server Address Suboption can be
"used" to carry an IPv6 multicast group address.

This semantical overloading seems to be an unfortunate 'hack' or
*abuse* of the option.  Usually, this option carries the *source*
address of NTP inbound packets; in the multicast case that's the
*destination* address of inbound NTP packets to listen for.

You have provided for a 16-bit suboption type namespace.
This should easily accommodate the allocation of another code point for
a specific NTP_SUBOPTION_MC_ADDR .

Thus, decision making logic in DHCPv6 clients could be based on the
suboption type and would not have to have built-in knowledge of which
IPv6 addresses are multicast addresses.
(This conceivably even could change with a future update of the IPv6
address allocation policy/architecture!)

Leaving the knowledge of what comprises feasible IPv6 multicast
addresses in the multicast modules of an IPv6 implementation (and only
dealing *there* with the subtle issues related to MC scope in IPv6)
would IMHO be a much clearer layering decision.
"

Here our view on that comment :

We think the remark about semantic overloading is perfectly valid. We
plan to make the change according to your suggestions in the next
version. 

Regards

Richard Gayraud and Benoit Lourdelet 

-----Original Message-----
From: Benoit Lourdelet (blourdel)
Sent: Friday, May 30, 2008 1:41 PM
To: [email-masked]; [email-masked]
Cc: Richard Gayraud (rgayraud); Benoit Lourdelet (blourdel)
Subject: draft-ietf-ntp-dhcpv6-ntp-opt-00 is now a WG item

Hello,

The Network Time Protocol (NTP) Server Option for DHCPv6 is now a WG
item.
http://www.ietf.org/internet-drafts/draft-ietf-ntp-dhcpv6-ntp-opt-00.txt

Please comment on this revision that includes the comments received on
the personal submission versions  of the draft.

regards

Richard Gayraud, Benoit Lourdelet

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

Filename: draft-ietf-ntp-dhcpv6-ntp-opt

Revision: 00

Title: Network Time Protocol (NTP) Server Option for DHCPv6

Creation_date: 2008-05-14

WG ID: ntp

Number_of_pages: 10

Abstract:

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

The IETF Secretariat.

_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Fri, 11 Jul 2008 16:15:05 +0200

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: [email-masked]; [email-masked]
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 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]