Subject: RE: [Speermint] NATs and Firewalls

From: "Malas, Daryl" <[email-masked]>
Date: Tue, 4 Apr 2006 11:16:20 -0600

Totally agree!!!  Anyone who was configuring firewalls back in the day
when ARIN was giving away subnets like candy should definitely
understand the difference.  Thanks for the reminder...

Daryl M.

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Tuesday, April 04, 2006 11:15 AM
To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; [email-masked]
Subject: [Speermint] NATs and Firewalls

I think some people out there either do not understand
the difference between NATs and firewalls or are starting
to believe their own propaganda
 
NATs are NATs and firewalls are firewalls
 
The worst misconception here is that a NAT is for providing you security
against the bad Internet
 
Private adress spaces have been introduced to save a scarce ressource
(or what some believed are a scarce ressource at some point of time)
 
You can live very safe behind a properly configured firewall using only
public IP adresses.
 
The basic idea of IPv6 was to give every device on earth and also
within the solar system a unique public IP address
 
But the fake security of NATs was already in the minds of
most people, that the first things that were implemented
in IPv6 where NATs for IPv6, which is a perversion
 
Geoff Huston had once a nice eleborate on this in an IETF paper
 
Richard

________________________________

Von: Hadriel Kaplan [mailto:[email-masked]]
Gesendet: Di 04.04.2006 18:22
An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno';
[email-masked]
Betreff: RE: [Speermint] Reachability

Hi Richard,
And here we get to the fun stuff.  :)

The idea of every serving proxy/registrar/sip-node needing to be
publicly
addressable is neither an Internet requirement, nor a requirement of the
IETF.  Entire working groups in the IETF concern themselves with
allowing,
enabling, and inter-working private address spaces and VPNs.  What's
missing
is how to join them at the application and transport layer, when that
application layer embeds addressing in itself. 

Most consumers on the planet Earth are in private address spaces at this
point I think (i.e., 192.168.x.x), and many Enterprises are as well.
Entire
networks in some countries are privately addressed, yet they are members
of,
and use, the Internet.  There are also now 2 disjoint address groups
defined
by the IETF, as you know: IPv4 and IPv6.  There are mechanisms to try to
provide interoperation/migration support for them, but that typically
requires intermediaries.

So I agree with you there needs to be an entity providing an ingress
(and
egress) point(s), either on the public network for it to be public, or
for
it to cross into another private address domain.  For this WG's purpose,
I
recommend we allow either model to work, as well as the model of the
private
going to public (and vice-versa) so long as the peering element of both
sides are in the same public or private space.

-Hadriel

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 9:55 AM
> To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan;
[email-masked]
> Subject: Re: [Speermint] Reachability
>
> >The conclusion here -- every endpoint and every serving
proxy/registrar
> >needs to be publicly addressable.
>
> This was my basic assumption, and I seemed not so clear to everybody.
> This was also why I had a problem with Sohel's presentation at the
IETF,
> because I did not see any public adressable entities AT ALL.
>
> For the avoidance of doubt: I have no problem if the same peering
> principles we develop here are used between some entities in a private
> network,
> but it is not out task to consider this separately. Because if it
works
> on the Internet, it also works in a private network (extranet in this
> case)
> (see DNS). this private network may even use public IP adresses, but
if
> the
> are not routable from the public Internet, they are could as well be
> private
> (example IPX)
>
> What never can work is a peering between one entity on the public
network
> and one on a private network. The private entities need at least to
have
> one
> ingress element on the public network
>
> Richard
>
> ________________________________
>
> Von: Patrick Melampy [mailto:[email-masked]]
> Gesendet: Di 04.04.2006 15:29
> An: 'Reinaldo Penno'; 'Hadriel Kaplan'; [email-masked]
> Betreff: RE: [Speermint] Reachability
>
>
>
> Reinaldo -- I agree with your assertions.
>
> But I want to ensure everybody understands what your really saying
here.
>
>   Before somebody mentions it...for a UA behind a NAT to be reachable,
>   he/she needs a public NAT binding so that a session _initiated_ from
the
>   public side can be made to him/her.
>
> This means that for carrier to carrier peering models, each and every
> customer of every carrier that wants to inter-connect needs to have a
> 'public NAT binding'.
>
> I believe by extension, this means that a serving proxy/registrar for
the
> target of a communication must ALSO have either a public address or a
> public
> NAT binding.
>
> The conclusion here -- every endpoint and every serving
proxy/registrar
> needs to be publicly addressable.
>
> Am I correct?
> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 5:29 AM
> To: Hadriel Kaplan; [email-masked]
> Subject: RE: [Speermint] Reachability
>
> Hello Hadriel,
>
> Comment inline....
>
> > -----Original Message-----
> > From: Hadriel Kaplan [mailto:[email-masked]]
> > Sent: Monday, April 03, 2006 11:01 PM
> > To: Reinaldo Penno; [email-masked]
> > Subject: RE: [Speermint] Reachability
> >
> > Hi Reinaldo,
> > Comments inline...
> >
> > > -----Original Message-----
> > > From: Reinaldo Penno [mailto:[email-masked]]
> > >
> > > Maybe I'm missing something, but given that this workgroup is
> interested
> > > only in call routing (E.164 is out of scope), do we really need to
> care
> > > about that? An AoR in the end will be translated to an IP address,
> and
> > > IP addresses have a very good definition of public and private (in
> IPv4
> > > and IPv6).
> >
> > I don't understand fully what you mean.  An AoR is only fully
> "translated"
> > to an IP Address (and really to a contact URI) by the AoR's domain.
> So
> > what
> > you're saying is if the AoR's user-part represents a consumer behind
a
> > home
> > NAT (a private IP), then it is a private AoR; but for those
consumers
> who
> > don't use home-NATs then it's a public AoR?
> [[Reinaldo]]
>
> Hello,
>
> Actually I'm trying to understand the whole purpose of the discussion,
> that's why I gave that example. I was trying to understand why it
> matters, before getting knee deep into the classification. Can someone
> refresh that for me?
>
> So, if SIP peering is going to get woven into the fabric of the
> internet, the rules for domains names, DNS resolution, private vs.
> public IP address, etc should apply, right?
>
> I believe the current model of host to host or email communication is
> not different for SIP. We could have the following main
> situations...(correct me where I'm wrong).
>
> 1) The AoR (just like a traditional domain name or email), in the end
> will get resolved into an IP address. Then there are only two
> situations.
>
>    a) the IP address is private (RFC 1918).
>
>    This means the SIP endpoint is unreachable unless you are also in
the
> same private network. Actually I believe a private IP address cannot
> even be provisioned in a public DNS.
>
>    Before somebody mentions it...for a UA behind a NAT to be
reachable,
> he/she needs a public NAT binding so that a session _initiated_ from
the
> public side can be made to him/her.
>
>    b) the IP address is public.
>
>    The SIP endpoint is theoretically reachable.
>
> 2) The AoR cannot get translated. Again, just like the Internet we
have
> today, this means the domain name/user is private, does not exist, etc
>
> All this has been happening okay with just a few basic rules. If an
AoR
> is very similar to an email address, why it would not work with the
> current infrastructure/definitions?
>
> If somebody says that they have a "private" email address or domain
> name, what is your interpretation of that?
>
> Regards,
>
> Reinaldo
>
>
>
>
>
>
>  And if the AoR gets
> > translated
> > into an IP by a registrar inside a private IP subnet, and somehow it
> later
> > gets translated into the public IP address space, that's also
private
> > because the AoR was translated to a private IP originally?
> >
> > Or maybe you mean what the domain part of the AoR resolves to?
> >
> > > For you to be "SIP reachable", you need to be IP reachable first,
> let's
> > > not forget about that. And if you are IP reachable, you could
> > > potentially be SIP reachable by registering to some free SIP
service
> (or
> > > the SIP "domain" above you in the hierarchy...if this was the
> email/DNS
> > > model).
> >
> > Actually, to be very specific ultimate target of the AoR can be "sip
> > reachable" but not IP reachable.  But I think for now we should
ignore
> the
> > implications of that, unless it becomes a problem.
> >
> > -hadriel
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
>
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
>

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

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

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Wed, 5 Apr 2006 09:44:46 -0500

In future, SBC functions may be distributed in different network
components.
(Please review my presentation in IETF-63 Paris VoIP Peering BOF).
We need to define peering entities as functions (e.g., Signaling Peering
Function, Media Peering Function, ...)
(Please review my presentation in IETF-65 Dallas SPEERMINT wg).

Thank you.

Sohel Khan, Ph.D.
Technology Strategist
Sprint-Nextel

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 7:34 AM
To: [email-masked]
Subject: Re: [Speermint] NATs and Firewalls

And if people avoided using the term "SBC" anywhere in RAI, that would
be lovely, too, for exactly the reasons that Keith cited (we don't get
smarter in other RAI working groups :-)

Thanks,

Spencer

From: "Drage, Keith (Keith)" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, April 05, 2006 4:23 AM
Subject: RE: [Speermint] NATs and Firewalls

> And to support Richard on this.
>
> Please avoid using the term "SBC" in the speermint area. Please 
> clearly identify the function of these supposed wonder boxes that you 
> are addressing as an area of concern or advantage. Therefore if you 
> mean NAT, say NAT, if you mean firewall, say firewall, if you mean 
> something else, say so. These boxes contain so many features (in the 
> widest sense of the
> word) that in the absence of specific information we get lost.
>
> regards
>
> Keith

---

From: "Malas, Daryl" <[email-masked]>
Date: Wed, 5 Apr 2006 09:01:23 -0600

Well, in IMS terms, the closest stated term is IMS ALG.  Since, I do not
like that term, because it limits the capability of the element; I
commonly refer to the device simply as an IP MG (Media Gateway).  This
eliminates the need to place a frame work around the function.

--Daryl

-----Original Message-----
From: Peter Macaulay [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 7:59 AM
To: Drage, Keith (Keith); [email-masked]
Subject: RE: [Speermint] NATs and Firewalls

Agree.  Let's avoid the term "SBC" in the speermint area.  We don't
need the history lesson and the term is still evolving.  I just finished
a Skype call and did not use a SBC to peer with my one in 6 million
users.

Yes, let's just define the requirements ... Edge Proxy, NAPT, Media
Proxy,
Security Firewall and NAT/firewall traversal.

/PETER MACAULAY

At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote:
>clearly identify the function of these supposed wonder boxes that 
>you are addressing as an area of concern or advantage. Therefore if 
>you mean NAT, say NAT, if you mean firewall, say firewall, if you 
>mean something else, say so. These boxes contain so many features 
>(in the widest sense of the word) that in the absence of specific 
>information we get lost.
>
>regards
>
>Keith
>
> > Sent: 04 April 2006 18:15
> > The idea of every serving proxy/registrar/sip-node needing to
> > be publicly
> > IETF.  Entire working groups in the IETF concern themselves
> > with allowing,
> > enabling, and inter-working private address spaces and VPNs.
> > What's missing
> > point I think (i.e., 192.168.x.x), and many Enterprises are
> > as well.  Entire
> > networks in some countries are privately addressed, yet they
> > are members of,
> > and use, the Internet.  There are also now 2 disjoint address
> > groups defined
> > So I agree with you there needs to be an entity providing an
> > ingress (and
> > egress) point(s), either on the public network for it to be
> > public, or for
> > it to cross into another private address domain.  For this
> > WG's purpose, I
> > recommend we allow either model to work, as well as the model
> > of the private
> > > This was also why I had a problem with Sohel's presentation
> > at the IETF,
> > > but it is not out task to consider this separately. Because
> > if it works
> > > (see DNS). this private network may even use public IP
> > adresses, but if
> > > the
> > > What never can work is a peering between one entity on the
> > public network
> > > and one on a private network. The private entities need at
> > least to have
> > > one
> > > But I want to ensure everybody understands what your really
> > saying here.
> > >
> > >   he/she needs a public NAT binding so that a session
> > _initiated_ from the
> > > I believe by extension, this means that a serving
> > proxy/registrar for the
> > > > you're saying is if the AoR's user-part represents a
> > consumer behind a
> > > > home
> > > > NAT (a private IP), then it is a private AoR; but for
> > those consumers
> > > who
> > >    This means the SIP endpoint is unreachable unless you
> > are also in the
> > > he/she needs a public NAT binding so that a session
> > _initiated_ from the
> > > 2) The AoR cannot get translated. Again, just like the
> > Internet we have
> > > All this has been happening okay with just a few basic
> > rules. If an AoR
> > > > gets translated into the public IP address space, that's
> > also private
> > > > > potentially be SIP reachable by registering to some
> > free SIP service
> > > (or
> > > > reachable" but not IP reachable.  But I think for now we
> > should ignore
> > > the

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 5 Apr 2006 11:15:10 -0400

The one problem that I have with the term IP Media Gateway is the
assumption that signaling and media will traverse the element.  The
focus needs to be on the signaling.  I understand the logical evolution
of the Media Gateway from it's historical roots, but we have to leave
the bearer/media out of this working group's charter.

-AU

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 11:01 AM
To: Peter Macaulay; Drage, Keith (Keith); [email-masked]
Subject: RE: [Speermint] NATs and Firewalls

--Daryl

-----Original Message-----
From: Peter Macaulay [mailto:[email-masked]]
Sent: Wednesday, April 05, 2006 7:59 AM
To: Drage, Keith (Keith); [email-masked]
Subject: RE: [Speermint] NATs and Firewalls

Agree.  Let's avoid the term "SBC" in the speermint area.  We don't need
the history lesson and the term is still evolving.  I just finished a
Skype call and did not use a SBC to peer with my one in 6 million users.

Yes, let's just define the requirements ... Edge Proxy, NAPT, Media
Proxy, Security Firewall and NAT/firewall traversal.

/PETER MACAULAY

At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote:
>Please avoid using the term "SBC" in the speermint area. Please clearly

>identify the function of these supposed wonder boxes that you are 
>addressing as an area of concern or advantage. Therefore if you mean 
>NAT, say NAT, if you mean firewall, say firewall, if you mean something

>else, say so. These boxes contain so many features (in the widest sense

>of the word) that in the absence of specific information we get lost.
>
>regards
>
>Keith
>
> > I think some people out there either do not understand the 
> > difference between NATs and firewalls or are starting to believe 
> > their own propaganda
> >
> > The worst misconception here is that a NAT is for providing you 
> > security against the bad Internet
> >
> > You can live very safe behind a properly configured firewall using 
> > only public IP adresses.
> >
> > But the fake security of NATs was already in the minds of most 
> > people, that the first things that were implemented in IPv6 where 
> > NATs for IPv6, which is a perversion
> >
> > publicly addressable is neither an Internet requirement, nor a 
> > requirement of the IETF.  Entire working groups in the IETF concern 
> > themselves with allowing, enabling, and inter-working private 
> > address spaces and VPNs.
> > What's missing
> > Most consumers on the planet Earth are in private address spaces at 
> > this point I think (i.e., 192.168.x.x), and many Enterprises are as 
> > well.  Entire networks in some countries are privately addressed, 
> > yet they are members of, and use, the Internet.  There are also now 
> > 2 disjoint address groups defined by the IETF, as you know: IPv4 and

> > IPv6.  There are mechanisms to try to provide 
> > interoperation/migration support for them, but that
typically

> > (and
> > egress) point(s), either on the public network for it to be public, 
> > or for it to cross into another private address domain.  For this 
> > WG's purpose, I recommend we allow either model to work, as well as 
> > the model of the private going to public (and vice-versa) so long as

> > the peering element of both sides are in the same public or private 
> > space.
> >
> > -Hadriel
> >
> >

---

From: "Malas, Daryl" <[email-masked]>
Date: Wed, 5 Apr 2006 09:31:22 -0600

That's a good point...technically if we wanted to blow it out, it could
be classified as a: I-CSCF, THIG, and IMS ALG.  I was trying to simplify
the combined functionality into one term.  I guess it's not that easy.

This is probably more specific:

I-CSCF/THIG - Signaling
IMS ALG (IP-IP MG) - Bearer

Thanks...

Daryl M.

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 9:15 AM
To: Malas, Daryl; Peter Macaulay; Drage, Keith (Keith);
[email-masked]

-AU

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 11:01 AM
To: Peter Macaulay; Drage, Keith (Keith); [email-masked]
Subject: RE: [Speermint] NATs and Firewalls

--Daryl

-----Original Message-----
From: Peter Macaulay [mailto:[email-masked]]
Sent: Wednesday, April 05, 2006 7:59 AM
To: Drage, Keith (Keith); [email-masked]
Subject: RE: [Speermint] NATs and Firewalls

/PETER MACAULAY

typically

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Wed, 5 Apr 2006 09:33:41 -0500

Jonathan Rosenberg wrote: 

...
>Folks also claim that NAT provides security by obfuscating the network
behind the NAT. An attacker cannot 
>determine how many hosts are behind the nat, and it never sees any of
their addresses. I'm skeptical that this is a real > security benefit,
but hiding of internal topology and internal addresses is often cited as
a security feature; YMMV.

I agree that topology hiding is a kind of security feature.

Sohel Khan, Ph.D.
Technology Strategist
Sprint-Nextel

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 5 Apr 2006 15:03:26 -0400

Hello Adam, 

The charter seems pretty clear that media is included. 

" However, in order to achieve real-time Session PEERing,
both signaling and media flows must be taken into
consideration."

As I mentioned in a previous thread, is it any good that the SIP session
is established but you cannot hear/talk?

We need to keep media in mind so we do not come up with a peering
architecture with fundamental problems. I mean, I considered the fact
that I cannot hear/talk a fundamental problem.

Regards,

Reinaldo

> Sent: Wednesday, April 05, 2006 8:15 AM
[email-masked]
> Agree.  Let's avoid the term "SBC" in the speermint area.  We don't
need
> >Please avoid using the term "SBC" in the speermint area. Please
clearly
> > > So I agree with you there needs to be an entity providing an
ingress
> > > egress) point(s), either on the public network for it to be
public,
> > > > are not routable from the public Internet, they are could as
well
> be

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 5 Apr 2006 15:09:28 -0400

Hello Spencer, 

Not even routers that have been around 30-40 years have a "standard"
list of functions. In the BGP/VPN area alone you have at least 100
different functions. 

The only thing all routers do for sure is perform a routing lookup and
send a packet out of an interface. 

Regards,

Reinaldo

> Sent: Wednesday, April 05, 2006 6:51 AM
> To: Patrick Melampy; [email-masked]
> As Keith said - this list of functions should have been at least two
or
> three lines long for most SBC products, and there is no standard list
> offered by all SBCs. This is, of course, WHY we need to avoid using
the
> word
> "SBC" as if we had agreement on what SBCs do, and do not, provide.
> 
> Spencer
> 
> 
> > What should we call the function(s) that an SBC provides? How
about...
> >
> > Edge Proxy/NAPT/Media Proxy/Security Firewall
> 
> 
>

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 5 Apr 2006 15:38:59 -0400

Hello Reinaldo,

We may be stumbling on some ambiguity?!?!  I read this...

Session Peering for Multimedia Interconnect
   focuses on how to identify and route real-time sessions (such as VoIP
   calls) at the application layer, and it does not (necessarily)
   involve the exchange of packet routing data or media sessions.
http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-termin
ology-01.txt

...and then compare it to the citation you put forth and get to
thinking.  I should have been more clear - we should consider, but not
assume that signaling and media will follow the same path - that's all I
meant. The term 'IP Media Gateway' makes me think that media will be
going to it. 

The path that the session signaling may take could be complete different
than the media.  I agree that we need to keep media in mind to ensure we
do not come up with a problematic peering arch.  I know the initial
impetus here is voip, but a Session can be anything at the end of the
day, so hear/talk might not be meaningful.  I know all to well what you
are referring to, and what's worse than not being able to hear/talk is
uni-directional communications, like I can hear you, but you can't hear
me. Holy asymmetric frustration batman!

Reinaldo - I am agreeing with you (and the charter), media should be
considered.

-AU

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 3:03 PM
To: Uzelac, Adam; Malas, Daryl; Peter Macaulay; Drage, Keith (Keith);
[email-masked]

Hello Adam, 

" However, in order to achieve real-time Session PEERing, both signaling
and media flows must be taken into consideration."

Regards,

Reinaldo

[email-masked]

need
clearly

ingress
public,
well

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 5 Apr 2006 20:50:20 -0400

Hi Hadriel,

See below.

> I think what may be the issue is our definition of SBCs may simply not
be
> the same.  Maybe you feel all the functions of modern SBCs are all
> implemented in a single physical box, which is not the case from my
view at
> all.  The functions can be broken up, or not.  It does not matter from
the
> context of this working group, because the peering partner is a single
> logical entity and it's the requirements that must be covered, not the
> implementations meeting those requirements. (as pointed out to me
earlier!
> :)  

I think that is the problem today. There are too many SBC definitions
and behaviors. This is the result of different point solutions for
similar requirements given by service providers in different
circumstances (fixed, mobile etc). Clearly something this under-defined
cannot be taken into account by the WG when making choices. That's what
I essentially said in an earlier thread on WG scope. We need to get all
the requirements on the table and be practical about them. SBCs are out
of scope...

> My only point relative to what should be "required", is applicability
to
> as broad a spectrum of providers as possible, where covering the case
of L3
> VPNs is probably the broadest approach, and within the IETF's domain.
> 
> Or maybe you feel the definition of "SBC" _requires_ media relaying
> somewhere?  That is not the case for any of the current physical
> implementations of SBCs that I know of in the service-provider market.
It
> happens to be that many providers enable them to do that, for many
reasons
> way beyond "point" requirements.  For example, I consider
media-relaying for
> the purpose of hosted-nat-traversal a "point" requirement.  Someday it
will
> fix itself.  But that's not why many providers relay media, and
certainly
> not in peering applications; and some providers don't relay media with
their
> SBCs.

I think in the speermint we should look at the problem of peering during
session setup. After the setup phase, the service providers may decide
to do media peering or not. We should tackle those requirements later
on.

> Regardless, in my view even if the SBC does not relay media it's still
an
> SBC if it performs other functions related to security, inter-working,
> policies, etc.  Some of those functions are described in
> draft-camarillo-sipping-sbc-funcs-03.txt, which I believe you helped
author.
> Clearly at some point as you remove those functions it ends up being
just a
> proxy.  

B2BUA to be precise. If I remove those functions, I will still be left
with a lot more functions! (it is not easy to document all SBC
functions, especially since there is no clear definition or requirements
out there on functions or expected behavior. We only mention some in
that draft).

But since a large group of providers appear to want some or all of
> those functions (and more) today, at peering points, then a peering
BCP for
> peering providers would be most successful if it "worked" within the
> constraints of those wants while providing BCPs to enable new services
or
> applications.

I think the problem we are trying to solve in the WG is definition of a
specific SIP signaling profile (as defined by this WG at some point I
guess) and location mechanism for next hop (again TBD from this WG)
which will enable successful hand-off of the call between domains. This
is clearly my interpretation and the chairs may think o/w. We should not
be taking the SBC functions as defined somewhere (especially since they
are incomplete) and try to write BCPs on them. We should be defining
interfaces in this WG, not elements, architecture etc.

> I think the simplest way to do it is to simply also cover the case of
L3
> VPNs peering with each other.  Do you disagree with that?  Any
"services" or
> applications which cannot be met by peering L3 VPNs, may be documented
as
> such in the BCPs, as far as I care.
> 

L3 is out of scope... I think that I am pretty sure of. I am not sure
what you mean by peering L3 VPNs in speermint's context.

-Medhavi.