[DNSOP] draft-licanhuang-dnsop-urnresolution

[Andrew Sullivan <[e-mail]>]

Hello,

I have read the documents, draft-licanhuang-dnsop-urnresolution-00,
and draft-licanhuang-dnsop-distributeddns-02.  

In the DNSOP meeting today, participants were asked to comment on
the first of those documents.  Hence this email.

I have a number of questions about your documents.

To begin with, the motivation in both cases is unclear.
Draft-licanhuang-dnsop-distributeddns-02 makes a glib claim that "the
existing DNS architecture is unsuitable for the growth of the
Internet[DINGNS]".  I'm familiar with the paper in question, but I
think its conclusions are not strong enough that one can just mention
that paper, and conclude therefore that we have to throw away DNS. 

Since the -urnresolution- draft appears to depend on
-distributeddns-, -urnresolution- does not seem to have a motivation,
either.  Therefore, the first problem you would need to solve in these
drafts is to define exactly what the problem is that you're trying to
solve.  At the moment, it isn't clear to me.

Even if you had a clear motivation for the work, I do not think that
-urnresolution- is a good answer to any question.

First, if the document is saying that authority in URNs is delegated
across label boundaries have to be managed in order to provide a
deterministic hierarchical namespace, then this is just a part of the
definition of URNs, and we need no new documentation to say this.

Second, the document mixes different kinds of resolution pieces in a
way that I don't think add anything.  What does calling
"functionscheme", "global-hier-part", and "local-name" (when taken
together) add to the simple activity of picking apart and resolving a
URI as we do it today?  The current infrastructure provides in
addition the happy effect that you can re-use parts of a given URN
without having any relation to the URN itself: the DNS name part of a
URN is almost accidentally part of it, and that DNS name is maybe
handy to use for other purposes.  Your proposal seems to me to be
trying to undermine that, and to the extent it is, it represents a
step backwards.

Third, this document appears to be suggesting that there is something
like a semantics for labels in the DNS (or some DNS-replacement
thing).  For reasons that have been amply discussed within the IETF
community, this is a suggestion that should be rejected out of hand. 
Labels are labels and nothing more: the idea that there is some
"music" virtual organization that is going to "control" the
delegation of the label [music] just imports yet more policy baggage
into the protocol.  That is not a good idea.

Given the above, I cannot support adoption of your document by the
DNSOP working group.  I also have a hard time imagining what
alterations you could make to it such that I would think it a good
idea to adopt.  I'm happy to look at additional revisions to the
document, however, if they address the above issues.

Best regards,
Andrew

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[e-mail]>                              M2P 2A8
                                        [phone] x4110


_______________________________________________
DNSOP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dnsop