Subject: Re: Last Call: <draft-ietf-dnsext-xnamercode-00.txt> (xNAME RCODE and Status Bits Clarification) to Proposed Standard

From: SM <[email-masked]>
Date: Mon, 23 Jan 2012 11:04:17 -0800

At 10:23 23-01-2012, The IESG wrote:
>The IESG has received a request from the DNS Extensions WG (dnsext) to
>consider the following document:
>- 'xNAME RCODE and Status Bits Clarification'
>   <draft-ietf-dnsext-xnamercode-00.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2012-02-06. Exceptionally, comments may be

 From the Introduction Section:

   "This document clarifies, in the case of such redirected queries,
    how the RCODE and status bits correspond to the initial query
    cycle (where the (first) xNAME was detected) and subsequent or
    final query cycles."

 From Section 2.1:

   "[RFC1035] states that the AA bit is to be set based on whether the
    server providing the answer with the first owner name in the answer
    section is authoritative.  This specification of the AA bit has not
    been changed.  This specification of the AA bit has not been changed."

And Section 2.2:

   "[RFC4035] unambiguously states that the AD bit is to be set in a DNS
    response header only if the DNSSEC enabled server believes all RRs in
    the answer and authority sections of that response to be authentic.
    This specification of the AD bit has not been changed."

It is not clear to me what is being clarified about the status bits.

In Section 3:

     "The RCODE in the ultimate DNS response
      MUST BE set based on the final query cycle leading to that
      response."

Shouldn't the "BE" be lowercased?

The status of the memo suggests sending comments to 
[email-masked].  Is that IETF mailing list still being 
used by DNSEXT?

Regards,
-sm

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 24 Jan 2012 22:46:45 -0500

Hi,

>   been changed.  This specification of the AA bit has not been changed."

Actually, the last sentence above is not duplicated in the draft.

> It is not clear to me what is being clarified about the status bits.

This draft brings together the aspects of the AA, AD, and RCODE bits
related to xNAME RR query cycles and expresses them clearly and
succinctly. As such it has been approved by the DNSEXT WG. I do not
believe that text has to make a change to be a clarification.

> Shouldn't the "BE" be lowercased?

Yes, thanks for pointing this out. "BE" should probably be lowercase.

> [email-masked].  Is that IETF mailing list still being used by
> DNSEXT?

That was the mailing list at the time of the -00 personal draft
version. Sorry I missed updating the mailing list reference somewhere
along the way.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Jan 2012 22:59:44 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
> Sent: Tuesday, January 24, 2012 7:47 PM
> To: SM
> Cc: [email-masked]
> Subject: Re: Last Call: <draft-ietf-dnsext-xnamercode-00.txt> (xNAME
> RCODE and Status Bits Clarification) to Proposed Standard
> 

I made the same point in my review of this for AppsDir, and it got a similar response.

In short, I also find the current presentation a bit awkward.  To fix it, I believe Section 2 should be dropped, and the references for the definitions of AA and AD should be moved to the current Section 4.  No details are lost, the document becomes simpler, and simpler is better.

I appreciate any working group's time spent developing and reviewing something, but the fact that DNSEXT approved it this way doesn't mean it can't be improved.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 25 Jan 2012 18:00:32 -0500

> In short, I also find the current presentation a bit awkward.  To fix it, I believe Section 2 should be dropped, and the references for the definitions of AA and AD should be moved to the current S…

Rather than moving to Section 4, could we rename section 2, adding
some explanatory text as to why it's _not_ changing the interpretation
of those bits, and then make the statements that are already there?

The reason it's structured this way is because actual fielded
implementations had mistakes around these things.  We wanted to make
clear that the spec isn't wrong.  (In the DNS, it's not always good to
trust the RFCs.  It turns out that quite often, despite what one might
like, you get uninteroperable behaviour when you follow the RFC, and
interoperable behaviour when you look at the implementations.  Yes,
this is a Bad Thing.  No, I don't know what to do about it.)

I do understand the bafflement this section is causing as it stands,
however, because it seems not to be doing anything to these bits at
all.  That's actually the clarification, however, and so I want to
make it explicit.

Best,

Andrew (as document shepherd)

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 15:09:17 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Wednesday, January 25, 2012 3:01 PM
> To: [email-masked]
> Rather than moving to Section 4, could we rename section 2, adding some
> explanatory text as to why it's _not_ changing the interpretation of
> those bits, and then make the statements that are already there?
> [...]
> all.  That's actually the clarification, however, and so I want to make
> it explicit.

That would be far better than what's there now.  Without the context you just gave, it does indeed seem rather awkward and a prime candidate for simplification.

Thanks,
-MSK