IETF Logo Mail Archive

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

Danny Mayer <mayer@ntp.org> Mon, 19 November 2007 04:01 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 1ItxpW-00069N-KE; Sun, 18 Nov 2007 23:01:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItxpW-00069H-6u for dhcwg@ietf.org; Sun, 18 Nov 2007 23:01:50 -0500
Received: from mx05.gis.net ([208.218.130.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItxpS-0004YV-UU for dhcwg@ietf.org; Sun, 18 Nov 2007 23:01:50 -0500
Received: from [10.10.10.100] ([63.209.224.211]) by mx05.gis.net; Sun, 18 Nov 2007 23:01:28 -0500
Message-ID: <474109FB.2080508@ntp.org>
Date: Sun, 18 Nov 2007 22:58:51 -0500
From: Danny Mayer <mayer@ntp.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Brian Utterback <Brian.Utterback@Sun.COM>
Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6
References: <A05118C6DF9320488C77F3D5459B17B7062ED3C6@xmb-ams-333.emea.cisco.com> <4733482A.7020302@sun.com> <A05118C6DF9320488C77F3D5459B17B70634E4E5@xmb-ams-333.emea.cisco.com> <4735A243.6090905@sun.com>
In-Reply-To: <4735A243.6090905@sun.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: ntpwg@lists.ntp.org, dhcwg@ietf.org, "Richard Gayraud (rgayraud)" <rgayraud@cisco.com>
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

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

I consider that it is most unlikely for the DHCP server to know the
delay. Consider DHCP server D, client C and NTP server N. Each are in
different locations on the physical wire (wireless and other medium are
  similar). D may know its own delay to N but C is elsewhere on the
wire. You might be able to figure out the delay between D and C but how
does it relate to the delay between C and N? They are in different
locations on the wire. Is C closer to N, further away, on another
segment of the network?

Danny

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

v2.23.0 | Report a Bug | By Email