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
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
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-(Continue reading)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).
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-(Continue reading)donley-* is available at: http://tools.ietf.org/html/draft-boucadair-pcp-bittorrent-00 (various
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-(Continue reading)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
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)
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)
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.
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
RSS Feed45 | |
|---|---|
52 | |
13 | |
5 | |
48 | |
11 | |
7 | |
12 | |
27 | |
12 | |
46 | |
125 | |
33 | |
7 | |
57 | |
11 | |
54 | |
16 | |
135 | |
73 | |
75 | |
97 | |
52 | |
33 | |
82 | |
22 | |
323 | |
75 | |
72 | |
21 | |
57 | |
118 | |
113 | |
49 | |
101 | |
29 | |
53 | |
62 | |
189 | |
159 | |
212 | |
378 | |
181 | |
290 | |
231 | |
250 | |
413 | |
58 | |
122 | |
208 | |
183 | |
112 | |
33 | |
138 | |
623 | |
212 | |
62 | |
87 | |
202 | |
109 | |
183 | |
219 | |
142 | |
116 | |
156 | |
196 | |
71 | |
52 | |
75 | |
79 | |
212 | |
90 | |
75 | |
206 | |
82 | |
78 | |
57 | |
50 | |
45 | |
89 | |
55 | |
35 | |
56 | |
89 | |
156 | |
52 | |
87 | |
12 | |
24 | |
67 | |
19 | |
16 | |
15 | |
14 | |
141 | |
101 | |
116 | |
36 | |
95 | |
108 | |
10 |
