Hi, Ralph, I agree what you said here, Scott raised the possible issue how to differentiate the source.
One instant thinking about the two different 802.11 interface is that the principal source policy selection will not be able to tell the diffference, we could allow high level policy to recommend how to handle it, give a example, we may prioritize some wifi apn policy, and make others as just a category of normal wifi. Anyhow, those thing need to be further studied based on the current practice. Thanks for the discussion. -Hui 2009/4/13 Ralph Droms <rdr...@cisco.com>: > Hui - I think there is an issue for hosts with multiple interfaces triggered > by Scott's comments about the container option: even if a host is physically > aware that it has multiple interfaces, how does it take the characteristics > of the networks behind those interfaces into account when it merges > information? For example, would a host process information received from a > Starbucks network over its 802.11 interface differently from information > received a home network over the 802.11 interface? > > - Ralph > > On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote: > >> Hi, Scott, >> >> Based on the current MIF charter proposal, it consider only host. >> http://www.ietf.org/mail-archive/web/mif/current/msg00367.html >> I am wondering whether RG is a kind of host? >> >> Anyhow, this discussion benefit MIF for the future consideration how >> to identify the source. >> >> Many thanks >> >> -Hui >> >> 2009/4/11 Scott Brim <s...@employees.org>: >>> >>> 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. >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dh...@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf