Re: [Speermint] FW: I-D draft-bhatia-sip-peering-00.txt

> 
> Network Working Group                                          M. Bhatia
> Internet-Draft                                    NexTone Communications
> Expires: August 30, 2006                               February 26, 2006
> 

This draft is quite helpful as it provides clarificatons concerning the
terminology and describes some setups.

Some questions, though:

> 2.  Terminology

>       Service Provider (SP): We use the term Service Provider in this
>       document to refer to a SIP Service Provider[3].  The individual
>       types of SPs are defined below.
> 
>          Access SP: An SP which acts as the first hop between the
>          subscriber and the Core SP.

Is this Access SP role restricted to the SIP layer or is it implied 
that this Access SP also is the layer 3 access provider for "O"?

> 4.  Routing Architectures
> 
>    1.  Direct Peering: 
> 
>           Federation: A federation is typically a set of SPs which are
>           terminating calls to each other using some well known
>           mechanisms for settlement, address location and some other
>           common administrative policies.  In most cases the peering SPs
>           are connected to a trusted private network and trust all calls
>           terminating on them over this network.
> 
>              Federations typically use ENUM as the registry database
>              (owned by the federation or a trusted third party) to
>              provide address location services and applications like
>              number portability.  Other aspects of the routing policy
>              (as described in Section 5) are implemented using edge
>              proxies or session border controllers (Section 4.1).

This use of "Federation" fits in very well with my definition
of draft-lendl-speermint-federations-00. Good.

Federations can only use ENUM if routing is based on E.164 numbers.
If we ever switch to direct URI dialing, then ENUM cannot be used
within a federation.

Btw, draft-lendl-domain-policy-ddds-00 provides a solution for
selecting the right federation for a call and thus enables SPs
to be part of multiple federations.

> 
> 5.  Requirements for route policy and architecture for peering
> 
>    2.  Addressing: Whether the address of record of the termination is
>        an E.164 address or a generic AOR (e.g foo@bar.com)

IMHO: We should not design a system which does assume that E.164
numbers are available as routing information.

/ol
-- 
< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >

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