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

Paul Duffy <> Thu, 17 October 2002 16:56 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id MAA17702 for <>; Thu, 17 Oct 2002 12:56:44 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id g9HGx0Q04676 for; Thu, 17 Oct 2002 12:59:00 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g9HGx0v04673 for <>; Thu, 17 Oct 2002 12:59:00 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA17699 for <>; Thu, 17 Oct 2002 12:56:43 -0400 (EDT)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id g9HGw3v04618; Thu, 17 Oct 2002 12:58:03 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g9HGvTv04586 for <>; Thu, 17 Oct 2002 12:57:29 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA17635 for <>; Thu, 17 Oct 2002 12:55:12 -0400 (EDT)
Received: from ( []) by (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA12392; Thu, 17 Oct 2002 12:57:21 -0400 (EDT)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 17 Oct 2002 12:57:21 -0400
To: Thomas Narten <>
From: Paul Duffy <>
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


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 !



Paul Duffy
Cisco Systems, Inc.

dhcwg mailing list