Subject: [PEPPERMINT] Some comments on the ESPP reqs draft

From: Otmar Lendl <[email-masked]>
Date: Tue, 11 Mar 2008 22:55:54 +0100

I haven't managed to fully read both drafts yet, so these are
just first comments.

>1.  Introduction
>
>   This document presents a set of use cases and protocol requirements
>   for an ENUM-SIP addressing Server Provisioning Protocol (ESPP).  An
>   ENUM-SIP addressing server is a session routing server which resolves
>   telephone numbers or any type of public user addresses into routable
>   Uniform Resource Identifiers (URIs) based on various rules and
>   routing logic.  

Could you elaborate what you mean by "routable"? Suitable for RFC3263
processing? In which networks?

>   A provisioning protocol has been defined based on the requirements
>   summarized in this document ([CableLabs-ESPP]) and it is presented in
>   [I-D.espp-protocol].  A number of vendors have client and server
>   implementations of this protocol and two interoperability testing
>   events have been conducted to date.

What is the aim of this draft (and the spec one)? Just document what
cablelabs did? Ideas for peppermint? A solution of the general 
peppermint problem statement?

>   For example, two SIP service providers that respectively service the
>   New York-Manhattan and New-York Queens metropolitan areas agree to
>   peer.

Can a service area just be served by a single SSP? Can they overlap?

>   Some of the session establishment data (SBEs, Service Areas, Routes)
>   is usually provisioned once for each cable operator with occasional
>   subsequent updates as interconnect points are added or changed.  It
>   is provisioned independently from the provisioning of the elements
>   contained in Service Areas (TNs, TN Ranges, LRNs, or public
>   identities such as IM identifiers).  This allows the rare process of
>   provisioning SBEs, service areas, etc. to be distinctly separate from
>   the continuous process of adding subscribers.

It's a good idea to separate these two different types of information.

(For my part, I think that should be two different protocols, but I'm
glad that there is at least some sort of two-stage mapping in the
design.)

>   Figure 1 illustrates how telephone numbers may be grouped logically
>   into service areas (which may not necessarily be based on
>   geographical boundaries).  It also shows how each service area may be
>   reachable via signaling path border elements.

I have a hard time understanding the data design (and the naming) behind
ESPP. I'll try to go through the protocol specs later.

>3.3.  Backward Compatibility to Legacy Switch Translations
>
>   The underlying data schema used to provision ENUM-SIP addressing
>   servers should be backward compatible with today's VoIP server
>   translations and legacy PSTN.  This requirement arises from the fact
>   that some SIP service providers may wish to utilize the same number
>   translation data employed by their SIP servers or Call Management
>   Servers (CMS).
>
>   For example, a SIP service provider's switch translation personnel,
>   who are responsible for managing CMS translations, are given
>   responsibility for managing the operator's ENUM data.  Rather than
>   provisioning complete 10-digit numbers to a peer's ENUM server some
>   may choose to provision Location Routing Numbers (LRNs).  This
>   decision is, in large part, due to the fact that, in some networks,
>   the trunk selection algorithm of the operator's CMS are based on LRNs
>   (NPA-NXX).  The switch translation personnel choose to reuse LRNs
>   rather than taking responsibility for keeping a complete set of the
>   operator's numbers up to date.

Phew, this is awefully NANP-specific.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint