Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful

From: "Stastny Richard" <[email-masked]>
Date: Wed, 22 Jun 2005 10:38:11 -0400

Thank you Patrik for this clarification.
 
I also agree that option c is preferable
 
During the discussion a third alternative showed up:
 
c1: using non-terminals
c2. using terminal NAPTRs
both options having these NAPTRs side-by-side
in tier 1.
 
c3: moving the carriers to  e.g 1.2.3.4.carrier.c.c.e164.arpa
I considered this option as ugly and requiering special clients,
to derieve the domain to query from the E.164 number and
knowing the CC structure, but as Lawrence pointed out,
carriers should know this anyway ;-)
 
The advantage of this solution would be that User ENUM
in e164.arpa remains completely untouched. User Clients
would normally never see these domains
 
The second advantage is that in case c1 and c2 ALWAYS
two or three queries are necessary, in case c3 only one,
both for user and carrier.
 
The "ugly part" remains with the carriers, and they may deserve this
anyway ;-)
 
Richard

________________________________

Von: Patrik Fältström [mailto:paf at cisco.com]
Gesendet: Mi 22.06.2005 15:23
An: Stastny Richard
Cc: lconroy; enum at ietf.org; Richard Shockey
Betreff: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful

On Jun 22, 2005, at 04:56, Stastny Richard wrote:

> The following options exists:
> Put the Carriers in:
> a. e164carrier.arpa - this requires only the IAB and does not involve
> ITU-T
> BUT requires a policy framework to be set up by whom? This may take
> some time even to create a body. -> Restart at square -1

Having two domains in the DNS not technically bound to each other 
(i.e. 6.4.e164.arpa and 6.4.e164carrier.arpa) will create discussions 
regarding policy for who runs the (two) domains. Having them 
synchronized in any way will be a nightmare, and, it forces the local 
regulative bodies that already have had headache over "who will run 
cc.e164.arpa" to wake up again.

> b. carrier.e164.arpa - involves IAB and ITU-T but may not involve the
> national regulators.
> BUT involves for policy mainly the ITU-T. So the body is known, but
> since even the interim procedures are not places in a Rec. yet ...
> -> restart at square 1

See earlier bullet. Similar problems, as you point out.

> c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd 
> ITU-T
> only on the side, but definitely the national regulators.
> The international policy framework may be taken basically as is, but
> national policy needs to be amended. So the time taken is a national
> matter, but it may be easier and faster to set-up (less involved
> parties)

Correct. The policy have to be adjusted in some cases, but the policy 
work is, I claim, not at all as heavy as the previous suggestions.

> The other benefit: National regulators may be forced by the carriers
> to opt-in to e164.arpa, which may be of benefit also for User ENUM.
> -> Continue where we are.
>
> Conclusion: option c may not be the optimal solution, but it will
> be definitely the fastest for the carriers and also be of some
> benefit for User ENUM.

I agree.

    paf

> Additional remark:
> Other trees may and will co-exist, but any tree in e164.arpa may
> serve as a glue. GSMA operators just need to put a pointer in to
> ;enum-context=e164.enum.net
>
> Regards
> Richard
>
>
>
> Richard Stastny
> OeFEG
> tel:+43 664 420 4100
> enum:+43 780 203 211
> callto://fordprefect
> http://voipandenum.blogspot.com
>
>
>
>> -----Original Message-----
>> From: lconroy [mailto:lconroy at insensate.co.uk]
>> Sent: Wednesday, June 22, 2005 1:40 PM
>> To: Stastny Richard
>> Cc: 'enum at ietf.org' ENUM; Richard Shockey
>> Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful
>>
>> Hi Richard, Richard, folks,
>> This proposal should work, albeit it will take effort and => time to
>> analyse and
>> get the specifications in place - at least it doesn't directly
>>
> conflict
>
>> with 3761.
>>
>> N-Ts are, as you spell out, evil (and the existing specs are, at 
>> best,
>> complex in
>> this area).
>>
>> However... As an alternative:
>>
>> Given that Users are in x..x.c..c.e164.arpa. already, whilst Carriers
>> aren't, why
>> not just have a sub-domain (for example carrier.e164.arpa.)
>> specifically for Carriers
>> to populate and query, and leave the Users where they are?
>>
>> Basically, if the carriers are looking somewhere else, then ALL of 
>> the
>> problems go away.
>>
>> The carriers and their suppliers have much better "connections" to 
>> ITU
>> (and, arguably, to
>> the IAB and IETF - see current discussion on WG chair commitments on
>> the IETF-general list).
>> If the agreements need to be changed at all, then the
>> carriers/suppliers will have to do
>> this policy (re-)development work anyway.
>>
>> I am still waiting for convincing arguments justifying the clearance
>>
> of
>
>> users from the
>> space allocated for user ENUM.
>>
>> So far, we seem to have missed that completely.
>>
>> all the best,
>>    Lawrence
>>
>> On 22 Jun 2005, at 11:50, Stastny Richard wrote:
>>
>>> Dear all,
>>>
>>> The proposal brought forward in
>>> draft-pfautz-lind-enum-carrier-user-00
>>> raises two issues:
>>>
>>> 1) Should (user) ENUM and Infrastructure (Carrier) ENUM
>>> implementations be mixed within e.164.arpa?
>>>
>>> 2) If yes, how should this be done technically?
>>>
>>> Regarding 1) I have submitted to the list the position of
>>> ETSI TISPAN WG4 in a previous post, containing the pro and cons.
>>>
>>> So I want to concentrate here on issue 2) only:
>>>
>>> draft-pfautz-lind-enum-carrier-user-00 proposes
>>> the usage of non-terminal NAPTRs to separate
>>> between user and carrier entries in Tier 1 of
>>> e164.arpa
>>>
>>> The usage of non-terminals creates many problems,
>>> (see below), so I consider this harmful.
>>>
>>> It is therefore proposed to consider the usage
>>> of terminal NAPTRs to solve the problem at hand,
>>> a technical proposal is also contained below.
>>> This proposal does not solve all problems raised
>>> with non-terminals below, but most of them.
>>>
>>> Problems with non-terminal NAPTRs:
>>>
>>> The first problem with non-terminals is non-conformant
>>> with RFC3761:
>>>
>>> Although RFC3761 allows the usage of non-terminals
>>> (section 1.3 and 2.4), the intrinsic assumption is
>>> that in this case there is no Enumservice used
>>> in the service field (beside E2U).
>>>
>>> Basically the template in RFC3671 to register a
>>> Enumservice cannot be used as is, because in section
>>> 3.1.1 is stated:
>>> "A registered Enumservice must be able to function as
>>> a selection mechanism when choosing one NAPTR resource
>>> record from another.  That means that the registration
>>> MUST specify what is expected when using that very NAPTR
>>> record, and the URI which is the outcome of the use of it.
>>>
>>> Specifically, a registered Enumservice MUST specify the
>>> URI scheme(s) that may be used for the Enumservice, ..."
>>>
>>> So a URI definition such as "N/A" or "Any" is not allowed.
>>>
>>> Additional problems:
>>>
>>> -existing users are forced to move out of e164.arpa
>>> -Non-Terminals are not supported in existing clients
>>> -Non-Terminals involve multiple DNS queries
>>> -No Glue Records in Non-Terminals
>>> -Prone to "Error in User"
>>> -Automatically checking the domain is not easy
>>> -Pre-existing targets only (the privacy/control problem)
>>> -Going in Circles, by accident or design
>>> -Time To Live across domains
>>> -Etc.
>>> I think Lawrence is here better suited to explain these
>>> problems more in detail, if required or requested.
>>>
>>> Proposal to use terminal NAPTRs
>>>
>>> It is therefore proposed to use terminal NAPTRs
>>> for this purpose:
>>>
>>> I propose to reuse the Enumservice "enum" as specified
>>> in ETSI TS 102 172 for redirection:
>>>
>>> This Enumservice uses the "tel:" URI to instruct the
>>> ENUM client to launch another ENUM query for the
>>> E.164 number given in the "tel:" URI. The purpose is
>>> to allow a user who has say three different E.164 numbers
>>> registered in ENUM to point two of this numbers to the
>>> third and maintain the real NAPTRs only in the domain
>>> of the third.
>>>
>>> The default assumption with the tel: URI as given is
>>> that the domain to query is e164.arpa (ENUM)
>>>
>>> If now an additional parameter is defined for the tel: URI
>>> e.g. ";enum-context=foo.bar", the behaviour could be
>>> exactly the same, except that in step 4. of section 2.4
>>> in RFC3761 instead of e164.arpa the domain given in
>>> enum-context is appended. This causes not much changes
>>> to existing ENUM-clients, some of them already allow
>>> a different apex from e164.arpa to be used or query two
>>> different trees subsequently.
>>>
>>> If no enum-context is given, the ENUMservice "enum" works
>>> as defined in TS 102 172 for e164.arpa
>>>
>>> The advantage of this proposal is: minimum change
>>> to the user enum clients and all solutions for
>>> variable length number plans and DDI work as usual.
>>>
>>> For the carrier part a new Enumservice "carrier"
>>> is proposed which works in exactly the same way with
>>> a "tel:" and in this case with a mandatory enum-context
>>> parameter.
>>>
>>> Using the "tel: URI in this context provides an
>>> additional bonus: the "tel:" URI may be used with
>>> additional parameters, e.g. the ones defined
>>> in draft-ietf-iptel-tel-np-05, especially ";rn=" and
>>> ";cic=". This would allow carriers also to enter
>>> data for numbers existing on the PSTN only and
>>> providing national routing numbers or Carrier Identification
>>> Codes, if required. Carriers may retrieve e.g a routing
>>> number already in ENUM an save an additional IN-dip on the
>>> PSTN.
>>>
>>> User ENUM clients do not need to be able to process NAPTRs
>>> with Enumservice "carrier", they may ignore it.
>>>
>>> To implement this solution, an additional measure is necessary:
>>>
>>> If Tier 1 contains both User and Carrier NAPTRs, the User NAPTR
>>> cannot be stored in e164.arpa any longer (this is also true
>>> for the non-terminal proposal). So the user MUST move out to
>>> another domain e.g. as proposed to joesenum.com. Since there
>>> is no reason normally for a user in e164.arpa suddenly to
>>> go and look for an own domain if a carrier decides to opt-in,
>>> there should be a default domain available also under e614.arpa,
>>> where the Registrar or Nameserver provider can move the user
>>> in this case. It is proposed to use user.e164.arpa for this
>>> purpose.
>>>
>>> This requires a slight modification in the agreements between
>>> IAB, RIPE and ITU-T insofar that
>>> 1. this domain is created
>>> 2. the delegation of this domain is always performed in
>>> parallel and according the rules as defined in
>>> the Interim Procedures for the delegation of e164.arpa
>>> 3. Any existing delegation in e164.arpa gets an automatic
>>> delegation to the same conditions e.g nameservers as stated
>>> in the original request
>>>
>>> If carrier ENUM is implemented within e164.arpa and what the
>>> national specific rules are is a national matter and has
>>> to be added to the existing framework for User ENUM.
>>>
>>> Best regards
>>>
>>> Richard
>>>
>>>
>>> Richard Stastny
>>> OeFEG
>>> tel:+43 664 420 4100
>>> enum:+43 780 203 211
>>> callto://fordprefect
>>> http://voipandenum.blogspot.com
>>>
>>>
>>> _______________________________________________
>>> enum mailing list
>>> enum at ietf.org
>>> https://www1.ietf.org/mailman/listinfo/enum
>>>
>>>
>>>
>> ---------------------------------------
>> lawrence conroy    |tel:+44-1794-833666
>>
>
>
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 22 Jun 2005 15:45:58 -0400

On Jun 22, 2005, at 07:41, Stastny Richard wrote:
c1: using non-terminals
c2. using terminal NAPTRs
both options having these NAPTRs side-by-side
in tier 1.
c3: moving the carriers to  e.g 1.2.3.4.carrier.c.c.e164.arpa
I considered this option as ugly and requiering special clients,
to derieve the domain to query from the E.164 number and
knowing the CC structure, but as Lawrence pointed out,
carriers should know this anyway ;-)
Carriers, yes, but think of the poor stupid device that want to use  
the information the carriers have put in dns? I.e. only carriers  
might store things there, everyone might do lookups.

   paf