RE: [jig] Some random note on draft-ietf-dnsext-aliasing-requirements-01.txt

["Terry L Davis, P.E." <tdavis2@xxxxxxxxxxxxx>]

Avri

I would certainly second your points 2, 4, and 6!

Take care
Terry Davis

-----Original Message-----
From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of Avri
Doria
Sent: Tuesday, May 17, 2011 9:35 AM
To: jig
Cc: Suzanne Woolf
Subject: [jig] Some random note on
draft-ietf-dnsext-aliasing-requirements-01.txt




Hi,

In re-reading the draft for the 16 May meeting I came up with a few
questions and comments which Edmon asked me to send to the list.  I want to
start though by saying I think it is a good draft and the first time i read
it I had no comments, and it offers a lot for us to think about.  I still
think it would be worth having Suzanne walk us through it during one of our
meetings.

I have copied Suzanne on this message and I hope she corrects any
misunderstanding I have, and especially any misstatements I make about the
draft.

1. It impressed me again that, at this point there is no technical solution
to the aliasing problem.  Not CNAME and not DNAME, though our crowd has
bandied those around as solutions.  People in this group and others focused
on the issue may know this already, but most people do not.  A lot of people
I talk to, just figure it has to be possible.

2. The draft talks about there being administrative methods that Registries
have for dealing with the problem: 

"there are also administrative mechanisms available for manipulating
   databases underlying the generation and resolution of DNS names.
   Registry operators have many mechanisms for working around DNS
   protocol in order to get behavior they want for names in DNS zones,
   and management of "aliases" is no exception.  However, it is not
   clear how much of the user and operator requirements for "aliases"
   can be met by mechanisms for provisioning DNS zones, at acceptable
   cost."

Perhaps it is just me, but I do not  understand how they do it.  While I can
figure out how it might be handled at the top level and even in second level
zone files, I have no clue what they do about the 3rd+ level. Is there a
centralized scalable process?  I.e. I do not know why we are saying that the
problem can be solved administratively and am not convinced that we can -
though we have ccTLDs now that are ostensibly doing so.  I think the
document says as much, but I may be reading more into it than is said.

3. The draft provides about a page of case studies (2.3.1), but this is the
shallowest part of the document.  I think the draft would benefit from some
serious case studies, the kind Dennis' group will be working on, before it
is published.  In so far as it has cases, it would probably benefit from JIG
and other group review of those cases.

4.  In talking to the IETF it is also important to remember something that
is mentioned in the draft.  The IETF looks at strings as having no meaning.
Just as it took me years to accept that there was something more to domain
names, from the policy and rights perspective,  than just a happy
coincidence if it was a word or a phrase, the IETF in its technical role
does not recognize the importance  of labels as having semantic importance
as words.  That difference in perspective can be important to establishing
requirements for aliasing and the priority of such work.

5. Some of the possible solutions are mentioned.  It is important to
remember that these have not been standardized and that without a coherent
set of requirements, it is not certain that these meet the requirements for
a  policy view for sameness.  It is also not enough to read this section to
understand what the possible solutions offer. (and that is not a requirement
for this draft.  But for example, I do understand how zone cloning deals
with varaince at all levels, and would each level need to cloned? This
question is not relevant to our discussions, but it is bugging me so I will
have to go research further.)

6. There are complexities in adding aliasing to DNSSEC, even in the
administrative solutions that I do not understand - I just beleive that
there are dragons in those waters.  I am actually not sure that the issue is
completely understood on a general level, but it might just be me.

7. One of the problems that impresses me most was that even if they could
develop a solution, what makes anyone think that it would be deployed widely
or soon enough for it to be useful?  There is a recognition of the
'maturity' of the DNS and the extreme care that much be taken in adding
things with backward compatability.  That plus the incentive to actually
support aliasing at all points in the network including resolvers and
applications is quite a project.

Finally as someone who is both of ICANN and of the IETF (with my roots being
in IETF), I do not think the draft should be published as an Informational
RFC until such time as we have managed to get both communities to understand
the requirements and to understand the same set of  requirements.  I expect
I will be making that point if/when the draft gets to IETF last call.  I
would also suggest that ICANN use its liaison function to make that point.
I will try to get myself to the next IETF meeting (a funding issue) and make
the point there as well, if I can get there.

On the other hand I do not suggest that we take our time in typical ICANN
fashion in understanding our requirements.  I am not convinced that we will
need to wait until the final report from Dennis' group to be able to
establish a good set of case descriptions or requirements.  Ie. I think we
need to work together, IETF and ICANN, in the near term to make sure this
requirements doc comes out right and does so this year.

That is about it for now.  

a.