Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7

From: "Francois Audet" <[email-masked]>
Date: Mon, 27 Jun 2005 10:57:55 -0700 (PDT)

I'm sorry Bryan, but after seeing the arguments over and over again, it
seems to me that we have more people in favour of the MAY versus the SHOULD.
There is not much I can do about it.

We did have one NAT  vendor resist STRONGLY the SHOULD. We did NOT have NAT
vendors resist the MAY.

I will leave it as a MAY, and mark it as an Open issue for now.

Cheers.

> -----Original Message-----
> From: Bryan Ford [mailto:baford@xxxxxxx] 
> Sent: Sunday, June 26, 2005 15:04
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Saikat Guha'; 'Behave'
> Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7
> 
> 
> On Thursday 23 June 2005 23:03, Francois Audet wrote:
> > I think it is time for closure on REQ-7a.
> >
> > I have opted for the MAY in 7a because it doesn't look like 
> we can get 
> > consensus for the SHOULD.
> 
> I still don't see any consensus on the MAY version either.  I 
> am not the only 
> one who has spoken for promoting EF=I filtering or 
> configurability.  With 
> MAY, that item says absolutely nothing and is useless.  
> Absolutely anything 
> MAY be configurable; no one needs to be told that.
> 
> I continue to have STRONG OBJECTIONS to the publication of a 
> BEHAVE document 
> that further legitimizes the existing trend toward NATs 
> having "hard-coded" 
> EF=A filtering behavior and which seriously reducing Internet 
> connectivity 
> for all users, regardless of whether they or their NAT 
> administrator feels 
> the functionality/security tradeoff is justified.  While the 
> existence of 
> EF=A filtering may be unavoidable for the moment, hard-coding 
> it into NATs is 
> by no means necessary, and doing so runs counter to the basic 
> connectivity 
> principles the Internet was built on and which this working group was 
> intended to promote.
> 
> The ONLY objections I have heard to my proposal are based on 
> arguments that 
> NAT implementors will find the proposed SHOULD recommendation 
> seriously 
> troublesome, and that they would use that one "troublesome" 
> recommendation as 
> an excuse not to adopt the BEHAVE specification at all.  Yet 
> the _ONLY_ NAT 
> vendor who has actually spoken up on this topic on the list (Suresh) 
> confirmed my claim that making filtering behavior 
> configurable, as proposed, 
> should be easy for any NAT that has already implemented EF=A 
> filtering.
> 
> If a NAT vendor actually exists who will vehemently resist 
> making filtering 
> behavior configurable, then please get them on this list and 
> let's hear their 
> objections.  Otherwise, I'm frankly tired of listening to and 
> refuting long 
> arguments about what objections some other people _not_ 
> participating on this 
> list _might_ have and what they _might_ do.  So please write the 
> configurability recommendation as a SHOULD for now, and let's 
> see if any NAT 
> vendor actually resists.
> 
> Thanks,
> Bryan
> 
>

---

From: Bryan Ford <[email-masked]>
Date: Thu, 30 Jun 2005 00:01:40 -0700 (PDT)

On Monday 27 June 2005 19:57, Francois Audet wrote:
> seems to me that we have more people in favour of the MAY versus the
> SHOULD. There is not much I can do about it.

How did you figure that?  If we're counting votes, then from the recent 
discussion on this thread here's how it looks to me:

SHOULD: 3 - me, David, Suresh
MAY: 2 - you (presumably), Saikat

Cullen objected to the earlier "user-configurable" language, but hasn't said a 
peep since we changed the language to "administrator-configurable" 
specifically to address that concern.  At any rate, at the moment I see no 
clear majority in favor off MAY.  So let's see what the situation actually is 
- if you're right, then I'll shut up and we can all have blessed peace (or a 
different battle :)).

So I'm calling a vote on REQ-7(a).  Everyone who has an opinion on this and 
isn't already in the tally above (or who I may have mis-tallied), please 
express it - all your message needs to have is the above subject line and an 
obvious "MAY" or "SHOULD" in the body.  To review:

MAY := "a) The filtering behavior MAY be an option configurable by the 
administrator of the NAT."

SHOULD := "a) The filtering behavior SHOULD be an option configurable by the 
administrator of the NAT."

I propose giving a week - say through July 6 - for the votes to trickle in.

> We did have one NAT  vendor resist STRONGLY the SHOULD. We did NOT have NAT

I don't remember any such statement by a NAT vendor here - can you point me to 
the relevant message on the list?

Thanks,
Bryan

---

From: David Barrett <[email-masked]>
Date: Thu, 30 Jun 2005 01:09:19 -0700 (PDT)

Bryan Ford wrote:

SHOULD := "a) The filtering behavior SHOULD be an option configurable by the 
administrator of the NAT."
Bryan tallied my vote correctly, but just so there's no confusion:

I vote "SHOULD".