<hat wg-co-chair=on>
In my opinion, Paul is proposing that we attempt to solve a
different problem than dnsop-serverid and austein-nsid attempt to
solve. This says nothing about the merits of Paul's proposal-to-be,
just that, again in my opinion, it is a nontrivial change in goal.
The goal of dnsop-serverid and austein-nsid is to attempt to answer
loud cries for help that we have been receiving from the root zone
server operators (among others) for many years now.
</hat>
<hat wg-co-chair=off just-another-bozo=on>
Personally, I do not view the tasks of identifying the server and
identifying the client as at all symmetric in a protocol like DNS,
so it's not obvious to me that such mechanisms should be linked.
</hat>
<hat wg-co-chair=on>
Since dnsop-serverid is in WG last call, it would be useful to know
whether the WG:
a) Agrees with my characterization of Paul's proposal as a change (or
expansion, if you prefer) of the goals for this work item;
b) Agrees with Paul on this change in goals.
Silence will be interpreted as "yes" on (a) and "no" on (b).
Finally, please note that nothing above rules out future work along
the lines Paul suggests. The issue on the table is just whether we
need to reopen dnsop-serverid to address Paul's point.
</hat>
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
