Subject: RE: [Speermint] Comments on reqs-and-terminology-01andpolicy-dds-00(Peerign concepts and others..)

From: "Stastny Richard" <[email-masked]>
Date: Wed, 29 Mar 2006 11:20:44 +0200

> > We also could define this in another way: a SP is giving out
> > to their customers a public user identity, in SIP also called
> > an Address-of-Record. Note the term PUBLIC.
> 
> I think this is the wrong assumption given P2P SIP. Why can't the user
> have a unique public user identity and it not be linked to the SP at
all
> (The SP may not be a VoIP SP).

Hi Medhavi,

Good point, but there are more issues in one:

1. re: P2P SIP
As I understood the P2P SIP BoF, one of the most feasible models
in P2P SIP is that P2P domains interconnect with each other using
SIP proxy peers and normal client-server SIP and DNS SRV RR 
(RFC3263) to interwork. Therefore the global identities (AoRs)
used will be sip:[email-masked]

2. re: user owned public user identity
a. a user may run his own SIP server, and act as his own SP
this has not been excluded in the speermint charter. IMHO he
should be able to do so as long as he fulfils the minimum
requirements.

b. a user may also host his sip:[email-masked] with a SP
this is BTW a MUST for enterprises (as it has been requested
from ECMA at TISPAN for IMS. This will (or is already) causing
a lot of headaches, especially if you use domain certificates
e.g. for TLS and also certified user identities.  This is
definitely a must for spearmint to look at and create some
kind of BCP.

Cheers

Richard

> -----Original Message-----
> From: Medhavi Bhatia [mailto:[email-masked]]
> Sent: Wednesday, March 29, 2006 2:57 AM
> To: Stastny Richard; Reinaldo Penno; [email-masked]
> Subject: RE: [Speermint] Comments on
reqs-and-terminology-01andpolicy-dds-
> 00(Peerign concepts and others..)
> 
> Hi Richard,
> 
> >
> > We also could define this in another way: a SP is giving out
> > to their customers a public user identity, in SIP also called
> > an Address-of-Record. Note the term PUBLIC.
> 
> I think this is the wrong assumption given P2P SIP. Why can't the user
> have a unique public user identity and it not be linked to the SP at
all
> (The SP may not be a VoIP SP).
> 
> >
> > If I get a public user identity from a SP, I assume to be able to
give
> this
> > to somebody else and he/she is able to reach me via a public
> > communications network (note that I do not mention here
> > the Internet, also a walled garden network such as Vonage
> > is a public communications network)- Ok they are not giving out AoRs
> >
> > So if I use this public user identity in any other public "network"
> > accepting SIP URIs (in the definition of Speermint) or with any
other
> > SP providing services for the public, I assume to be able to reach
the
> > user having this public user identity. And speermint is only talking
> > about peering or interconnecting with SIP URIs (E.164 numbers
> > need first to be translated to SIP URIs (AoRs)
> >
> > The originating SP has NO CHOICE other then to Interconnect
> > on L5 with the termination SP. We can do these games with
> > "peering", "peering federations", etc. only as long as there
> > is another choice, e.g. the PSTN for voice calls.
> >
> > The terminating SP has a monopoly (or in EU terms, he
> > has Significant Market Power (SMP) (which may imply
> > some remidies, such as the requirement to interconnect!
> >
> > The terminating SP may reject incoming calls, but only
> > on behalf (or by order) of the end-user. not on his own.
> >
> > the terminating SP may belong to a federation or even more
> > then one, but this is only shifting the problem, because then
> > the SMP (monopoly) moves then to the federation.
> >
> > A federation MAY be used for additional policies such as
> > ADDITIONAL provision of end-to-end QoS or special peering
> > (direct links on L3), but IMHO a call set-up via plain SIP may never
> > be rejected, because of the originator has no other choice.
> >
> > What could (should) be done by Speermint is defining a minimum
> > set of requirements (profile) which are required to interconnect,
> > (e.g. TLS, some level of certificates, asserted user identities,
etc.)
> > but if these are met, a terminating SP provider must accept a call
> > in principle (the end-user may reject it finally, e.g. not accepting
> calls
> > from .biz or or from sip:[email-masked] or whatever)
> >
> 
> I think we should use this to set the minimum scope given the amount
of
> confusion in the WG at this point. This can actually be done and I
> believe will be useful.
> 
> -Medhavi.
> 
> > I have something similar as the profile between SP and PBX in mind
> > as created by the SIPForum.
> >
> > If Speermint has achieved this, it may move on to more complicated
> > stuff, such as peering policy agreements providing additional SLAs
> > eg on L3.
> >
> > The either we want to enable a public communications network
> > (and I cannot imagine something else in IETF) or not. If
> > not Speermint is out of scope as a whole.
> >
> > regards
> >
> > Richard
> >
> > ________________________________
> >
> > Von: Reinaldo Penno [mailto:[email-masked]]
> > Gesendet: Di 28.03.2006 23:34
> > An: [email-masked]
> > Betreff: [Speermint] Comments on reqs-and-terminology-01 and
> policy-dds-00(Peerign
> > concepts and others..)
> >
> >
> >
> > Hello,
> >
> > I've been reading "reqs and terminology" and I would like to step
back
> > and ask some questions about some of the definitions.
> >
> >
> > Peering:
> > ========
> >
> > In layer 3 peering two routers exchange their routing tables, reach
a
> > steady state, and after that data packets can flow between the two
> > domains.
> >
> > Layer 5 peering means, "interconnection of two service providers for
> the
> > purposes of SIP signaling".
> >
> > Making the inevitable comparison with layer 3 peering, there are
some
> > fundamental differences that I'm trying to reconcile.
> >
> > 1) In a traditional (a.k.a. layer 3) peering, both routers exchange
> all
> > necessary routing information and enter a steady state. At this
point,
> > no other routes are exchanged and routers concentrate on forwarding
> > packets.
> >
> > I know the WG is in the beginning, but it is not clear to me what
> pieces
> > are needed for an equivalent functionality. For example:
> >
> > 1) Are the entities exchanging SIP signaling for the purpose of
> peering
> > doing so on a _per call_ basis?  Is there going to be some mechanism
> to
> > exchange such information in bulk such as in a routing protocol?
Maybe
> > based on domain names or something similar?
> >
> > 2) The draft states that " A
> >    domain's ingress point can be thought of as the location pointed
to
> >    by the SRV record that resulted from the resolution of the CRD
> (i.e.,
> >    a SIP URI)."
> >
> > So, it seems to me that although the "layer 5 peering" is happening
> > between the two entities exchanging SIP signaling, the peering point
> > discovery is a result of a SRV query. But the draft also states that
"
> > SPEERMINT Working Group is focused on the use of such CRD."
> >
> > Draft peering-policy states that " This documents proposes the use
of
> > DNS entries to publish a SIP proxy's policy for accepting incoming
> > calls" proposes DNS as a way of exchange polices.
> >
> > This begs the question of what are the two "peering" entities really
> > doing besides exchange traditional SIP signaling? It seems the real
> > _information peering_ (for the lack of a better term) is happening
> > between DNS servers. All important information related to "peering"
is
> > coming from a DNS server which might as well be on your own domain
(if
> > your exchange DNS information).
> >
> > In summary, it seems to me the whole architecture is quite a
departure
> > from layer 3 peering where the entities peering are the holders of
the
> > necessary information to allow data packets to flow. Here the
entities
> > peering publish their peering information to third party server
which
> > does the actual "peering" (exchange inter-domain information).
> >
> >
> > Anyway, the idea of the mail is to try to clarify things. There is
> much
> > emphasis on SIP but it seems DNS plays a more central role. Or maybe
> > some SIP extension will be made to exchange peering policies?
> >
> >
> > Policies and Independence of lower layers:
> > ==========================================
> >
> > It seems sections 5.5 and 5.6 are _somewhat_ conflicting. Today BGP
> > exchange QoS and VPN information, performs discovery, etc. This
> implies
> > that BGP indirectly (or directly) knows the capabilities of the
> > transport layer (thus the name capability negotiation).
> >
> > So, although the mechanism to exchange the actual policies needs to
be
> > independent of the lower layers, there needs to be a way to input
> lower
> > layer information into the devices exchanging the policies. Just
like
> > BGP has filters and priorities based on a myriad of options. So,
maybe
> > the wording should change a little.
> >
> > As far as 5.6 goes, it seems to me the policies can be quite
complex.
> > The experience of BGP tells us that in the end policies can be huge.
> So,
> > if policies are going to be huge, what draft dds-00 states as a
> > possibility
> >
> > " If the simple boolean logic and the limited space in the DNS
answers
> >    are insufficient for an application then a type of policy rule
URIs
> >    can be defined which links to policy statements written in a
fully
> >    featured policy description language like SAML [14] or XACML
[15]."
> >
> > will actually going to be the rule. So, this begs the question of
DNS
> is
> > a good choice to publish peering policies.
> >
> > Thanks,
> >
> > Reinaldo
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> >
> >
> > _______________________________________________
> > 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.1/292 - Release Date:
> 3/24/2006
> >
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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