Subject: [dhcwg] 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.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Matthew Ryan <[email-masked]>
Date: Mon, 07 Jul 2008 10:29:32 -0700

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

Section 3 (second paragraph) states:
    [The option] contains one or several suboptions that carry
    NTP server configuration information.

Is the "or" in that sentence supposed to be an "of"?

    The first suboption in this option MUST be NTP_OPTION_SRV_ADDR,
    NTP_OPTION_SRV_MC_ADDR or NTP_OPTION_SRV_FQDN.

While this currently has no effect since only those three sub-
options are defined, requiring a specific ordering to sub-options
would potentially require servers to have special-case handling of
this option if additional sub-options are defined.  Can this
requirement be removed?

  - Matt

---

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]