aaaa rrs, icann, and rssac

[Rob Austein <sra@hactrn.net>]

summary of a discussion on the rssac list that's been sitting idle for
the last few days.  no current action needed by iab/iesg/ietf.

the .jp zone mentioned to vixie that they're unhappy about the fact
that they have asked "iana" (icann) to include aaaa rrs for the .jp
zone, with no response.  vixie dutifully brought their gripe to icann
via the rssac list.  subsequent discussion bifurcates:

- icann should answer their mail, even if the answer is "no" or "duh?"
  bad icann, no biscuit.

- icann doesn't want to include aaaa rrs in the root zone until they
  have opinions from technical folks on what this will do to the
  operational net.  louis asked vixie personally, vixie said "no, ask
  rssac, not just me", i said "perhaps we could take this discussion
  to ietf dnsop wg for public technical discussion"?  vixie basicly
  agrees but wants his ducks in a row first; other members of rssac
  don't seem to think they need to do anything beyond their own back
  of the envelope calculations.  that's where it sits at the moment.

first issue is not an iab/iesg/ietf problem.

if anybody objects to my recommendation for the second part, please
say so.  as several of us have discussed privately, rssac has its own
transparency issues, so having the technical discussion in a public
place like the dnsop wg seems advisable.

for those for whom it may not be obvious, the critical aspect of the
technical issue is almost certainly the question of what aaaa rrs do
to dns response message sizes.  the dns directorate discussed this
many moons ago, but what notes we took were on the back of soggy beer
coasters (cooper's, i think), so i doubt that any record survived
beyond the (obsolete by the time it was published, sigh) a6 rr
discussion in rfc 3226.