On 7/19/12 9:02 AM, "Sam Hartman" <hartmans@xxxxxxxxxxxxxxxxxxxxx> wrote: >I think that behave-lsn-requirements is far more useful if it names a >specific protocol by name. By endorcing one of our middlebox protocols, >we encourage interoperability. If we don't pick a protocol by name, we >don't really promote interoperability. It's not useful if your CGN does >midcom and my client does PCP and I'm your customer. The assumption >behind LSN-requirements is that the CGN and the CPE are not >controlled/purchased/whatever by the same entity. So, mandating a >specific protocol seems desirable. The IETF could mandate a specific protocol to try to ensure interoperability, but doing this takes the decision out of the responsibility of the deployer to choose the best solution for the deployment environment, and out of the responsibility of the vendor to best meet their customers' demands. Some vendors already support an SNMP-based environment, and a CGN-NAT-MIB might best meet their needs. Some vendors might support a Netconf environment and desire a Netconf-based configuration solution. Some vendors already use AAA widely to control their environment, and Diameter NAT control might be preferable. Some vendors might be implementing the (not yet IETF-approved) PCP standard, and would prefer that solution. > >I think that the behave WG is the right place to make that decision. >The IETF as a whole should be able to second guess behave, but we should >need a fairly high bar for doing so. I think that **within IETF**, behave wg might have the right expertise to make this decision (technical comparison of middlebox protocols by protocol designers). Of course, no current WG has much input from proponents of the original MIDCOM WG strategy, and most Diameter proponents are not very active in behave wg. And behave DOES have an overlap between the PCP developers and behave solutions. So behave WG might be rather biased toward a specific solution (not that the bias is necessarily bad, but the bias should be recognized). Of course, if CGN is only an ipv4 exit strategy, as is asserted, then sunset4 would seem the appropriate choice, so we have one consistent ipv4 exit strategy. We already recognize that different wgs are developing ipv4 exit strategies that conflict; that's why a sunset4 wg has been approved. And if CGN **is** only for ipv4-sunsetting, a "this IETF recommendation becomes obsolete on such-and-such a date" might be appropriate for lsn-requirements. The right expertise might be in the sunset4 wg, which might have increased operator input about a complete ipv4/ipv6 transition deployment strategy rather than middlebox protocol design comparisons by middlebox protocol designers. While I would love to see consensus for a good interoperable solution, and would support ***A*** standard that says "to be compliant to THIS specification, use THIS middlebox proposal", I hesitate to say "this is the ONLY middlebox standard that is recommended or usable within IETF standards" - especially if that only recommended part has little or no actual field experience to back up the RECOMMENDED, and little or no documentation has been done of the suitability/useability in various environments of the existing IETF standards that would become NOT RECOMMENDED. I think the right place to make the decision about which midcom solution should be used in a particular environment is in the market. My cable provider lets me purchase/control my cable router (to a degree), but only certain routers are supported. I can choose which cable router offers the additional functionality/control I want for my environment. My provider has input to the decision, and so do I (to a limited extent). Of course, to a limited extent, I can also choose a different provider or get less support from my provider. > >The claim that PCP is the IETF's only protocol in this space does seem a >little bit on the wishful thinking side of things. So, I could >understand if the IESG wanted to ask behave to spend a little more time >on the question. +1 (or ask sunset4 to spend a little more time on the question). David Harrington ietfdbh@xxxxxxxxxxx +1-603-828-1401