Subject: RE: [Enum] Declaring an "Implementation"

From: "Anne Brown" <[email-masked]>
Date: Wed, 28 Jun 2000 13:38:00 -0500

Patrik,

You stated:
" With the word standard in the IETF we mean _one_ agreed way of 
solving a specific problem. Not alternative ways. If you have more 
than one alternative, then you don't have interperability."

I would be careful with your use of "IETF" definitions.  At the onset of the
WG there were several people who wanted a standard protocol for the ENUM
service after investigating the alternatives.  And yet the IETF/IESG saw fit
to mandate a DNS-only solution, stating that other WGs could be formed to
work on other solutions to the same problem.  This was done even before the
requirements document was started. One of the biggest problems with this is
interoperability, in the event that another WG develops another solution.  

You also stated:
"We can not have alternatives for that piece of the puzzle."  

But you have not disagreed with the statement that NAPTR RRs are not a
requirement for the deployment of the ENUM service.  Yet if you define NAPTR
RRS for use with ENUM and then turn around and state that we must have only
one according to the "IETF", then you are in contradiction. 
I have asked you to put a statement into your draft indicating that NAPTR
RRs are not a requirement and that there may be others.  However you will
not agree to do that unless I give you " text which describes one algorithm
which can be used to go from an E.164 number to a URL", which I told you
beforehand I did not have.  
Of course you also know from discussions on the listserv that there is not a
consensus on NAPTR as the RR of choice.  My particular objection to use of
NAPTR is its requirement to specify service-specifics (e.g., services
available and email addresses, etc.) at such a high level, when it
understood that DNS is often not appropriate for maintaining information on
a per resource basis (see draft-ietf-urn-dns-rds-01) and such information is
not scaleable and manageable on a global or even a national level.
Is it your intention to mandate NAPTR as "the" ENUM RR to be used, and not
allow others?  I hope and suspect not and would therefore like to see text
in your draft stating that there are other possible RRs that can be used.
This request does not require for those examples to be stated. 

Anne Brown
Nortel Networks
[email-masked]
+1 613 765 5274

 -----Original Message-----
From: 	Patrik Fältström [mailto:[email-masked]] 
Sent:	June 28, 2000 11:53 AM
To:	David P. Peek; ENUM List Group
Subject:	Re: [Enum] Declaring an "Implementation"

At 09.44 -0400 00-06-28, David P. Peek wrote:
>1. I agree with the comments suggesting the removal of defining a specific
>implementation using the NAPTR RR.  Other examples exist in the draft
><draft-peek-enum-itd-00.txt> that show the use of another RR (TXT) that
>could be shown in addition to examples defined by the Greg Vaudreuil/Anne
>Brown draft.

With the word standard in the IETF we mean _one_ agreed way of 
solving a specific problem. Not alternative ways. If you have more 
than one alternative, then you don't have interperability.

This WG is to solve the problem to, given a E.164 number, get a set 
of URIs using a DNS-based system.

We can not have alternatives for that piece of the puzzle.

   paf

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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jun 2000 22:13:21 +0200

At 13.38 -0500 00-06-28, Anne Brown wrote:
>I would be careful with your use of "IETF" definitions.  At the 
>onset of the WG there were several people who wanted a standard 
>protocol for the ENUM service after investigating the alternatives. 
>And yet the IETF/IESG saw fit to mandate a DNS-only solution, 
>stating that other WGs could be formed to work on other solutions to 
>the same problem.  This was done even before the requirements 
>document was started. One of the biggest problems with this is 

Ok. Understood.

>But you have not disagreed with the statement that NAPTR RRs are not 
>a requirement for the deployment of the ENUM service.

It depends on what you mean by ENUM service. _I_ define ENUM service 
to take one E.164 and get a set of URIs, and I think that should be 
done by NAPTR RRs, and nothing else.

One of these URIs can be an LDAP URI, which in turn can give back 
(through use of LDAP) other URIs which can be selected based on the 
data in the LDAP database.

>Yet if you define NAPTR RRS for use with ENUM and then turn around 
>and state that we must have only one according to the "IETF", then 
>you are in contradiction.

What I am trying to say is that the domainname that you get by 
mapping the E.164 according to what is in the paper that I drafted 
can be used for other purposes, like all domainnames.

>I have asked you to put a statement into your draft indicating that 
>NAPTR RRs are not a requirement and that there may be others.

Requirement for what? That is what I don't understand. I might be 
tired, slow, or whatever...

>However you will not agree to do that unless I give you " text which 
>describes one algorithm which can be used to go from an E.164 number 
>to a URL", which I told you beforehand I did not have.

I see three things here:

(1) Mapping from E.164 into a domainname
(2) Using domainname given in (1) and get back URI(s)
(3) Do other things than asking for URI(s) with domainnames defined by (1)

I try to follow the charter of the wg to do (1) and (2). I claim that 
other people can do (3) if they want, but if one want a set of URI(s) 
given a E.164, NAPTR RRs are what they should use.

>Of course you also know from discussions on the listserv that there 
>is not a consensus on NAPTR as the RR of choice.

The only alternatives I have seen include:

(1) TXT RRs -- immediately turned down by the DNS wg co-chair
(2) Defining a new RR -- which will take years to deploy

1 is just out, and 2 is out as a conclusion because we do have NAPTR 
support in for example bind, but not the new RR type -- AND (as I 
explain in a different email) I don't agree that regexp handling is 
hard, compared with for example the code you have to write to talk 
with the resolver to get back a TXT RR or something new. Getting back 
responses from SRV is harder than getting back the regexp from a 
NAPTR because of the compression used in the SRV for example.

>   My particular objection to use of NAPTR is its requirement to 
>specify service-specifics (e.g., services available and email 
>addresses, etc.) at such a high level, when it understood that DNS 
>is often not appropriate for maintaining information on a per 
>resource basis (see draft-ietf-urn-dns-rds-01) and such information 
>is not scaleable and manageable on a global or even a national level.

The draft you point at talks about the URN resolution process which 
is a very specific one, and I don't want to go into extrapolating 
that discussion into what we deal with here. And, as one of the 
people which came up with the current design of URNs, it is NOT 
because I am trying to run away.

>Is it your intention to mandate NAPTR as "the" ENUM RR to be used, 
>and not allow others?

My personal, yes, when I define the algorithm we talk about in the 
ENUM group is to get back URI(s). I hear that you want to do other 
things than get URI(s) back, and that is for me not an ENUM thing.

>I hope and suspect not and would therefore like to see text in your 
>draft stating that there are other possible RRs that can be used. 

IF one can use more than one type of RR to get back URI(s) given a 
E.164, how should the one querying DNS know what RR to query for?

I claim that we need one and only one algorithm to use to find URI(s) 
when having a E.164, but IF we want to get back other things than 
URI(s) then we can reuse the domainname definition part of the draft 
and do whatever someone come up with.

And, I still don't, as a sidenote, understand what you can NOT do 
with a URI which is easier to do with an SRV? But, as that is (from 
my point of view) not part of ENUM, I really don't care. People 
should be able to come up with whatever they want.

    paf