Subject: RE: [Speermint] NATs and Firewalls -- scope of requirements

From: "Bob Natale" <[email-masked]>
Date: Thu, 6 Apr 2006 16:46:20 -0400

Hi Hadriel,

Just one clarification concerning your suggestion that "the requirements
should be as open and broad as _possible_
to achieve the goals of the WG".  I understand and in some ways
sympathize with that statement.

I just want to point out that our charter calls for the Requirements BCP
milestone to address "the minimum set" of such requirements.

I interpret that to mean something like "only as open and broad as
_necessary_" [to achieve whatever we end up deciding are the
interoperable aspects of "session peering for multimedia interconnect"].

Cheers,
BobN

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 3:55 PM
To: 'Stastny Richard'; Medhavi Bhatia; [email-masked]
Subject: RE: [Speermint] NATs and Firewalls

Hi Richard and Medhavi,
Comments inline. 

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Thursday, April 06, 2006 3:12 AM
> To: Medhavi Bhatia; Hadriel Kaplan; [email-masked]
> Subject: RE: [Speermint] NATs and Firewalls
> 
> 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.

And no one said we should. (at least I never intended to)  I have said,
again and again, I am not proposing we mandate nor even mention SBCs in
any
documents.  The entire conversation started because someone asked "does
it
matter if it crosses them" and I said it may.  If some of the market
uses
them to do things for peering reasons, then perhaps we should address
the
needs of that part of the market as well, by not excluding them.  Not by
definining SBCs, not by requiring SBCs.  

At this point I regret having mentioned the term "SBC" because it's
provided
a lightning rod of hysteria and confusion when the point of my response
was
simply to suggest the requirements should be as open and broad as
possible
to achieve the goals of the WG.  As I said, I think the best way to
describe
them, is if you imagine a peer's voip network is in it's own L3 VPN,
which
is an IETF-acceptable concept based on the work of other WGs.

What that means, essentially, is of course there are one or more
entry/exit
peering points from/to that peer. (ie, proxies)  And of course the
peering
proxy(s) points must share the same address space as the partner peer's
exit/entry proxies.  Both at a L3 IP level and at a L5 SIP level.  What
it
does NOT mean, however, is that any nodes inside the L3-VPN peer's
network
are directly addressable at an L3 IP-Address level (FQDN is another
matter).
And naturally if we care about media (as the charter and I think most
people
using SIP today do), then we'll need to take into consideration the
L3-VPN
issues.  How, or even IF, we fix them or address them or not I am NOT
proposing, and I don't think we'll need to in the end.  It's merely the
recognition of such networks as legitimate peering partners that I
request
be considered.

As several people have said, this whole concept may not make one bit of
difference in the end.  Or it may.  I don't know until the requirements
are
done and the BCP ideas/mechanisms are discussed.  
Yeesh.  :)

-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