Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment

[Suzanne Woolf <[e-mail]>]

On Mon, Feb 14, 2011 at 11:37:43AM -0500, Andrew Sullivan wrote:
> But in
> between those events very little discussion on the topic seems to have
> happened.  Moreover, when we do have discussion it tends to focus on
> existing proposals: "Do BNAME", for instance.  But the problem we have
> is that we cannot tell whether BNAME (or any other proposal) actually
> addresses the particular problems people have.  So either we get a
> clear and broadly agreed-upon statement of the problem we are trying
> to solve, or we don't solve the problem (because if we can't say what
> it is, I think that means we don't know).

With all due respect, I'm not sure this is the most (or at least only)
useful razor for where we are at the moment.

I went back and looked at the problem statement draft after being
forced to put it aside for other things for some time. What I'm seeing
is that it has a couple of examples, and could benefit from more, and
needs to more clearly state the potential protocol issues around
application awareness, special processing, etc....

But the other thing we haven't talked about much is the actual
requirements for solutions. We did once (in Anaheim maybe?) but IIRC
only the once.

The main piece that the -00 will have that the previous individual
submission versions didn't, I think now, will be the list of what we
think a solution should look like....not in the protocol details of
behavior, I agree we won't know those without finer details of the
problems (probably plural) we're talking about....but in the sense of
things like:

* A solution must not break DNSSEC;
* A solution must not (should not?) require client changes to be useful;
* A solution must not change existing behavior of established RRtypes and
  protocol (which would make "fix CNAME" a non-starter);
* A solution should clearly either be less work than existing techniques, or
  solve some specific case (such as the canonicalization of email
  addresses that Vaggelis mentioned) that isn't otherwise solvable, so there's
  some incentive for deployment....
* A solution should not be specific to the root zone;

etc.

best,
S.