Subject: [dispatch] Should IETF have a BEHAVE WG for SBCs?

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 1 Jul 2010 22:57:10 +0530

In the past few years there has been a proliferation of Session Border
Controller (SBC) deployments in SIP networks mainly because the
development of SIP protocol specifications hasn't been able to keep in
pace with industry and operator requirements. The common functions they
perform and the architectural issues they introduce are described in
RFC-5853.
 
Due to lack of well defined guidelines and best current practices many
SBC implementations break end-to-end features and introduce problems
that are difficult to troubleshoot, many a times because of poor
implementations rather than to meet any specific requirements. For
example, when they do media processing they assume everything coming on
the media channel is RTP, don't do even basic RTP header validations as
recommended in RFC-3550, try to decode STUN and DTLS packets as RTP
corrupting them and making them useless.
 
I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to
the one for NATs, to set guidelines and identify best current practices
to encourage better SBC implementations, interoperability and ease of
troubleshooting, rather than just keeping quiet and letting them go out
of control.
 
Comments?
 
Muthu

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 1 Jul 2010 14:10:08 -0400

On Jul 1, 2010, at 1:27 PM, Muthu ArulMozhi Perumal (mperumal) wrote:

> In the past few years there has been a proliferation of Session  
> Border Controller (SBC) deployments in SIP networks mainly because  
> the development of SIP protocol specifications hasn't been able to  
> keep in pace with industry and operator requirements. The common  
> functions they perform and the architectural issues they introduce  
> are described in RFC-5853.
>
> Due to lack of well defined guidelines and best current practices  
> many SBC implementations break end-to-end features and introduce  
> problems that are difficult to troubleshoot, many a times because of  
> poor implementations rather than to meet any specific requirements.  
> For example, when they do media processing they assume everything  
> coming on the media channel is RTP, don't do even basic RTP header  
> validations as recommended in RFC-3550, try to decode STUN and DTLS  
> packets as RTP corrupting them and making them useless.
>
> I am wondering whether IETF should have a BEHAVE WG for SBCs,  
> similar to the one for NATs, to set guidelines and identify best  
> current practices to encourage better SBC implementations,  
> interoperability and ease of troubleshooting, rather than just  
> keeping quiet and letting them go out of control.
>
> Comments?

I would support this. This area is a mess IMHO.

Regards
Marshall

>
> Muthu
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Thu, 1 Jul 2010 14:56:31 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Muthu ArulMozhi Perumal (mperumal) [[email-masked]]

I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to the one for NATs, to set guidelines and identify best current practices to encourage better SBC implementations, interoperability and ease of troubleshooting, rather than just keeping quiet and letting them go out of control.
________________________________________

This is a good idea.

Dale

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 1 Jul 2010 15:29:55 -0400

I concur.

There is some useful background in RFC5853 and perhaps
http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00

And then some things which died on the vine such as:
http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01
and perhaps some others?

I don't think any of these deal with RTP issues - so that would be
useful information.

Also, treatment of ICE etc. would be of interest.

Peter Musgrave

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Jul 2010 09:45:12 +0200

Hi,

If you think the reason for SBCs being deployed is the fact that "the development of the SIP protocol hasn't been able to keep in pace", isn't THAT the problem we should try to fix? What makes you think that this new WG would "be able to keep in pace"?

It took 3,5 (!!!!) years just to produce RFC 3550...

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Muthu ArulMozhi Perumal (mperumal)
Sent: 1. heinäkuuta 2010 20:27
To: DISPATCH list
Subject: [dispatch] Should IETF have a BEHAVE WG for SBCs?

In the past few years there has been a proliferation of Session Border Controller (SBC) deployments in SIP networks mainly because the development of SIP protocol specifications hasn't been able to keep in pace with industry and operator requirements. The common functions they perform and the architectural issues they introduce are described in RFC-5853.

Due to lack of well defined guidelines and best current practices many SBC implementations break end-to-end features and introduce problems that are difficult to troubleshoot, many a times because of poor implementations rather than to meet any specific requirements. For example, when they do media processing they assume everything coming on the media channel is RTP, don't do even basic RTP header validations as recommended in RFC-3550, try to decode STUN and DTLS packets as RTP corrupting them and making them useless.

Comments?

Muthu

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 2 Jul 2010 17:01:32 +0530

Hi Christer,
 
I am not sure whether we'll be able to keep in pace in the near term, but I think a focused WG that can come up with guideline and best current practices for SBCs to be more predictable, pay attention to end-to-end communication, feature interoperability and ease of troubleshooting can have a significant influence on current and future implementations, and lead us to a much better position in the longer run.
 
Isn't that better than just keeping quiet and letting the problem go out of control?
 
Muthu  
 
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, July 02, 2010 1:15 PM
To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list
Subject: RE: Should IETF have a BEHAVE WG for SBCs?

Hi,

 
Regards,
 
Christer

	

	 
	 
	Comments?
	 
	Muthu

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Jul 2010 14:53:52 +0200

Hi,

Could you describe what you think the problems are, and why you think they are caused by SBCs?

Regards,

Christer

________________________________
From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
Sent: 2. heinäkuuta 2010 14:32
To: Christer Holmberg; DISPATCH list
Subject: RE: Should IETF have a BEHAVE WG for SBCs?

Hi Christer,

Muthu

Hi,

Regards,

Christer

Comments?

Muthu

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 2 Jul 2010 09:46:55 -0400

> think they are caused by SBCs?

Whose SBCs ?

More fundamentally, what is an SBC ? What should it do ?

In my operational experience, I have seen a wide variety of answers to  
those questions. The 3GPP world may be an exception (I don't know),  
but from what I see SBC's are hard to interoperate with because first  
you have to figure out just what they are doing.

Now, maybe this is something that the IETF shouldn't get involved in,  
but it would be nice to have a standard that vendors followed, and I  
am not sure where else this would come from.

Regards
Marshall

> I am not sure whether we'll be able to keep in pace in the near  
> term, but I think a focused WG that can come up with guideline and  
> best current practices for SBCs to be more predictable, pay  
> attention to end-to-end communication, feature interoperability and  
> ease of troubleshooting can have a significant influence on current  
> and future implementations, and lead us to a much better position in  
> the longer run.
>
> If you think the reason for SBCs being deployed is the fact that  
> "the development of the SIP protocol hasn't been able to keep in  
> pace", isn't THAT the problem we should try to fix? What makes you  
> think that this new WG would "be able to keep in pace"?
>
> From: [email-masked] [mailto:[email-masked]]  
> On Behalf Of Muthu ArulMozhi Perumal (mperumal)

---

From: Tom Taylor <[email-masked]>
Date: Sat, 03 Jul 2010 16:08:23 -0400

Perhaps even a taxonomy would be helpful -- SBC vendors could check off which of 
the identified functions their box performs. Some functions may be susceptible 
to standardization, and perhaps others might not be.

Marshall Eubanks wrote:
> those questions. The 3GPP world may be an exception (I don't know), but 
> from what I see SBC's are hard to interoperate with because first you 
> have to figure out just what they are doing.
> 
> but it would be nice to have a standard that vendors followed, and I am 
> not sure where else this would come from.
> 
> Regards
> Marshall
> 
...

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 4 Jul 2010 21:05:26 -0400

Well the reasons SBC's exist is that the definitions of SIP in the RAI
directorate and 3GPP/IMS are out of control and since nature abhors a vacuum
SBC's fill that void at the edge of SIP networks. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of WORLEY, Dale R (Dale)
Sent: Thursday, July 01, 2010 2:57 PM
To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list
Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of
Muthu ArulMozhi Perumal (mperumal) [[email-masked]]

I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to the
one for NATs, to set guidelines and identify best current practices to
encourage better SBC implementations, interoperability and ease of
troubleshooting, rather than just keeping quiet and letting them go out of
control.
________________________________________

This is a good idea.

Dale

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 5 Jul 2010 20:36:59 +0530

RFC-5853 already describes some of problems caused by SBCs. However, it doesn't specify any guidelines or best current practices for addressing those problems. One of the most common problems is that they don't pass SIP/SDP hearers they don't understand, even if those headers have nothing to do with the policy configured at the SBC -- just poor implementation that breaks many end-to-end features. 
 
For example, the Session-ID header described in draft-kaplan-sip-session-id is one that a good SBC implementation will pass across to aid troubleshooting. There many other headers that need to be carefully considered with the requirements specified RFC-5853 to get guidelines or best practices for SBCs.
 
In essence what I am thinking is that IETF could have an umbrella BEHAVE-like WG for SBCs that can come with guidelines, best current practices, and new specifications (such as the notion of a SIP session and session-ID) that can help us to achieve more predictability, end-to-end feature interoperability and ease of troubleshooting with SBCs.
 
Muthu  
 
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, July 02, 2010 6:24 PM
To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list
Subject: RE: Should IETF have a BEHAVE WG for SBCs?
 
Hi,

Regards,
 
Christer

	 

	Muthu  

	Hi,

	 
	Regards,
	 
	Christer

		

		 
		 
		Comments?
		 
		Muthu

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Jul 2010 10:22:56 -0600

We had a BOF on pretty much this topic. Some people wrote drafts. There was pretty much no energy to even send comments on it and it was hard to find authors. It was eventually published as RFC 5853 and we all need to give Jani Hautakorpi a big thanks for that. 

The whole experience around 5843 does left me thinking that it was better to consider B2BUA in any draft and effected any type of UA including B2BUA. When we ask the question "should we make SBC interoperate better" we get a resounding yes from everyone. When asked so what do we need to change to make that happen we get a resounding "might do that some of the time but certainly not all the time from the SBC vendors". I like the idea of finding specific addressable problems such as Hadriels session-id stuff then going and figuring out how to fix that problem. If there are other specific problems that can be fixed, by all means write some drafts and get some proposals on the table. 

On Jul 1, 2010, at 11:27 AM, Muthu ArulMozhi Perumal (mperumal) wrote:

> Due to lack of well defined guidelines and best current practices many SBC implementations break end-to-end features and introduce problems that are difficult to troubleshoot, many a times because of poor implementations rather than to meet any specific requirements. For example, when they do media processing they assume everything coming on the media channel is RTP, don't do even basic RTP header validations as recommended in RFC-3550, try to decode STUN and DTLS packets as RTPcorrupting them and making them useless.
>  

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Jul 2010 12:10:32 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Musgrave
> Sent: Thursday, July 01, 2010 12:30 PM
> To: WORLEY, Dale R (Dale)
> Cc: DISPATCH list

http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-02 died.

-d

> > From: [email-masked] [[email-masked]] On Behalf
> Of Muthu ArulMozhi Perumal (mperumal) [[email-masked]]
> >
> > I am wondering whether IETF should have a BEHAVE WG for SBCs, similar
> to the one for NATs, to set guidelines and identify best current
> practices to encourage better SBC implementations, interoperability and
> ease of troubleshooting, rather than just keeping quiet and letting
> them go out of control.

---

From: [email-masked]
Date: Thu, 8 Jul 2010 10:16:02 +0800

Hi Cullen,

I agree most of your points, especially for the suggesting about finding 
specific addressable problems as the base of the work. This is a practical 
way.

But I have a tiny different point towards whether should B2BUA be 
discussed/defined in any draft and effected any type of UA including B2BUA 
or not. I'd like to see more and more BCP level draft/RFC about B2BUA, but 
I don't think any normative one need to define things for B2BUA as basic 
rules. To be mitigatory, normative one can/may define things for B2BUA, 
but should not be mandatory.

The reason why I think we should not make it as a mandatory rule, is that 
B2BUA is just usage of UAC/UAS rules and is just implementation level 
thing, not normative level thing. 
If the B2BUA behaves as the normatively defined UAC and UAS, it is OK. And 
B2BUA MUST make itself looks like a normal UAC or UAS from other sides' 
view. So, there's no need to do more rule/defintion for the B2BUA. And I 
do not prefer to see any normative text do more rule for B2BUA, and allow 
it do more or less things than normal UAC/UAS.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Cullen Jennings <[email-masked]> 
发件人:  [email-masked]
2010-07-08 00:22

收件人
Muthu ArulMozhi Perumal (mperumal) <[email-masked]>
抄送
DISPATCH list <[email-masked]>
主题
Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?

We had a BOF on pretty much this topic. Some people wrote drafts. There 
was pretty much no energy to even send comments on it and it was hard to 
find authors. It was eventually published as RFC 5853 and we all need to 
give Jani Hautakorpi a big thanks for that. 

The whole experience around 5843 does left me thinking that it was better 
to consider B2BUA in any draft and effected any type of UA including 
B2BUA. When we ask the question "should we make SBC interoperate better" 
we get a resounding yes from everyone. When asked so what do we need to 
change to make that happen we get a resounding "might do that some of the 
time but certainly not all the time from the SBC vendors". I like the idea 
of finding specific addressable problems such as Hadriels session-id stuff 
then going and figuring out how to fix that problem. If there are other 
specific problems that can be fixed, by all means write some drafts and 
get some proposals on the table. 

> Due to lack of well defined guidelines and best current practices many 
SBC implementations break end-to-end features and introduce problems that 
are difficult to troubleshoot, many a times because of poor 
implementations rather than to meet any specific requirements. For 
example, when they do media processing they assume everything coming on 
the media channel is RTP, don't do even basic RTP header validations as 
recommended in RFC-3550, try to decode STUN and DTLS packets as 
RTPcorrupting them and making them useless.
> I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to 
the one for NATs, to set guidelines and identify best current practices to 
encourage better SBC implementations, interoperability and ease of 
troubleshooting, rather than just keeping quiet and letting them go out of 
control.

Cullen Jennings

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Jul 2010 21:47:47 -0600

On Jul 7, 2010, at 8:16 PM, <[email-masked]> wrote:

> 
> Hi Cullen, 
> 
> I agree most of your points, especially for the suggesting about finding specific addressable problems as the base of the work. This is a practical way. 
> 
> But I have a tiny different point towards whether should B2BUA be discussed/defined in any draft and effected any type of UA including B2BUA or not. I'd like to see more and more BCP level draft/RFC about B2BUA, but I don't think any normative one need to define things for B2BUA as basic rules. To be mitigatory, normative one can/may define things for B2BUA, but should not be mandatory. 
> 
> The reason why I think we should not make it as a mandatory rule, is that B2BUA is just usage of UAC/UAS rules and is just implementation level thing, not normative level thing. 
> If the B2BUA behaves as the normatively defined UAC and UAS, it is OK. And B2BUA MUST make itself looks like a normal UAC or UAS from other sides' view. So, there's no need to do more rule/defintion for the B2BUA. And I do not prefer to see any normative text do more rule for B2BUA, and allow it do more or less things than normal UAC/UAS. 
> 
> Thanks, 
> 
> Gao 

That makes sense to me.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Jul 2010 14:26:40 +0200

Hi,

I agree.

The purpose of RFC 5843 was to identity what SBCs are doing, why they do it, and the potential problems it may cause, and then try to come up with standard mechanisms in order to solve specific problems.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cullen Jennings [[email-masked]]
Sent: Wednesday, July 07, 2010 7:22 PM
To: Muthu ArulMozhi Perumal
Cc: DISPATCH list
Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?

Cullen Jennings

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 8 Jul 2010 08:46:01 -0400

On Jul 8, 2010, at 8:26 AM, Christer Holmberg wrote:

> The purpose of RFC 5843

5843 ? I think you and Cullen mean rfc 5853,
Requirements from Session Initiation Protocol (SIP) Session Border  
Control (SBC) Deployments,
which indeed looks like a useful start here.

Regards
Marshall

> was to identity what SBCs are doing, why they do it, and the  
> potential problems it may cause, and then try to come up with  
> standard mechanisms in order to solve specific problems.
>
> Regards,
>
> Christer
>
> From: [email-masked] [[email-masked]] On  
> Behalf Of Cullen Jennings [[email-masked]]
> We had a BOF on pretty much this topic. Some people wrote drafts.  
> There was pretty much no energy to even send comments on it and it  
> was hard to find authors. It was eventually published as RFC 5853  
> and we all need to give Jani Hautakorpi a big thanks for that.
>
> The whole experience around 5843 does left me thinking that it was  
> better to consider B2BUA in any draft and effected any type of UA  
> including B2BUA. When we ask the question "should we make SBC  
> interoperate better" we get a resounding yes from everyone. When  
> asked so what do we need to change to make that happen we get a  
> resounding "might do that some of the time but certainly not all the  
> time from the SBC vendors". I like the idea of finding specific  
> addressable problems such as Hadriels session-id stuff then going  
> and figuring out how to fix that problem. If there are other  
> specific problems that can be fixed, by all means write some drafts  
> and get some proposals on the table.
>
>
>
>
>> problems that are difficult to troubleshoot, many a times because  
>> of poor implementations rather than to meet any specific  
>> requirements. For example, when they do media processing they  
>> assume everything coming on the media channel is RTP, don't do even  
>> basic RTP header validations as recommended in RFC-3550, try to  
>> decode STUN and DTLS packets as RTPcorrupting them and making them  
>> useless.
>>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 08 Jul 2010 08:49:47 -0400

http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-03 has just 
been submitted.

...

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Jul 2010 14:50:04 +0200

Hi,

>which indeed looks like a useful start here.

Correct.

At least that's what I meant :)

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 8 Jul 2010 08:59:58 -0600

On Jul 8, 2010, at 6:46 AM, Marshall Eubanks wrote:

> Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments,

oops - good catch. Yes I meant 5853

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Jul 2010 08:42:34 -0700

> From: Tom Taylor [mailto:[email-masked]]
> Sent: Thursday, July 08, 2010 5:50 AM
> To: Dan Wing
> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list'
> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-03
> has just been submitted.

Splendid.  I refer to the media latching in that document frequently.

Myself, I would be happier if IETF could find it possible to include
the acronym-that-must-not-be-spoken (SBC) in SBC-related 
specifications -- no matter if an SBC working group is formed or 
not.  Calling them 'middleboxes' is too vague to be useful, much
like "gateway" is too vague (a gateway to the PSTN?  a router?)  
Call a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an 
SBC an SBC.

-d

> On

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 8 Jul 2010 14:34:12 -0600

Seems reasonable. I think B2BUA is reasonable well defined. Care to put on your fire proof suit and propose a definition of what an SBC is?

Cullen Jennings

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Jul 2010 16:45:12 -0400

> Seems reasonable. I think B2BUA is reasonable well defined. Care to put on your fire proof suit and propose a definition of what an SBC is?

"An SBC is a B2BUA that acts in a proxy-like role but that may modify 
sip messages and associated media in ways that a proxy may not."

The above is half serious and half tongue-in-cheek.

	Thanks,
	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Jul 2010 14:31:24 -0700

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Thursday, July 08, 2010 1:34 PM
> To: Dan Wing
> Cc: DISPATCH list
> Seems reasonable. I think B2BUA is reasonable well defined. Care to put
> on your fire proof suit and propose a definition of what an SBC is?

  SBC:  a B2BUA that also terminates and originates media from user 
        agents or media from an adjacent SBC.

-d

> >>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-
> middleboxes-
> >> 02 died.
> >>>
> >>> -d
> >> ...
> >

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Thu, 8 Jul 2010 17:26:52 -0500

Doesn't the B2BUA term also implies media origination, and termination
capabilities ? It seems that the B2BUA term is already overloaded to
include SBC. 

Mo 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dan Wing (dwing)
Sent: Thursday, July 08, 2010 5:31 PM
To: Cullen Jennings (fluffy)
Cc: 'DISPATCH list'
Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?

> Seems reasonable. I think B2BUA is reasonable well defined. Care to 
> put on your fire proof suit and propose a definition of what an SBC
is?

-d

> >> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes
> >> -
> 03
> >> has just been submitted.
> >

> > like "gateway" is too vague (a gateway to the PSTN?  a router?) Call

> > a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an 
> > SBC.
> >
> > -d
> >
> >
> >> Dan Wing wrote:

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Jul 2010 20:10:28 -0400

> capabilities ? It seems that the B2BUA term is already overloaded to

The term "B2BUA" is distinguished by the minimality of its definition 
and the corresponding broadness of applicability. It neither implies nor 
forbids media processing.

The term SBC, as typically used, is somewhat narrower in scope that 
B2BUA, but is still incredibly broad. I certainly know of things that 
consider themselves to be SBCs that (at least sometimes) don't terminate 
media.

And certainly there are B2BUAs that *do* terminate media that you would 
not want to call an SBC. (E.g. a conference focus and mixer.)

	Thanks,
	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Jul 2010 17:29:45 -0700

> capabilities ?

But then we need a new term for a device that does not touch media, 
but does more than a SIP proxy (SIP proxy as defined by 
http://tools.ietf.org/html/rfc3261#section-16).

http://tools.ietf.org/html/rfc3261#section-6 already defines B2BUA,
and does not say it initiates a (media) 'session', nor does it say a 
SIP UAC or UAS initiates a 'session'.  

-d

> It seems that the B2BUA term is already overloaded to
> include SBC.
> 
> Mo
> 
> middleboxes
> Call

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Jul 2010 17:32:28 -0700

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, July 08, 2010 5:10 PM
> To: Mohammad Al-Taraireh (maltarai)
> Cc: Dan Wing (dwing); Cullen Jennings (fluffy); DISPATCH list

Putting on my BEHAVE hat, what we did in BEHAVE with problems like this
was invent new terms that are not already overloaded by marketing,
product feature checklists, and so on.

This resulted in some awkward phrases for BEHAVE, such as 'endpoint
independent filtering', but it's pretty accurate phrasing that doesn't
get everyone wrapped around the axle of terminology.

-d

---

From: [email-masked]
Date: Fri, 9 Jul 2010 08:38:09 +0800

By classification, B2BUA behaving SBC belongs to the set of B2BUA, the 
reverse is not true.

So, term of B2BUA itself would not have to have media origination, and 
termination capabilities.

Thanks,

Gao 

"Mohammad Al-Taraireh (maltarai)" <[email-masked]> 
发件人:  [email-masked]
2010-07-09 06:26

收件人
"Dan Wing (dwing)" <[email-masked]>, "Cullen Jennings (fluffy)" 
<[email-masked]>
抄送
DISPATCH list <[email-masked]>
主题
Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?

Mo 

-----Original Message-----

is?

-d

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 8 Jul 2010 21:44:21 -0400

On Jul 8, 2010, at 8:10 PM, Paul Kyzivat wrote:

> The term "B2BUA" is distinguished by the minimality of its  
> definition and the corresponding broadness of applicability. It  
> neither implies nor forbids media processing.
>
> B2BUA, but is still incredibly broad. I certainly know of things  
> that consider themselves to be SBCs that (at least sometimes) don't  
> terminate media.
>
> And certainly there are B2BUAs that *do* terminate media that you  
> would not want to call an SBC. (E.g. a conference focus and mixer.)

As I said, this area is a mess. Maybe the first task is to come up  
with a new name with a tight description.

Marshall

>
> 	Thanks,
> 	Paul
>
>> Mo -----Original Message-----
>>> Seems reasonable. I think B2BUA is reasonable well defined. Care  
>>> to put on your fire proof suit and propose a definition of what an  
>>> SBC
>> is?
>>  SBC:  a B2BUA that also terminates and originates media from  
>> user         agents or media from an adjacent SBC.
>> -d
>>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC  
>>>> an SBC.
>>>>
>>>> -d
>>>>
>>>>
>>>>> Dan Wing wrote:
>>>>>>> There is some useful background in RFC5853 and perhaps http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00
>>>>>>>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 8 Jul 2010 20:59:27 -0600

I look forward to Hadriel's take on all this.

Cullen Jennings

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 9 Jul 2010 10:30:32 +0530

If we go by their name and RFC-5853, then SBCs are B2BUAs that are
deployed at the border between two networks where network policies are
typically enforce. They typically terminate and re-originate both
signaling and media and perform the following type of functions:
1. Perimeter defense like access control, topology hiding, denial of
service (DoS) detection and prevention.
2. Functionality not available in the endpoints like NAT and firewall
traversal, protocol interworking/repair.
3. Traffic management including media monitoring/reporting.
4. Media encryption/decryption at the edge of the network where media is
carried unencrypted in the inner network.
5. Enforcing Quality of Service (QoS) like DSCP marking and queueing.

The problem that needs to be solved is, how to let them perform these
functions that are considered critical for enterprises and service
providers, in a more predictable way paying attention to end-to-end
communication, feature interoperability and ease of troubleshooting --
Hadriel's "session-id" is one leap in the troubleshooting direction.

Muthu 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf
|Of Cullen Jennings (fluffy)
|Sent: Friday, July 09, 2010 8:29 AM
|To: Paul Kyzivat (pkyzivat); Hadriel Kaplan
|Cc: DISPATCH list
|Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?
|
|
|I look forward to Hadriel's take on all this.
|
|
|On Jul 8, 2010, at 6:10 PM, Paul Kyzivat (pkyzivat) wrote:
|
|>
|>
|> Mohammad Al-Taraireh (maltarai) wrote:
|> > Doesn't the B2BUA term also implies media origination, and
termination
|> > capabilities ? It seems that the B2BUA term is already overloaded
to
|> > include SBC.
|>
|> The term "B2BUA" is distinguished by the minimality of its definition
|> and the corresponding broadness of applicability. It neither implies
nor
|> forbids media processing.
|>
|> The term SBC, as typically used, is somewhat narrower in scope that
|> B2BUA, but is still incredibly broad. I certainly know of things that
|> consider themselves to be SBCs that (at least sometimes) don't
terminate
|> media.
|>
|> And certainly there are B2BUAs that *do* terminate media that you
would
|> not want to call an SBC. (E.g. a conference focus and mixer.)
|>
|>         Thanks,
|>         Paul
|>
|> > Mo
|> >
|> > -----Original Message-----
|> > From: [email-masked] [mailto:[email-masked]]
On
|> > Behalf Of Dan Wing (dwing)
|> > Sent: Thursday, July 08, 2010 5:31 PM
|> > To: Cullen Jennings (fluffy)
|> > Cc: 'DISPATCH list'
|> > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?
|> >
|> >> -----Original Message-----
|> >> From: Cullen Jennings [mailto:[email-masked]]
|> >> Sent: Thursday, July 08, 2010 1:34 PM
|> >> To: Dan Wing
|> >> Cc: DISPATCH list
|> >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?
|> >>
|> >>
|> >> Seems reasonable. I think B2BUA is reasonable well defined. Care
to
|> >> put on your fire proof suit and propose a definition of what an
SBC
|> > is?
|> >
|> >   SBC:  a B2BUA that also terminates and originates media from user
|> >         agents or media from an adjacent SBC.
|> >
|> > -d
|> >
|> >
|> >> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote:
|> >>
|> >>>> -----Original Message-----
|> >>>> From: Tom Taylor [mailto:[email-masked]]
|> >>>> Sent: Thursday, July 08, 2010 5:50 AM
|> >>>> To: Dan Wing
|> >>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list'
|> >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?
|> >>>>
|> >>>>
http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes
|> >>>> -
|> >> 03
|> >>>> has just been submitted.
|> >>> Splendid.  I refer to the media latching in that document
|> > frequently.
|> >>> Myself, I would be happier if IETF could find it possible to
include
|> >
|> >>> the acronym-that-must-not-be-spoken (SBC) in SBC-related
|> >>> specifications -- no matter if an SBC working group is formed or
|> >>> not.  Calling them 'middleboxes' is too vague to be useful, much
|> >>> like "gateway" is too vague (a gateway to the PSTN?  a router?)
Call
|> >
|> >>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC
an
|> >>> SBC.
|> >>>
|> >>> -d
|> >>>
|> >>>
|> >>>> Dan Wing wrote:
|> >>>>>> -----Original Message-----
|> >>>>>> From: [email-masked]
|> >>>>>> [mailto:[email-masked]]
|> >>>> On
|> >>>>>> Behalf Of Peter Musgrave
|> >>>>>> Sent: Thursday, July 01, 2010 12:30 PM
|> >>>>>> To: WORLEY, Dale R (Dale)
|> >>>>>> Cc: DISPATCH list
|> >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?
|> >>>>>>
|> >>>>>> I concur.
|> >>>>>>
|> >>>>>> There is some useful background in RFC5853 and perhaps
|> >>>>>>
http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00
|> >>>>>>
|> >>>>>> And then some things which died on the vine such as:
|> >>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01
|> >>>>>> and perhaps some others?
|> >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-
|> >> middleboxes-
|> >>>> 02 died.
|> >>>>> -d
|> >>>> ...
|> >>> _______________________________________________
|> >>> dispatch mailing list
|> >>> [email-masked]
|> >>> https://www.ietf.org/mailman/listinfo/dispatch
|> >>
|> >> Cullen Jennings
|> >> For corporate legal information go to:
|> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
|> >>
|> >
|> >
|> > _______________________________________________
|> > dispatch mailing list
|> > [email-masked]
|> > https://www.ietf.org/mailman/listinfo/dispatch
|> > _______________________________________________
|> > dispatch mailing list
|> > [email-masked]
|> > https://www.ietf.org/mailman/listinfo/dispatch
|> >
|>
|
|
|Cullen Jennings
|For corporate legal information go to:
|http://www.cisco.com/web/about/doing_business/legal/cri/index.html
|
|
|
|_______________________________________________
|dispatch mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Jul 2010 13:07:28 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan Wing
> Sent: 09 July 2010 01:32
> To: 'Paul Kyzivat'; 'Mohammad Al-Taraireh (maltarai)'
> Cc: 'DISPATCH list'
> definition
[JRE] Yes, for example, B2BUAs can pass contact URIs and dialog identifiers transparently or map them, and I could imagine terms for these two types of behaviour would be useful. As already noted, B2BUAs can handle media or not handle media, and again we might benefit from having a couple of terms. Perhaps the BEHAVE-like activity should be on B2BUAs in general, rather than SBCs.

John

---

From: Brett Tate <[email-masked]>
Date: Fri, 9 Jul 2010 05:54:50 -0700

> Perhaps the BEHAVE-like activity should be 
> on B2BUAs in general, rather than SBCs.

As has been mentioned, there are a variety of B2BUA types.  If the activity is to apply to B2BUAs in general, the activity would need to recognize that the following types of B2BUA (or their services) exist and would remain.  Thus B2BUAs desiring to act mostly like proxies could benefit from the activity; however others because of configuration or otherwise might not be able to fully comply.

Some B2BUAs or their services intentionally attempt to restrict/control end-to-end functionality.  Ironically one reason may even be to improve interoperability.

Some B2BUAs or their services (such as discussed within RFC 3323) intentionally attempt to hide the correlation of the two call halves.

There are some B2BUAs (such as conference servers and gateways) that typically may not consider themselves to be B2BUAs even though they are connecting the call halves directly or indirectly through using other devices/protocols.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Jul 2010 09:18:30 -0400

Perhaps it would be worthwhile to begin creating a taxonomy of the more 
interesting sorts of B2BUAs. This wouldn't have been possible at the 
time 3261 was published. But by now there is a lot of experience and it 
seems there are a number of common forms evolving independently.
(Who will be the Linnaeus of B2BUAs?)

Then there might be a basis for further standardization of some of those 
when it seems useful/necessary in order to promote interoperability.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Jul 2010 18:23:14 +0200

Hi,

In my opinion the definitions of B2BUA and SBC are completely different.

B2BUA is normallly used as a SIP term, and describes an entity which acts as a UA towards each direction. What happens to SIP information (header field values, SDP etc) passing the B2BUA varies.

SBC is much more than SIP, and from a pure SIP perspective an SBC may in some cases even act as a normal SIP proxy, ie it does not touch the SIP information and does not do anything else "forbidden".

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Friday, July 09, 2010 4:18 PM
To: Brett Tate
Cc: 'DISPATCH list'
Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?

        Thanks,
        Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Jul 2010 20:43:56 +0200

Hi,

Rather than focus on node terminology, I think we should focus on the FUNCTIONS they perform, and see whether something can do done in order to avoid claimed interop problems etc, rather than arguing about whether the entity that performs the function shall be called B2BUA, SBC, Application Server, or something else...

Regards,

Christer

Sent: Friday, July 09, 2010 3:10 AM

        Thanks,
        Paul

>>>>>> [mailto:[email-masked]]
>>>> On
>>>>>> Behalf Of Peter Musgrave

---

From: Daryl Malas <[email-masked]>
Date: Wed, 14 Jul 2010 16:45:01 -0600

All,

Many if not all of the functions of an SBC have already been defined in one way or another.  An SBC is a "jack-of-all-trades" platform.  I think this is a slippery slope to try and define, and is a quagmire the IETF should stray from.  In some cases, SBCs are not even deployed on the edge of networks.

I agree that a B2BUA is different, but it could be considered a function of the SBC.  B2BUA's were created with the intention of breaking up the end-to-end environment, so creating rules to define allowances for the end-to-end environment will be challenging at best.

Regards,

Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Friday, July 09, 2010 12:44 PM
To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai)
Cc: DISPATCH list
Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?

Hi,

Regards,

Christer

> capabilities ? It seems that the B2BUA term is already overloaded to 

The term "B2BUA" is distinguished by the minimality of its definition and the corresponding broadness of applicability. It neither implies nor forbids media processing.

The term SBC, as typically used, is somewhat narrower in scope that B2BUA, but is still incredibly broad. I certainly know of things that consider themselves to be SBCs that (at least sometimes) don't terminate media.

And certainly there are B2BUAs that *do* terminate media that you would not want to call an SBC. (E.g. a conference focus and mixer.)

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Jul 2010 18:53:42 -0400

I won't comment on the rest of this right now,
but its not right to describe a B2BUA as a function of an SBC.
Rather, an SBC is a particular sort of B2BUA.
There are *many* sorts of B2BUA that have nothing in common with an SBC.

Its actually this sort of disagreement that would benefit from beginning 
a taxonomy of B2BUAs.

	Thanks,
	Paul

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 14 Jul 2010 20:05:32 -0400

Should we arrange a (true) Bar BOF (AKA DrinkTime) for this topic in  
Maastricht ?

Marshall

On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote:

> Its actually this sort of disagreement that would benefit from  
> beginning a taxonomy of B2BUAs.
>
> 	Thanks,
> 	Paul
>
> Daryl Malas wrote:
>> All,
>> Many if not all of the functions of an SBC have already been  
>> defined in one way or another.  An SBC is a "jack-of-all-trades"  
>> platform.  I think this is a slippery slope to try and define, and  
>> is a quagmire the IETF should stray from.  In some cases, SBCs are  
>> not even deployed on the edge of networks.
>> I agree that a B2BUA is different, but it could be considered a  
>> function of the SBC.  B2BUA's were created with the intention of  
>> breaking up the end-to-end environment, so creating rules to define  
>> allowances for the end-to-end environment will be challenging at  
>> best.
>> Regards,
>> Daryl
>> On Behalf Of Christer Holmberg
>> Rather than focus on node terminology, I think we should focus on  
>> the FUNCTIONS they perform, and see whether something can do done  
>> in order to avoid claimed interop problems etc, rather than arguing  
>> about whether the entity that performs the function shall be called  
>> B2BUA, SBC, Application Server, or something else...
>> Regards,
>> Christer
>> Behalf Of Paul Kyzivat [[email-masked]]
>>> Doesn't the B2BUA term also implies media origination, and  
>>> termination capabilities ? It seems that the B2BUA term is already  
>>> overloaded to include SBC.
>>> On Behalf Of Dan Wing (dwing)
>>>> to put on your fire proof suit and propose a definition of what  
>>>> an SBC
>>> is?
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Jul 2010 20:21:25 -0400

> Should we arrange a (true) Bar BOF (AKA DrinkTime) for this topic in 

I'm open to that, unless I run into conflicts.
(I'm too busy and unmotivated to do any organization of it.)

	Thanks,
	Paul

>>> Many if not all of the functions of an SBC have already been defined 
>>> in one way or another.  An SBC is a "jack-of-all-trades" platform.  I 
>>> think this is a slippery slope to try and define, and is a quagmire 
>>> the IETF should stray from.  In some cases, SBCs are not even 
>>> deployed on the edge of networks.
>>> allowances for the end-to-end environment will be challenging at best.
>>> Regards,
>>> Daryl
>>> Behalf Of Christer Holmberg
>>> Rather than focus on node terminology, I think we should focus on the 
>>> FUNCTIONS they perform, and see whether something can do done in 
>>> order to avoid claimed interop problems etc, rather than arguing 
>>> Of Paul Kyzivat [[email-masked]]
>>> and the corresponding broadness of applicability. It neither implies 
>>> nor forbids media processing.
>>> consider themselves to be SBCs that (at least sometimes) don't 
>>> terminate media.

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 15 Jul 2010 17:25:04 +0530

I love to join in this topic 

Thanks
Partha
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat (pkyzivat)
Sent: Thursday, July 15, 2010 5:51 AM
To: Marshall Eubanks
Cc: DISPATCH list; Daryl Malas
Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?

	Thanks,
	Paul

>> I won't comment on the rest of this right now, but its not right to 
>> describe a B2BUA as a function of an SBC.

>>> in one way or another.  An SBC is a "jack-of-all-trades" platform.  
>>> I think this is a slippery slope to try and define, and is a 
>>> quagmire the IETF should stray from.  In some cases, SBCs are not 
>>> even deployed on the edge of networks.
best.
>>> the FUNCTIONS they perform, and see whether something can do done in

>>>>>> Myself, I would be happier if IETF could find it possible to 
>>>>>> include the acronym-that-must-not-be-spoken (SBC) in SBC-related

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Jul 2010 15:57:45 +0200

I would try to join if there is no conflict.

John 

> [mailto:[email-masked]] On Behalf Of Marshall Eubanks
> Sent: 15 July 2010 01:06
> To: Paul Kyzivat
> > There are *many* sorts of B2BUA that have nothing in common 
> with an  
> > SBC.
> >

---

From: Daryl Malas <[email-masked]>
Date: Thu, 15 Jul 2010 08:57:14 -0600

I would try and join the discussion.  --Daryl 

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2010 6:06 PM
To: Paul Kyzivat
Cc: Daryl Malas; DISPATCH list
Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?

Should we arrange a (true) Bar BOF (AKA DrinkTime) for this topic in Maastricht ?

Marshall

On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote:

>> in one way or another.  An SBC is a "jack-of-all-trades"
>> platform.  I think this is a slippery slope to try and define, and is 
>> a quagmire the IETF should stray from.  In some cases, SBCs are not

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 15 Jul 2010 11:03:42 -0400

OK, here are the options I see

There is an informal Bar BOF list

http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78

Wednesday Lunch, thursday Lunch or Thursday before plenary are taken.

I would suggest

Monday night
Wednesday after plenary
Thursday after plenary
Friday Lunch

I would prefer Monday night, but these all WFM. Please let me know  
what you think.

Regards
Marshall

---

From: Daryl Malas <[email-masked]>
Date: Thu, 15 Jul 2010 09:25:27 -0600

I would prefer Monday night or Friday Lunch.

Regards,

Daryl 

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]] 
Sent: Thursday, July 15, 2010 9:04 AM
To: Elwell, John
Cc: Paul Kyzivat; DISPATCH list; Daryl Malas
Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?

I would suggest

Monday night
Wednesday after plenary
Thursday after plenary
Friday Lunch

I would prefer Monday night, but these all WFM. Please let me know what you think.

Regards
Marshall

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Jul 2010 13:02:01 -0400

> I would prefer Monday night, but these all WFM. Please let me know what 

Thurs aft plenary seems to be taken by E2MD.

The others work for me at the moment.

	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 16 Jul 2010 11:30:24 +0530

+1 

-----Original Message-----
Sent: Thursday, July 15, 2010 10:32 PM

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 16 Jul 2010 14:11:26 +0300

Hi,

the purpose of RFC 5853 was to identify functions that are currently
performed by SBCs and cause some type of problem. It was expected that
recommendations on how to perform those functions in a better way were
going to follow.

The parallelism with BEHAVE is clear. BEHAVE identified functions
performed by NATs (filtering and mapping) and recommended how they
should be performed to minimize problems related to those functions.

So, for example, if we find that the way current SBCs perform media
management causes problems, specifying how to properly implement that
particular function would make sense.

In addition to clarifying how to implement individual functions, it has
been suggested to come up with a taxonomy for SBCs. If people could
elaborate on the usefulness of such an exercise, that would be great.
For example, SBC type 1 could be defined as performing media management
and NAT binding maintenance while SBC type 2 could be defined as
performing media management and topology hiding. Do people think that
grouping individual functions in bundles to form a taxonomy be useful?

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Jul 2010 10:53:00 -0400

You can blame me for the recommendation about a taxonomy.
But I'm talking about a taxonomy of B2BUAs, not of SBCs.

In terms of scope the B3BUA:SBC relationship is analogous to the 
Animal:Hominid relationship.

I don't yet know if it is a task worth doing. But IMO the primary value 
it would bring is simply in making it easier for people to talk to one 
another about these things and have some confidence that they were 
talking about the same thing.

In my experience many people seem to think that all B2BUAs are similar 
to whatever one kind they have had experience with.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 17 Jul 2010 10:01:04 +0300

Hi Paul,

yes, coming up with common terminology may be useful in order to have
more effective and efficient communications.

Cheers,

Gonzalo

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 21 Jul 2010 11:36:11 -0400

OK, here are the tabulations :

> Wednesday Lunch, thursday Lunch or Thursday before plenary are taken.

Here are the respondents so far :

TME - Marshall
JE - John Elwell
DM - Daryl Malas
MB - Mary Barnes
PK - Paul Kyzivat
PR - Partr

Monday night - TME prefer, JE prefer, DM prefer, MB prefer*
Wednesday after plenary, JE Prefer, MB prefer
Thursday after plenary - JE avoid, MB prefer, PK & PR avoid (E2MD  
collision)
Friday Lunch - JE avoid DM prefer

* after the meeting, not after dinner

So, sifting through all of this, I come up with Monday night _before  
dinner_.

Does that seen OK, or should I set up a proper doodle ?

Regards
Marshall

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 21 Jul 2010 17:38:56 +0200

A proper Doodle would be better. I am also interested, and there may be
other. 

Dan

> Sent: Wednesday, July 21, 2010 6:36 PM
> To: Marshall Eubanks
> Wednesday after plenary, JE Prefer, MB prefer Thursday after 
> plenary - JE avoid, MB prefer, PK & PR avoid (E2MD
> collision)
> So, sifting through all of this, I come up with Monday night 
> _before dinner_.
> 
> >>>>>>>> include the acronym-that-must-not-be-spoken (SBC) in 
> >>>>>>>> SBC-related specifications -- no matter if an SBC 
> working group 
> >>>>>>>> is
> >>> formed or

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 21 Jul 2010 11:54:30 -0400

> A proper Doodle would be better. I am also interested, and there may  

Ask, and ye shall receive.

http://www.doodle.com/f5bniwsrsndr29y3

Please send this to other people / lists as you feel necessary.

Notes :

green = prefer this time
yellow = could make this time if  necessary
red = cannot make this time

I have separated the evening meeting possibilities into

- Just after the end of the IETF (i.e., AT or BEFORE dinner
- A little over 1 hour later (i.e., AFTER dinner)

If you think 1 hour is not enough for dinner, but prefer the after  
dinner time, please vote for after dinner anyway and send a comment to  
this list. If we pick an after dinner time, we might adjust the actual  
rendezvous time.

If you have another time, suggest it.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 22 Jul 2010 08:53:19 -0400

> http://www.doodle.com/f5bniwsrsndr29y3

I intend to close this by the end of the day today (East Coast US  
time), so please doodle if you haven't already.

So far, Monday evening is ahead.

Regards
Marshall

> dinner time, please vote for after dinner anyway and send a comment  
> to this list. If we pick an after dinner time, we might adjust the  
> actual rendezvous time.
>

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 24 Jul 2010 10:33:54 -0400

> Please send this to other people / lists as you feel necessary.

Based on the doodle, and with Mary Barnes acceptance (as she will not  
be able to attend), I think that
  we should meet just after the last session on Monday. (See the  
Doodle site for the votes.)

Do people want to make this a dinner meeting and, if so, in the MECC  
area or somewhere else ? Specific suggestions would be welcomed.

Please send agenda items if there is anything specific you want to  
discuss, but I thought we would keep this fairly informal.

Regards
Marshall

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 Jul 2010 11:43:36 -0400

Marshall Eubanks wrote:

> Based on the doodle, and with Mary Barnes acceptance (as she will not be 
> able to attend), I think that
>  we should meet just after the last session on Monday. (See the Doodle 
> site for the votes.)

Any idea *where* to meet? Perhaps in the ietf registration table area?
(Not having seen the facility yet, I don't know what else there is.)

> area or somewhere else ? Specific suggestions would be welcomed.

If we are meeting at 7:50, then unless its for dinner there may not be 
any dinner. So dinner sounds good to me.

I have no idea of where. I haven't done *any* homework on Mastricht.

	Thanks,
	Paul

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 24 Jul 2010 17:11:11 -0400

How about this

Lunch will be available from 11:00 to 15:00 Monday through Thursday in  
the
Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu will vary
throughout the week, but a sample of offered items is below:

Marshall

On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote:

>
>
> Marshall Eubanks wrote:
>
>> Based on the doodle, and with Mary Barnes acceptance (as she will  
>> not be able to attend), I think that
>> Do people want to make this a dinner meeting and, if so, in the  
>> MECC area or somewhere else ? Specific suggestions would be welcomed.
>
> If we are meeting at 7:50, then unless its for dinner there may not  
> be any dinner. So dinner sounds good to me.
>

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 25 Jul 2010 21:49:06 -0400

Sorry - please disregard that, as this will NOT be a lunch meeting.  
This is a dinner meeting.

I would suggest that we either

- eat at the NH hotel or
- take a taxi to the city center.

Regards
Marshall

On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote:

> How about this
>
> Lunch will be available from 11:00 to 15:00 Monday through Thursday  
> in the

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 26 Jul 2010 08:53:20 +0200

Hi Marshall,

the last session today ends at 19:40. Where and when exactly shall we meet?

Thanks,

Gonzalo

---

From: Daryl Malas <[email-masked]>
Date: Mon, 26 Jul 2010 02:54:32 -0600

Marshall,

I am pretty much just waiting for a decision to be made, and I will attempt to meet up for discussion on this topic.

Regards,

Daryl 

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]] 
Sent: Monday, July 26, 2010 3:49 AM
To: Marshall Eubanks
Cc: Paul Kyzivat; DISPATCH list; Daryl Malas
Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs?

- eat at the NH hotel or

Regards
Marshall

On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote:

> the Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu 
> will vary throughout the week, but a sample of offered items is below:
>
> Marshall
>
>>> not be able to attend), I think that we should meet just after the 
>>> last session on Monday. (See the Doodle site for the votes.)
>>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 26 Jul 2010 10:59:43 +0200

Sorry, I lost something in the chain. What day are we talking about? 

Dan

> [mailto:[email-masked]] On Behalf Of Daryl Malas
> Sent: Monday, July 26, 2010 11:55 AM
> To: Marshall Eubanks
> Cc: DISPATCH list
> I am pretty much just waiting for a decision to be made, and 
> I will attempt to meet up for discussion on this topic.
> 
> Regards,
> 
> Daryl 
>

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 26 Jul 2010 05:06:17 -0400

Let's meet at the giant white inflatable Tulip in front of  
registration (by the SIDN exhibit) at 1740 - 1750.

My cell is + 1 703 501 4376, in case you need to call.

Marshall

On Jul 26, 2010, at 4:54 AM, Daryl Malas wrote:

> Marshall,
>
> I am pretty much just waiting for a decision to be made, and I will  
> attempt to meet up for discussion on this topic.
>
> Regards,
>
> Daryl
>
>> in
>>>> MECC

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 26 Jul 2010 05:10:28 -0400

Today, Monday, at the end of the regular sessions. At the giant white  
tulip at registration.

Regards
Marshall

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Jul 2010 05:12:22 -0400

Marshall Eubanks wrote:
> Let's meet at the giant white inflatable Tulip in front of registration 
> (by the SIDN exhibit) at 1740 - 1750.
> 

Don't you mean 1940 - 1950 ???

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 26 Jul 2010 05:28:38 -0400

Yes

On Jul 26, 2010, at 5:12 AM, Paul Kyzivat wrote:

>>> I am pretty much just waiting for a decision to be made, and I  
>>> will attempt to meet up for discussion on this topic.
>>>
>>> Regards,
>>>
>>> Daryl
>>>

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 26 Jul 2010 10:47:02 -0400

> the last session today ends at 19:40. Where and when exactly shall  

Well, I put 1940 (AKA 7:40 PM) on the Doodle poll for that reason.

So, that's _when_ (obviously, we need to wait around a bit to collect  
stragglers).

I do not see an obvious session for everyone to be at - what if we  
meet just near the registration ? Say
at the SIDN "booth" with the big inflated tulip across from the  
registration desks.

Regards
Marshall

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 26 Jul 2010 16:53:18 +0200

Sure, let's meet there after the last session.

Cheers,

Gonzalo