Re: [BEHAVE] draft-ietf-behave-lsn-requirements - BCP, STD, AS, or Informational?

["Reinaldo Penno (repenno)" <[e-mail]>]

Good point, some data in this regards:

All previous behave RFCs that 'standardized' NAT behavior are BCPs
(RFC4787, 5508, etc).

And they are have lots of MUSTs


On 7/19/12 9:37 AM, "David Harrington" <[e-mail]> wrote:

>-- BCP or not? --
>
>As previously-responsible AD for behave, I have had serious concerns about
>this document being published as a BCP.
> 
>
>In another email, I discussed whether PCP should be required to be
>compliant to this BCP.
>
>I think the IETF needs to decide whether lsn-requirements is something to
>be compliant to. The title and BCP status seem rather misleading, in my
>opinion. 
>Following RFC3365, MUST is for implementers; SHOULD is for deployers. If
>we want to require vendors to implement specific features in a manner
>COMPLIANT to this specification, then this really should be a standard,
>not a BCP. 
>If we want to standardize implementation behaviors, then I think this
>should be an explicit standard, not some other type of RFC that will
>implicitly be a standard but with possibly less scrutiny than an explicit
>standard would generate.
>
>
>A BCP often carries similar weight to a standard, and I question whether
>some of these requirements are best CURRENT practice, especially if PCP is
>a MUST. It might be best DESIRED practice, or best RECOMMENDED practice,
>but I doubt some of these requirements are best CURRENT practice. If we
>simply want to document what some existing deployments are doing, then I
>think an Applicability statement or an Informational RFC might be more
>appropriate than a BCP. I think this should be a BCP only if there is a
>strong consensus that this is the way deployments SHOULD be done, based on
>actual deployment experience by a variety of operators using current
>implementations - that would represent best CURRENT practices.
>
>
>--
>David Harrington
>Internet Engineering Task Force (IETF)
>[e-mail]
>[phone]
>
>
>
>
>
>On 7/19/12 8:51 AM, "Simon Perreault" <[e-mail]> 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 [e-mail].
>>
>>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 <[e-mail]>
>>Pour : Simon Perreault <[e-mail]>
>>Copie à : The IESG <[e-mail]>, <[e-mail]>,
>><[e-mail]>
>>
>>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
>>
>>-- 
>>[e-mail]
>>
>>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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/behave
>
>
>_______________________________________________
>Behave mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/behave