Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

[Otmar Lendl <[e-mail]>]

Michael,

On 2006/05/24 02:05, "Michael Hammer (mhammer)" <[e-mail]> 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 ([e-mail]) | nic.at Systems Engineer >

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