RE: Comments: draft-ietf-dnsext-keyrr-key-signing-flag-11.txt

["Michelle S. Cotton" <cotton@icann.org>]

Thanks for the explanation.

so, will the document get a revision to make clear
what the IANA needs to do and where?

Michelle


-----Original Message-----
From: Rob Austein [mailto:sra@hactrn.net]
Sent: Thursday, October 30, 2003 9:31 AM
To: Michelle S. Cotton
Cc: iesg@ietf.org
Subject: Re: Comments: draft-ietf-dnsext-keyrr-key-signing-flag-11.txt


At Thu, 30 Oct 2003 08:39:31 -0800, Michelle S. Cotton wrote:
> 
> Thomas,

I'm not Thomas, but I'll answer anyway.  If Thomas contradicts me,
believe him, not me.

> 
> The IANA Considerations section for this document says
> the following:
> 
> 6. IANA Considerations
> 
>    IANA considerations:  The flag bits  in the DNSKEY RR are assigned by
>    IETF consensus. This document assigns the 15th bit in the DNSKEY RR
>    as the Secure Entry Point (SEP) bit. [Final text pending
>    clarification of the DNSKEY flag registry]
> 
> Is this document referring to the following registry:
> 
> <http://www.iana.org/assignments/dns-key-rr>

No, it's not.  This is a new bit allocation in the flags field of the
DNSKEY RR type.  I can't find a current registry listed for this, it
may not exist yet (but see below for why the authors may not have
realized this).

> If so, it says that it is closed.

That's the protocol octet of the KEY RR type, and that registry is
indeed closed.  Different issue.

> Also, what does the final sentence mean?
> [Final text pending clarification of the DNSKEY flag registry]

Hint that the authors themselves are a bit confused about who's
supposed to define the missing registry, probably.  Arguably
draft-ietf-dnsext-dnssec-2535typecode-change should have done this,
but I don't see any text about this registry in that doc either.

Quick review of a very confusing situation: we had the KEY RR type,
which came into being along with the original DNSSEC specs.  That RR
type had a ridiculous number of fields, some of which never had IANA
registries created for them, although they probably should have.  Over
the years we've restricted the allowed content of many of those fields
as we killed off various bad ideas in the DNSSEC specs.  Recently we
decided that the KEY RR type was so crippled by old broken code that
we "rolled over" to a new RR type (DNSKEY), which inherited a lot of
stuff (including the entire RR format) from the KEY RR but which is,
technically, a whole new type.  So we have all those whacky fields all
over again, and are just now figuring out which ones never had
registries in the first place, and it's easy to confuse the old
registries with the new registries.

To put it another way, IANA is quite right to be confused here :).