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

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