Dave Thaler | 1 Jun 01:10 2012
Picon

May 17 interim meeting proceedings available

The minutes and slides from our May 17 webex interim are all posted at http://www.ietf.org/proceedings/interim/2012/05/17/behave/proceedings.html

Let me know if there are any corrections to the minutes.

-Dave

Dan Wing | 1 Jun 04:08 2012
Picon

BEHAVE interim conference call, June 21

BEHAVE will have a conference call interim meeting at 7am PDT on Thursday,
June 21.  Details on the conference call will be posted at
http://trac.tools.ietf.org/wg/behave/trac/wiki.  We expect the meeting to
last 1.5 - 2 hours.  If you want to be on the agenda, please send email to
behave-chairs <at> tools.ietf.org.

-d

Dan Wing | 1 Jun 04:14 2012
Picon

BEHAVE at IETF84

We requested a one hour slot for BEHAVE at IETF84 (Vancouver).

-d

mohamed.boucadair | 1 Jun 14:19 2012

Re: AD review of LSN requirements draft

Hi Simon, all,

>-----Message d'origine-----
>De : behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] 
>De la part de Simon Perreault
>Envoyé : jeudi 31 mai 2012 19:40
>À : Wesley Eddy
>Cc : draft-ietf-behave-lsn-requirements.all <at> tools.ietf.org; 
>behave <at> ietf.org
>Objet : Re: [BEHAVE] AD review of LSN requirements draft
>
>
>> (6) I think it would be good to have an advisory
>> reference to the issues in:
>> http://tools.ietf.org/html/draft-donley-nat444-impacts-03
>> and whether or not following the recommendations in this
>> document helps to avoid such issues.  The RFC 6269
>> reference already in the introduction is okay, but it
>> probably glosses over this topic too quickly.
>
>In addition to Dan's response, the draft-donley does not evaluate CGNs 
>that have a PCP server, which our draft requires. I think the 
>inclusion 
>of PCP would affect the results significantly.

Med: Agree. FWIW, an example of a detailed report for an application tested in draft-donley-* is available
at: http://tools.ietf.org/html/draft-boucadair-pcp-bittorrent-00 (various combinations are
tested including playing with the configuration of the BT clients to allow multiple connections from the
same IP).
(Continue reading)

Wesley Eddy | 1 Jun 14:41 2012

Re: AD review of LSN requirements draft

On 6/1/2012 8:19 AM, mohamed.boucadair <at> orange.com wrote:
> Hi Simon, all,
>  
> 
>> -----Message d'origine-----
>> De : behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] 
>> De la part de Simon Perreault
>> Envoyé : jeudi 31 mai 2012 19:40
>> À : Wesley Eddy
>> Cc : draft-ietf-behave-lsn-requirements.all <at> tools.ietf.org; 
>> behave <at> ietf.org
>> Objet : Re: [BEHAVE] AD review of LSN requirements draft
>>
>>
>>> (6) I think it would be good to have an advisory
>>> reference to the issues in:
>>> http://tools.ietf.org/html/draft-donley-nat444-impacts-03
>>> and whether or not following the recommendations in this
>>> document helps to avoid such issues.  The RFC 6269
>>> reference already in the introduction is okay, but it
>>> probably glosses over this topic too quickly.
>>
>> In addition to Dan's response, the draft-donley does not evaluate CGNs 
>> that have a PCP server, which our draft requires. I think the 
>> inclusion 
>> of PCP would affect the results significantly.
> 
> 
> Med: Agree. FWIW, an example of a detailed report for an application tested in draft-donley-* is
available at: http://tools.ietf.org/html/draft-boucadair-pcp-bittorrent-00 (various
(Continue reading)

Simon Perreault | 1 Jun 15:00 2012
Picon

Re: AD review of LSN requirements draft

On 2012-06-01 08:41, Wesley Eddy wrote:
>>>> (6) I think it would be good to have an advisory reference to
>>>> the issues in:
>>>> http://tools.ietf.org/html/draft-donley-nat444-impacts-03 and
>>>> whether or not following the recommendations in this document
>>>> helps to avoid such issues.  The RFC 6269 reference already in
>>>> the introduction is okay, but it probably glosses over this
>>>> topic too quickly.
>>>
>>> In addition to Dan's response, the draft-donley does not evaluate
>>> CGNs that have a PCP server, which our draft requires. I think
>>> the inclusion of PCP would affect the results significantly.
>>
>> Med: Agree. FWIW, an example of a detailed report for an
>> application tested in draft-donley-* is available at:
>> http://tools.ietf.org/html/draft-boucadair-pcp-bittorrent-00
>> (various combinations are tested including playing with the
>> configuration of the BT clients to allow multiple connections from
>> the same IP).
>
> I think it would be great to add a sentence in the justification of
> the PCP requirement to specifically say that it's intended to improve
> on prior CGN implementations that did not include PCP and were found
> to have problems with certain applications (with citations).

Makes sense.

We had this:

    Justification:  Allowing subscribers to manipulate the NAT state
(Continue reading)

Simon Perreault | 1 Jun 17:24 2012
Picon

Unjustified SHOULDs in CGN requirements

Dear BEHAVErs,

During AD review of draft-ietf-behave-lsn-requirements it was pointed 
out that many requirements are at the SHOULD level but do not include 
justification for why they are not MUSTs.

Here's a list of all unjustified SHOULDs (there are 18). I'm asking the 
WG for a justification for each of them. If a SHOULD isn't justified, 
I'm going to turn it into a MUST. Note that I'm not looking for a 
justification for the requirement itself. I'm looking for a reason why 
we're saying SHOULD instead of MUST.

(1) REQ-3: The CGN function SHOULD NOT have any limitations on the size
            nor the contiguity of the external address pool.  In
(2)        particular, the CGN function SHOULD be configurable with
            contiguous or non-contiguous external IPv4 address ranges.

(3) REQ-4: A CGN SHOULD support limiting the number of external ports
            (or, equivalently, "identifiers" for ICMP) that are assigned
            per subscriber.

(4)        A.  Limits SHOULD be configurable by the CGN administrator.

(5)        C.  Additionally, it is RECOMMENDED that the CGN include
                administrator-adjustable thresholds to prevent a single
                subscriber from consuming excessive CPU resources from
                the CGN (e.g., rate limit the subscriber's creation of
                new mappings).

(6) REQ-5: A CGN SHOULD support limiting the amount of state memory
(Continue reading)

ssenthil | 1 Jun 18:05 2012
Picon

Re: Unjustified SHOULDs in CGN requirements


On 6/1/12 11:24 AM, "Simon Perreault" <simon.perreault <at> viagenie.ca> wrote:

> Dear BEHAVErs,
> 
> During AD review of draft-ietf-behave-lsn-requirements it was pointed
> out that many requirements are at the SHOULD level but do not include
> justification for why they are not MUSTs.
> 
> Here's a list of all unjustified SHOULDs (there are 18). I'm asking the
> WG for a justification for each of them. If a SHOULD isn't justified,
> I'm going to turn it into a MUST. Note that I'm not looking for a
> justification for the requirement itself. I'm looking for a reason why
> we're saying SHOULD instead of MUST.
> 
> (1) REQ-3: The CGN function SHOULD NOT have any limitations on the size
>             nor the contiguity of the external address pool.  In

I would disagree with turning the above SHOULD to a MUST. The reason being
that the size of the pool is directly related to the resources in the box
memory and saying that the size of the pool MUST NOT be limited is
restrictive and makes the device vulnerable. You may want to separate the
size and contiguity and make the contiguity argument as a MUST and the size
argument as a SHOULD.

> (2)        particular, the CGN function SHOULD be configurable with
>             contiguous or non-contiguous external IPv4 address ranges.
> 
This can be changed to a MUST.

(Continue reading)

IESG Secretary | 1 Jun 22:49 2012
Picon

BEHAVE WG Virtual Interim Meeting, June 21, 2012

BEHAVE will have a conference call interim meeting at 7am PDT on Thursday,
June 21. Details on the conference call will be posted at
http://trac.tools.ietf.org/wg/behave/trac/wiki. We expect the meeting to
last 1.5 - 2 hours. If you want to be on the agenda, please send email to
behave-chairs <at> tools.ietf.org.
Dave Thaler | 2 Jun 03:07 2012
Picon

Last call: draft-ietf-behave-nat64-discovery-heuristic-09

This email initiates a two-week Working Group Last Call on 
draft-ietf-behave-nat64-discovery-heuristic-09, to conclude
Friday June 15th.   Hopefully that will give some time before
our next interim meeting to review the comments and
have proposed resolutions ready to discuss at the
June 21st interim meeting.

We need at least 5 reviewers to comment on the doc 
(even if just saying "loos good").

-Dave Thaler


Gmane