RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

["Michael Hammer \(mhammer\)" <[e-mail]>]

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:[e-mail]] 
> Sent: Tuesday, May 23, 2006 4:59 PM
> To: Michael Hammer (mhammer)
> Cc: Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; 
> David Meyer; [e-mail]
> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> On 2006/05/23 22:05, "Michael Hammer (mhammer)" 
> <[e-mail]> 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 ([e-mail]) | nic.at Systems Engineer >
> 

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