Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 18 May 2006 15:08:12 -0400

Francois,

I understand the reasoning, but any mention of the PSTN tends to raise red flags.  It also seems to duplicate other efforts inside IETF and out:

The SIP WG is trying to compile a document defining interoperability for SIP.  I see that as one form of federation.  Such an RFC (when it appears) could be cited.  

ATIS is planning an ANSI standard that could also be cited.  That may influence the CRTC.

I think all we need is for Speermint to have a mechanisms to identify such reference points.  It's a measure of indirection.  I don't think we need to compile those (dare I say) profiles in Speermint.

Mike

> -----Original Message-----
> From: Francois D. Menard [mailto:[email-masked]] 
> Sent: Wednesday, May 17, 2006 5:10 PM
> To: 'Khan, Sohel Q [CTO]'; 'David Meyer'; [email-masked]
> Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> I would, because ultimately, the minimum level of 
> interoperability will be (at least in Canada) mandated by the 
> regulator (here, the CRTC). So therefore, the baseline 
> comparison is what goes on today in the SS7 PSTN. 
> 
> F.
> --
> François D. Ménard
> Chargé de projet
> Xit télécom inc.
> 1350 rue Royale #800
> Trois-Rivières, QC, G9A 4J4
> Canada
> [email-masked]
> Tel: (819) 374-2556 ext. 268
> Fax: (819) 374-0395
> Cell: (819) 692-1383
>  
> 
> -----Original Message-----
> From: Khan, Sohel Q [CTO] [mailto:[email-masked]]
> Sent: 17 mai 2006 16:50
> To: Francois D. Menard; David Meyer; [email-masked]
> Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> Franois,
> 
> Thanks for the input. Question: is it necessary to mention 
> SS7 specifically?
> 
> 
> -----Original Message-----
> From: Francois D. Menard [mailto:[email-masked]]
> Sent: Wednesday, May 17, 2006 2:37 PM
> To: Khan, Sohel Q [CTO]; 'David Meyer'; [email-masked]
> Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> Just completed reading 02 and I have the following proposal:
>  
> 1) With regards to SIP interoperability in section 4.3, I 
> would like to mention that in Canada, we have agreed at the CISC NTWG
> (http://www.crtc.gc.ca/cisc/eng/cisf3d0.htm) that that the 
> following RFCs are sufficient to implement the equivalement 
> of the CCS7 minimum message
> set:
>  
> http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTRE035B.doc
>  
> SIP +
> http://www.ietf.org/rfc/rfc3323.txt
> http://www.ietf.org/rfc/rfc3325.txt
>  
> I therefore propose that we state the following in the 
> document under SIP interoperability in section 4.3:
> 
> It is expected that the level of SIP interoperability 
> achieved between two service providers will arise out of the 
> outcome of market-based bilateral negociations. 
> 
> However, it is expected that a level of interoperability 
> equivalent to the
> SS7 minimum message set of the conventional PSTN will require 
> service prociders to implement SF that SHALL BE compliant 
> with both, RFC 3323 (A Privacy Mechanism for the Session 
> Initiation Protocol) and RFC 3325 (Private Extensions to the 
> Session Initiation Protocol (SIP) for Asserted Identity 
> within Trusted Networks).
> 
> -=Francois=-
> --
> François D. Ménard
> Projet manager
> Xittel telecommunications inc.
> 1350 Royale #800
> Trois-Rivieres, QC, G9A 4J4
> Canada
> [email-masked]
> Tel: (819) 374-2556 ext. 268
> Fax: (819) 374-0395
> Cell: (819) 692-1383
>  
> ________________________________
> 
> From: Khan, Sohel Q [CTO] [mailto:[email-masked]]
> Sent: 17 mai 2006 15:12
> To: David Meyer; [email-masked]
> Subject: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> 
> 
> 
> We submitted the updated SPEERMINT Peering Architecture draft. 
> This update includes many of your input from the last IETF meeting. 
> 
> Please review and provide input in the mailing list 
> 
> 
> http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-ar
> ch-02.txt
> <http://www.ietf.org/internet-drafts/draft-khan-ip-serv-peer-a
> rch-02.txt>  
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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: Tue, 23 May 2006 09:53:20 -0500

Mike,

Do you know the name of the SIP WG draft defining SIP interoperability? I cannot find it in SIP WG web.

Sohel

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Thursday, May 18, 2006 2:08 PM
To: Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Francois,

Mike

> I would, because ultimately, the minimum level of interoperability 
> will be (at least in Canada) mandated by the regulator (here, the 
> CRTC). So therefore, the baseline comparison is what goes on today in 
> the SS7 PSTN.
> 
> F.
> --
> François D. Ménard
> Chargé de projet
> Xit télécom inc.
> 1350 rue Royale #800
> 1) With regards to SIP interoperability in section 4.3, I would like 
> to mention that in Canada, we have agreed at the CISC NTWG
> (http://www.crtc.gc.ca/cisc/eng/cisf3d0.htm) that that the following 
> RFCs are sufficient to implement the equivalement of the CCS7 minimum 
> message
> set:
>  
> I therefore propose that we state the following in the document under 
> SIP interoperability in section 4.3:
> 
> It is expected that the level of SIP interoperability achieved between 
> two service providers will arise out of the outcome of market-based 
> bilateral negociations.
> 
> However, it is expected that a level of interoperability equivalent to 
> the
> SS7 minimum message set of the conventional PSTN will require service 
> prociders to implement SF that SHALL BE compliant with both, RFC 3323 
> (A Privacy Mechanism for the Session Initiation Protocol) and RFC 3325 
> (Private Extensions to the Session Initiation Protocol (SIP) for 
> Asserted Identity within Trusted Networks).
> 
> -=Francois=-
> --
> François D. Ménard
> Projet manager

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 23 May 2006 22:54:07 +0200

>I think the the interworking of SIP to PSTN is out of scope here.

Yes
I did not find anything about this in the charter.
It is not even mentioned in the out-of-scope section (which mentions at 
least H.323 ;-)
 
>While coloring within those lines, the next question is whether there is
>a single subset that can be defined or whether there will be many.  I am
>betting on many, probably a different set for each federation or even
>bilateral pairing that might exist. 
 
I always had the idea that we could define minimum requrements
(which could be the overlap of the many subsets)
but maybe I am asking too much
Or is SIP already as baroque at OSI FTAM was?
(where we could only find bilateral "peerings" between
DEC, IBM and Siemens, but not a subset with worked with all three ;-)

Richard

Von: Michael Hammer (mhammer) [mailto:[email-masked]]
Gesendet: Di 23.05.2006 22:32
An: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; [email-masked]
Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Brian,

I think the the interworking of SIP to PSTN is out of scope here.  The
issue is whether two peers, once they have discovered each other, can
know what subset of SIP they need to support.  I don't think there is
any need to go down the rabbit hole on what applications are supported
and whether they are PSTN emulations or simulations or whatever.  We may
know in the back of our mind that some application won't work if RFC X
is not supported, but we don't need to discuss that.  We need only to
focus on what SIP RFCs are needed on the SIP peer interface.

While coloring within those lines, the next question is whether there is
a single subset that can be defined or whether there will be many.  I am
betting on many, probably a different set for each federation or even
bilateral pairing that might exist.  That could be another rabbit hole.
I would be happy if two peers could point to the same subset and agree
to use it, no matter how many subsets might exist.

Mike

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, May 23, 2006 3:05 PM
> To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan,
> Sohel Q [CTO]'; 'David Meyer'; [email-masked]
> By far the largest mistake EVER made by the IETF in the
> development of SIP was to allow SIP to be extended to imitate
> the existing PSTN.  If we ever were to start again, the
> golden rule would be DON'T IMITATE THE PSTN, and the
> corollary would be "Just because the PSTN does it that way
> DOES NOT MEAN it's a good idea".
>
> So, the very idea that "replication of functionality in the
> SS7 minimum message set" is the definition of what we need to
> do makes me want to puke.
>
> No, and a pox on your houses for even thinking that.
>
> While we're going to start with "basic call", we need to
> define those call features that must cross domain boundaries.
>  Most of them have existing SIP messaging (in sip-examples,
> for instance).  We need to make sure those features work
> across the boundary.  That has nothing whatsoever to do with
> an SS7 message.  The mms might give us clues on what features
> might be interesting to put on our list, but I'll bet we end
> up with a lot less of them, and a bunch of stuff not in SS7
> (or C7); inter-domain presence, for example.
>
> Brian
>
> Sent: Tuesday, May 23, 2006 2:50 PM
> To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; 'David
> Meyer'; [email-masked]
> > I don't see anything diametrically opposed between what I suggested
> > and
> what you are suggesting. 
>
> I would be satisfied with this:
>
> SPEERMINT compliance requires replication of the
> functionality available in the SS7 minumum message set which
> can be done by SIP, 3323, 3325.  Better than SS7 mms
> functionlality made possible with ATIS, IP Sphere or other
> sip profiles will also be considered as SPEERMIT compliant.
>
> > If there is to be an IETF-approved SIP profile, I think it should
> > first be
> decided if that is the turf of the Speermint or the SIP WG.
> Those last two statements are at the heart of my concerns.
>
> SPEERMINT will be completely toothless as an RFC if it just
> states, compliance with SPEERMINT can be achieved by
> compliance with non-IETF standards.
>
> F.
>
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 23 May 2006 19:54:42 -0400

It still seems a slippery slope to me, but if someone can present such a
list, great.

Mike

> Sent: Tuesday, May 23, 2006 4:50 PM
> To: Michael Hammer (mhammer); 'Francois D. Menard'; 'Khan, 
> I mostly agree, but you have to decide what is in the set of 
> RFCs, and to me, that is what call features are supported.  
> So, I don't want to see an argument that says "we have to 
> implement RFC xxxx because I like the author".  I want to say 
> "because we agree such and such feature works across the 
> peering point, we must implement RFCs x, y and z".
> 
> Dunno whether we need more than one list.  Try for one and 
> see what happens, back off if you can't get consensus.
> 
> Brian
> 
> Sent: Tuesday, May 23, 2006 4:32 PM
> To: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; 
> David Meyer; [email-masked]
> I think the the interworking of SIP to PSTN is out of scope 
> here.  The issue is whether two peers, once they have 
> discovered each other, can know what subset of SIP they need 
> to support.  I don't think there is any need to go down the 
> rabbit hole on what applications are supported and whether 
> they are PSTN emulations or simulations or whatever.  We may 
> know in the back of our mind that some application won't work 
> if RFC X is not supported, but we don't need to discuss that. 
>  We need only to focus on what SIP RFCs are needed on the SIP 
> peer interface.
> 
> While coloring within those lines, the next question is 
> whether there is a single subset that can be defined or 
> whether there will be many.  I am betting on many, probably a 
> different set for each federation or even bilateral pairing 
> that might exist.  That could be another rabbit hole.
> I would be happy if two peers could point to the same subset 
> and agree to use it, no matter how many subsets might exist.
> 
> Mike
> 
> 
> > To: 'Francois D. Menard'; Michael Hammer (mhammer); 'Khan, Sohel Q 
> > [CTO]'; 'David Meyer'; [email-masked]
> development of 
> > SIP was to allow SIP to be extended to imitate the existing 
> PSTN.  If 
> > we ever were to start again, the golden rule would be DON'T IMITATE 
> > THE PSTN, and the corollary would be "Just because the PSTN does it 
> > that way DOES NOT MEAN it's a good idea".
> > 
> > SS7 minimum message set" is the definition of what we need 
> to do makes 
> > me want to puke.
> > 
> define those 
> > call features that must cross domain boundaries.
> >  Most of them have existing SIP messaging (in sip-examples, for 
> > instance).  We need to make sure those features work across the 
> > boundary.  That has nothing whatsoever to do with an SS7 
> message.  The 
> > mms might give us clues on what features might be 
> interesting to put 
> > on our list, but I'll bet we end up with a lot less of them, and a 
> > bunch of stuff not in SS7 (or C7); inter-domain presence, 
> for example.
> > 
> > Brian
> > 
> > To: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; 
> 'David Meyer'; 
> > [email-masked]
> > SPEERMINT compliance requires replication of the functionality 
> > available in the SS7 minumum message set which can be done by SIP, 
> > 3323, 3325.  Better than SS7 mms functionlality made possible with 
> > ATIS, IP Sphere or other sip profiles will also be considered as 
> > SPEERMIT compliant.
> > 
> > SPEERMINT will be completely toothless as an RFC if it just states, 
> > compliance with SPEERMINT can be achieved by compliance 
> with non-IETF 
> > standards.
> > 
> > F.
> > 
> >

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 23 May 2006 19:59:08 -0400

A least common denominator set will likely be small, 
but perhaps not sufficiently rich for any two wishing to peering.

Mike

> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Tuesday, May 23, 2006 4:54 PM
> To: Michael Hammer (mhammer); Brian Rosen; Francois D. 
> Menard; Khan, Sohel Q [CTO]; David Meyer; [email-masked]
> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> It is not even mentioned in the out-of-scope section (which 
> mentions at least H.323 ;-)
>  
> whether there 
> >is a single subset that can be defined or whether there will 
> be many.  
> >I am betting on many, probably a different set for each 
> federation or 
> >even bilateral pairing that might exist.
>  
> I always had the idea that we could define minimum 
> requrements (which could be the overlap of the many subsets) 
> but maybe I am asking too much Or is SIP already as baroque 
> at OSI FTAM was?
> (where we could only find bilateral "peerings" between DEC, 
> IBM and Siemens, but not a subset with worked with all three ;-)
> 
> Richard
>  
>

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 24 May 2006 10:18:37 +0200

> but perhaps not sufficiently rich for any two wishing to peering.
e.g. RFC3261 and 3263 ;-)

plus TLS and one kind of asserted identity

additional richness could be provided by policy records

Richard

> > IBM and Siemens, but not a subset with worked with all three ;-)
states,

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 24 May 2006 10:06:01 -0400

Which is why I didn't want to get into that business, but leave it to
the SIP WG to do, if they thought it worthwhile.  Thus, my reference to
the hitchiker's guide.

Mike

> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Wednesday, May 24, 2006 1:46 AM
> To: Michael Hammer (mhammer); 'Brian Rosen'; 'Francois D. 
> Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; [email-masked]
> here.  The 
> > know what subset of SIP they need to support.
> 
> Oh goodie ... finally we can get the SIP working group to try 
> and define a rational set of SIP Profiles so SPEETMINT can 
> use them do discover what subsets of SIP they can support.
> 
> Talk about going down black holes ...
> 
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 24 May 2006 10:07:18 -0400

My thought was to put it all in the policy records, and point to them
with a 10-foot pole. :)

Mike

> Sent: Wednesday, May 24, 2006 4:19 AM
> > A least common denominator set will likely be small, but 
> perhaps not 
> > sufficiently rich for any two wishing to peering.
> > 
> > > It is not even mentioned in the out-of-scope section 
> (which mentions 
> > > at least H.323 ;-)
> > >
> > > (which could be the overlap of the many subsets) but maybe I am 
> > > asking too much Or is SIP already as baroque at OSI FTAM was?
> DEC, IBM and 
> > > Siemens, but not a subset with worked with all three ;-)
> > >
> > > Richard
> > >
> > >
> > > The issue is whether two peers, once they have discovered each 
> > > other, can know what subset of SIP they need to support.  I don't 
> > > think there is any need to go down the rabbit hole on what 
> > > applications are supported and whether they are PSTN 
> emulations or 
> > > simulations or whatever.  We may know in the back of our 
> mind that 
> > > some application won't work if RFC X is not supported, 
> but we don't 
> > > need to discuss that.
> > >  We need only to focus on what SIP RFCs are needed on the 
> SIP peer 
> > > interface.
> > >
> > > While coloring within those lines, the next question is whether 
> > > there is a single subset that can be defined or whether 
> there will 
> > > be many.  I am betting on many, probably a different set for each 
> > > federation or even bilateral pairing that might exist.  
> That could 
> > > be another rabbit hole.
> > > I would be happy if two peers could point to the same subset and 
> > > agree to use it, no matter how many subsets might exist.
> > >
> > > Mike
> > >
> > >

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 24 May 2006 14:17:54 -0400

> peering point, we must implement RFCs x, y and z".

That's a pretty good way of stating it.  And we'll get there soon.  But
we have to go one step at a time.  Expect a message from the chairs soon
on next steps for the WG that should hopefully clear up next steps and
how we'll answer these questions.

Jason

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 26 May 2006 11:42:20 -0400

I don't think the approaches each of us is suggesting are mutually
exclusive.

In your case, you are saying here is all the info you need, go ahead and
send your INVITEs.

In my case, it is adding an added level of indirection.  What is
advertised in DNS is a contact point to find out further information.
After subscribing to that pointer, you get a tailored response of where
and how to send your INVITEs.

Both can co-exist.  It all boils down to how a domain wants to set
itself up and what information to reveal initially versus later as the
peer reveals more information (authentication) about itself.

Mike

> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Friday, May 26, 2006 11:12 AM
> To: Michael Hammer (mhammer)
> Cc: Khan, Sohel Q [CTO]; [email-masked]
> Michael,
> On 2006/05/25 18:05, "Michael Hammer (mhammer)" 
> <[email-masked]> wrote:
> > 
> > If an address is advertized in public ENUM or DNS, then it 
> ought not 
> > be unreachable due to use of private networks or NATs, which is the 
> > basis for some of your arguments about why not SIP.
> 
> We're moving a bit into ENUM WG turf here, but anyway.
> 
> We're in a bit of a dilemma here regarding infrastructure ENUM:
> 
> On a national level it's manageable to build a private DNS 
> which only proper (whatever than means) operators can access. 
> Thus you can build a system that has the feature "if you can 
> see the URI, then you can reach it".
> 
> On an international level I consider this to be impossible. 
> The definitions about who is a proper carrier or not will 
> vary a great deal and I doubt that a big incumbent in one 
> country will want to directly talk to an upstart VoIP 
> operator two continents away. 
> Keeping that tree hidden from public view is quite impossible 
> if you consider the scope of the legitimate readers. 
> Consistent selective visibility in a distributed DNS tree is 
> very tricky.
> 
> [e164.info managed to do so on a small scale, but they use a 
> central DB. I doubt that you can scale up their system to 
> worldwide, non-centralized one.]
> 
> My conclusion from that is that
> 
> * infrastructure ENUM will be public (if it wants to enable more than
>   just national peerings).
> 
> * Thus the reachability assumption will have to yield.
> 
> I wish it weren't so. But I haven't found a way to avoid this 
> conclusion.
> 
> Do you see other options?
> 
> > My thinking was that one would need to progress through a series of 
> > steps/functions where the bootstrap steps are very public, but the 
> > later steps depend on the previous step enabling it.  The 
> chicken or 
> > egg problem shouldn't occur for first steps.
> 
> That's why we put the bootstrapping steps into the DNS. Any 
> other system SPEERMINT will come up with, e.g. some 
> SUBSCRIBE/NOTIFY would fit in very nicely: the domain policy 
> the can reference this framework as the requirement to reach 
> the destination.
> 
> > (I do understand your model
> > where you advertise what is only reachable by a few, but then it is 
> > working as you intended with selective unreachability being part of 
> > your
> > design.)
> 
> As I see the market right now, we already have a very 
> selective reachability on the SIP layer between VoIP operators.
> 
> I can't see a way to move the state of affairs to 
> "interconnection on SIP basis between all commercial 
> VoIP-operators worldwide" without either
> 
> * building a SIP routing protocol complete with transit networks
>   (the BGP model)
> 
> or 
> 
> * require the possibility of direct connections between all
>   operators worldwide. 
>   Determining whether the caller from halfway around the globe
>   is a legitimate operator is massively difficult, thus we
>   end running open servers. (the email model)
> 
> Thus I think selective reachability on SIP will stay with us 
> for the medium term.
> 
> > Hopefully, any delays to call setup occur only because of initial 
> > contact to previously unknown domains.  For, previously contacted 
> > domains or for federations that use a central SIP proxy or some 
> > interconnect SIP fabric, the call can be quickly handed to 
> the heavily 
> > used local contact point for that federation, since they 
> were learned 
> > previous to the call.
> 
> That sounds good.
> 
> > Anyway, it may be possible through configuration to address 
> both ways, 
> > with some heuristic to guide when to transition from the "policy is 
> > simple" approach to the "policy is complex" approach.
> 
> Even if the policy record just states "this is a carrier URI, 
> calls must use RFC-SPEERMINT-SUBSCRIPTIONS", this is helpful 
> for callers.
> 
> I see domain policies as the meta-protocol to bootstrap 
> various other peering mechanisms. 
> 
> The adoption of my draft thus does not preclude further work 
> in speermint. Quite the contrary.
> 
> /ol
> --
> < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
>

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Mon, 29 May 2006 09:30:06 -0500

Richard,

Would you please describe what LF should perform (in your opinion)?

Thanks,

Sohel 

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Sunday, May 28, 2006 3:07 AM
To: Khan, Sohel Q [CTO]
Cc: [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

I do not know how often I stated here that numbering issues (and
therefore also NUMBER Portability issues) are out-of-scope in SPEERMINT
 
So NUMBER Portablility cannot ne addressed in SPEERMINT LF
 
Or we change the SPEERMINT charter
 
Richard

Von: Khan, Sohel Q [CTO] [mailto:[email-masked]]
Gesendet: So 28.05.2006 06:48
An: Stastny Richard; Reinaldo Penno
Cc: [email-masked]
Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

I think issues of mobility and number portability need to be addressed
together in SPEERMINT LF.

Sohel Khan, Ph.D.
Sprint-Nextel

-----Original Message-----
From: "Stastny Richard" <[email-masked]>
To: "Reinaldo Penno" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 5/27/06 4:52 PM
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

What question?
Richard

Von: Reinaldo Penno [mailto:[email-masked]]
Gesendet: Sa 27.05.2006 23:46
An: Stastny Richard
Cc: [email-masked]
Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Apart form your outside-of-the-us rhetoric the questions remains.

> Sent: Saturday, May 27, 2006 2:38 PM
> To: Reinaldo Penno
> Cc: [email-masked]
> ENUM issues should not be discussed in SPEERMINT, just some questions
>
> >Enum? When I dial (650) 453 2312, what is there to resolve _inside_
the
> >wireless network that owns this number apart from the location of the

> >user?
>
> and _outside_?
> ENUM is about numbers like +16504532312
>
> hello, we are talking E.164 numbers in ENUM, which is international 
> numbers
>
> >Now, in the scenario where an external call (for example, a cingular 
> >customer calling a Verizon customer (which owns an original t-mobile 
> >number). How that works today? If you say ENUM I would stand
corrected
> >(and surprised), since LNP has been fully deployed since 2003.
>
> Cingular?Verizon? ...
>
> we are talking about a global solution here You are a bit US centric 
> here, there is also some 200 other nations ozt there.
>
> I have no access to the US LNP database from e.g. Austria
>
> So you want to consider US national databases only in speermint?
>
> Richard
>
>
>
> Von: Reinaldo Penno [mailto:[email-masked]]
> Gesendet: Sa 27.05.2006 21:30
> An: Stastny Richard; Otmar Lendl
> Cc: [email-masked]
> Enum? When I dial (650) 453 2312, what is there to resolve _inside_
the
> wireless network that owns this number apart from the location of the 
> user?
>
>
> Now, in the scenario where an external call (for example, a cingular 
> customer calling a Verizon customer (which owns an original t-mobile 
> number). How that works today? If you say ENUM I would stand corrected

> (and surprised), since LNP has been fully deployed since 2003.
>
> When a user takes its number with them, I assumed this punches a whole

> in the telephone prefix hierarchy and a specific entry somewhere is 
> needed.
>
> Regards,
>
> Reinaldo
>
>
> > Sent: Saturday, May 27, 2006 4:26 AM
> > To: Reinaldo Penno; Otmar Lendl
> > Cc: [email-masked]
> > >I wonder how
> > >LNP is solved within wireless...A specific entry for each phone?
That
> > >would be crazy.
> >
> > Ahem, ENUM?
> >
> > I thought that is all what ENUM is about?
> >
> > Richard
> >
> >
> > Von: Reinaldo Penno [mailto:[email-masked]]
> > Gesendet: Sa 27.05.2006 11:04
> > An: Otmar Lendl; Patrick Melampy
> > Hello,
> > I believe the crux of the problem was missed.
> >
> > The issue is not really the number of domains. We have today some 
> > 400.000.000 million hosts on the Internet. BGP peers to do not
> exchange
> > 400.000.000 million routes, they exchange in the low hundreds of 
> > thousands.
> >
> > And why is that? (I guess you know where I'm getting at). That's
> because
> > IP addresses lend themselves very well to hierarchical deployment, 
> > compression through prefix/CIDR usage and the like. DNS names are 
> > strings and hence difficult to come up with a similar scheme.
> >
> >
> > I believe that if domains need to be exchanged between peers:
> >
> > 1 - Just a limited set would be exchanged and a "default layer 5
> route"
> > (equivalent to a traditional default route) would be used.
> >
> > 2 - Compression schemes like *.company.com, regular expressions or
the
> > like would need to be used. Having specific routes to AORs would be 
> > hairy (maybe for the eventual roaming or visiting user). I wonder
how
> > LNP is solved within wireless...A specific entry for each phone?
That
> > would be crazy.
> >
> > 3 - Some new scheme that will make somebody rich....until then..
> >
> > I believe subscriptions would be used to exchange mostly "cost" and 
> > policy information and some domains. I use cost here in the layer 3 
> > sense (number of calls, jitter, whatever). Cost would be an abstract

> > value or a more specific one (up to the administrator).
> >
> > Regards,
> >
> > Reinaldo
> >
> > > Sent: Saturday, May 27, 2006 1:29 AM
> > > To: Patrick Melampy
> > > Cc: 'Khan, Sohel Q [CTO]'; [email-masked]
> > > On 2006/05/26 18:05, Patrick Melampy <[email-masked]>
> wrote:
> > > > I suppose like in any distributed routing protocol, there are
some
> > > chicken
> > > > an egg issues. But consider the following.
> > > >
> > > > PREREQUISITES:
> > > > 1.) You know the destination DOMAIN from either ENUM or other
> means.
> > >
> > > [...]
> > > >
> > > > This technique is very similar to TRIP, only its for DOMAINS and
> not
> > > partial
> > > > E.164 numbers.
> > >
> > > [...]
> > >
> > > > Obviously, the data set could get large, as the list of domains
> can
> > be
> > > > really big. There are some possibilities here...
> > >
> > > Let's do a quick estimate on the number of domains involved:
> > >
> > > Right now, operators usually give customers URIs of the form 
> > > <number>@<providerdomain>. As long as this is the state of
affairs,
> > > we're fine as the number of providers is quite finite (a few 
> > > thousands, perhaps).
> > >
> > > This is like the state of affairs with respect to email, anno
1990.
> > > Back then customers started to notice that if they use their own
> > domain
> > > for email, then they can switch providers without having to change

> > > their email address. Thus a *lot* of people opted to use their own

> > > domain for email.
> > >
> > > My guess is that the same will happen to SIP. Once customers print

> > > their SIP uris on business cards, they will want to use their own 
> > > domains. If providers won't support that feature then I suspect
that
> > > the regulators will step in and mandate an URI portability
solution
> > > just as they did in the PSTN with respect to numbers from number
> > blocks.
> > > (This could get really nasty protocol-wise, so I guess using
> customer-
> > > owned domains is the far better and likelier solution to the
porting
> > > question.)
> > >
> > > So: Anything we come up with here in SPEERMINT needs to cope with
a
> > > scenario where the use of customer domains in SIP URIs is just as 
> > > widespread as it is for email.
> > >
> > > How many domains are used for email? That's hard to say. There are

> > > about 60 million gTLD domains and probably more than 20 ccTLD
ones.
> > > Assuming that only a tenth of that is used for email we're at
> > > 8 million domains. Given the exponential growth any system which 
> > > doesn't scale to at least 10 million domains will be obsolete
before
> > > the ink is dry on the RFC.
> > >
> > > So what happens if we do some sort of BGP or TRIP with domains?
> > >
> > > Let's say we need at least 100 bytes of state information per
> domain.
> > > That makes a full routing table 1 GB worth of data. That also
means
> > > that a new border element needs to exchange that amount of data 
> > > with its peers before it has learned the current state of the 
> > > routing table.
> > >
> > > That is some serious amount of data.
> > >
> > > > 1.) Have notification point to a published document, and the
> > document
> > > lists
> > > > all of the relevant reachability in real time. Thus any change
to
> > the
> > > > document would generate a NOTIFICATION.
> > >
> > > + a download of up to 1 GB per peer.
> > >
> > > > 2.) User partial domains, broken up by the "dots". This may
allow
> > some
> > > > wildcarding to reduce the number of domains. For instance, a
> carrier
> > > like
> > > > Verizon may have many 100's of domains attached to it, and
version
> > is
> > > > willing to route and manage SIP traffic to any of them. The
NOTIFY
> > could
> > > > contain something like: Verizon.com or *.verizon.com to indicate
> > that
> > > any
> > > > domain in Verizon is reachable.
> > >
> > > That's helpful if a provider uses subdomains for internal
purposes,
> > > but that won't help you with customer owned domains.
> > >
> > > > This technique may work -- and fit nicely into an existing
> protocol.
> > All
> > > we
> > > > would need to do is define the data models (XML?) and or
documents
> > for
> > > > exchanging.
> > >
> > > I think this technique can work -- if you add an aggregation step 
> > > before the routing scheme.
> > >
> > > Take another look at BGP: there you have the concept of an 
> > > Autonomous System and not only that of prefixes. Maybe you need 
> > > something similar.
> > >
> > > One approach to cope with hosted SIP domains could be to use the 
> > > hostnames as found in SRV records. E.g. for settings like
> > >
> > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com
> > >
> > > run the routing algorithm on "sip.provider.com" instead of 
> > > "customer.domain".
> > >
> > > Another option is to store some AS-equivalent in the customer
domain
> > > and have the routing algorithm operate on that. In my
domain-policy
> > > framework this could be expressed e.g. like
> > >
> > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id"
> > >       "!.*!urn:ietf:speermint:RID:1042!" .
> > >
> > > stating that this domain can be reached using the Speermint
routing
> > > logic by using the learned route to RoutingID 1042.
> > >
> > > Or, even better, use non-terminals, and thus refer to the ingress 
> > > policy stored in the provider's domain:
> > >
> > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com
> > >
> > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id"
> > >       "!.*!urn:ietf:speermint:RID:1042!" .
> > >
> > > (+ whatever other facts provider.com wants to announce about his
> > > reachability.)
> > >
> > > This combination of our ideas can indeed work and scale to an 
> > > unlimited number of customer-owned domains.
> > >
> > > /ol
> > > --

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 29 May 2006 17:05:36 +0200

Sohel,

I posted this already on Friday, but I think everybody
(including me) lost track already;-)

So here once again:

"May I try my summary: the Location function is a process containing
eventually more then one step:

"If you start with the CRD (e.g a SIP AoR entered by the User 
or derived from ENUM)"

Remark: Whith this I ment that the E.164 to SIP URI mapping
is already done, because this is out-of-scope of SPEERMINT.
In addition, SPEERMINT MUST be able to work in the same way
if the user has entered a SIP URI direct. This is why I prefer
that the result of an ENUM query is an AoR and not directly
the ingress element to the destination network.

"1. The AoR gives you the destination network 

2. You need to locate the peering club (= federation) for 
exchanging SIP messages (L5 )with the destination network

3. so you need to locate the policy you want to use and 
make a decision on the federation
(note: a destination network may belong to more then one federations)"
(Remark: both origination network and destination network
may be members of more then one federation. They may
need to locate a common one. If more then one federation
is in common, it is the choice of the origination network
to select one - So the Policy Function is embedded in the LF)

4.  "having chosen a federation, you need to locate the ingress 
proxy(ies) the destination network is using within this federation.

5. If you are using a separate peering for exchanging media, you now may
locate these"

Additional remark: In step 4. and 5. some geographic
location magic could come into play as requested by
some on this list.

Regards
Richard

> Sent: Monday, May 29, 2006 4:30 PM
> To: Stastny Richard
> Cc: [email-masked]
corrected

---

From: "Nieminen Klaus" <[email-masked]>
Date: Tue, 30 May 2006 09:41:48 +0300

Richard, Francois and all,

Francois, thanks for your proposal.

If I understood the proposal by Francois correctly, you did not propose to use OSP itself, but using the common data type definitions (format and codes) defined in OSP. Therefore the problems Richard mentioned in OSP should not apply to this case. I'm correct?

What others think?

Of course, providers can use this kind of mechanims for whatever they like and I don't want to enter that discussion. I just want to point out that we need something if we want to provide access to value added services that are billed by the caller's operator.

regards,

- Klaus -

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: 30. toukokuuta 2006 1:04
To: 'Francois D. Menard'; Nieminen Klaus; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

You might think that and Alan Johnston did some work on this in SIPPING but it seems no one cares...plus there are real issues of wether OSP can scale to the number of transactions necessary to support this kind of thing.

Boys and Girls ... in case you had not heard transaction pricing for voice is not all that popular among consumers these days.

Transaction or distance based pricing for communications has not been popular since the establishment of the penny post in the UK in the 1800's. 

http://www.dtc.umn.edu/~odlyzko/doc/history.communications0.pdf

BTW Content is not king.

http://firstmonday.org/issues/issue6_2/odlyzko/

From: Francois D. Menard [mailto:[email-masked]]
Sent: Monday, May 29, 2006 9:46 AM
To: 'Nieminen Klaus'; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Klaus,

I've always thought we could put some Open Settlement Protocol XML data in a SIP invite.

F.

--

François D. Ménard

Chargé de projet

Xit télécom inc.

1350 rue Royale #800

Canada

[email-masked]

Fax: (819) 374-0395

Cell: (819) 692-1383

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 30 May 2006 17:31:50 +0200

Andy wrote

>Stastny Richard wrote:
>>
>> IMHO SPEERMINT does not deal with E.164 numbers at all in routing, it is out of scope

>Would the "private" ENUM tree run by a peering point and specifying its
>location (i.e. DNS suffix) be in scope?

IMHO yes, because any ENUM is dealing with E.164 numbers

-sta

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 30 May 2006 12:53:53 -0400

> I still have a serious problem regarding how to bootstrap 
> such a system as
> 
> * Carriers seem to hate to expose their SIP ingress elements 
> to the open
>   Internet. They firewall, use private address spaces (e.g. GRX) or
>   otherwise block incoming SIP calls before they reach the SIP stack.

But that shouldn't be a design constraint just yet.  These same carriers
expose their SMTP gateways on the open Internet.  We need to find a
middle ground between SMTP (say, by reducing abuse for a start) and the
current model of firewalled SIP ingress points.

Jason

> * we want to avoid a mandatory bilateral configuration of peerings.
>   
> Could you sketch how a dynamic peering discovery could work 
> with a SIP subscription model?
> 
> /ol
> --

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 30 May 2006 13:11:05 -0400

> affairs, we're fine as the number of providers is quite 
> finite (a few thousands, perhaps).
> 
> This is like the state of affairs with respect to email, anno 1990.
> Back then customers started to notice that if they use their 
> own domain for email, then they can switch providers without 
> having to change their email address. Thus a *lot* of people 
> opted to use their own domain for email.
> 
> My guess is that the same will happen to SIP. Once customers 
> print their SIP uris on business cards, they will want to use 
> their own domains. If providers won't support that feature 
> then I suspect that the regulators will step in and mandate 
> an URI portability solution just as they did in the PSTN with 
> respect to numbers from number blocks.
> customer- owned domains is the far better and likelier 
> solution to the porting
> question.)
> 
> So: Anything we come up with here in SPEERMINT needs to cope 
> with a scenario where the use of customer domains in SIP URIs 
> is just as widespread as it is for email. 

I think this is a fair statement and probably worthwhile for inclusion,
in some manner, in the upcoming requirements draft.  I know I certainly
see more similarities to the email domain model that anything else.  I
think you can roughly size the problem by, as you have done, looking at
domain registrations and applying some penetration level to that
(increasing over time).  I would imagine, for example, any small
business, enterprise, or university would want their own domain to be
used in their public/published SIP URIs.  (The unstated assumption is
that we believe in the eventual ubiquity if public SIP URIs, as with
email addresses 10+ years ago.)  The records underlying a given SIP URI
may refer to service provider names / elements, but I'd agree with you
that these parties will want to continue using their own domains.  Thus,
we should not place a constraint on this problem that envisions the
number of domains being roughly equal to the number of so-called
carriers today.  The number of domains will be much, much larger over
time IMHO.

Jason

---

From: "Malas, Daryl" <[email-masked]>
Date: Tue, 30 May 2006 16:18:12 -0600

So, I'm trying to differentiate traditional PSTN transit from SPEERMINT
transit.  I think the features/extensions of SIP provide a more
intelligent capability of transit than traditional TDM/SS7
interconnections.  I took your definition (described below) to a "next
step up" approach, where my peers and/or my policies may permit transit
to only some or all of my peers.

...I suppose, your definition does work; because, technically my other
peers do not exist to you if I don't allow you to transit to them due to
my policies or theirs.

Sorry, it's a little confusing, but I hope it makes sense.  I may be
breaking the traditional term of transit, but I think it fits the
capability the closest.  If you can come up with a better "summarizing"
term, I'm listening. ;-)

--Daryl M.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:10 PM
To: Malas, Daryl; 'Pfautz, Penn L, GBLAM'; 'Otmar Lendl';
[email-masked]

I don't like your definition of "transit".  Transit means "I am peered
to
others, and they will permit me to let you get to them through me".  

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 5:54 PM
To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

After reading my own email, I think I have implied 3 different peering
policies (not flows):

1.  Private - It is a 1:1 relationship.  I peer with you and you with
me...no other options...no other routes, etc.

2.  Public - I'll peer with anyone 1:*, as long as you meet the policy
criteria I have specified.

3.  Transit - I am peered to many, but will only allow you to peer with
some or all of my peers based on my peers and my policies.

Any thoughts??

--Daryl M.

-----Original Message-----
From: Malas, Daryl 
Sent: Tuesday, May 30, 2006 3:43 PM
To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

I was thinking in terms of Contradiction 2 (if I'm reading your list
correctly)...B won't tell A about it's routes to C and D, because B has
negotiated a "private" relationship with A. In this case, A can only
route to B (and D via it's other "private" relationship).  In this case,
I am not describing a transit scenario with B.  B simply has multiple
peering relationships with varying types of peering partners (public or
open vs. private).  Now please don't confuse the internet as implying a
public peering relationship, although that is what I intended for this
example.  The internet is simply a layer 3 mechanism, and a private
peering relationship could exist via that path as well.

Peering can and should be architected to work in a transit scenario as
well, as you began to describe below.  A peers with B, because it knows
B is peered with many federations or domains.  In this case, B is acting
as a transit or termination peering hub to multiple spokes (if I can use
that analogy liberally) -- B may also have domains associated with it.
Also, A could still maintain a private peering relationship with D, to
create multiple layer 5 path choices for getting to D.  For example, D
may be peered with a DS-3 with high levels of quality (e.g. diffserv,
ToS, etc.), while the peering relationship to B may be an OC-12 without
quality guarantees.  A's primary choice to D is via it's private peering
relationship to D, and a secondary choice is through B.

This is getting fairly complex, but all of these are good to hash out in
the architecture document...otherwise, the industry will run with crazy
one-offs in every different direction causing incompatibilities on
several levels.

--Daryl

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:03 PM
To: 'Pfautz, Penn L, GBLAM'; Malas, Daryl; 'Otmar Lendl';
[email-masked]

Perhaps we are misinterpreting the figure.  I am interpreting C as
accepting
calls over the Internet from any domain (that is, not limited to
specific
peers).  I'm not just thinking that the peering fabric is the Internet;
of
course any connection between peers can traverse the Internet.  I assume
A
knows it wants a route to C.  ENUM is out of scope.  The Route
Advertisement
is what domains B tells A it can get to, so that A knows B can get to C.

Contradiction 1 is that if C is known to accept connections from any
domain,
then B is not adding value.  It can't be a secret only known to B that C
accepts any connections.

Contradiction 2 is that B can't tell A that it can reach all possible
C's.
A specific C, maybe, but then you are back to Contradiction 1.

Let's be more concrete.  Suppose there is an enterprise with a SIP PBX.
Suppose it starts out by purchasing VoIP termination services from a
carrier
and sends all its traffic there, and to start, only accepts traffic from
its
carrier.   Now, suppose that at some point the enterprise gets
comfortable
and starts allowing traffic from the Internet direct to its PBX.
Suppose,
just to get it off the table, that there is public ENUM, so number
services
are not an issue.

This enterprise is now a "C".  How does B tell A that it can get to C?
How
does it know that?

Generally, C freely "advertises" its "route" by simply putting an SRV
record
in its public DNS.  What is the way A "seeks a route to C" by any
mechanism
short of just trying DNS.  What I'm getting at is that B can't make a
definitive list of all the C's out there, and there is no wildcard that
works.   

Brian

-----Original Message-----
From: Pfautz, Penn L, GBLAM [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:20 PM
To: Brian Rosen; Malas, Daryl; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Sorry, sent too soon...
This is the kind of thing that makes we wonder why anyone wants to look
at this in terms of route advertisement where A doesn't know the
destination is C and just looks at what B says it can reach. I can
imagine that A knows the ultimate destination is C and then seeks a
route to C, which would eliminate the contradictions Brian raises.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:02 PM
To: 'Malas, Daryl'; 'Otmar Lendl'; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

I am absolutely certain that these kinds of arrangements will be seen
"in
the wild".  Two thoughts strike me:
1) If Domain A is paying Domain B a lot for this kind of service, it may
need a software update so it can do it itself
2) The route advertisement from B towards A gets REALLY tricky.  The
reason
is that there is no convenient way to express it.  It's not "*" (I can
get
you to any domain).  It's "I can get you to any domain that accepts
connections from the Internet".  It's the terminating network that
decides
if it will allow traffic from some other domain, and "Domain B" below,
doesn't know what the rules for Domain C are.

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:45 PM
To: Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

In addition to your comments below, I think peering will likely occur in
one of the following methods or all of them (this includes the
capabilities described in the Peering Architecture Draft:

+---------+
                                                           |         |
+--------+         +--------+           +------------+    /|Domain C | 
|        |		 |        |          /              \  / |
|
|Domain A| Private |Domain B| Public  |    Internet    |/  +---------+
|        |=========|        |=========|                |\
|        |  Peer   |        |  Peer    \              /  \ +---------+
+--------+         +--------+           +------------+    \|         |
    ||
|Domain D |	
    =======================================================|         |	
				Private Peer
+---------+

As far as PBX interconnect goes...

I don't think SPEERMINT should design a tie-line replacement
architecture.  IMO, it is out of scope.  I know this becomes somewhat
blurry, as more SIP PBX's are a conglomeration of multiple SIP
capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in
the architecture.  However, the SIP Forum is already addressing many of
those concerns in SIP Forum drafts such as:
sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf.

My two cents...

--Daryl M.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 11:51 AM
To: [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

On 2006/05/30 19:05, "Livingood, Jason"
<[email-masked]> wrote:
> > I believe this discussion has gone over the edge.
> > 
> > The reason SPEERMINT exists is that CARRIERS want to peer.
> 
> Perhaps a fair assessment, but I suspect we all would like it to
> progress beyond that.  
>  
> > Email is an inappropriate metaphor for carrier peering.
> 
> Perhaps but I don't think we can conclude that as yet.  There are most
> definitely differences though.  I see no reason not to try to take
some
> of the simplicity and ubiquity of that model and trying to apply it to
a
> new application where it makes sense.

My take is that we need a system that

* allows selective peering. If we require that everybody can talk
  directly to everybody else, we don't get carrier opt-in.

* supports branching off into private interconnects.

  Ideally, all the existing private peering fabrics should fit
  into the speermint umbrella.

* scales to wide adoption, both for SIP URIs / domains as well as
  peering operators.

  Nothing in the protocol should preclude that it is used e.g.
  to get VoIP-enabled PBX systems to peer with each other.

  (Whether a carrier wants to peer with a PBX is his choice. 
  The protocol shouldn't dictate a peering policy. The contrary:
  the protocol must support all possible peering policies.)

* gives BCPs on how to do the nitty-gritty SIP details
  (caller-ID, privacy, ...)

/ol

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 31 May 2006 00:26:32 +0200

>the protocol must support all possible peering policies.)

In principle I agree with Otmar, I want only to add some details:
 
All communications (in Speermint) start with an end-user requesting
a communication. The user can only do so by entering Public User 
Identity. This can either be an E.164 number (which is translated via ENUM
to an AoR) or the AoR direct. So we have to start with on AoR.
 
If this AoR is giving the destination domain (hosting the called end-user) direct
and if this can be located by RFC3263 - done (provider or PBX) PBX the synonym
for a direct hosted SIP system)
 
If the AOR is giving a destination domain (e.g. stastny.com) hosted by e.g. provider.net,
we need to "translate" stastny.com to provider.net, e.g with a method Otmar pointed out in
a previous e-mail. 
 
Now we have find out how to contact provider.net.
 
provider.net may accept calls from the internet without any polcy - done
 
provider.net may have policies in place, so we have to find out what the policies
are
 
this policies could either be some additional requirements, e.g providing a certificate
accepting calls only from certain provider (federations), accepting calls only
via VPNs, whatever - we have to select and define the options here, there is a lot of
work to be done
 
One of these options could be that provider.net can only be reached via a "transit network"
this could also be announced in the policies, or with local tables of the originating
network, Also here some work is required for the options.
 
Regading a PBX hosted by provider.net, this case seems to get very complicated, especially
if a PBX accepts both calls direct Ifrom selected peers and via provider.net
(the outbound case is simpler, because it is the choice of the PBX to go direct or via
the provider.net as "transit network". This case is similar to the provider.net itself)
 
In any case, this "dual-mode" direct peering and transit via a provider is a definite
requirement from ECMA (responsible for PBX standards)
 
>  (caller-ID, privacy, ...)

This is also important. As I already stated, we should define
a set of minmum requirements providing features that are approx equivalent 
to the minimum requirements of a NNI in the PSTN (e.g. ISUP v2),
because this interface will be used as a replacement

Some proposals of RFCs have already been made on this list.

In words this is basically TLS and CLIP and CLIR (network and user provided)
(=P-asserted identity)

One last word about E.164 numbers: I said the mapping of
E.164 numbers to AoRs is out-of-scope. E.164 numbers
in signalling ARE in scope:

The information that calls are originating on E.164 numbers or originally targeted
to E.164 numbers should keept intact end-to-end.

IMHO all additional issues should go with lower priority
(e.g. charge messages, etc) this also never was a big success
on the PSTN

-sta

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 31 May 2006 00:27:37 +0200

Daryl,
 
I think this is in a nutshell what I just posted more verbose ;-)
 
-sta

Von: Malas, Daryl [mailto:[email-masked]]
Gesendet: Di 30.05.2006 23:53
An: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; [email-masked]
Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Any thoughts??

--Daryl M.

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 31 May 2006 00:41:32 +0200

As I pointed out, the definition of transit in SIP is tricky

I want to give you an example:
 
A GSMA operator made the following statement regardin GSMA ENUM:
 
Even if we find out via ENUM what the destination network is,
the selection hoe we exchange traffic is our choice:

It may be via the GSMA IPX network, it may be
direct peering, it may be via the Internet, or it may
be via a specific transit network for this destination network

How they do this? with so-called local routing tables
(basically NAPTR records) giiving the peerng path to
select in this specific case.
 
This works in principle

The drawback of this solution is the local maintenance
overhead required, in principle again local routing tables
IMHO not a good idea.
 
OTOH, I have currently no idea how to publish these
bilateral agreements otherwise
 
-sta

Von: Malas, Daryl [mailto:[email-masked]]
Gesendet: Mi 31.05.2006 00:18
An: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; [email-masked]
Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

--Daryl M.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, May 30, 2006 4:10 PM
To: Malas, Daryl; 'Pfautz, Penn L, GBLAM'; 'Otmar Lendl';
[email-masked]

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]]
Sent: Tuesday, May 30, 2006 5:54 PM
To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Any thoughts??

--Daryl M.

-----Original Message-----
From: Malas, Daryl
Sent: Tuesday, May 30, 2006 3:43 PM
To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

--Daryl

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, May 30, 2006 3:03 PM
To: 'Pfautz, Penn L, GBLAM'; Malas, Daryl; 'Otmar Lendl';
[email-masked]

Brian

-----Original Message-----
From: Pfautz, Penn L, GBLAM [mailto:[email-masked]]
Sent: Tuesday, May 30, 2006 4:20 PM
To: Brian Rosen; Malas, Daryl; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Sorry, sent too soon...

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, May 30, 2006 4:02 PM
To: 'Malas, Daryl'; 'Otmar Lendl'; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]]
Sent: Tuesday, May 30, 2006 3:45 PM
To: Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

+---------+
                                                           |         |

My two cents...

--Daryl M.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]]
Sent: Tuesday, May 30, 2006 11:51 AM
To: [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

some
a

/ol

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 31 May 2006 14:45:17 +0200

Thanks Brian that you finally made it clear
that the whole issue of VoIP peering is about
trust and identity.

> One of the things that we have to face is that most of us WILL accept
a
> call
> from someone we don't know.  We balance the risk of being annoyed or
> offended against the risk of discovering something new that we like.
A
> business, as an example, doesn't want to miss a call from a new
customer,
> so
> it always accepts calls directed to its general sales line from
anyone.

Exactly

The problem here is that we talk about two layers of trust:

One is the end-to-end trust between the end-users and
the other is the commercial and policy trust between
the providers. I think our problem is partially
derived that we always mix these two issues.

There is also different kind of identities.

An example: In normal communications as an
end-user I just want to know that a Brian Rosen
contacting me is really the Brian Rosen I know,
if I do not know you I want to have some assertion that
this is your real name, or at least I want to have
some guaranty that I could find out. This requires
some kind of third party to be able to retrieve 
this information on request.

But this does not imply if you sell me something
that I will get my money ;-). Ok, with the identity
given I my find out enough to sue you, but this is
very complicated.

So if I make business with you, I basically do not
care if you are really Brian Rosen as long as I get
my money. This required another kind of third party,
somebody guarantying me the money on behalf of you.

This is basically the trust relationship also
the service providers need.

So for guarantying the identity for end-users in
the first case, we simply need some trusted third
party, which could be the originating service provider 
providing a P-asserted identity. If I am then be
happy to connect via the Internet with best effort, 
this is none of the service provides issue.
We simply need same basic requirements to securely
transmit the identities.

So what is all this fuzz about only excepting
calls from certain providers, only via VPNs,
direct peerings, not trusting the Internet, etc.

It is all about the business trust layer between
operators, e.g. to get termination charges, service
charges, service level agreements, etc.

This does not help the end-user very much.

Also the transit issue is only for provider trust
The end-user trust is end-to-end, if the minimum requirements
are kept between all providers in the chain, it does not matter.
(OTOH one could ask why a transit network is required in this case)

The transit trust is required if money is involved, e.g.
termination fees: C is not trusting A that he will pay
termination fees, because they have no agreement. C trusts B, 
because they have one. If now C trusts B, he does not care
anymore about A. B is basically a clearing house.

In policy terms: A is looking up the policy federation of
C and finds out it a member of federation X.

A now looks for a provider he has an agreement with, and is also
member of X which in this case is B.

So A forwards the call to B because A can assume that B
is able to deliver the call to C. B is trusted by C to pay and
also trusts A to get the money back

-sta

> Sent: Wednesday, May 31, 2006 1:46 PM
> To: 'Otmar Lendl'; 'Patrick Melampy'
> Cc: [email-masked]
> Oh, I really expect to see most connections through carriers for quite
a
> while.  I do wonder if "trust" is something transit networks can
actually
> help with.
> 
> I believe in identity, and identity has to be asserted by someone.
One
> reasonable source of trusted identity is the originating carrier.
That is
> an enduring value; if a carrier does little more than provide a
reliable
> identity, that will help avoid SPIT.
> 
> However, it seems hard to me for a transit network to provide a trust
> chain
> stronger than a direct connections.  Maybe this is wrapped up in what
you
> call "trusted communications".  What is the assertion that B is making
> about
> A that C cares about?
> 
> One of the things that we have to face is that most of us WILL accept
a
> call
> from someone we don't know.  We balance the risk of being annoyed or
> offended against the risk of discovering something new that we like.
A
> business, as an example, doesn't want to miss a call from a new
customer,
> so
> it always accepts calls directed to its general sales line from
anyone.
> 
> We have to deal with identity, which is one of the trust
characteristics
> an
> originator provides to a terminator.  What else are we trusting?
> 
> Brian
> 
> Sent: Wednesday, May 31, 2006 2:15 AM
> To: Patrick Melampy
> Cc: 'Brian Rosen'; [email-masked]
> On 2006/05/31 03:05, Patrick Melampy <[email-masked]> wrote:
> >
> > B's value (which you seem to completely be disregarding) isn't
solely
> that
> > he can forward SIP messages directly to C -- more importantly, C
trust's
> B
> > that B will only forward TRUSTED communication to C. Thus the chain
of
> > identity asserted, trusted communication, can only work when
untrusted
> > networks and proxies are either excluded, or clearly identified as
> > untrusted.
> 
> Correct.
> 
> > Speaking of enterprises...I bet very few will connect their IP PBX
to
> the
> > public internet.
> 
> You've got to distinuish "public internet" on layer 3 from open SIP
> proxy on the Internet. Right now, some of the enum.at registrars are
> happily selling VoIP-based PBX installations to enterprises which
> peer with each other automatically based on User-ENUM and open SIP
URIs.
> 
> >                  I suspect they will connect these types of systems
only
> to
> > proxies and sources of inbound communications requests that they
trust.
> 
> That's one of the examples of my "federation" draft. E.g. take the
> MPAA as a typical industry association: If they run a X.509
> certification authority (incl. revocation lists) which signs the
> TLS certs of the PBXs of member organizations then all the
> telephone systems of Hollywood can peer with each other over the
> open Internet in a secure fashion.
> 
> Whatever Speermint comes up with: such a scenario must IMHO be
supported.
> 
> > This group needs to be focused on developing schemes for
"connecting"
> these
> > proxies into trusted chains. I believe that an advertisement
mechanism
> > (subscribe/notify) can meet this requirement.
> 
> As mentioned before, (subscribe/notify) is very nice for manually
> configured relationsships. I don't see how you implement
> the guild example from above with that concept.
> 
> Please elaborate.
> 
> /ol
> --