[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

draft-ietf-behave-lsn-requirements - BCP, STD, AS, or Informational?



-- 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)
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





[IETF Annoucements]     [IETF Obscurity Interest]     [IETF]     [IP Storage]     [Yosemite News]     [Linux]     [Pilates]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]

Add to Google