Re: [Speermint] Terminology Draft vs. VoIP Usecases Draft Terminology

[Otmar Lendl <[e-mail]>]

David,

On 2007/07/09 12:07, David Schwartz <[e-mail]> wrote:
> 
> 4.2.3. Assisted Peering 
> 
>    In this case, some entity (usually a federation, see Section 5) 
>    provides peering assistance to either the originating or terminating 
>    party. Examples of such assistance can include (but are not limited to):
> 
>    * The lookup function (who owns the number)
>      
>      * covers any mechanism reducing the need for an endpoint 
>        to hold all number ranges of all his peers (this can 
>        include a centralized database accessible via ENUM or a 
>        DHT containing relevant lookup information)
> 
>    * The policy function (who can see what and how)
> 
>        * Who gets a direct uri to other peer 
>        * Who must use intermediary
>        * Who gets a 404 Not found
> 
>    * The location function (ingress point at terminating or transit peer)
>      
>      * covers any mechanism (including BUT NOT LIMITED to RFC 3263) used
>        to locate the next routing hop for this call. Note that this may 
> 	 require the assistance of an element filling the role of indirect 
>        peering as described above. Note as well that this may or may not
>        be related to lookup function.

I really like way you structured the peering problem into these three steps.

Limiting this to "Assisted Peering" is selling the idea short, though:
Even direct and indirect peering have to perform these three steps
(although they might be mixed up in some cases).

Let's look how standard ENUM/SIP performs these three steps:

 * The lookup function (who owns the number)
 	User ENUM according to RFC3761. Public DNS.
 * The policy function (who can see what and how)
	Not needed as everybody talks to everybody
 * The location function (ingress point at terminating or transit peer)
	RFC 3263: NAPTR/SRV/A lookup

My proposal from last year (see
http://tools.ietf.org/html/draft-lendl-domain-policy-ddds-02 and
http://tools.ietf.org/html/draft-lendl-speermint-federations-03 ) 
can also be described according to this scheme:

 * The lookup function (who owns the number)
 	Public Infrastructure ENUM 
 * The policy function (who can see what and how)
	It's not a question of "can see", but "can use":
	Domain policy DDDS application (see the drafts)
 * The location function (ingress point at terminating or transit peer)
	Federation specific.

> 
> One final note. As you probably noticed under assisted peering I broke
> the location function into a lookup function and a location function. In
> my experience it is this subtlety that can provide most of the
> flexibility we need to accommodate most of the models out there. While
> in many or most cases one URI can be used both for lookup and location -
> the flexibility to have separate URIs for these must not be sacrificed.
> I would therefore add this term to the draft as well.

Once again, I concur.

The flexibility gained by this approach makes a simple, unified
peering architecture for all scenarios feasible.

/ol
-- 
/ Otmar Lendl <[e-mail]>, T: [phone] - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

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