[dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

Brian Utterback <Brian.Utterback@Sun.COM> Wed, 14 November 2007 13:11 UTC

Return-path: <dhcwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsI1b-000351-LB; Wed, 14 Nov 2007 08:11:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqpLB-0006My-4k for dhcwg@ietf.org; Sat, 10 Nov 2007 07:21:33 -0500
Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqpL8-00068Q-Gd for dhcwg@ietf.org; Sat, 10 Nov 2007 07:21:33 -0500
Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAACLTmN010343 for <dhcwg@ietf.org>; Sat, 10 Nov 2007 12:21:29 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRA00201I35VF00@mail-amer.sun.com> (original mail from Brian.Utterback@Sun.COM) for dhcwg@ietf.org; Sat, 10 Nov 2007 05:21:29 -0700 (MST)
Received: from [192.168.1.5] ([71.168.64.220]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRA00JWTIBNWPE0@mail-amer.sun.com>; Sat, 10 Nov 2007 05:21:28 -0700 (MST)
Date: Sat, 10 Nov 2007 07:21:23 -0500
From: Brian Utterback <Brian.Utterback@Sun.COM>
In-reply-to: <A05118C6DF9320488C77F3D5459B17B70634E4E5@xmb-ams-333.emea.cisco.com>
To: "Benoit Lourdelet (blourdel)" <blourdel@cisco.com>
Message-id: <4735A243.6090905@sun.com>
MIME-version: 1.0
Content-type: text/plain; format="flowed"; charset="ISO-8859-1"
Content-transfer-encoding: 7bit
References: <A05118C6DF9320488C77F3D5459B17B7062ED3C6@xmb-ams-333.emea.cisco.com> <4733482A.7020302@sun.com> <A05118C6DF9320488C77F3D5459B17B70634E4E5@xmb-ams-333.emea.cisco.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071009)
X-Spam-Score: -1.0 (-)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
X-Mailman-Approved-At: Wed, 14 Nov 2007 08:11:04 -0500
Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud (rgayraud)" <rgayraud@cisco.com>
Subject: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Errors-To: dhcwg-bounces@ietf.org

Benoit Lourdelet (blourdel) wrote:
> Hello,
>
> A possible usage of all the NTP parameters specified in the new options
> is to configure router gateway . In that scenario, the goal of a Service
> Provider or an Enterprise IT  is to autoconfigure the gateway as much as
> possible, including some NTP client behavior, in order to keep the
> control. An additional benefit is that the gateway can be shipped to
> remote sites virtually without any configuration while keeping full
> control of the NTP behavior.
I'm sorry, but I still don't see it. Are you saying that the router
is a DHCP client and gets the server from DHCP? Okay fine,
but how does minpoll, maxpoll, I and B get used? I still
don't see the point of maxpoll here at all, that is, I don't even
get what it means to the client to get this value imposed.
See, minpoll says "do not poll more often than this",
but maxpoll would mean "do not poll less often than this".
This just doesn't make sense to me.

> Following that line of thought, I may still see a need for  "minpoll,
> maxpoll, I and B fields".
>   

Now, I could see the I and B meaning "do not do this" rather than "do 
this". If I and B are 0, then
it means to do whatever you want, but if they are 1, then do not do it. 
It doesn't
make sense to tell a client to use iburst when it wasn't going to 
anyway. Same with burts, although
in a strange set of ceircumstances I could imagine the need for burst 
being known centrally,
so maybe the B flag makes some kind of sense as is.
> Considering a central DHCP server, the use of remote-id [RFC4649] or
> just link-id may tell the server from where 
> the request is coming then giving it the knowledge of the delay to
> apply.
> In the case of a DHCP server hosted by the first hop, the DHCP server is
> well positioned to know the delay.
>
>   

Oh, agreed, it is possible for the delay to be known. But I just don't 
think it is likely
that it will ever be used correctly in that scenario. All I said is that 
it should generally
be left at 0 unless there is a good reason not to.

> Considering the current option format which includes more than IP
> addresses, the choice of multiple occurrences of the 
>  same option looks sensible. Should we reduce the new options to IPv6
> addresses only, a list makes more sense.
>
>   

Okay.

--blu

"You've added a new disk. Do you want to replace
your current drive,protect your data from a drive failure
or expand your storage capacity?"
- Disk management as it should be.
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.

Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg