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

[Avri Doria <avri@xxxxxxx>]

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.