Subject: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

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 
_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

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
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

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: "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