RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Otmar,

I think our main difference is that I am suspecting that the policy will
be large and possibly very dynamic, thus less suitable for locating in
DNS.  Also, instead of pointing directly to a single policy document,
which seems like a one-size-fits-all periodic user poll option,; rather,
use Subscriptions where the resulting document may depend on
authentication and who is asking, and can be pushed on the schedule of
the server when the policy changes.

These are just suggestions being thrown out for discussion.  I'd like to
hear what folks think about them.

I'm also questioning how much information about SIP needs to be embedded
in other protocols like DNS, DHCP, etc. and how much might be more
cohesive if handled via SIP-based mechanisms.  Finding the right
balance, if you will.

Mike

> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@nic.at] 
> Sent: Wednesday, May 24, 2006 7:44 AM
> To: Michael Hammer (mhammer)
> Cc: speermint@ietf.org; Khan, Sohel Q [CTO]
> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> 
> Michael,
> 
> On 2006/05/24 02:05, "Michael Hammer (mhammer)" 
> <mhammer@cisco.com> wrote:
> > 
> > I did read one of your drafts, but had doubts about whether 
> all this 
> > 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.
> 
> > I was wondering whether the DNS could be used to discover:
> >  - 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)
> 
> > and
> >  - that service provider has a URI to which the originating SP can 
> > 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.
> 
> >  - that information says the terminating SP can support peering with
> >    = federation subset A, or 
> >    = 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.
> 
> > 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.
> 
> That problem is independent of whether you store the 
> requirement list in the DNS or retrieve it via different means.
> 
> /ol
> --
> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >
> 

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint