Subject: RE: [Enum] Address completion vs private dialing plans

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Fri, 11 Aug 2000 09:44:23 -0500

Not seeing any dissent, I see at least two uses of the ENUM mechanism
(DNS+NAPTR) beyond the resolution of E.164 numbers.  I argue the ENUM
document should be clear enough to ensure that these applications are not
precluded in the future.

	1) resolution of private dial plans
	2) Address completion

For the use with private dialing plans, we have a strawman proposal to use
the + as a separator between a dialplan identifier and the digits of the
dialplan.  In the current context, having a bare "+" signifies the default
dialing plan, E.164.   Clearly NATPRs for both private dialing plans and for
public dialing plans can coexist at the same node in the DNS tree.

In this case, the ENUM document should be very clear what should happen if a
client encounters one or more NAPTR records that match something other than
a bare "+".  I understand the Regexp will simply not match the initial key
and the entry will be ignored....  is this the case?  Without text,
implementations may assume only NAPTRs that operate on E164 numbers will be
returned and never use the RegExp for matching, only doing the obvious
simplification to select the appropriate NAPTR on service, order, and
preference only.  Note, I am not asking for specification of numbering
plans, simply ensuring that they can be added using at least the current
strawman proposal.

For use as an address completion facility, we have a proposal that would use
NAPTR rewrite rules and itteration to transform an incomplete number into a
complete number in some dialing plan such as e164.  It is not clear to me if
a separate delimiter is needed from "+" to distinguish matches on an
incomplete number vs a complete number in a defined numbering plan.  I hope
Patrick can provide greater clarity to his proposal for exactly how a client
can identify whether it needs to apply itteration.....     My guess is that
this application will not clash with ENUM because 1) It uses a set of
distinguished topological doman suffixes e.g., num.se and 2) Non-terminal
e.g., other than "u", status flags are illegal in ENUM, and 3) the client
clearly understands it is not using a complete telephone number (private or
public).  From my understanding, NATPRs for address completion and for ENUM
resolution should never occure at the same node in the DNS tree.

If this is so, then we can simply clarify the existing document with no
protocol changes.  (unless we want another less-ambigious separator
character than "+" or we see value in explicit designation of the e164
numbering plan.)

Comments?

Greg V.

-----Original Message-----
From: BARNOLE Valerie FTRD/DAC/ISS
[mailto:[email-masked]]
Sent: Friday, August 11, 2000 6:08 AM
To: Vaudreuil, Greg M (Greg)
Cc: [email-masked]'; Manfredi, Albert E; 'Hong Liu'; Patrik Fältström
Subject: RE: [Enum] Address completion vs private dialing plans

Greg,
you're right in distinguishing both issues.
A few considerations I have :

1)Even if the matter of identifying the numbering plan is not the hardcore
of ENUM WG work, I think it is an important issue for the development of
ENUM services.
By now, I just don't figure out which is the best way to proceed for the
dialling user (the calling party)and I do not know where is the best
place/mailing list to discuss it.
Maybe the solution can be proprietary to a computer manufacturer or to a
telco. I really just do not have in mind all the possibilities.

2)To the US examples you quoted, I would add :
2.2.7.2.3.3.7.2.7.9.telcosp.us (the [local loop ?] telco subscribers or
telecommunications service provider's plan reached by dialing 9+ 10 digits
of this telco/sp subscribers' numbers)

3)I agree with what you say : "Stated more generally, address completion
takes as input a topological "location" and an input string and results in a
numbering plan identifier
and a set of digits unique to that number plan.  Of course, this is a
fantastic facility, but totally out-of-scope for ENUM except to keep options
open for other cool stuff using the same mechanism."

I think this input of topological "location" will have to be looked at
carefully according to mobility, I think in another WG or in relationship
with another WG.

The important thing is indeed to keep ENUM open, because it is the key to
its widespread use in my opinion.
 
end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole

FTR&D/DAC/ACE

tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

mail to : [email-masked]

-----Message d'origine-----
De: Vaudreuil, Greg M (Greg) [mailto:[email-masked]]
Date: jeudi 10 août 2000 21:06
À: Patrik Fältström; BARNOLE Valerie FTRD/DAC/ISS
Cc: [email-masked]'; Manfredi, Albert E; 'Hong Liu'
Objet: [Enum] Address completion vs private dialing plans

I think we are talking about two different things.  One is the proper
handling of private dialing plans.  The second is an implementation of an
address completion facility using DNS.  We need to distinguish between them.

The address completion facility takes a dialed string of digits and applies
logic to determine 1) What dialing plan (or local service codes) if any the
dialed digits correspond to and 2) what if any prefix needs to be added or
stripped to construct a valid and unique number within that dial plan.

The example Patrick illustrates A swedish address completion facility.
Given that I am in Sweden, I resolve the digits received using the ENUM
process using a hard-coded num.se domain.  Through the DDDS mechanisms, I
eventually get to a "fully qualified" E164 number and begin the ENUM
process.  

Stated more generally, address completion takes as input a topological
"location" and an input string and results in a numbering plan identifier
and a set of digits unique to that number plan.  Of course, this is a
fantastic facility, but totally out-of-scope for ENUM except to keep options
open for other cool stuff using the same mechanism.

So, in the spirit of "+" to keep things open, I believe we need to go a bit
deeper.  In the general case, the ENUM algoritmn really takes as input both
a string of digits and the identifier of the dial-plan in which the digits
are unique.  The dial plan identifier is used to select the domain suffix
for the DNS lookup and to select between various candidate remapping rules.
Patrick recognized that the RegExp algorithm needs the dialplan identifier
in order to operate as an address completion facility and proposed using "+"
as the e164 identifier.  I would argue that we should address this need in a
more complete way and should explicitly identifing the numbering plan as
part of the input to the NAPTR algorithm. 

So, rather than use +e164digits as the input, why do not we use something
like numberingplan+e164digits.   This is far more powerful than just looking
for a "+" and guessing about which "other" is to be used.

This also addresses another complication that arises with the use of DNAMEs
in conjunction with NAPTRs.   I may arive at the same NAPTR set using
numerous paths defined in by my clients dial-plan tables:

	2.2.7.2.dal.lucent.com (a 4 digit site-wide extension reached 
		by simply dialing four digits)
and
	2.2.7.2.1.0.1.lucent.com    (A 7 digit corporate location+extension
		VPN dialing plan reached by dialing 8+location+extension)
and
	2.2.7.2.3.3.7.2.7.9.nanp.us (the NANP plan reached by dialing 9+10
digits)

and
	2.2.7.2.3.3.7.2.7.9.1.e164.arpa (The E164 GSTN plan reached by
dialing
		011+e164 number in the US.)

where the e164.arpa, and lucent.com are a Cnames pointing back to
2.2.7.2.dal.lucent.com and nanp.us has a Dname pointing to 1.e164.arpa.  Now
I can  have a set of four NAPTR entries, one with a different re-write for
each of the "dialplans".

With the numbering plan identified, one could more easily determine which
regexp to use where the current proposal would leave you guessing.

Greg V.

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 11 Aug 2000 19:35:26 +0200

At 09.44 -0500 00-08-11, Vaudreuil, Greg M (Greg) wrote:
>I hope
>can identify whether it needs to apply itteration.....

In NAPTR (if that is what you talk about), the recursion is 
identified by having an empty flag field.

   paf