On Tue, Oct 30, 2001 at 06:48:40PM -0500,
Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
On Tue, 30 Oct 2001 21:15:35 GMT, Zefram <zefram(_at_)fysh(_dot_)org> said:
I'm looking for discussion of the problem more than the solution at this
stage; my I-D does outline a couple of possible solutions, but considering
the issues that have arisen already in respect of the problem statement,
solution finding will have to wait a bit.
URI - we'll work with the ISSN example that you gave. Designing a DNS
that is fault-tolerant is well-understood (use multiple NS in different
AS, not all in the same /24 like certain famous sites did ;). Therefor,
for this discussion, "if issn.org goes away that URN space is hosed".
Very true - but let's think a bit deeper. "issn.org" is not likely
to go away unless the ISSN International Centre goes away - in which case
the ISSN system is in trouble anyhow.
Woaaaaaah... I think there's a huge misunderstanding of the URI Resolution
process here. Cutting out the original document's discussion here:
<paste>
2.2 URI Resolution
The URI resolution process defined by [NAPTR] refers URI resolvers
through a series of domain names to route a resolution request to the
appropriate authority that can give a location or other information
for a resource. These referrals, being by name, implicitly assume
that the name/identity mapping is persistent.
In particular, consider URN types that are managed and resolved by a
single organisation, for example the "ISSN" URN namespace described
in [ISSN-URN]. In cases like this, resources critical to the
handling of all URIs of a particular type are named within a domain
managed by the single organisation responsible for that URI type.
Any interruption of name resolution in that domain, or any compromise
of the name/identity correspondence for that domain, would be highly
disruptive. It is necessary in these cases that the name of a
privately-managed domain be reliably persistent.
</paste>
The referrals are meant to be dynamic. That's the entire point of
the URI Resolution process. If issn.org becomes disrupted either
through some DNS problems or through the fact that ISSN changes
their dns entries to be ISSSSSN.info or somesuch, the URI Resolution
process still works if you do the delegation the way the documents
suggest you do it. The ISSN organization could setup their NAPTR resolution
process so that every day at 4:00 the delegation through (not to, but
through) issn.org gets changed to some other domain-name. The
entire process is dynamic enough using DNS' TTLs that there is no
need for the domain-names to be persistent. The only one that does have
to be persistent is the very first one (uri.arpa).
In that one small sense, you are right. We do need some domains to be
persistent. But we already have a process for doing that in the .arpa domain.
But it should be done _EXTREMELY_ carefully. Persistence in the DNS is
just the wrong way of going about it. Make your URIs persistently bound
to the logical Resource and then use some dynamic resolution
mechanism to make sure you can keep that resolution step in line with the
logical binding....
-MM
--
--------------------------------------------------------------------------------
Michael Mealling | Vote Libertarian! | urn:pin:1
michael(_at_)neonym(_dot_)net | |
http://www.neonym.net