Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt

Paul Duffy <paduffy@cisco.com> Thu, 17 October 2002 16:56 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17702 for <dhcwg-archive@odin.ietf.org>; Thu, 17 Oct 2002 12:56:44 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HGx0Q04676 for dhcwg-archive@odin.ietf.org; Thu, 17 Oct 2002 12:59:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HGx0v04673 for <dhcwg-web-archive@optimus.ietf.org>; Thu, 17 Oct 2002 12:59:00 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17699 for <dhcwg-web-archive@ietf.org>; Thu, 17 Oct 2002 12:56:43 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HGw3v04618; Thu, 17 Oct 2002 12:58:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HGvTv04586 for <dhcwg@optimus.ietf.org>; Thu, 17 Oct 2002 12:57:29 -0400
Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17635 for <dhcwg@ietf.org>; Thu, 17 Oct 2002 12:55:12 -0400 (EDT)
Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-253.cisco.com [161.44.149.253]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA12392; Thu, 17 Oct 2002 12:57:21 -0400 (EDT)
Message-Id: <4.3.2.7.2.20021017123314.02862720@funnel.cisco.com>
X-Sender: paduffy@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 17 Oct 2002 12:57:21 -0400
To: Thomas Narten <narten@us.ibm.com>
From: Paul Duffy <paduffy@cisco.com>
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt
Cc: dhcwg@ietf.org
In-Reply-To: <4.3.2.7.2.20021016112408.02a0a348@funnel.cisco.com>
References: <200210111700.g9BH0dH08214@rotala.raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
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>

Thomas,

Pall's comment re: unicasting a REQUEST prompted me to re-read the relevant 
section of 2131 and the PacketCable MTA prov spec.  I now have a better 
sense of where the confusion is rooted...

>> >   8.1. TSP's DHCP Server Address Sub-Options
>>
>>Seems to me that this options does (however subtly) modify DHC client
>>behavior. My understanding is that CCC option 1/2, which
>>lists a primary/backup DHC server are sent to the CM, which then
>>communicates those two addresses to the MTA (a separate entity). The
>>MTA then invokes DHC on its own, but is only allowed to talk to the
>>servers whos addresses it received from the CM. In normal DHC, the
>>client isn't restricted in anyway in what servers it communicates
>>with. Thus, I would argue that CCC options 1/2 do modify the DHC
>>protocol, albeit subtly and perhaps not signficantly. I am not
>>particularly comfortable with this, but would like to hear more from
>>the WG on this point. (Also, is my understanding here correct?)
>
>RFC 2131 Section 4.4.1 "The time over which the client collects messages 
>and the mechanism used to select one DHCPOFFER are implementation 
>dependent".   PacketCable does not feel CCC.1/.2 in any way modifies the RFC.

The PacketCable MTA prov spec, as it is currently worded, could give the 
reader the impression that an MTA unicasts its DHCP REQUEST to a specific 
server identified via CCC.1/.2.  This is not the intent, nor how the 
present implementations currently operate.

The MTA applies CCC.1/.2 as a filter to all received OFFERS, selects one, 
then broadcasts its REQUEST (per RFC 2131).

PacketCable is modifying the MTA prov spec (in the next few days) to 
clearly state that the REQUEST is broadcast.

Good point Pall !

Cheers,




--

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com


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