Re: [Gen-art] Gen-ART review of draft-ietf-dhc-container-00
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. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Retry: Gen-ART LC review of draft-ietf-tcpm-tcpsecure-11.txt
Brian: Yes, I have asked Anantha (primary editor now) to change my contact address. Unfortunately he has not done so yet. R On Apr 10, 2009, at 7:17 PM, Brian E Carpenter wrote: And: Randy's address is wrong in the I-D, hence mail to the generic address doesn't reach him. draft-ietf-tcpm-tcpsecure-11-carpenter.txt -- Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Retry: Gen-ART LC review of draft-ietf-tcpm-tcpsecure-11.txt
I am cool with that... Anantha can you get Mitesh to respond to this too? R On Apr 10, 2009, at 11:31 PM, Brian E Carpenter wrote: On 2009-04-11 12:57, Anantha Ramaiah (ananth) wrote: Thanks for the responses. ... - when you mention disclaimer for pre-RFC5378 I am assuming this comes with the new boiler plate change. If yes, the new boiler plate changes would also be addressed. FWIW, this document has been circulating in the TCPM for the past 5 years! So not sure about pre-RFC 5378 etc., The question is, do all contributors to the draft agree to it being re-submitted under RFC5378 rules? If so, you just use the normal version of the new boilerplate (rfc ipr=trust200902 in xml2rfc). If you can't be sure that all contributors agree, you have to add the extra disclaimer (rfc ipr=pre5378Trust200902 in xml2rfc). At least, that's my non-lawyer understanding. Brian -- Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-dhc-container-00
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 ATT 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. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-dhc-container-00
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 ATT 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 i...@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Gen-art mailing list Gen-art@ietf.org
