ietf
[Top] [All Lists]

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

2012-07-20 14:01:47
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" <ietfdbh(_at_)comcast(_dot_)net> 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)
Ietfdbh(_at_)comcast(_dot_)net
+1-603-828-1401





On 7/19/12 8:51 AM, "Simon Perreault" 
<simon(_dot_)perreault(_at_)viagenie(_dot_)ca> 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(_at_)ietf(_dot_)org.

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(_dot_)stiemerling(_at_)neclab(_dot_)eu>
Pour : Simon Perreault <simon(_dot_)perreault(_at_)viagenie(_dot_)ca>
Copie à : The IESG <iesg(_at_)ietf(_dot_)org>, 
<behave-chairs(_at_)tools(_dot_)ietf(_dot_)org>,
<draft-ietf-behave-lsn-requirements(_at_)tools(_dot_)ietf(_dot_)org>

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(_dot_)stiemerling(_at_)neclab(_dot_)eu

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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/behave


_______________________________________________
Behave mailing list
Behave(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/behave


<Prev in Thread] Current Thread [Next in Thread>