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

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

---

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.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

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: 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

On May 22, 2013, at 11:30 AM, Bernie Volz (volz) <[email-masked]> wrote:
> 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: Ted Lemon <[email-masked]>
Date: Wed, 22 May 2013 17:45:09 +0000

On May 22, 2013, at 1:38 PM, Andre Kostur <[email-masked]> wrote:
> 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...".

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

---

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

On May 22, 2013, at 1:52 PM, Andre Kostur <[email-masked]> wrote:
> 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.

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: Ted Lemon <[email-masked]>
Date: Wed, 22 May 2013 20:24:03 +0000

On May 22, 2013, at 3:37 PM, Andre Kostur <[email-masked]> wrote:
> 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