Subject: RE: draft-iab-dns-choices-02.txt comments

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 10 Jun 2005 12:42:25 -0700 (PDT)

On Fri, 10 Jun 2005, Eastlake III Donald-LDE008 wrote:

> Am I missing something?
>
> RFC 2929, as well as allocating RR Type numbers from 65280 - 65534 (0xFF00 - 0xFFFE) for private use also allocates almost half of all RR Type numbers, those from 32768 - 65280 (0x8000 - 0xFEFF), for use based on "Specification Required". That is, as defined in RFC 2434:
>
>      Specification Required - Values and their meaning must be
>           documented in an RFC or other permanent and readily available
>           reference, in sufficient detail so that interoperability
>           between independent implementations is possible.
>
> Isn't getting an RR Type based on just publicly documneting its use 
> liberal enough?

I've not seen any RR types allocated except though IETF consensus and RFC.

Perhaps if RFC2929 is already liberal enough then clarification from
this WG would be good or establishing a better documented procedure for 
requesting new RR (documented in separate document released preferably
as INFORMATIONAL RFC or BCP) would be good enough and allow those who
are proposing new uses of DNS to get RR type numbers quickly though
IANA that they could test their proposals and experiment with real-life
deployment.

-- 
William Leibzon
Elan Networks
[email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: John Levine <[email-masked]>
Date: 10 Jun 2005 23:08:03 -0000

> Isn't getting an RR Type based on just publicly documneting its use

You're right, I misremembered 2929.  My bad.

This still leaves us with the question of why we see so few new RR types
in practice.  I guess it's a combination of the difficulty of getting
them into zone files and the dismayingly large number of junkware clients
that can't query them.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Jun 2005 08:46:52 -0400

>>  Isn't getting an RR Type based on just publicly documneting its 
>>use liberal enough?
>

Prior to RFC 2929, one example, to pick a flawed one, was the OPT RR. 
The OPT RR process was flawed in that it received the wrong number. 
(It was thought that it would have a number with the meta-types, 
instead it got #41.)  The problem was that no one informed IANA that 
the OPT record deserved a special type number.

This mishap was one reason for the production of RFC 2929.

As far as "isn't ... just publicly documenting" in an RFC or other 
permanent reference "liberal enough?"  I would say no.

These are the type codes defined by documents post RFC 2929:

APL             42 APL                          [RFC3123]
DS              43 Delegation Signer            [RFC3658]
SSHFP           44 SSH Key Fingerprint          [RFC-ietf-secsh-dns-05.txt]
IPSECKEY        45 IPSECKEY                     [RFC-ietf-ipseckey-rr-11.txt]
RRSIG           46 RRSIG                        [RFC3755]
NSEC            47 NSEC                         [RFC3755]
DNSKEY          48 DNSKEY                       [RFC3755]

Note that two of them are in pending RFC's, which kind of violates 
the instructions in RFC 2929.  Some may say that these are "special 
cases" and the rules ought to be bent for these instances.  I'd 
agree, but when we start with unwritten bending of the rules, it's a 
sign we've build a bad bureaucracy.

Note that all of the types listed also originated within the DNSEXT 
WG.  The SSH and IPSEK key work did come from other WG's but that was 
not until the work was expelled in December 2001. (RFC 2929 is dated 
September 2000.)

Since RFC 2929, no application-driven RR type code number has been 
assigned by IANA.  I would say that this is a sign that the policy is 
not liberal enough.

PS - For an added bit of irony, the numbers preceding that list are 41 (the
incorrectly assigned OPT RR) and 40, the SINK record.  There is no 
permanently archived document describing the SINK record.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 14 Jun 2005 12:22:34 -0400 (EDT)

> I've not seen any RR types allocated except though IETF consensus and RFC.

IANA has repeatedly told me that they've never gotten requests for
'specification required' type codes.  Yesterday Anders Rundgren
claimed that IANA had turned him down for lack of an RFC, and I'm be
curious to know if he had any other permanent reference.  (Per the
Specification Required definition below, an i-d shouldn't be
sufficient, because it's not permanent.)

Unfortunately, IANA has refused to give an unequivocal answer to the
question of what sort of document might be sufficient to meet the
threshhold of: "Values and their meaning must be documented in an RFC
or other permanent and readily available reference, in sufficient
detail so that interoperability between independent implementations is
possible."  Perhaps DNSEXT could tell them what that answer should be?

I've discussed this before on this list, too:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00243.html

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 14 Jun 2005 12:23:23 -0400 (EDT)

On Mon, 13 Jun 2005, Edward Lewis wrote:

> the instructions in RFC 2929.

I disagree.  IANA has to do the assignment at some point in time, and,
per the RFC Editor's processes, that's during the editing process[1].
That process has happened for SSHFP -- SSHFP is just waiting for a
normative reference to be cleared up.

And IPSECKEY (RFC4025) was published in February -- IANA just hasn't
updated their registry (despite two notes on this list urging them
to).  Perhaps the IANA's processes need to include reviewing all
published RFCs to remove these temporary citations in the registries.

-- Sam

[1] ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-editor-process.gif

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Jun 2005 13:55:48 -0400

At 12:23 -0400 6/14/05, Samuel Weiler wrote:

>... IANA has to do the assignment at some point in time, and,

By the time an effort is in the "editing process" it is already too 
late to assign a type code.  If I had my druthers, I would have at 
least mocked up the application, tested it in a workshop environment 
before trotting out a formal document.

Whatever happened to running code and rough consensus?  Remember the 
days when code ruled?  We are letting regulation get ahead of 
technology.

>published RFCs to remove these temporary citations in the registries.

Ok, but which came first - the RFC number or the type code number?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 14 Jun 2005 14:38:45 -0400 (EDT)

> before trotting out a formal document.

I'm confused.  First I heard what sounded like a complaint that these
two type codes were issued based only on I-D's instead of RFCs, now
the text above.  Perhaps they're not incongruous after all -- I
suppose one could want the process to change while still complaining
that the current process isn't being followed closely enough.

In any case, I agree with your point that we need the type codes
earlier.  It's particularly galling that it might be easier to get a
type code for something that's happening completely outside IETF
processes than something inside (since an i-d isn't a permanent
reference).  Then, too, no one has tested that premise.

> Ok, but which came first - the RFC number or the type code number?

Per [1], the type code.  As it happened, that was the actual order,
too.

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Jun 2005 16:15:48 -0400

>that the current process isn't being followed closely enough.

Both appear to be problems.

If the rules say "RFC or other permanent record" then any 
pre-assignment is out of order.  It's not healthy if "but that's the 
way it works."

If the rules are making "doing the right thing" hard or worse - 
encouraging short cutting the proces, then the rules ought to be 
changed.

---

From: "IANA" <[email-masked]>
Date: Tue, 14 Jun 2005 08:25:15 -0700

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. Please fix your 
   subscription addresses. ]

Regarding the second paragraph in Sam's message:

IANA has a process to update the reference in the registry after the
RFC-Editor notifies the IANA what the RFC number is and the date of
publication.  We are a bit behind in updating these in efforts to get
documents awaiting IANA actions for publication to the RFC-Editor, however
we have already begun updating references where the document has been
published as an RFC.

I'll go ahead and take care of the (RFC4025) reference update today.

Thanks,

Michelle

-----Original Message-----
From: Samuel Weiler [mailto:[email-masked]] 
Sent: Tuesday, June 14, 2005 9:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: New type code assignments (was: RE: draft-iab-dns-choices-02.txt
comments)

On Mon, 13 Jun 2005, Edward Lewis wrote:

> Note that two of them are in pending RFC's, which kind of violates the 
> instructions in RFC 2929.

I disagree.  IANA has to do the assignment at some point in time, and, per
the RFC Editor's processes, that's during the editing process[1].
That process has happened for SSHFP -- SSHFP is just waiting for a normative
reference to be cleared up.

And IPSECKEY (RFC4025) was published in February -- IANA just hasn't updated
their registry (despite two notes on this list urging them to).  Perhaps the
IANA's processes need to include reviewing all published RFCs to remove
these temporary citations in the registries.

-- Sam