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 > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
