Subject: [PEPPERMINT] While we wait on the drafts

From: Andrew Newton <[email-masked]>
Date: Fri, 5 Jan 2007 12:03:47 -0500

David Schwartz is producing an I-D with his take on requirements for  
a SIP peering provisioning protocol.  And I've been told privately of  
one other in the works.  But to get the discussions started, I'd like  
to share my observations in this space.

As I stated in the SPEERMINT meeting in San Diego, there seems to be  
near zero deployment of RFC 4114.  And almost every single time I've  
asked about it, the response has been "What is RFC 4114?"  In the  
interest of understanding why RFC 4114 might not meet the  
requirements for SIP peering provisioning, how many people have  
implemented and/or deployed RFC 4114?

 From what I've seen with the proprietary solutions, there appear to  
be two different models used in the industry:

Model 1) This is very similar to how RFC 4114 and EPP work, though  
the mechanisms differ (usually they are flat files sent using FTP).  
The exchange is all about deltas, any additions or deletions since  
the last transaction.

Model 2) This is the "entire catalog" approach.  In each transaction,  
every "address" (e.g. telephone # or SIP URI) is given.

 From a client perspective (or a provisioner's perspective... we need  
a term for that), model 2 is easier even though it obviously consumes  
more bandwidth.  However, from the server perspective (or the  
provisionee's perspective... again, we need a term), I would think  
this is cumbersome, as the tracking of the changes occurs on that  
side of the transaction.  When you extract the business  
considerations, tracking the changes may not be important... but we  
have to work within the confines of the real world here where  
charging, customer service, etc. do exist.

The opposite is true for Model 1.  More processing and attention must  
be paid by the client.

And though Model 1 is similar in operation to EPP, EPP's genesis in  
the domain name space doesn't exactly make it a perfect fit for VSPs  
with multiple peers.  In the registrar/registry domain name world of  
EPP, a registrar will only have one registry with which to provision  
any one instance of a domain name.  In other words, a registry only  
ever deals with one registry when it must do something with  
"example.org".

But for VSPs peered with multiple partners, this breaks down.  Each  
"address" (again, a phone # or SIP URI or whatever) could be  
provisioned with each partner.  This means deltas for each  
relationship must be tracked.

Comments and opinions welcome....

-andy

_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/peppermint

---

From: "Uzelac, Adam" <[email-masked]>
Date: Fri, 5 Jan 2007 12:22:27 -0500

Andy - If you are asking for a show of hands as to who has or hasn't
implemented/deployed 4114 - you can put Global Crossing as a company
that has NOT.  As for the provisioning models that you put forth, is
there not room for a hybrid environment?  I think there has to be a
combination of the 2 models to achieve a practical implementation.
There must be an "entire catalog" download/upload to start before any
delta model can be realized.  But to do a full download of the catalog
at a regular interval would be unruly.  

What about a model that follows a "per query" methodology?  There would
be some minor upfront provisioning that would ensure that a preexisting
contractual or trust relationship exists, but then query the catalog of
your peers for reachability of the intended target.  I realize there are
scaling issues involved, but it's realistic that this model would exist,
no?

-AU

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]] 
> Sent: Friday, January 05, 2007 12:04 PM
> To: [email-masked]
> Cc: David Schwartz
> Subject: [PEPPERMINT] While we wait on the drafts
> 
> David Schwartz is producing an I-D with his take on 
> requirements for a SIP peering provisioning protocol.  And 
> I've been told privately of one other in the works.  But to 
> get the discussions started, I'd like to share my 
> observations in this space.
> 
> As I stated in the SPEERMINT meeting in San Diego, there 
> seems to be near zero deployment of RFC 4114.  And almost 
> every single time I've asked about it, the response has been 
> "What is RFC 4114?"  In the interest of understanding why RFC 
> 4114 might not meet the requirements for SIP peering 
> provisioning, how many people have implemented and/or 
> deployed RFC 4114?
> 
>  From what I've seen with the proprietary solutions, there 
> appear to be two different models used in the industry:
> 
> Model 1) This is very similar to how RFC 4114 and EPP work, 
> though the mechanisms differ (usually they are flat files 
> sent using FTP).  
> The exchange is all about deltas, any additions or deletions 
> since the last transaction.
> 
> Model 2) This is the "entire catalog" approach.  In each 
> transaction, every "address" (e.g. telephone # or SIP URI) is given.
> 
>  From a client perspective (or a provisioner's perspective... 
> we need a term for that), model 2 is easier even though it 
> obviously consumes more bandwidth.  However, from the server 
> perspective (or the provisionee's perspective... again, we 
> need a term), I would think this is cumbersome, as the 
> tracking of the changes occurs on that side of the 
> transaction.  When you extract the business considerations, 
> tracking the changes may not be important... but we have to 
> work within the confines of the real world here where 
> The opposite is true for Model 1.  More processing and 
> attention must be paid by the client.
> 
> And though Model 1 is similar in operation to EPP, EPP's 
> genesis in the domain name space doesn't exactly make it a 
> perfect fit for VSPs with multiple peers.  In the 
> registrar/registry domain name world of EPP, a registrar will 
> only have one registry with which to provision any one 
> instance of a domain name.  In other words, a registry only 
> But for VSPs peered with multiple partners, this breaks down. 
>  Each "address" (again, a phone # or SIP URI or whatever) 
> could be provisioned with each partner.  This means deltas 
> for each relationship must be tracked.
>

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 5 Jan 2007 12:42:01 -0500

NeuStar has not implemented 4114 for that matter though we have implemented
EPP in our normal domain name registry operations.

> From: Uzelac, Adam [mailto:[email-masked]]
> Sent: Friday, January 05, 2007 12:22 PM
> To: Andrew Newton; [email-masked]
> Cc: David Schwartz
> Subject: RE: [PEPPERMINT] While we wait on the drafts
> 

We would assume a incremental update of changes to the entire cached catalog
" aka registry" would be a MUST.

> scaling issues involved, but it's realistic that this model would exist,

Of course .. some folks will not want to cache the catalog/registry and
others will simply want a per dip model. The issue will be then what are the
appropriate per dip query mechanisms and do we want to limit the scope of
acceptable models limit discussion to just RFC 3761 (DNS) and SIP Redirect?

---

From: Andrew Newton <[email-masked]>
Date: Fri, 5 Jan 2007 13:17:45 -0500

In-line...

On Jan 5, 2007, at 12:42 PM, Richard Shockey wrote:

>> that has NOT.

I was.  Thanks for understanding the obtuseness of the request.  For  
the record, SunRocket has not implemented 4114 (we'd be doing client- 
side), but have given it consideration and would have implemented it  
if any of our partners had.

>> As for the provisioning models that you put forth, is

Yes, there is room for a hybrid model.  But in Model 1, there is no  
exact need for a model 2 style start up.  Startup is simply a truck- 
load of additions.  However, I think it reasonable that normal  
operations would be model 1 and startup and checkpoints/resyncs would  
be model 2.

> " aka registry" would be a MUST.

So why doesn't 4114 meet your needs?

As far as MUST/SHOULD language goes, I'd like to see both models (and  
their hybrid) be a MUST implement.  Must deploy is a different matter.

And while I'm reciting my wish list, I'd like to see a couple of  
protocol features:

Model 1 Transactions) It would be nice to group the deltas into  
discrete transactions, similar to SQL transactions.  If one fails,  
they all fail.

Model 2 Chunking) With a reasonably sized catalog, the number of  
octets in the catalog (especially if it uses XML) can get quite  
cumbersome.  Typical octet counting mechanisms (such as EPP or plain  
HTTP POST) would then require an enormous buffer.  It would be better  
if the catalog could be sent in chunks or different, sequential  
messages.

It is possible that both features could be achieved with the same  
mechanism.

> acceptable models limit discussion to just RFC 3761 (DNS) and SIP  

I'd prefer we leave the actual mechanism for the query out of scope.

-andy

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 5 Jan 2007 14:00:39 -0500

> I'd prefer we leave the actual mechanism for the query out of scope.

Its certainly a topic for discussion but in principal I agree with you.

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 8 Jan 2007 12:17:25 +0100

> implemented and/or deployed RFC 4114?

The Austrian I-ENUM trial as run by enum.at uses EPP + RFC4114 as
the provisioning interface.

Personally, my love for RFC4114 is limited. 

EPP is fine for incremental changes, and I think we found a decent
way to use EPP in the +43 user-ENUM provisioning.

I see three flaws with 4114:

* The key is the domain, not the number.

  IMHO the provisioning protocol should reflect the fact that
  we're dealing primarily with E.164 numbers. Yes, maybe
  the end-result of that provisioning is an ENUM-style domain,
  but that could just as well be a SIP redirect server or
  some other mechanism.

* Reliance on the NAPTR format.

  As above: If all you are ever going to produce is an ENUM zone,
  then yes: that may be ok and gives you full control over the
  resulting NAPTR record. Once again, if you consider other
  query protols other than DNS/ENUM, then 4114 is too specific.

* No simple way to specify number-ranges or prefixes.

  You can work-around using wildcard domain-names for prefixes,
  but things like +1 555 123 4444 -- +1 555 123 4532 can only
  be done by enumerating all numbers in that range.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: "David Schwartz" <[email-masked]>
Date: Tue, 9 Jan 2007 00:27:25 +0200

Hi

I just submitted a 00 draft on provisioning data sets.

Until it shows up on the ID tracker you can use this version.

Cheers,

David

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 9 Jan 2007 12:22:37 +0100

Thanks for the input, here is the first question:

> 
>    o  Static Information
> 
>       The data in this category relates to the identification, ownership
>       and general validity of the number.
> 
>       1.  Value
> 
>           The value is the resource that is being sought.  This value
>           may be a fully qualified E.164 number (e.g. 12127775555), or
>           alternatively, the value may be a number representing a range
>           of numbers (e.g. 1212777).  In this latter case the "length"
>           field defined below is needed to establish the limits of the
>           number range.
> 
>       2.  Range
> 
>           This and the next field are used to assist in resolving ranges
>           into individual and unique valid E.164 numbers.  The Range
>           field is a Boolean value, which indicates whether the resource
>           specified in the "Value" field is a range that needs to be
>           expanded out to the "length" number of digits, or
>           alternatively, an individual number that does not require
>           further manipulation.
> 
>       3.  Length
> 
>           This field is used for expanding ranges to individual unique
>           numbers.

I can see how this works for blocks of numbers in countries with 
closed numbering plans. How this is supposed to work in Germany or
Austria, I don't know.

The problem is that "expanding ranges to individual unique numbers" is
a fool's errand in the context of open numbering plans. There are no
"ranges" assigned to corporate PBXs, they get prefixes (=pilot numbers,
"Kopfnummern") to which the PBX admin appends extensions according to
their own taste.

e.g.: the enum.at office in Vienna has +4315056416 (= 10 digits). We're
completely free to use the remaining 5 digits of the E.164 standard
as we wish. We don't even need to use a fixed length, we could use
-0, -1X, -2XX, -3XXX, -4XXXX, or any other scheme.

Thus: 

 * "Length" needs to be a range.

 * Expanding such a "block" into individual numbers turns a simple
   ISDN BRI customer into more than 100,000 DB entries.

--

In a more generic sense, you want to handle prefix-based in any case,
e.g. how else are you going to communicate that you offer termination
to London numbers, other than by saying route to +4420XXXXXXXX ? 
In that case, too, you don't want to translate that single route into
10^8 = 100 million individual routes.

Summary: Do we want to provision individual numbers, or are we aiming at
generalized prefix-based routes (with numbers as special cases)?

/ol

---

From: "T. Martin" <[email-masked]>
Date: Tue, 9 Jan 2007 06:28:01 -0800

Dave

I would suggest you qualify the definition of an E.164 number as defined by
ITU E.123.  And indicate what will be included in the field number

Were to get the correct notation information:
http://www.itu.int/rec/T-REC-E.123-200102-I/E

The definition should include:

Each assigned number contains a country code (CC), a national destination
code (NDC), and a subscriber number (SN). There can be up to 15 digits in an
E.164 number. The E.164 plan was originally developed by the International
Telecommunication Union (ITU).

I have another question: 

Where do you get the time and date information?

Terry Martin 
GVNW Consulting Inc
Senior Consultant
phone:503.612.4400
fax 503.612.4401
cell 503.318.8909

-----Original Message-----
From: David Schwartz [mailto:[email-masked]] 
Sent: Monday, January 08, 2007 2:27 PM
To: Andrew Newton; Richard Shockey
Cc: [email-masked]; [email-masked]
Subject: [Speermint]
draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

Hi

Cheers,

David

---

From: "David Schwartz" <[email-masked]>
Date: Tue, 9 Jan 2007 17:09:41 +0200

Hi Otmar.

In general, the assumption I made in the draft was that ranges cover a
factor of 10 numbers, i.e. if the pattern is 12345 and the length is 6
than the numbers provisioned are 123450, 123451, ... 123459. The problem
you raise regarding the numbering plans in Germany is not new to me and
brings up the question that often arises in database architecture,
namely that of width (or length) of a record Vs the depth or table size.
Specifically, how complicated do we want to make each provisioning
record at the expense of not writing another record. 

I contend and I may be wrong that while it is possible to add minLength,
maxLength, numberOfValuesInRange, etc, to cover ALL possible scenarios,
this obfuscates and complicates the processing of each record to the
point where it is more prone to errors. 

If on the other hand we simplify the record at the expense of adding
more records, while the upload time is perhaps increased (negligible)
the complexity is reduced and the errors that creep in to the system are
reduced as well.

While at one extreme is the prospect of provisioning each number
individually and not using ranges, it is possible using the mechanism I
proposed to combine individual numbers with ranges and take advantage of
"DeactivationDate" field that allows me to port individual values as
well as sub-ranges out of larger 10X ranges and arrive at the resolution
we desire.

If we take Germany as an example, suppose the number range I want to
provision is the 257 numbers starting with +4936628411 and going to
+493662841257. The way I would accomplish this with the mechanism
proposed in the draft using the "pattern|range|length" tuple is as
follows.

Activate...
493662841,true,12 // equivalent to adding 493662841XXX

Deactivate...
4936628413,true,12 // equivalent to removing 4936628413XX
4936628414,true,12 // equivalent to removing 4936628414XX
4936628415,true,12 // equivalent to removing 4936628415XX
4936628416,true,12 // equivalent to removing 4936628416XX
4936628417,true,12 // equivalent to removing 4936628417XX
4936628418,true,12 // equivalent to removing 4936628418XX
4936628419,true,12 // equivalent to removing 4936628419XX
4936628410,true,12 // equivalent to removing 4936628410XX

49366284126,true,12 // equivalent to removing 49366284126X
49366284127,true,12 // equivalent to removing 49366284127X
49366284128,true,12 // equivalent to removing 49366284128X
49366284129,true,12 // equivalent to removing 49366284129X

493662841258,false,12 // equivalent to removing 493662841258
493662841259,false,12 // equivalent to removing 493662841259

While I may have left out a record or two you get the point. 15 records
and you have clearly defined the range. While I could come up with a
scheme to do this in one record I felt that in light of the amount of
provisioning errors that we have seen in the field (with an even simpler
data set) I prefer to make porting in and out of ranges explicit and
thus reduce the chance of error.

Cheers,

D.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, January 09, 2007 1:23 PM
To: David Schwartz
Cc: Andrew Newton; Richard Shockey; [email-masked];
[email-masked]
Subject: Re: [Speermint]

Thus: 

--

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 10 Jan 2007 19:12:22 +0100

> Hi Otmar.

David,

> than the numbers provisioned are 123450, 123451, ... 123459. 

Sound fine as long as you can assume you know the length of the number.

> The problem

Oh, I'm not even there yet. What bothers me is the implicit assumption that
we're dealing with sets of numbers, and not sets of prefixes. 

In other words, I'd prefer to first get consensus on what a typical
database scheme of such a registry might look like.

Once we have that, we can start to talk about how to provision records
into that database. As you mention, a single provisioning record
might get expanded into multiple records in the database. On the
other hand, any rule we want to store in the DB must also be possible
to provision in some way.

> well as sub-ranges out of larger 10X ranges and arrive at the resolution

I think I understand your scheme and I think it is very reasonable
for sets of fixed-length numbers.

It's just that I don't think that "sets of fixed-length numbers" is
all we're going to need.

E.g. yes, you can use that scheme to announce a route to the
full NANP area with

Activate...
1,true,11 // equivalent to adding 1XXXXXXXXXX

but how do you do a route to Austria? This way?

43,true,15 // equivalent to adding 43XXXXXXXXXXXXXX

Is this record supposed to match 436624669 which is not 15 digits long?
Or do I also need to provision the following:

43,true,9

Or, to take the example from my last mail: What should Telekom Austria
provision into your system to announce that they serve +43 1 50564616
plus all set of possible extensions behind that number?

/ol

---

From: Paul Erkkila <[email-masked]>
Date: Tue, 16 Jan 2007 17:27:38 +0000

My thoughts on this discussion.

- Adapting this data to fit the "common" database case *may* be very 
difficult . I think separating communication of the data and using it 
should be left separate.

- The "extreme" case as David named it where a fully expanded route list 
is transmitted is actually the easiest to adopt case. It can be 
converted to pretty much any format. (This is covered by the Range flag 
in the draft).

- Any format compression such as the range flag and length field as 
proposed really needs to cover the entire namespace. As much as I love 
the NANP ignoring the requirements of variable plan implementors like 
Austria (no kangaroos) seems like a bad idea.

   Would it be horribly evil to allow regular expression like syntax in 
the value field? Expansions would be bounded by E164, and the rules 
allowed can be modified to reduce complexity errors that David is 
concerned about, purely for example:
     - Matches and expansions on numbers only (E164)
     - Expansion just inside the E164 space (E164: no 17 digit numbers)
     - Can make all values here inclusive (positive) and not allow 
negation operations. (complexity)
     - All expansion is done on the right side (complexity)

The answer to Telecom Austria announcing "+43 1 50564616" could then be 
4315056461[6][0-9]* (pick a favorite syntax).

A value with no syntax sugar would just be the standard value.

This seems to cover the number/prefix issue, as well as the length 
variation issue (inside of e164).

-pee

---

From: "David Schwartz" <[email-masked]>
Date: Mon, 22 Jan 2007 14:35:50 +0200

Hi Terry

> I would suggest you qualify the definition of an E.164 number as
defined 
> by ITU E.123.  And indicate what will be included in the field number

> code (NDC), and a subscriber number (SN). There can be up to 15 digits
in 
> an E.164 number. The E.164 plan was originally developed by the 
> International Telecommunication Union (ITU).

Agreed.

> Where do you get the time and date information?

So the only field where this is really an issue is "CreationDatetime".
If no value is entered the provisioning server enters the current time,
otherwise the provisioning client needs to enter the value for this.
Specifically, one thing this draft did not address was the data set for
the provisioning response (which will hopefully be included in the next
version). One of the fields that must be returned is the creation date
time field. When provisioning a number for the first time, the
provisioning client leaves the "CreationDatetime" field empty and the
server enters the current time. This time is returned to the client and
upon any subsequent modification of this record this date time should be
used.

David

---

From: "David Schwartz" <[email-masked]>
Date: Mon, 22 Jan 2007 15:07:44 +0200

Hi Otmar

I think the problem is that of an unclear definition. The current
definition of length is "This field is used for expanding ranges to
individual unique numbers". The wording I would add is as follows...
"This value is an exact match and is used for expanding ranges to
complete number sets. In areas of the world where non NANP type
numbering plans exist there may be a need for multiple "exact" length
records to account for all possibilities:".

With that said I am not completely averse to exchanging "exact" length
with two alternate fields: minLength and maxLength. All I was trying to
say was that anything you can do with those two can be done with 1 exact
length field as well.

David

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Wednesday, January 10, 2007 8:12 PM
To: David Schwartz
Cc: Andrew Newton; Richard Shockey; [email-masked];
[email-masked]
Subject: Re: [Speermint]

David,

> record at the expense of not writing another record. 

Oh, I'm not even there yet. What bothers me is the implicit assumption
that
we're dealing with sets of numbers, and not sets of prefixes. 

Activate...

43,true,9

/ol