Subject: RE: [Speermint] Speermint Charter (now re SBCs)

From: "Medhavi Bhatia" <[email-masked]>
Date: Mon, 3 Apr 2006 10:51:51 -0400

Hi Jason,

Our focus at this point should be trying to keep it simple and
practical. Commercial choices (whether to use SBCs, firwewalls or SIP
proxies) for peering should be kept out of scope of the charter. The
specification of any sort of architecture can be very consuming at this
point and the usefulness is quite limited.

I suggest starting with the following simple use cases which have no
architecture implications or dependencies:

- Direct peering between Core-O and Core-T
	o Technology required (ENUM/DNS, SIP Requirements)
- Peering with IXP in the middle
	o Technology required (ENUM/DNS, SIP Requirements)

In addition, the role of federations and IXPs needs to be well
documented since that affects the technology we develop or use.

-Medhavi.

> -----Original Message-----
> From: Livingood, Jason [mailto:[email-masked]]
> Sent: Monday, April 03, 2006 8:41 AM
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: RE: [Speermint] Speermint Charter (now re SBCs)
> 
> 
> > To your question of "does it matter if they go through SBCs
> > for our work?"
> > So, to your actual question: it depends.  If the end goal of
> > this WG is to define BCPs of call flows for peering, then
> > that's easy: someone can just send an ethereal trace. :)  If
> > it's to define best future (vs.
> > current/common) practices, then yes it may hit issues if the
> > reality (from my perspective) isn't taken into account.  It's
> > like talking about IP peering without acknowledging routers
> > exist.  The irony from my perspective is what SBCs do
> > "differently" is used by many for very valuable
> > peering-related benefits.
> 
> I suspect this issue will continue to arise every so often as it has
> before (which is okay, by the way; continued discussion is generally a
> signal of a lack of consensus).  IMHO, the architecture and BCPs
> proposed will need to show how you can do SIP peering without and with
> session border elements.  There are some domains that will not want to
> use them, and some that will want to use them.  And even where a
domain
> prefers to use such an element, it may be application-specific such
that
> it is perhaps used for SIP-VoIP but not for SIP-IM.
> 
> Anyway, I think the point is that I don't expect we'll try to dictate
> that session border elements absolutely must or must not be used.  For
> some domains with particular requirements (business, IP networking, IP
> addressing, whatever), for some applications, such elements may make
> sense and may be considered.  For those that feel strongly about the
> fact that use of such elements are not a good trend, we should be able
> to spell out how a domain can meet all of their requirements and
deploy
> a SIP peering architecture without them if they so choose (and so
we'll
> ask for your constructive assistance on such work).  Thus, we first
> describe requirements, then we describe all of the different
> architecture options that would accomodate those requirements, and
then
> implementers better understand all of the issues and can make
decisions
> based on this expert information as well as their own particular
needs.
> 
> Jason
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.4/299 - Release Date:
3/31/2006

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: David Meyer <[email-masked]>
Date: Mon, 3 Apr 2006 11:50:11 -0700

Medhavi,

> practical. 

	Exactly.

> Commercial choices (whether to use SBCs, firwewalls or SIP

	I agree, at least initially.

> documented since that affects the technology we develop or use.

	Do you think we need to add terminology (to the
	terminology draft) for these last 2?

	Dave