Hi Ralph - Yup.. we've been at this way too long. On the matter at hand: Both of these documents allow a bit of twiddling with what gets sent to the ultimate end client. The DHCP relay agent does this indirectly by signally which branch of the network tree it exist in so the upstream DHCP server can serve addresses (and specific configuration options) to the client from the appropriate address pool. The container document does it by having an autonomous DHCP server in an RG fetch configuration options that can then be supplied to the client. What happens if you get a relay agent which inserts a relay agent option in the RG to SP DHCP query and the SP responds by returning the options related to that relay agent as well as the container related to the RG? Specifically, which options control if they are incompatible with each other? What happens if the RG is implemented using the third version of section 4 and the request passes through both the RG and the relay agent? (In the diagrams, the relay agent is between the RG and the SP DHCP - in a cable modem system it would be the cable modem termination system or CMTS). As I said - not sure this is an issue, but the lack of mention of 3046 seemed problematic. Mike At 07:09 AM 4/13/2009, Ralph Droms wrote: >Mike - Can you give a little more detail? I'm not sure I see how the >RFC 3046 options - passed between a relay agent and a server - would >interact with the container option. > >BTW, please feel free to join the conversation at any time. The SF >meeting marked the 20th year anniversary of the first dhc WG meeting >at IETF 13 in Cocoa Beach. I was looking at the list of attendees ... >and you were at that first meeting, so we welcome your input as a >charter member. > >Also, from the minutes of that first dhc WG meeting: > > We quickly decided to limit the scope of our discussion to "Internet > participants" with only a single interface. This decision allowed us > to avoid the "host versus gateway" and "multi-homed host" religious > wars... > >Guess we won't be able to duck the issue any more. > >- Ralph > >On Apr 11, 2009, at 4:00 PM 4/11/09, Michael StJohns wrote: > >>Sorry to stick my oar in, but does this or could this interact with >>the options specified in RFC3046 in an unexpected way? >> >>At 01:41 PM 4/11/2009, Ralph Droms wrote: >>>Scott - even knowing "which interface which DHCP information came >>>from" may not be enough for a device with multiple interfaces. Can >>>policies for merging information be written just based on the >>>characteristics of the interface - say, 3GPP versus 802.11, or IP >>>address of the interface - or does the device need to differentiate >>>between Verizon Wireless and Starbucks if I'm away from home? Or >>>differentiate between my AT&T femtocell and my home WiFi network? >>> >>>- Ralph >>> >>>On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote: >>> >>>>Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>>>Scott raises an interesting point about identifying the source of >>>>>options when delivered to clients. >>>>> >>>>>BTW, Scott - what is "DHS"? >>>> >>>>Sorry, DHCP server >>>> >>>>>The usual case - almost the only case today - is that there is a >>>>>single >>>>>upstream service provider and a single source of DHCP options to be >>>>>passed along to the client. In this scenario, there's no need to >>>>>pass >>>>>along any information identifying the source of the options. >>>>> >>>>>To allow for a multihomed subscriber network, I can imagine adding >>>>>a tag >>>>>that would be passed along with the options so the subscriber >>>>>client can >>>>>identify the source of each option. But, what would the client do >>>>>with >>>>>that information? How would the client interpret it? What is the >>>>>syntax >>>>>and semantics of the tagging? >>>>> >>>>>Taken a step farther, sourcing information might be required even >>>>>if >>>>>there is no intermediate RG and the contained option is not in >>>>>use. How >>>>>does a device with multiple interfaces make policy decisions about >>>>>information received on those multiple interfaces (which is pretty >>>>>much >>>>>the question Scott asks about the container option)? >>>>> >>>>>- Ralph >>>> >>>>Well put. It all comes down to where information is going to be >>>>merged. The case where a single RG client connected to multiple SP >>>>servers is essentially already covered by MIF/6man, they just need >>>>to >>>>document it. If the information is merged at the RG server, then >>>>the >>>>RG server should somehow know which interface which DHCP information >>>>came from. If all of the information is transparently passed to the >>>>consumer device, then it needs the tags as well. >>>> >>>>I don't know how the information could be usefully tagged -- the SP >>>>server's IP address doesn't sound like a good idea. The WG should >>>>decide if tagging should be included in the container syntax or >>>>added >>>>later (but documented now as needing study). >>>> >>>>I'm CCing MIF in case people there aren't on the ietf list. >>>> >>>>Thanks ... Scott >>>> >>>>> >>>>>On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>>>> >>>>>>I have been selected as the General Area Review Team (Gen-ART) >>>>>>reviewer for this draft (for background on Gen-ART, please see >>>>>>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>> >>>>>>Please wait for direction from your document shepherd >>>>>>or AD before posting a new version of the draft. >>>>>> >>>>>>Document: draft-ietf-dhc-container-00 >>>>>>Reviewer: Scott Brim >>>>>>Review Date: 7 April 2009 >>>>>>IESG Telechat date: 14 April 2009 >>>>>> >>>>>>Summary: >>>>>> >>>>>>This draft is on the right track but has open issues. >>>>>> >>>>>>Comments: >>>>>> >>>>>>More significant: >>>>>> >>>>>>I am concerned about multiple interface scenarios as are being >>>>>>discussed in MIF and 6MAN, where either the RG is multiply >>>>>>connected >>>>>>or the end device is. For a discussion of the sort of problems >>>>>>that >>>>>>lead to this concern, see (for example) notes from the MIF BOF at >>>>>>IETF74. >>>>>> >>>>>>- There must be a way to associate options with a particular >>>>>> upstream DHS they were obtained from, when the container is >>>>>>passed >>>>>> to the RG server and perhaps to the end device. This source >>>>>> information may or may not be in the container itself -- that's >>>>>>up >>>>>> to the WG to decide. If it is decided that the source >>>>>>information >>>>>> will not be part of the container syntax, at least the fact that >>>>>> it is necessary should be documented for people who ultimately do >>>>>> specify how container options are passed. >>>>>> >>>>>>- The SP server may have its ideas of how a consumer device should >>>>>> be configured, but it is not appropriate to say that the "SP >>>>>> server MUST be able to control which DHCP options are transmitted >>>>>> to the consumer device". The RG server may need to make >>>>>>decisions >>>>>> about information from multiple DHCP servers. Perhaps you could >>>>>> say that the SP server MUST be able to "provide information" to >>>>>> the RG server. >>>>>> >>>>>>Less significant: >>>>>> >>>>>>5.1 and 5.2 >>>>>> >>>>>> Alignment between the v4 and v6 descriptions would be better. The >>>>>> v4 description has "code" in the diagram and says that "code" is >>>>>> OPTION_CONTAINER_V4. The v6 description has >>>>>>"OPTION_CONTAINER_V6" >>>>>> in the diagram and says that "option-code" is >>>>>>OPTION_CONTAINER_V6. >>> >>>_______________________________________________ >>>Ietf mailing list >>>Ietf@xxxxxxxx >>>https://www.ietf.org/mailman/listinfo/ietf >> >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@xxxxxxxx >>https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf