Hi, (I restricted this response to behave wg, since that is where lsn-requirements is chartered, not pcp wg; I added ietf@xxxxxxxx since this is about a DISCUSS relating to ietf consensus). I think we should mandate something if interoperability will break if it is not done. But if the port-control aspect can be achieved using proprietary protocols with no impact on cgn operations, then a specific protocol should not be mandated. -- REQUIREMENTS for COMPLIANCE -- I frequently refer to the logic in the "Strong Security" BCP (RFC3365), which makes a distinction between what MUST be implemented in a compliant implementation, and what SHOULD be used by operators for interoperability between network elements. If an operator wants to set up a lsn-requirements-compliant CGN in a multi-vendor environment, will it be problematic if vendor A uses A-style port control, vendor B uses B-style port control, vendor C uses PCP, vendor D uses MIDCOM-MIB, and vendor E uses Diameter NAT control? If so, then there would seem to be justification to specify that **to be compliant to the IETF lsn-requirements standard/BCP/InformationalRFC recommendation** PCP MUST be implemented, so it is AVAILABLE if an operator chooses to use it. If implementers don't implement it in product, it won't be there for operators to use to achieve interoperability. Of course, a similar argument might justify also requiring implementation of Diameter NAT control and the MIDCOM-MIB. Do we want to require one specific standard as THE solution required to be compliant to this lsn-requirements standard, or do we want to provide a toolkit of multiple must-implement standards plus advice about how to combine them, and a deployer gets to choose which to use together, or do we want to specify a toolkit of implementation-optional standards that might be available and a deployer needs to figure out how to make the available options work together? Requiring PCP for compliance does not mean a vendor is required to implement PCP, any more than a vendor is required to implement BGP, but if a vendor claims to be BGP compliant, then there are aspects of BGP, or other standards that BGP relies upon being present, that MUST be there. If an implementer wants to claim compliance to the NAT-MIB, they MUST also implement ifIndex (and presumably SNMP to access the MIB). If a vendor claims to be compliant to the lsn-requirements standard (or BCP or Informational RFCXXXX) then they MUST implement those aspects that are required for compliance. Now, in the security world, where security is a system-wide process, if using multiple algorithms can create hard-to-detect security holes, there is strong justification for REQUIRING specific protocols be used across devices/vendors to avoid introducing such holes into the system. And, in the security world, there is a whole community of attackers looking for those holes so they can take advantage of such weaknesses in the overall security system. If CGN interoperability is not significantly impacted by having multiple types of port forwarding or other middlebox algorithms rather than a single algorithm, other than extra work for operators, then we probably should not REQUIRE, but simply RECOMMEND a standards-based solution such as PCP. We should NOT require it just because we want to see vendors use our protocols; that is a market-driven decision to be made by vendors based on customer demand. -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@xxxxxxxxxxx +1-603-828-1401 On 7/19/12 8:51 AM, "Simon Perreault" <simon.perreault@xxxxxxxxxxx> wrote: >Behaviers, PCPers, > >During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was >filed regarding the PCP requirement. Details below. > >I think this DISCUSS needs to be discussed. So please discuss. > >Please reply to behave@xxxxxxxx. > >Thanks, >Simon > > >-------- Message original -------- >Sujet: Re: Martin Stiemerling's Discuss on >draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) >Date : Thu, 19 Jul 2012 10:46:42 +0200 >De : Martin Stiemerling <martin.stiemerling@xxxxxxxxx> >Pour : Simon Perreault <simon.perreault@xxxxxxxxxxx> >Copie à : The IESG <iesg@xxxxxxxx>, <behave-chairs@xxxxxxxxxxxxxx>, ><draft-ietf-behave-lsn-requirements@xxxxxxxxxxxxxx> > >Hi Simon, all, > >On 07/17/2012 11:11 PM, Simon Perreault wrote: >> Le 2012-07-17 16:42, Martin Stiemerling a écrit : >>>> Each and every CGN MUST have PCP and MUST follow the constraints. I'll >>>> fix the text in a later revision. >>> >>> Can we mandate a specific protocol to be used for this or can we only >>> mandate that such a type of protocol is being used? I don't see the >>>IETF >>> in the position to mandate this type of protocol for CGNs. >>> >>> There are other protocols out there which might be suitable. Note that >>>I >>> am co-author of some, but this isn't the reason for the question. I do >>> not get any reward if I promote these protocols. >>> >>> It is more: >>> do we need to constrain CGN deployments to a protocol (PCP) which is >>> developed right now, or are we open to existing or future protocols, or >>> whatever folks deploying this deem right? >>> >>> I would propose to change REQ-9 to : >>> REQ-9: A CGN MUST include a middlebox control protocol that allows >>> manipulation of CGN bindings with the following contstraints <list >>>items >>> A and B> >>> REQ-9a: If PCP is used these contstraints MUST be applied in addition >>>to >>> contraints A and B: >>> <list items C and D> >> >> That was discussed in IETF 81 (Québec). Here's the extract from the >> minutes: >> >> Stuart Cheshire: ietf has one port forwarding protocol, which >> is PCP, so we should require it by name > >There are multiple middlebox control protocols published by the IETF >(standards track and experimental) and I have not seen any call for >consensus on what **the** IETF's middlebox control is, neither I have >seen any RFC that states this. > >I do not see that an individual can declare IETF consensus based on his >own opinion. > > >> >> Dave Thaler: I agree. PCP doc is in final stages. > >Again, an opinion of an individual. Nothing wrong about it, but it does >not state IETF consensus. > >> >> There was consensus from the WG. In consequence, the text was changed >> from this (-02): >> >> A CGN SHOULD support a port forwarding protocol such as the >> Port Control Protocol [I-D.ietf-pcp-base]. >> >> to this (-03): >> >> A CGN SHOULD include a Port Control Protocol server >> [I-D.ietf-pcp-base]. >> >> (That requirement later became a MUST, but that's orthogonal to what >> protocol we require.) > >I do not see that the IETF can mandate what protocols are being used to >control a device. The market will decide! > >For instance, the is no MUST required that routers implement BGP. It is >good to do this, but if one decides to go for IS-IS (or whatever) that >is just fine. > >Another example, there is also no MUST requirement that routers, or >hosts in general, have to implement SNMP. > >However, I can see the immediate need to mandate that a CGN SHOULD/MUST >support a middlebox control protocol that is able to install and >maintain NAT bindings. > > Martin > >-- >martin.stiemerling@xxxxxxxxx > >NEC Laboratories Europe - Network Research Division NEC Europe Limited >Registered Office: NEC House, 1 Victoria Road, London W3 6BL >Registered in England 283 > > >_______________________________________________ >Behave mailing list >Behave@xxxxxxxx >https://www.ietf.org/mailman/listinfo/behave