Subject: [dhcwg] Question about RFC5908

From: François-Xavier Le Bail <[email-masked]>
Date: Tue, 21 May 2013 00:44:27 -0700 (PDT)

[Adding dhcwg and RFC authors]

Hello,

About RFC5908, "Network Time Protocol (NTP) Server Option for DHCPv6".

Section 4 says: 
The option itself does not contain any value.  Instead, it contains
one or several suboptions that carry NTP server or SNTP server
location.  This option MUST include one, and only one, time source
suboption. 

(http://tools.ietf.org/html/rfc5908#section-4)

It seems to me contradictory:
- The option itself [...]. Instead, it contains one or several suboptions [...]
- This option MUST include one, and only one, time source suboption.

Did I miss something ?

Best regards,

Francois-Xavier le Bail

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 May 2013 15:18:11 +0000

> - This option MUST include one, and only one, time source suboption.

Yes.   The point is that the option can only contain one suboption in the set (server-addr, multicast-addr, server-fqdn).   There can be more than one of these options, and so there can be more than one source suboption in the DHCPv6 packet: one for each such option.

---

From: François-Xavier Le Bail <[email-masked]>
Date: Wed, 22 May 2013 06:58:24 -0700 (PDT)

----- Original Message -----

> From: Ted Lemon <[email-masked]>
> To: François-Xavier Le Bail <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Tuesday, May 21, 2013 5:18 PM
> Subject: Re: [dhcwg] Question about RFC5908
> 
> Yes.   The point is that the option can only contain one suboption in the set 
> (server-addr, multicast-addr, server-fqdn).   There can be more than one of 
> these options, and so there can be more than one source suboption in the DHCPv6 
> packet: one for each such option

I think the text is not clear:
Why not :
This option MUST include one, and only one, time source suboption type ?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 22 May 2013 15:30:59 +0000

You can always file an errata.

- Bernie

On May 22, 2013, at 9:58 AM, "François-Xavier Le Bail" <[email-masked]> wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 May 2013 16:41:16 +0000

> This option MUST include one, and only one, time source suboption type ?

No, this would be less correct, because you are now allowing for two time source options of the same type, which the current document (I believe correctly) forbids.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 May 2013 17:25:21 +0000

> You can always file an errata.

An erratum, some errata.   But please don't, because you are mistaken about this (or at least, you have failed to explain why you are not mistaken).

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 22 May 2013 17:36:53 +0000

I am not in favor of it being filed. The text could certainly have been better but I think it has not been an issue.

- Bernie (from iPad)

---

From: Andre Kostur <[email-masked]>
Date: Wed, 22 May 2013 10:38:39 -0700

> An erratum, some errata.   But please don't, because you are mistaken about this (or at least, you have failed to explain why you are not mistaken).

I'm not clear where the RFC forbids a response with two instances of
56, each with one instance of sub-option 1, or where one instance of
56 may only contain one sub-option instance.

I do see where there may be multiple instances of 56 (both sections 4
& 5 acknowledge this), and an instance of 56 may contain multiple
sub-options (section 4, and the diagram of option 56 acknowledge
this).  I do think that the phrasing of "This option MUST include one,
and only one, time source suboption." is ambiguous and does appear to
directly contradict the previous statement "Instead, it contains one
or several suboptions that carry...".

--
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 May 2013 17:45:09 +0000

> or several suboptions that carry...".

No, it doesn't, because not all suboptions are time source suboptions.

---

From: Andre Kostur <[email-masked]>
Date: Wed, 22 May 2013 10:52:12 -0700

> No, it doesn't, because not all suboptions are time source suboptions.

So it's trying to acknowledge that there may be a bunch of other,
unrelated suboptions stuck into this option?   Wait... are we possibly
arguing over a typo?  If we re-read the problematic statement as
"Instead, it contains one _of_ several suboptions that carry..." that
seems to make more sense.

--
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 May 2013 18:19:35 +0000

> seems to make more sense.

It might have been better to say "one or more," but the meaning of the sentence is correct, and your proposed change would make it incorrect.   The option can contain any number of suboptions greater than zero.   Exactly one of those suboptions can be a time source suboption.   That's what the text says, and that's what the text was intended to say.   There is no error or ambiguity here.

---

From: Andre Kostur <[email-masked]>
Date: Wed, 22 May 2013 12:37:13 -0700

> It might have been better to say "one or more," but the meaning of the sentence is correct, and your proposed change would make it incorrect.   The option can contain any number of suboptions great…

What other suboptions can it be?

--
Andre Kostur

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 22 May 2013 20:04:04 +0000

This option serves as a container for server location information
   related to one NTP server or Simple Network Time Protocol (SNTP)
   [RFC4330] server.  This option can appear multiple times in a DHCPv6
   message.  Each instance of this option is to be considered by the NTP
   client or SNTP client as a server to include in its configuration.

   The option itself does not contain any value.  Instead, it contains
   one or several suboptions that carry NTP server or SNTP server
   location.  This option MUST include one, and only one, time source
   suboption.  The currently defined time source suboptions are
   NTP_OPTION_SRV_ADDR, NTP_OPTION_SRV_MC_ADDR, and NTP_OPTION_SRV_FQDN.

Those 3 suboptions are the only ones currently defined.

Bottom line is:
- There may be multiple instances of the OPTION_NTP_SERVER option.
- A OPTION_NTP_SERVER ONLY contains suboption(s). (This is what is meant by "The option itself does not contain any value. ")
- Each OPTION_NTP_SERVER MUST only contain ONE time-source suboption: thus one of the 3 currently defined suboptions: NTP_OPTION_SRV_ADDR, NTP_OPTION_SRV_MC_ADDR, and NTP_OPTION_SRV_FQDN.
- If there are future suboptions defined (I don't believe there are), they may or may not be time-source suboptions and if they are not, they might appear in addition to a time-source suboption.

The IANA considerations are also broken:

8.  IANA Considerations

   IANA has assigned 56 as an option code from the "DHCPv6 Options
   Codes" registry for OPTION_NTP_SERVER.

   IANA is required to maintain a new number space of NTP time source
   suboptions, located in the BOOTP-DHCP Parameters Registry.  The
   initial suboptions are described in Section 4 of this document.  IANA
   assigns future NTP time source suboptions with an "IETF Consensus"
   policy as described in [RFC5226].  Future proposed suboptions are to
   be referenced symbolically in the documents that describe them, and
   shall be assigned numeric codes by IANA when approved for publication
   as an RFC.

I am not sure why this new number space was in the "BOOTP-DHCP Parameters Registry" as that is the DHCPv4 registry, not the DHCPv6 registry. IANA did do what the RFC requested (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml#ntp-time-source).

This document is really bad and it is too bad it slipped through the cracks.

- Bernie

-----Original Message-----
From: Andre Kostur [mailto:[email-masked]] 
Sent: Wednesday, May 22, 2013 3:37 PM
To: Ted Lemon
Cc: Bernie Volz (volz); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dhcwg] Question about RFC5908

--
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 May 2013 20:24:03 +0000

> What other suboptions can it be?

Right now no non-time source suboptions are defined.   I don't know what the authors had in mind for this, TBH, but I'm pretty sure that the intent of the text that you see there was to allow for multiple suboptions, as long as only one was a time source option.

If you want to open a can of worms here, the fact is that this option specification is badly broken, not only because it is the only option definition for IPv6 that uses suboptions, but as written, there is no value to the suboptions.   The reason it's broken in this way is that the NTP working group disregarded substantial comment from the DHC working group.

Personally, I think (ad hat off) that the DHC working group should just define a new NTP option and deprecate this one.   There is no excuse for something as basic as configuring an NTP server to be so complicated.

---

From: François-Xavier Le Bail <[email-masked]>
Date: Sat, 25 May 2013 09:27:07 -0700 (PDT)

> This document is really bad and it is too bad it slipped through the cracks.

+1