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

From: "Richard Gayraud (rgayraud)" <[email-masked]>
Date: Tue, 8 Jul 2008 18:25:03 +0200

Hello Matt,

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 ?

Richard.

-----Original Message-----
From: Matthew Ryan [mailto:[email-masked]] 
Sent: Monday, July 07, 2008 7:30 PM
To: Benoit Lourdelet (blourdel)
Cc: [email-masked]
Subject: Re: [dhcwg] Network Time Protocol (NTP) Server Option for
DHCPv6 WG item updated

Benoit Lourdelet (blourdel) wrote:
>  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.t
> xt

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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jul 2008 11:20:59 -0700

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

Reason 1 isn't a particularly good reason - it seems adequate to simply state that the server location sub-option can only appear once.   Reason 2 isn't a good reason at all - what does "natural" mean?   Reason 3 simply isn't true.   The client is a general-purpose tool, and it already knows how to decode packets.   What you as the NTP customer are going to get is what the client decodes.   The client shouldn't need to have special knowledge of the NTP options - it's just the middleman.   Whatever actually looks at the results from the client needs to collate the data, it's true, but this is trivial.   Insisting on a specific order actually increases the brittleness of the solution.

What I would do if I were defining this option in the way that you've decided to define it would be to make the server location /not/ a suboption.   Define the option as a series of static fields (maybe just one, the server location) followed by suboptions.   This way you get all your ordering and uniqueness guarantees in a way that is general - the server and client already know how to unpack options like this because this is how your IP addresses are delivered.

---

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Tue, 8 Jul 2008 20:31:27 +0200

Ted,
 
I propose we follow Matt's comment. You gave us good DHCP reason to do
so.

Let us specify that each of the three suboptions defined  in the
currenmt draft MUST appear only once but not in any particular position.

Regards

Benoit 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
Sent: Tuesday, July 08, 2008 8:21 PM
To: Richard Gayraud (rgayraud); Matt Ryan
Cc: [email-masked]
Subject: Re: [dhcwg] Network Time Protocol (NTP) Server Option forDHCPv6
WG item updated

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

Reason 1 isn't a particularly good reason - it seems adequate to simply
state that the server location sub-option can only appear once.   Reason
2 isn't a good reason at all - what does "natural" mean?   Reason 3
simply isn't true.   The client is a general-purpose tool, and it
already knows how to decode packets.   What you as the NTP customer are
going to get is what the client decodes.   The client shouldn't need to
have special knowledge of the NTP options - it's just the middleman.
Whatever actually looks at the results from the client needs to collate
the data, it's true, but this is trivial.   Insisting on a specific
order actually increases the brittleness of the solution.

What I would do if I were defining this option in the way that you've
decided to define it would be to make the server location /not/ a
suboption.   Define the option as a series of static fields (maybe just
one, the server location) followed by suboptions.   This way you get all
your ordering and uniqueness guarantees in a way that is general - the
server and client already know how to unpack options like this because
this is how your IP addresses are delivered.