Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protoco

On 28 May 2014, at 21:43, David Conrad <drc(_at_)virtualized(_dot_)org> wrote:

> > I would like every A-M.root-servers.net have an A and AAAA record.
> [...]
> >  The root name service:
> >     ...
> >     MUST support IPv4[RFC0791] and IPv6[RFC2460] transport of DNS
> >     queries and responses.
> And if they don't?
>
> Just for clarity, the root server operators are under no obligation to do 
> anything. The whole "MUST" bit is actually sort of misplaced since it isn't 
> like people are going to wave a RFC (BCP or otherwise) at the root operators 
> and change will magically happen. Root server operators will do what they 
> want according to their own requirements/business drivers. In an ideal world, 
> what the community wants and what the root server operators' 
> requirements/business drivers are correspond, but people shouldn't be under 
> any illusion that an RFC will make this happen.
But that is not the problem of the IETF. If the IETF come to conclusion that 
root server services "must" support IPv4 and IPv6, so be it. It should be in 
the RFC. It is then up to whoever is policing the services (the root server 
operator themselves, their owner, the regulator in the jurisdiction they are 
within or whatever) to do the policing.

Policing will not happen without a spec that services can be compared against.

And lack of policing (which seems to be what you talk about) is I think a 
separate issue.

I think IETF should do a darn good job here. As IETF can do. And then other 
open issues have to be taken care of elsewhere.

Sure, it might be that some of the requirements are hard to enforce, and that 
IETF will be frustrated, but that is not worse than support for new RR Types, 
IPv6, DNSSEC and about a thousand other things IETF think is very important.

IETF should lead. Not follow.

I think personally a lot of the discussions for example in ICANN related to the 
new gTLDs would have been easier if IETF had had a clear lead on various issues 
related to the root zone. Like charset, strings etc that "are ok". Now a lot of 
that discussion has happened elsewhere, and even if of course some of that is 
more policy/business (and because of that fit in ICANN environment) it would 
have been easier if that discussion had a stable solid technical ground to 
stand on.

   Patrik

signature.asc
Description: Message signed with OpenPGP using GPGMail