Subject: [Ietf-behave] Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 24 Sep 2004 06:07:38 -0700 (PDT)

Dear IESG,

On Fri, 17 Sep 2004, The IESG wrote:
A new IETF working group has been proposed in the Transport Area. 
The IESG has
not made any determination as yet. The following description was 
submitted,
and is provided for informational purposes only. Please send your 
comments to
the IESG mailing list (iesg@xxxxxxxx) by September 24.
My apologies for responding at the last second...

I happen to agree with the current charter, as far as it goes.

I also note that there's a fascinating discussion (thread starts at 
http://www1.ietf.org/mail-archive/web/sip/current/msg10349.html on 
"GRUU and things that rewrite contacts", about the impact of Session 
Border Controllers on new features in SIP.

If I understand the meta-goal for BEHAVE, it's "write a BCP so NAT 
vendors stop breaking VoIP" (since classic TCP-based client-server 
protocols work passably well on NAT/ALGs).

BEHAVE declined the privilege (I think correctly) of defining BCP 
behavior for ALGs in general, but I expect that while BEHAVE is fixing 
NATs, the Internet will deploy SBCs with behavior just as destructive 
for VoIP as NATs, and we'll be back doing "Son of BEHAVE" in five 
years (and arguing whether it's worth doing, because of all the SBCs 
that are built into wireless APs, etc.). We could sidestep that agony 
by attacking the problem now (or "immediately after finishing a BCP 
for NATs", if you are worried about defocusing BEHAVE.

Maybe BEHAVE isn't the right WG to think about SBCs, but there sure 
are a lot of BEHAVE participants I recognize from 
SIP/SIPPING/SIMPLE/XCON... I would hate to see them wasting their time 
if we move from "can't deploy because of broken NAT behavior" to 
"can't deploy because of broken SBC behavior".

Spencer

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 28 Sep 2004 16:13:50 -0700 (PDT)

Session Border Controllers are most like HTTP proxies and FTP
proxies -- packets are generally sent to the IP address of
the SBC, much like most HTTP proxies and FTP proxies.  And,
like HTTP and FTP proxies, SBCs oftentimes change the content
of the packets.  

(There are invisible HTTP and FTP proxies, too, of course).

-d

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Spencer
> Dawkins
> Sent: Friday, September 24, 2004 6:08 AM
> To: iesg@xxxxxxxx
> Cc: IETF Behave Mailing List
> Subject: [Ietf-behave] Re: WG Review: Behavior Engineering for
> HindranceAvoidance (behave) (fwd)
> 
> 
> Dear IESG,
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave