Subject: [PEPPERMINT] ESPP drafts

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Wed, 12 Mar 2008 09:28:56 -0400

Some high level comments on the ESPP drafts (
draft-mule-peppermint-espp-requirements-00.txt and
draft-mule-peppermint-espp-protocol-01.txt)

I was a little surprised to see the focus on  central office code-based
routing. While I understand this is the current basis of PSTN number
allocation and routing, I'm concerned about an approach that perpetuates
the code nexus. (E.164 I like, but the exchange code arrangement creates
a host of problems we should be trying to move away from.) One of the
good things about ENUM is the potential to free us from these
limitations while allowing us to make use of the good parts of E.164
numbering.
 
A couple of nits re the use of LRNs as long as you're going down the
code routing path: first, LRN is North American specific; second you
could just refer to the code prefix which would be more general since an
LRN by definition uses an NPA-NXX code for which the LRN assignee is the
code holder in the LERG. In LRN-based routing only the terminating
switch cases about the XXXX portion of the LRN.
 
I appreciate the attempt to deal with the data volume issues represented
by NAPTRs for each TN, but I have reservations about the particular
solution path. Perhaps a non-NAPTR URI record as proposed by Patrik
Faltstrom might be  worth some consideration. There are at least two
flies in the ointment of number aggregation: number portability and the
possibility that different numbers in a range served by the same service
provider might have different characteristics that require different
treatment.
In the US, for example, some carriers have more than one type of
network/service offer, e.g. wireless, TDM wireline, VoIP. These may be
served out of the same pool of numbers given numbering resource
optimization regulations and cross-modal portability. 

Penn Pfautz
AT&T National Access Management
+1-732-420-4962
 
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 12 Mar 2008 07:52:24 -0600

Penn,

   Thank you for your comments.

   First let me say that these drafts are provided as an input to a BOF to show a real need and an example of how a few folks viewed the provisioning data problem for a particular entity (addressing/routing server).  It is provided to help clarify the scope/charter items.
  
   Some of your concerns are shared and this is why the data model allows for number ranges, individual TNs and any type of URI really (under "public identity").  That said, to get this data model to meet the requirements that some telephony groups have within SIP service providers in North America (inside and outside cable really), LRNs were added into the mix during the intermediary phase of moving away from PSTN-like management.

   More inline.

Jean-Francois.

> -----Original Message-----
> From: [email-masked] [mailto:peppermint-
> [email-masked]] On Behalf Of PFAUTZ, PENN L, ATTCORP
> Sent: Wednesday, March 12, 2008 7:29 AM
> To: [email-masked]
> Subject: [PEPPERMINT] ESPP drafts
> 
> Some high level comments on the ESPP drafts ( draft-mule-
> peppermint-espp-requirements-00.txt and draft-mule-peppermint-espp-
> protocol-01.txt)
> 
> I was a little surprised to see the focus on  central office code-
> based routing. While I understand this is the current basis of PSTN
> number allocation and routing, I'm concerned about an approach that
> perpetuates the code nexus. (E.164 I like, but the exchange code
> arrangement creates a host of problems we should be trying to move
> away from.) One of the good things about ENUM is the potential to
> free us from these limitations while allowing us to make use of the
> good parts of E.164 numbering.
Point taken.
I would note that the other draft presented today from David, Rohan, Alan and Ed also very e.164 centric.  The data model added LRNs because we had a requirement from folks handling sip call routing to the PSTN that we should accommodate the way they do things with LRNs today.  Not visionary but just reality. 
 
> A couple of nits re the use of LRNs as long as you're going down
> the code routing path: first, LRN is North American specific;
> second you could just refer to the code prefix which would be more
> general since an LRN by definition uses an NPA-NXX code for which
> the LRN assignee is the code holder in the LERG. In LRN-based
> routing only the terminating switch cases about the XXXX portion of
> the LRN.
Yes

> I appreciate the attempt to deal with the data volume issues
> represented by NAPTRs for each TN, but I have reservations about
> the particular solution path. Perhaps a non-NAPTR URI record as
> proposed by Patrik Faltstrom might be  worth some consideration.
Yes.  We just tried to deal with what was available today.

> There are at least two flies in the ointment of number aggregation:
> number portability and the possibility that different numbers in a
> range served by the same service provider might have different
> characteristics that require different treatment.
> network/service offer, e.g. wireless, TDM wireline, VoIP. These may
> be served out of the same pool of numbers given numbering
> resource optimization regulations and cross-modal portability.
> 
> Penn Pfautz