Re: [Gen-art] Retry: Gen-ART LC review of draft-ietf-tcpm-tcpsecure-11.txt
I am fine with this too. (the new boilerplate that incorporates rfc3578 verbiage.) Thanks Mitesh -Original Message- From: Randall Stewart [mailto:r...@lakerest.net] Sent: Saturday, April 11, 2009 3:02 AM To: Brian E Carpenter Cc: Anantha Ramaiah (ananth); draft-ietf-tcpm-tcpsec...@tools.ietf.org; General Area Review Team; tcpm-cha...@tools.ietf.org; Lars Eggert Subject: Re: 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 ( in xml2rfc). > > If you can't be sure that all contributors agree, you have to add the > extra disclaimer ( 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] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
While this is certainly an interesting point, I don't really see that it is specific to the container option or that the container option adds any new or different issues? I don't see why this would hold up this draft (perhaps it is not holding it up)? Perhaps at most some statement(s) about the issue should be added to the draft. If there was no container option, the RG would have to extract those options it received that it thought where of interest to the client and pass them on when the client requested them. So, whether there is a container option or not does not change anything (it just makes it easier to deliver information the RG for its clients and to potentially deliver different information to the RG's clients from what is given the RG itself). The issue of how a multi-homed device decides to use sources of information is certainly an interesting one, but no different than what has existed for years with multi-homed clients. I guess one choice for those developing multi-interface RGs is to provide configuration for which interface(s) options are to be 'preferred' over others. In the simple case, this could be just a preference value that applies to any information from that interface. In more complex cases, one might envision policy that would indicate a preference on an option-by-option basis, with even the ability to merge data from multiple interfaces (in perference order). Though, this doesn't account for mobile RGs which might be connecting to vastly different services over the same interface(s) depending on where they are located (with the preferences for the interface changing based on the provider). - Bernie -Original Message- From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of Ralph Droms (rdroms) Sent: Friday, April 10, 2009 3:26 PM To: Scott Brim Cc: dhc WG; gen-art@ietf.org; black_da...@emc.com; i...@ietf.org Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Scott raises an interesting point about identifying the source of options when delivered to clients. BTW, Scott - what is "DHS"? 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 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 > > A
Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
How realistic is it anyway that an RG would get different *relevant* options on its different interfaces? This would seem to me to be an administrative error. Of course the broadcast address and subnet mask options might be different, but it doesn't make sense to send the RG, e.g., different name servers for each interface. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
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 add
Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
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 : > 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 : >>> >>> 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 decid
Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
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 : 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 "op
Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
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 t
