Subject: [Enum] DDDS, DNS clarification needed?

From: Brandner Rudolf <[email-masked]>
Date: Tue, 19 Feb 2002 12:57:08 +0100

Having read the DDDS part 1, 2 and 3, I have some questions about ENUM, DNS and DDDS.

My understanding of DDDS and ENUM is
     ENUM == a DDDS Application

Follwing the example in draft-ietf-urn-dns-ddds-database-07.txt:

1) I have got a number +49-8141-5359799
2) The AUS would be +4981415359799
3) The First Well Known Rule would yield the First Key 4981415359799
4) In order to use DNS the First Key is converted into a domain-name
   "9.9.7.9.5.3.5.1.4.1.8.9.4.e164.arpa."
5) Retrieve Rewrite Rules as NAPTR records using key
6) Apply NAPTR on AUS to produce a new key
7) If matching rule is terminal we have the result,
     else goto step 5 with this key

Questions:

- Shouldn't step 4 be part of the First Well Known Rule according to the algorithm diagram of draft-ietf-urn-ddds-05.txt, Page 6?

- If step 4 is not part of the First Well Known Rule, where does it fit into the algorithm diagram?

- The algorithm diagram in DDS-05 does not describe lookups that result in a NS record (through delegation). This means that it expects to use a Recursive Resolver?

Many thanks for the clarifications,
Rudi

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

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 19 Feb 2002 12:54:55 +0000

At 12:57 pm +0100 19/2/02, Brandner Rudolf wrote:
>- Shouldn't step 4 be part of the First Well Known Rule according to 
>the algorithm diagram of draft-ietf-urn-ddds-05.txt, Page 6?
>
>- The algorithm diagram in DDS-05 does not describe lookups that 
>result in a NS record (through delegation). This means that it 
>expects to use a Recursive Resolver?
>
>
To which I add more questions on the TripleDS thicket:
Question - is the AUS "+494023451234" or is it "494023451234"?

Question - Does the conversion of the AUS to a key (using the
"First Well Known Rule") give "494023451234" or instead give us
"4.3.2.1.5.4.3.2.0.4.9.4"?

Question - Should the process of converting a key to DNS-suitable
form append a "well known constant" domain (e.g. ENUM_ROOT_DOMAIN),
rather than "hard-wiring" the domain?
The value of this constant is ".e164.arpa.", of course, and it *is*
a generalisation, but this may be useful in the future.

Question - Application Collision Avoidance seems to be achieved by
placing the DNS queries in the ENUM_ROOT_DOMAIN; does this mean
that we CANNOT place NAPTRs for other application types (e.g
URN resolution) in zones within this space (i.e. all NATPRs under
ENUM_ROOT_DOMAIN *MUST* be ENUM rules)?

All the best,
    Lawrence

-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: Michael Mealling <[email-masked]>
Date: Tue, 19 Feb 2002 09:16:09 -0500

>      ENUM == a DDDS Application

Correct...

> - Shouldn't step 4 be part of the First Well Known Rule according to the 
> algorithm diagram of draft-ietf-urn-ddds-05.txt, Page 6?

Not really. I can see where the question comes from though. That diagram
is generic for all databases/applications. There is a database specific
step where the Key is converted into database specific form. In the
Database specification this is the 'Key Format'. 

> into the algorithm diagram?

It is the conversion step from the generic application into the Database
specific form. I.e. this ENUM step is actually all part of the "Lookup key
in DDDS Database" block in that diagram.

> - The algorithm diagram in DDS-05 does not describe lookups that result 
> in a NS record (through delegation). This means that it expects to use a 
> Recursive Resolver?

Correct. The DNS Database simply returns requests for Keys in the correct
Format according to the existing DNS standards. Thus, the algorithm simply
asks for "9.9.7.9.5.3.5.1.4.1.8.9.4.e164.arpa.", it is up to the DNS
resolver to handle all DNS specific NS processes and other standard techniques.

The reason all of this is this way is that you could just as easily
specify in the future that ENUM use another directory. Let's suppose
that in a few months we come up with some new DNS software that makes
the existing system obsolete (shudder). All you would need to do is
specify how the Key in #3 is expressed in that new Database and then
what the output record format was. The algorithm, APIs, policies, etc can
all stay the same.

One example was in the URI Resolution application. There was a need for
having cached records in a local file on a CDROM. The authors simply
specified a new database that worked on flat files with very simple keys.
The algorithms and APIs 'just worked', all they had to do is switch out
which database they were using depending on whether or not they were connected
to the Internet or not.

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: Michael Mealling <[email-masked]>
Date: Tue, 19 Feb 2002 09:26:53 -0500

> Question - is the AUS "+494023451234" or is it "494023451234"?

The AUS is the second one. The '+' is extraneous here so its
removed to make the Key as simple as possible but still useable.

> "First Well Known Rule") give "494023451234" or instead give us

It gives "494023451234". Its the conversion of that Key into the
Database Key Format that gives the dotted, DNS form.

> a generalisation, but this may be useful in the future.

I'm not going to go there! ;-) You could do that but IMHO changing
your root around like that is asking for insane amounts of trouble.
Define ENUM as e164.arpa and be done with it. If you want to do
something else in another root then call it something else: FooNum,
BarNum, FooBlat Telephone Number Lookup Service. 

> ENUM_ROOT_DOMAIN *MUST* be ENUM rules)?

You can place NAPTRs for other application types in those zones. You just
have to make sure that one applications rules can't be confused with another
applications rules. This can be achieved four ways:

1) flags that are specific to an application and unknown to others, thus 
causing the other application to drop these rules on the floor since
it doesn't understand its flags. Since ENUM uses the 'u' flag this
wouldn't work for ENUM and URI Resolution.

2) Services and/or protocols that are also unique to the application. I
discourage this because there is a good history of protocols and services
being used outside our zone of control.

3) Matching rules that are specific to a namespace. By anchoring the match
with the entire Key you can ensure that nothing else BUT that
application can use that record. I always do this in my URI Resolution
examples so that its clear what's being matched.

4) subdelegate to application specific zones. I.e. if you wanted to 
mix URI Resolution stuff inside e164.arpa I would delegate out of the
4.3.2.1.5.4.3.2.0.4.9.4.e164.arpa. with a uri-res zone. I.e.:
uri-res.4.3.2.1.5.4.3.2.0.4.9.4.e164.arpa. and then simply make your
rewrite rules talk about that domain instead of its parent.

-MM

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 20 Feb 2002 09:00:00 +0000

> a generalisation, but this may be useful in the future.

I think this would be useful. Apart from anything else, it means that you
can set up testbeds simply by changing the value of ENUM_ROOT_DOMAIN. If
software expected to do this, the value would be configurable rather than
hardwired, with obvious benefits.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <[email-masked]>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change