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 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf