RE: [dhcwg] AD Review: draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt

["Vijayabhaskar A K" <[e-mail]>]

Ralph,

I have submitted the draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt last
week. Still, it is not published, though I submitted nisconfig-03 and
timeconfig-03 together. Shall I proceed with the splitting up of the
drafts (or) shall I wait for timeconfig-03 to get published? I am
attaching the draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt along with
this mail. 

~ Vijay

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Ralph Droms
Sent: Tuesday, October 21, 2003 9:50 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [dhcwg] AD Review:
draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt


Seems to me we are closer to consensus on publishing the option for
(S)NTP 
servers than we are for the timezone configuration option.  Vijay, I 
suggest you split your current draft into two drafts, one for the (S)NTP

servers option (call it draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt if
you 
can publish it this week) and a new draft for the timezone option.  With

two documents, we can let each option proceed at its own pace...

- Ralph

At 12:59 AM 10/7/2003 +0530, Vijayabhaskar A K wrote:
>Hi Margaret
>
>Thanks for your very quick reply. My reply inline
>
>~ Vijay
>
> >
> > Hi Vijay,
> >
> > Thanks for your response.
> >
> > > > General question on this document:  We recently deprecated the 
> > > > option code allocation for the IPv4 version of this
> > option.  Why do
> > > > we think that there is a greater need for this in IPv4
> > than in IPv6?
> > > > Has anyone implemented these options?
> > >
> > > NTP version 4.0 available in www.ntp.org supports IPv6. Most of 
> > > the vendors provide this version and support NTP on IPv6. So,
> > it is really
> > > needed.
> >
> > Your response answers my concern about whether or not NTP is 
> > available for IPv6, but it doesn't answer my larger concern.
> >
> > We just deprecated the corresponding configuration options for IPv4,

> > because they weren't implemented.  Do we have some reason to believe

> > that people will implement this option for DHCPv6 when no one 
> > implemented the same option for IPv4?  If so, why?
>
>One of the two options specified in the draft has been already 
>standardized for IPv4. Refer RFC 2132, option code : 42, Network Time 
>Protocol Servers Option.
>
>There is an option called "Time offset" (option code: 2) defined in RFC

>2132. But, it could not convey enough information like day light 
>savings. Only to provide more information about the timezone, the  
>draft for "POSIX time zone option for DHCPv4" was written. Meanwhile, 
>There were few implementations providing this support in the vendor 
>specific options. One such example is Solaris's 
>"SUNW.posix-timezone-string" option. Hence, certainly there are few 
>users. Unfortunately, this draft was not advanced and got expired. As 
>most of the platforms provided this option in the form of vendor 
>specific options, nobody really bothered to restart the work and 
>advance it to the standard. Moreover, I could see alteast 2 
>implementation of DHCPv6, which have the support for POSIX time zone 
>option. (1) HPUX (2) KAME FreeBSD. What I am trying to say is, 
>Certainly keeping this as an vendor specific option may cause issues 
>while switching between the servers. Since, this option is used as 
>vendor specific option in few implementations of DHCPv4 and there are 
>implementations of DHCPv6 which support this option, its better to 
>standardize it.
>
> >
> > > > It is also my understand that we haven't (yet) specified how NTP

> > > > would run over IPv6, so this option may be premature.
> > >
> > > Since, there is actually no protocol changes are needed in 
> > > existing RFC for NTP, there is no specification for NTP on
> > IPv6. Its
> > > just like another application migration to IPv6. But, IPv6
> > version of
> > > NTP are available in various platforms. I don't think this
> > option is
> > > a premature one.
> >
> > Actually, there are several IPv4 dependencies in the NTP 
> > specification, as document in:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surve
> > y-apps-02.txt
> >
> > The folks who have implemented NTP for IPv6 must have worked around 
> > those dependencies, but I don't believe that their changes have been

> > document in an IETF specification (yet).
>
>The RFC it refers is version 3 of the SNTP protocol. The next version 
>deals with IPv6 also.
>
>         D. Mills.  Simple Network Time Protocol (SNTP) Version 4 for
>         IPv4, IPv6 and OSI.  Request for Comments (Informational)
2030,
>         Internet Engineering Task Force, October 1996.
>
> >
> > > > What is the reason for specifying a timezone format in this 
> > > > document, instead of relying completely on another establish 
> > > > standard for timezone representation?
> > >
> > > This flexibility is provided to help the vendors to use some other

> > > vendor specific database for timezone information. This is
> > needed, if
> > > they feel that their databases can convey more information
> > than POSIX
> > > time string.
> > [...]
> > > > What is a "timezone database"?  Is this a standard concept, or 
> > > > something you are assuming will be specific to each host? If the

> > > > latter, why do we need this flexibility?
> > >
> > > Its not a standard concept. Its something specific to the
> > OS. For the
> > > last question, you refer the prev answer.
> >
> > How do you maintain interoperability between the DHCP server and 
> > clients from multiple vendors, if the server may return the timezone

> > in an OS-proprietary format?
>
>Its basically through vendor-options/class ids. Based on the class-ids 
>the server can provide different information for the same entity to the

>different clients. This is the conventional methodology done from 
>DHCPv4 onwards.
>
> > You mentioned
> > earlier that this timezone information is set on a per-subnet basis,

> > with the assumption that all clients on the same subnet are in the 
> > same timezone.  Do you also assume that all clients on the same 
> > subnet are running the same OS?
>
>No, certainly not. There can be clients running different OS. But, they

>will be differentiated by the server.
>
> >
> > > > > To avoid attacks through these options, the DHCP client
> > SHOULD use
> > > > > authenticated DHCP (see section "Authentication of DHCP
> > messages"
> > > > > in the DHCPv6 specification [1]).
> > > >
> > > > Why only a "SHOULD"?  Given the critical nature of time
> > information
> > > > to some security protocols, I would prefer a statement that this

> > > > option MUST only be used when the DHCP messages are
> > authenticated.
> > > > Is there a reason not to say that?
> > >
> > > As such authentication is not mandatory in the DHCPv6 
> > > specification (RFC 3315) except for reconfiguration. That's the 
> > > reason why "MUST" is not used here.
> >
> > True, although we could require that DHCP security be implemented 
> > and used whenever certain sensitive options are in use...  I'm not 
> > sure what sort of policy has been used for deciding this in the
> > past, though.
> >
> > > > > [2]  D. Mills.  Simple Network Time Protocol (SNTP) Version 4 
> > > > > for IPv4, IPv6 and OSI.  Request for Comments
> > > > > (Informational) 2030, Internet Engineering Task Force, October

> > > > > 1996.
> > > >
> > > > This should be a reference to NTP, not to SNTP.
> > >
> > > Basically, the NTP servers I am referring are SNTP servers. I 
> > > believe, I could change the "NTP server option" to "SNTP server 
> > > option".
> >
> > If that is more accurate, then I think it would make sense to make 
> > that change.
> >
> >
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> >


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg