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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 23 May 2006 20:11:01 -0400

Otmar,

I did read one of your drafts, but had doubts about whether all this
policy data should be pushed in the DNS.  

I was wondering whether the DNS could be used to discover:
 - that a particular user is served by a particular service provider,
and 
 - that service provider has a URI to which the originating SP can
subscribe to get further information, and
 - that information says the terminating SP can support peering with
   = federation subset A, or 
   = federation subset B, or ...

I suppose that policy document could list all the RFCs you support and
then spend time figuring out what matches and what doesn't.  But I would
wonder how well each permutation has been tested.

Mike

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Tuesday, May 23, 2006 4:59 PM
> To: Michael Hammer (mhammer)
> Cc: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; 
> David Meyer; [email-masked]
> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> On 2006/05/23 22:05, "Michael Hammer (mhammer)" 
> <[email-masked]> wrote:
> > 
> > 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.
> [...]
> > 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.
> 
> Well, I've got a draft to sell to you.
> 
> From the example section of draft-lendl-domain-policy-ddds-00.txt:
> 
>    o  If the carrier example.com only accepts SIP calls (in 
> addition to
>       PSTN interconnect) if the PSTN emulation is good, he 
> might publish
>       a policy like this:
> 
>       $ORIGIN example.com.
>       ;      order pref flags service regexp replacement
>        IN NAPTR 10 10   "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3578!" .
>        IN NAPTR 10 11   "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3666!" .
>        IN NAPTR 10 12   "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3960!" .
> 
> /ol
> --
> < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> 

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

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 24 May 2006 13:43:58 +0200

Michael,

> policy data should be pushed in the DNS.  

Well, if the policy is to big, then the DNS can contain a URL which
points to the large policy. See the last example in
draft-lendl-domain-policy-ddds.

>  - that a particular user is served by a particular service provider,

Is the user identified by E.164 number or by SIP URI?

If the latter, then my draft says:

* either the domain part of the SIP URI is the provider's ID, or

* a non-terminal NAPTR in the customer's domain points to the 
  provider's domain where the real policy is stored.

(if the former, then ENUM is used first)

> subscribe to get further information, and

That fits in nicely with my draft. You just need to define a policy-type
for this subscription information.

>    = federation subset B, or ...

Ok; if this list is long, then an external document is fine. If it is
very short, I prefer storing it in the DNS and skip one step at call
setup time.

If these are just named subsets, then the DNS need only store the name
of the subset and not the list of RFC and BCPs.

> wonder how well each permutation has been tested.

That problem is independent of whether you store the requirement list in
the DNS or retrieve it via different means.

/ol