Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance

From: Alfred Hönes <[email-masked]>
Date: Thu, 14 Jun 2012 15:04:42 +0200 (MESZ)

I have once more read the most recent version of the rfc6195bis
draft and can approve that most of my previous review comments
for RFC 6195 and this draft have been acted upon satisfactorily.
My special thanks to Donald for his patience with my persistent
urges to improve the clarity in the visual presentation of the
tables; I think the pleasant result is worth the efforts.

Michael Sheldon's remark about "ALL" vs. "ANY" has lead me to
once more check the updated registry tables, and I got stuck
at two details, which lead to new considerations:

(1)  Section 3.1.4 and/or Appendix B

Maybe the IESG will call for a citation for closing the AFSDB
sub-registry.  RFC 5864 is the proper reference (and its author has
approved the formal closing after checking with the AFS community).

(2)  Section 3.2

In the RCODE registry (Section 2.3), there is an apparent
overloading of RCODE=16:
   BADVERS (RFC 2671 / RFC 2671bis) vs. BADSIG (RFC 2845).

Looking back into RFC 2845, it seems that the clerical error
has happened at IANA when acting upon the assignments in that RFC.
The second paragraph of Section 7 of RFC 2845 (on top of page 13)
clearly states:

!  IANA is expected to create and maintain a registry of "TSIG Error
!  values" to be used for "Error" values as defined in section 2.3.
!  Initial values should be those defined in section 1.7.  New TSIG
!  error codes for the TSIG error field are assigned using the IETF
!  Consensus policy defined in RFC 2434.

Note that the TSIG Error field is a component of TSIG RDATA distinct
from the RCODE field in the DNS message header and its extension in
OPT RRs.  An According to RFC 2845 (which seems to be mostly unaware
of EDNS, besides references to binary labels), there is an intentional
semantical overlap for Error values 0..15, which are specified as being
identical with the non-extended RCODES (0..15) in sect. 1.7 of RFC 2845;
the "new" TSIG Error values 16..18 are to be signaled together with
RCODE = NotAuth(9) (originally specified in RFC 2136).
The idea there obviously was to make TSIG independent of the OPT RR,
i.e. to allow TSIG without EDNS, but to this end RFC 2845 likely better
had accomodated the extended RCODE BADVERS(16) assigned by RFC 2671 and
chosen Error values 17..19 for TSIG purposes.

However, IANA obviously has registered the actual new values 16..18
in the RCODE registry and _not_ established a TSIG Error code registry.
Mistakes happen, and it also may be wise to have RCODE values 17 and 18
"reserved" so that additional overloading cannot arise in the future.

But IMO it would be worth adding "[*]" to the three RCODE registry
entries based on RFC 2845: BADSIG, BADKEY, and BADTIME, e.g.:

        16    BADSIG    TSIG Signature Failure [*]         [RFC2845]
        17    BADKEY    Key not recognized [*]             [RFC2845]
        18    BADTIME   Signature out of time window [*]   [RFC2845]

... and to add a footnote to the rigistry that says (e.g.):

   [*] These values are only to be used in the Error field of TSIG RRs;
       they cannot appear in the (extended) RCODE field of OPT RRs.

Also, for added precision and consistency with RFC 2845 and RFC 2930,
the last clause in the first paragraph of Section 2.3 should perhaps
be adjusted as follows:

OLD:
   and the TSIG and TKEY RRs have a 16-bit RCODE field.
                                           ^^^^^
NEW:
   and the TSIG and TKEY RRs have a 16-bit Error field.
                                           ^^^^^

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 28 Jun 2012 22:16:10 -0400

Hi Alfred,

On Thu, Jun 14, 2012 at 9:04 AM, Alfred HÎnes <[email-masked]> wrote:
> ...

Adding such a reference seems reasonable. I suggest that, just before
the last sentence of the first paragraph in Section 3.1.4, adding "Use
of the AFSDB RR to locate AFS cell database servers was deprecated by
[RFC5864]." and noting this addition in Appendix B.

>   BADVERS (RFC 2671 / RFC 2671bis) vs. BADSIG (RFC 2845).

Yes. But it seems unlikely to cause a problem as one is only used in
OPT and one s only used in TSIG.

> chosen Error values 17..19 for TSIG purposes.

Of course, your quote from the IANA Considerations of RFC 2845 (TSG)
is correct; however, I do not think the evidence is all on your side.
In particular, earlier in RFC 2845, the error field is described as an
"expanded RCODE".  This is essentially the same term that RFC 2671
(OPT) uses ("an extended RCODE") and the same term that RFC 2930
(TKEY) uses ("The error code field is an extended RCODE.").

>   and the TSIG and TKEY RRs have a 16-bit Error field.

I believe that the more different DNS error registries there are, the
more confusion and the more future errors in assignment will occur.
Except for the values of the 4-bit DNS header un-extended RCODE, for
which precious few free values exist, there is an abundance of values
available, so there is no scarcity reason for separate registries with
potentially overlapping values.  It is also the case that a single
unified number space for DNS errors has been presented for years in
RFC 6195, RFC 5395, and RFC 2929 for use in the unextended DNS header,
the OPT extended DNS header, the TSIG RR error field, and the TKEY
error field. In all these years, no one has had a problem with there
being a single, unified DNS error number space. So, to the extent that
there is any consensus among these document I believe it is for the
simpler model of a single number space.

To the extent that there s any ambiguity here, I would prefer to
resolve it by adding text to Section 2.3 of the rfc6195bis draft like
the following: "To the extent that any prior RFCs imply any sort of
different error number space for the OPT, TSIG, or TKEY RRs, they are
superseded by this unified DNS error number space. With the existing
exception of error number 16, the same error number MUST NOT be
assigned for different errors even if they would occur in different RR
types."

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 29 Jun 2012 14:24:07 -0400

> assigned for different errors even if they would occur in different RR

<RFC2845-editor hat>
As one of perpetrators of this confusion and historian of what happened.
The IANA processing of RFC2671 was a unmitigated disaster,
   OPT got allocated 41  which should have been 25x code
All the other assignments from the document did not take place (more 
below)

TSIG RFC2845 editors assumed single RCODE space but because of IANA 
mistake in processing 2671 we overlooked the double RCODE. The 
inconsistent wording reflects that different people edited different 
versions and the processes of document review in the WG were not up to 
the same standards as today.

<DNSEXT chair hat>
I think Donald's solution is the most appropriate one,
Alfred thanks for brining this up and enabling us to once for all close 
down this confusion.

This happened before I became a co-chair of DNSIND but within 10 minutes 
of the RFC2671 announcement I raised the issue of OPT allocation code, 
but missed the omissions in IANA processing.

If I had noticed that as well I think we would have had a good case to 
reissue the RFC as RFC2671.1.
To be fair to IANA the IANA actions in RFC2671 were badly stated and 
well hidden in the text thus I do not blame IANA solely for this as none 
of the Editors, Chairs, AD's and RFC-editor did notice that the 
processing did not take place. This was one of the triggers in putting 
more formal process in allocations, IANA considerations sections, 
external reviews for IANA actions, ID proto writeup etc.
	
	Olafur

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 29 Jun 2012 21:21:48 +0200 (MESZ)

Donald,
thanks for your toughts and your response.
And also thanks to Olafur for his enlightening historical notes!
(I follow up to Donald's message below, but I include referals
to Olafur's statement.)

At Jun 2R9, 2012, Donald Eastlake 3rd wrote:

>  Hi Alfred,
>
> On Thu, Jun 14, 2012 at 9:04 AM, <[email-masked]> wrote:
>> ...
>>

Agreed.

> OPT and one s only used in TSIG.

You spell it out so short and precisely that it would be a pity
to lose that clarification.  See my additional suggestion below.

> (TKEY) uses ("The error code field is an extended RCODE.").

Nevertheless, the field in the TSIG RDATA is denoted "Error",
and it might be worth staying literally with that, to avoid
confusion.

>> ... and to add a footnote to the registry that says (e.g.):
>>

So, in a sequel to what I said above, maybe it would be worth
to actually have this footnote in the registry.  Explaining in
a second footnote (and thereby turning these into numbered notes)
that BADVERS is to appear in the OPT RR only should be worth
considering.

Maintaining this suggestion is based on the assumption that the
full leading text of Section 2.3 (as amended by the clause given
below) will not appear in the IANA registry file, and that the
registry should be somehow self-contained for the benefit of
unsuspecting readers.
However, if IANA will actually copy the entire prose text as a NOTE
to the RCODE registry, admittedly these footnotes are not needed.

>>   and the TSIG and TKEY RRs have a 16-bit Error field.

So given what is said above and what Olafur has confirmed today,
I now slightly modify my suggestion to perhaps better say:

NEW:
   and the TSIG and TKEY RRs have a 16-bit RCODE field designated in
   the respective RFCs as the "Error" field.

(You may wordsmith if you like.)

> assigned for different errors even if they would occur in different RR

Yep.  In the light of Olafur's confirmation, that's a good addition.

I guess that consequentially the draft should be labelled as Updating
RFCs 2845 and 2930 as well, and mention this in the Abstract (due to
current IESG preferences) and in Appendix B as well.
RFC 2930 is included here because in Section 2.6 of that RFC, the
listing of RCODE values 16..18 for the TSIG Error field is misleading
and this is clarified by the above text addition.

Best regards,
  Alfred.