Subject: [dhcwg] AD comments on draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt

From: Thomas Narten <[email-masked]>
Date: Wed, 14 May 2003 14:09:35 -0400

substantive comments: Note, when I first reviewed this, I asked the
IESG about some aspects of this, so some of my comments reflect
concerns/questions that came out of that discussion.

>    The Timezone option is used by the server to convey client's timezone 
>    information to the client.

First, what are the actual semantics of this option?  Are the
semantics:

 - This is the timezone you are in at the time this message is sent?
 - this is the timezone the server is in at the time this message is
   sent?
 - or something else? What is the client expected to do with the option?

>    time-zone:   Time zone of the client in the format as explained below.
>    
>       Std[Offset[Dst[Offset],[Start[/Time],End[/Time]]]]
> 
>    where '[' and ']' enclose optional fields, '|' indicates choice
>    of exactly one of the alternatives, ',' and '/' represent literal
>    characters present in the string.
> 
>    If "Offset" is specified, then the time-zone is represented in the
>    IEEE 1003.1 POSIX timezone format [3].
> 
>       Std      Three or more octets for the standard timezone (Std).
>                Any character (or case) except a leading colon, digits,
>                comma, minus or plus sign is allowed. If the time-zone
>                is not represented in IEEE 1003.1 POSIX timezone format [3], 
>                then Std is treated as the index to the timezone database,
>                for example, a file name, from where additional information
>                about the timezone may be obtained.

If offset is not specified, what format is the timezone in then?  If
POSIX format is not used, how can the client and server be sure that
they agree on what the meaning of the string in the option? The above
says it is just an index into some unspecified table. But in general,
the client and server can't be assumed to be using the same table,
unless that is specified in this document... So this sounds like an
interoperability problem waiting to happen...

Or asking differently, is there a particular reason for not just using
the IEEE posix format exclusively? (Or, would it be better to have a
separate posix format option to make clear which is in use?)

Also, is DHCPv4 option 88 (IEEE 1003.1 POSIX Timezone ) documented in
an RFC? I couldn't find the obvious one ...  Is it used?

nits:

> 3. Terminology
> 
>    This document uses terminology specific to IPv6 and DHCPv6 as defined
>    in section "Terminology" of the DHCP specification.

s/DHCP/DHCPv6/? and cite the RFC.

>   time-zone:   Time zone of the client in the format as explained below.

Is this a string? If so, what character set?

security considerations probably needs to also say something about how
bogus NTP servers can cause clients to set their times incorrectly,
making them vulnerable to replay attacks in protocols that use
timestamps to detect replays.

> 8. IANA Considerations
> 
>    IANA is requested to assign an option code to these options from the
>    option-code space defined in section "DHCPv6 Options" of the DHCPv6
>    specification [1].

More clear to say:

IANA has assigned option code values out of the "DHCPv6 Options" name
space for the following options:

Option Name	    Value	Described in
OPTION_NTP_SERVERS  tbd		Section 4.
OPTION_TIME_ZONE    tbd		Section 5.

(Or something like that)

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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 May 2003 15:13:30 -0400

I can answer the easy question ... option 88 was never documented
in an RFC and is on the list of option codes to be marked by
IANA for reassignment.  See draft-ietf-dhc-unused-optioncodes-00

- Ralph

At 02:09 PM 5/14/2003 -0400, Thomas Narten wrote:
>[...]

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Thu, 15 May 2003 02:07:23 +0530

Hi Thomas

Thanks for you comments. See my reply inline.
Do get back to me, if you need any clarifications.

~Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas Narten
> Sent: Wednesday, May 14, 2003 11:40 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dhcwg] AD comments on 
> draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt
> 
> 
> substantive comments: Note, when I first reviewed this, I 
> asked the IESG about some aspects of this, so some of my 
> comments reflect concerns/questions that came out of that discussion.
> 

This is the timezone in which the client resides. The client is expected
to set the timezone in its system.
 
> If offset is not specified, what format is the timezone in 
> then? 

If there is no offset followed by the Std, then the timezone is not
represented in IEEE 1003.1 format. Its just a timezone string and the
clients can interpret them in platform specific way.

> If POSIX format is not used, how can the client and 
> server be sure that they agree on what the meaning of the 
> string in the option? 

The timezone option can be used along with the vendor/user class option
to make sure that they agree upon the meaning of the string. For
example, the clients running in different OS expect the string in
different ways. Thus, vendor/user class option can be used to
distinguish between the clients and proper string is returned by the
clients. I think, I need to document it for better understanding.

> The above says it is just an index into 
> some unspecified table. But in general, the client and server 
> can't be assumed to be using the same table, unless that is 
> specified in this document... So this sounds like an 

See the answer for prev question....

> 
> Or asking differently, is there a particular reason for not 
> just using the IEEE posix format exclusively? 

The main disadvantage POSIX format is its complexity. Some systems need
a very simpler timezone and they can use their own mechanism to
interpret and understand the underlying information. 

> (Or, would it 
> be better to have a separate posix format option to make 
> clear which is in use?)

No, having two different option for providing the same information may
lead to unnecessary complexity. What if both the options are sent to
client? And they are conflicting? Which one the client has to use? 

> 
> Also, is DHCPv4 option 88 (IEEE 1003.1 POSIX Timezone ) 
> documented in an RFC? I couldn't find the obvious one ...  Is it used?

There was a draft on this for DHCPv4, but I think, its obsoleted.

> s/DHCP/DHCPv6/? and cite the RFC.

Yes, I will update. Do you have any idea about the RFC number of DHCPv6?

> Is this a string? If so, what character set?

Its an NVT-ASCII string, I will document it.

> 
> security considerations probably needs to also say something 
> about how bogus NTP servers can cause clients to set their 
> times incorrectly, making them vulnerable to replay attacks 
> in protocols that use timestamps to detect replays.

I will update it.

> IANA has assigned option code values out of the "DHCPv6 
> Options" name space for the following options:
> 

Fine. I will update it.

Thanks
Vijay

---

From: Thomas Narten <[email-masked]>
Date: Fri, 16 May 2003 13:49:34 -0400

Hi Vijay.

> to set the timezone in its system.

OK.

> clients can interpret them in platform specific way.

This will lead to interoperability problems, it seems to me.

> clients. I think, I need to document it for better understanding.

This seems like a bad way to go. I.e., a standard DHC option that
requires use of a vendor specific option at the same time in order
to be used properly.  Wouldn't it be better to just have a
vendor-specific option that defines the timezone?

> interpret and understand the underlying information.

I'd like to hear from others about this. It seems like if there is a
standard format, we should use it. If we're going to define a simpler
alternate, we need to be sure we define it sufficiently to get a
reasonable amount of interoperability. I don't think we get that as
currently defined. (I'm also leary of trying to define a simpler
format, as from what I understand of timezone info, there's nothing
simple about it if you want to do it correctly.)

> client? And they are conflicting? Which one the client has to use?

Well, what if the server sends non-POSIX format and the client doens't
understand it? It might be clear what is supposed to happen, but the
option isn't useful now.

Thomas

---

From: Robert Elz <[email-masked]>
Date: Sat, 17 May 2003 19:52:50 +0700

Date:        Fri, 16 May 2003 13:49:34 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | This will lead to interoperability problems, it seems to me.

Nonsense.

  | This seems like a bad way to go. I.e., a standard DHC option that
  | requires use of a vendor specific option at the same time in order
  | to be used properly.  Wouldn't it be better to just have a
  | vendor-specific option that defines the timezone?

No.

DHCP servers send information tailored for a particular client.  That's
their role in life.   How the server decides which particular client, and
what particular information should be provided is up to the server.

  | I'd like to hear from others about this. It seems like if there is a
  | standard format, we should use it.

POSIX format doesn't provide enough information, all it tells is the
current timezone info, that is really, the UTC offset, and the dates
when DST next turns on/off.    There's no way from that to interpret
historic dates correctly (nor would it be reasonable for a DHCP server
to give out all the data that is needed for that to be done).

Some systems and applications require more than the current local time,
they also need to know what the local time was in the past.

  | Well, what if the server sends non-POSIX format and the client doens't
  | understand it?

Then the server is mis-configured, just as if it sends any other
information that the client doesn't want or cannot understand.
If the client only wants posix format, and gets something which isn't
that format, it ought to act just as if it didn't receive the option
at all.

If there's a problem with this draft, it is that there is no real way
for the server to have any knowledge of the timezone where the client
happens to be (a client could send a request to a particular DHCP server
from anywhere on the planet, in theory).   It isn't even that a particular
IP address is able to tell the server the timezone - we don't map addresses
into timezones, a network could easily span several (just consider a
large ATM LAN).

But all this means is that sometimes the server will have no information to
give the client, it isn't a reason to hold up the draft.

kre

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Mon, 19 May 2003 21:28:25 +0530

Thomas, 
Unfortunately, there was a mailer problem here and I missed your mail,
Could you please resend your mail to me. Moreover, I couldn't get the
archived version of your mail in the www.dhcp.org. Admins, could you
please take care of this?
Robert,
I totally agree with all your arguments. Adding to your point, vendor
specific option is just a tool for giving different values of same
options to the different clients. This is just a configuration issue,
rather than protocol issue. 
Vijay

> From: Robert Elz [mailto:[email-masked]] 
> Sent: Saturday, May 17, 2003 6:23 PM
> To: Thomas Narten
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dhcwg] AD comments on 
> POSIX format doesn't provide enough information, all it tells 
> is the current timezone info, that is really, the UTC offset, 
> and the dates
> historic dates correctly (nor would it be reasonable for a 
> DHCP server to give out all the data that is needed for that 
> to be done).
> 
> Some systems and applications require more than the current 
> local time, they also need to know what the local time was in 
> the past.
> 
> Then the server is mis-configured, just as if it sends any 
> other information that the client doesn't want or cannot 
> understand. If the client only wants posix format, and gets 
> something which isn't that format, it ought to act just as if 
> it didn't receive the option at all.
> 
> If there's a problem with this draft, it is that there is no 
> real way for the server to have any knowledge of the timezone 
> where the client happens to be (a client could send a request 
> to a particular DHCP server
> IP address is able to tell the server the timezone - we don't 
> map addresses into timezones, a network could easily span 
> several (just consider a large ATM LAN).
> 
> But all this means is that sometimes the server will have no 
> information to give the client, it isn't a reason to hold up 
> the draft.
> 
> kre
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 May 2003 14:48:09 -0500

> they also need to know what the local time was in the past.

Do we want to solve that problem, or is the POSIX solution sufficient 
to our needs?   I would argue that there is no solution we're going to 
come up with here that will adequately address the problem you're 
describing, and I don't know of any operating system that provides the 
capability to address the problem in the way you suggest even if DHCP 
somehow were able to communicate that information to it.   Certainly 
Unix and Linux don't.

> information that the client doesn't want or cannot understand.

The implication of this statement is that it's also okay to send 
arbitrary data in other options, even in contradiction of what the 
standard says the option should contain.   Or, really, you're saying 
that standards shouldn't specify the format of option data.   I don't 
think this is a good way to promote interoperability.

---

From: Robert Elz <[email-masked]>
Date: Tue, 20 May 2003 09:10:18 +0700

Date:        Mon, 19 May 2003 14:48:09 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | Do we want to solve that problem, or is the POSIX solution sufficient 
  | to our needs?

The draft already handles it, as much as need be handled.

  | and I don't know of any operating system that provides the 
  | capability to address the problem in the way you suggest even if DHCP 
  | somehow were able to communicate that information to it.   Certainly 
  | Unix and Linux don't.

Certainly they do.   You transmit America/New-York as  the timezone string
and Unix/Linux systems (well, many Unix, not all) will know that is
a different timezone than America/Detroit - even though both would be
described by an identical POSIX timestring to describe this year (or
last year, or lots of other years.)

Or Australia/Melbourne and Australia/Sydney just the same - this year
they're identical but not always (and more recently than the NY/Detroit 
differences).

  | The implication of this statement is that it's also okay to send 
  | arbitrary data in other options, even in contradiction of what the 
  | standard says the option should contain.

I have no idea how you read that into what I said.    Thomas was
complaining that sending data that the standard says the option can
contain (the draft, for now), which might not be understood by the
receiving host - and that that would cause interop proplems.  Not so.
This has nothing to do with sending data that the standard doesn't
say should be there.

Another example of this would be sending an address/netmask pair
that aren't a natural "classful" value to a host that is so ancient
that it doesn't understand classless addressing, and requires only
class A/B/C addresses (identified by the first few bits of the address).

Sending a classless address+mask to a classed address host would be
a configuration error on the part of the DHCP server (the server's
operator - the software obviously cannot know).    But this doesn't
mean that we outlaw sending classless address+mask just because some
host might not understand it - which was the logical implication of
Thomas' argument.

  | Or, really, you're saying that standards shouldn't specify the format
  | of option data.   I don't think this is a good way to promote
  | interoperability.

Not at all, which isn't what I said at all.   The draft specifies what
needs to be specified.

kre