Subject: RE: [Enum] RE: Standard DNS Delegation or CNAME/DNAME Redirection

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Thu, 2 Nov 2000 14:48:25 -0500

Dname/Cname are clearly useful for bottom-up ENUM services, but that is not
why I suggest their use.  There are a number of top-down topologies which
would benefit operationally from the ability to re-point one number tree to
another or to re-point one address to another.

Greg V.

-----Original Message-----
From: Leslie Daigle [mailto:[email-masked]]
Sent: Thursday, November 02, 2000 12:56 PM
To: Vaudreuil, Greg M (Greg)
Cc: Robert H. Walter; [email-masked]; Patrik Faltstrom; Randy Bush
Subject: Re: [Enum] RE: Standard DNS Delegation or CNAME/DNAME
Redirection

I am in danger of having completely missed the point, but it
strikes me that:

	. the "traditional" view of ENUM has been for "top-down"
	  resolution, following a delegation path, and for that
	  the NS/NAPTR route is appropriate/adequate.

	. your examples seem to treat "bottom-up" resolution -- 
	  working resolution from a local context outwards to the
	  closest applicable scope.  In that case, you don't
	  want to/it would perhaps be difficult to engineer
	  top-down resolution that would find the appropriate
	  level for your resolution

These are two different problems, and probably bear 2 different
solutions -- but ones that need to be properly integrated or else
we will wind up with "islands" of enum telephony (where you can't
work your way out to "the" global registry).

Leslie.

"Vaudreuil, Greg M (Greg)" wrote:
> 
> The key is your statement "Why re-issue, reform the query when standard
DNS
> delegation will suffice".  Where it is sufficient, it clearly preferable
to
> use NS records to delegate authority.  For the simple examples you have
> provided, the NS records are clearly sufficient and return more quickly.
> 
> In a previous response, I have described a number of topologies where NS
> records are not sufficient to represent existing numbering plan
topologies.
> 
> Unless we decide otherwise, Dname / CNAME are useful and standard DNS
> facilities.  As such they are part of the toolbox of an ENUM system
> administrator, must be supported by clients, and whose negative
interactions
> with NAPTR must be well understood.
> 
> Greg V.
> 
> -----Original Message-----
> From: Robert H. Walter [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2000 11:57 AM
> To: [email-masked]
> Cc: Vaudreuil, Greg M (Greg); Patrik Faltstrom; Randy Bush
> Subject: Standard DNS Delegation or CNAME/DNAME Redirection
> 
> Greg, Ann,
> 
> Please clarify why you believe CNAME and DNAME resource records
> are required to redirect the DNS query from the designated
> authority to the service registrar?  Why re-issue, reform the
> query when standard DNS delegation will suffice? Consider the
> following scenarios that assume the designated authority for
> 1.e164.arpa has provisioned the fully specified E.164 domain
> name 2.1.2.1.5.5.5.0.0.8.1.e164.arpa on behalf of the service
> registrar ACME:
> 
> Scenario 1: Use NS and A glue records to delegate authority for
> the fully specified E.164 domain name to the registered name
> server.  This approach has the advantage of not requiring client
> resolvers and/or foreign name servers to additionally query for
> the A records associated with the defined name servers.  Using
> glue records has the additional restriction that the delegated
> name servers MUST be children of the 1.e164.arpa sub-domain,
> but results in reduced resolution time because there are fewer
> queries and network traversals required.  Notice the extended
> domain names for acmes name servers.
> 
>   2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.1.e164.arpa.
>                                    IN NS ns2.acme.1.e164.arpa.
> 
>   ns1.acme.1.e164.arpa.            IN A  192.249.249.1
>   ns2.acme.1.e164.arpa.            IN A  192.249.249.2
> 
> Scenario 2: Use only NS records to delegate authority for the
> fully specified E.164 domain name to the registered name server.
> This approach has the disadvantage of requiring client resolvers
> and/or foreign name servers to additionally query for the A
> records associated with the defined name servers.  By not using
> glue records, the delegated name servers are not required to be
> children of the 1.e164.arpa sub-domain. The result is increased
> resolution time due to additional queries and network traversals.
> 
>   2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.com.
>                                    IN NS ns2.acme.com.
> 
> In either scenario, the delegated name server must be minimally
> provisioned with an e164.arpa zone that contains the associated
> NAPTR records.  It may be more conventional that the delegated
> name server be provisioned with the zone at the cut boundary
> (1.e164.arpa), but this is not a requirement. Are you attempting
> to avoid having the service registrar provision the e164.arpa
> zone on their name server?
> 
> Bob
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/enum

-- 

-------------------------------------------------------------------
"Reality with a delicate splash of the imaginary... 
    ... or was that the other way around?"
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

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

---

From: [email-masked]
Date: Fri, 3 Nov 2000 09:16:12 +0200

Hi All,

I am not as much of an expert on DNS as maybe I should be,
but I would like to put in my requirements.

> I support the use of DNAME in ENUM. I believe ENUM faces a 
> major deployment problem, that of finding the authoritative 
> publisher of an information. There are basically two solutions 
> to this problem, bureaucratic management and competition. DNAME 
> enables competition.

I beleive that Christian is correct in saying that competition
should be encouraged.  The scenario I have is in the coming
3G networks.  In these networks, there may be the oportunity
to associate many services with a phone number: SIP services,
voice messaging, video messaging, streaming media, web page,
email and so on.  I see ENUM as a great way to wrap up many
'identities' of a user.

My worry is that if a service provider is the ENUM service,
it may be difficult to change the service provider of 
some or all of the services.  

Currently, there are companies within 3GPP who are suggesting
the use of ENUM in the 3GPP networks, so this is an issue that
we may want to consider.

About the use of DNAME/CNAME, I will defer that discussion
to those more expert with DNS.

best regards,
John

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 3 Nov 2000 06:42:21 -0500

At 08.28 -0800 00-11-02, Christian Huitema wrote:
>I support the use of DNAME in ENUM. I believe ENUM faces a major deployment
>problem, that of finding the authoritative publisher of an information.
>There are basically two solutions to this problem, bureaucratic management
>and competition. DNAME enables competition.

I think you have to be VERY careful here.

As a person which have a E.164 number delegated to me (secondary 
delegation as it is called in Sweden), I don't want to know what 
listing service you use, and what I have to do so you find 
information about my number.

The key thing is that I as the holder of the E.164 number should be 
able to choose service provider for the service, and _regardless_ of 
what service provider I choose, you should find the record.

If you with competition include the risk that if you query two 
different listing services you get different results for my E.164 
number, then I claim we have failed.

    Patrik

---

From: "Pfautz, Penn L, NNAD" <[email-masked]>
Date: Fri, 3 Nov 2000 09:25:35 -0500

Chriatian:
Some comments, less directed at CNAME/DNAME, than the more general issues
you raise.

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Thursday, November 02, 2000 11:29 AM
To: 'Richard Shockey'; Michael Froomkin - U.Miami School of Law
Cc: Robert H. Walter; [email-masked]; Vaudreuil, Greg M (Greg); Patrik
Faltstrom; Randy Bush
Subject: RE: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection

If we have a single tree, we will end up with a set of regional monopolies
deciding what goes in the mapping. At the top, we will indeed find the ITU,
then the various local authorities, then the various phone providers. At
each level, there will be confusion and power struggles. For example, look
at "1.e164.arpa." Who has authority? The area is actually shared between
several North American countries; even within the US, the delegation to the
ITU is managed by the State Department while the regulation of telephony is
managed by the FCC. If you go down to the area code level, the matter is not
any clearer. Who has authority over "2.1.2.1.e164.arpa"? Is this the New
York State public utilities commission, Bell Atlantic, or a third party? The
matter only becomes kind of clearer at the lower level of the hierarchy,
where "x.x.x.2.1.2.1.e164.arpa" corresponds to a bloc of addresses, the
current unit of management for assignment of numbers to local competitive
carriers, and also for LNP. (The most likely result is that each PUC will
hire a contractor that manages the listing.) But then, a potential use of
ENUM is to bypass the local carrier, for example to send documents as e-mail
instead of faxes; this means, potentially, a loss of revenues. So, while the
users of phone numbers have an interest in listing their numbers, the phone
companies are conflicted. Expect some interesting developments.

>> I don't think that *this* part of the tree will be that much of a
problem.
>> If the other participants in the NANP don't want to join the US in ENUM
administration
>> RIPE, who will maintain the top e164.arpa domain, will provision down to
the NPA level
>> in their DNS. I envision, as James Yu and I have laid out in our I-D,
that there
>> will need to be some federally chartered entity that maintains a
1.e164.arpa 
>> (or us-npa.e164.arpa) level DNS that points for each number to the
appropriate service 
>>  registar. It's at the service registrar level that I hope competition
can occur. I
>> don't see states administering their own NPAs nor do I see telcos having
delegation 
>> for ther LERG-assigned number blocks, though it is possible that telcos
will have 
>> delegation for the numbers they actually provide service for.

IMHO, the only way out is to allow a competition, have a forest instead of a
tree, so that we could get alternative services such as
"2.1.2.1.joe-s-listings.com." The clients that decide to use Joe's listings
know what they get: Joe's idea of who owns what number; they can trade
bureaucratic certainty and pace for rapid updates and potential mistakes.
DNAME allows us to build forests instead of tree; Joe's listing may use the
DNAME technology to point at branches managed by other servers, maybe even
to point back to the main tree for some countries.

>> The problem with the "joe's listings" approach is it doesn't guarantee me
>> control over my telephone number's domain. At the end of the day Joe will
have
>> to verify TN ownership. Otherwise, someone may register a number they
don't own
>> with Joe, get calls/messages/etc that belong to someone else, and Joe,
possibly 
>> along with any registry that Joe uses, will get sued. When people's calls
get stolen,
>> which is worse than slamming, the bureaucrats will get involved with a
vengance.
>> That's why we need to build in safeguards to begin with, even if it drags
the process 
>> out.
>> There is also the problem Patrik points out: if folks need to figure out
what
>> listing sevice to use, ENUM will be that much less useful.

Another interesting case is that of enterprises, who manage a local dial
plan. If an enterprise uses 4 digits extensions, then it is much more
natural to resolve "x1234" through "4.3.2.1.local-plan.example.com" than to
go back all the way to the e164.arpa root. But then, it is also useful to
store any piece of data only once, so there is no point in replicating the
records of the local plan under "4.3.2.1.a.b.c.d.e.f.g.e164.arpa." This is a
case where DNAME are very interesting. By the way, this works both ways. If
the enterprise's dial plan has an escape code for international codes, say
"00", and if it contracts with Joe's Listing company for the ENUM service,
then it can enter a DNAME pointing "0.0.local-plan.example.com" to
"joe-s-listings.com."
>> I see no problem for folks who want to do *some* resolution using the
ENUM protocol 
>> in domains other than e164.arpa for their own private numbering plans.

In short, DNAME allow for a forest instead of a tree. A forest looks scary
for bureaucrats, but it enables competition. And it also enables local
management of resources without replication of records, smooth transitions
between local dial plans and global registries. In any case, the tool is in
the box, so the debate is a little bit futile...

>> Penn Pfautz

-- Christian Huitema