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

From: Donald Eastlake <[email-masked]>
Date: Sun, 1 Jul 2012 19:27:46 -0400

On Wed, Jun 13, 2012 at 12:00 PM, Michael Sheldon <[email-masked]> wrote:
> In section 3.1:
> "There are currently five QTYPEs
>    assigned: * (ALL), MAILA, MAILB, AXFR, and IXFR."
>
> I would consider changing "* (ALL)" to "* (ALL/ANY)"
>
> While officially type 255 is * ALL, just about every implementation I've
> ever seen refers to it as ANY.

If no one objects, I wouldn't mind making the above change.

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

> Michael Sheldon
> Dev-DNS Services
> GoDaddy.com
>
>> -------- Original Message --------
>> Subject: [dnsext] WGLC: RFC6195bis IANA guidance
>> From: Olafur Gudmundsson <[email-masked]>
>> Date: Mon, June 11, 2012 10:43 am
>> To: "<[email-masked]>" <[email-masked]>
>>
>>
>> Dear colleagues
>>
>> This message starts a 2 week WGLC for RFC6195bis ending at midnight UTZ
>> June 28'th 2012.
>> http://tools.ietf.org/html/draft-ietf-dnsext-rfc6195bis-02
>>
>> This document addresses known flaws in the RFC6195 (see appendix A).
>>
>> Please review the document and post a note that you have reviewed the
>> document we need a minimum of 5 reviewers.
>>
>>      Olafur & Andrew
>> _______________________________________________
>> dnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsext
>
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 2 Jul 2012 10:22:14 -0400

[cc'ed to DNSEXT with permission]

Hi Mark,

Thanks for the comments. Stuff in curly braces ("{ }") is stuff I've added.

On Thu, Jun 28, 2012 at 11:04 PM, Mark Andrews <[email-masked]> wrote:
>
>   {existing draft:}
>    The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
>    only in queries or only in responses, depending on the bit. However,
>    some DNS implementations copy the query header as the initial value
>    of the response header without clearing bits. Thus, any attempt to
>    use a "query" bit with a different meaning in a response or to define
>    a query meaning for a "response" bit is dangerous, given existing
>    implementation. Such meanings may only be assigned by a Standards
>    Action.
>
>   {proposed:}
>    The AA, TC, RD, RA, AD[1], and CD bits are each theoretically meaningful
>    only in queries or only in responses, depending on the bit.  Only
>    RD and CD are expected to be copied from the query to the response
>    however some DNS implementations copy all the query header as the
>    initial value of the response header.  Thus, any attempt to
>    use a "query" bit with a different meaning in a response or to define
>    a query meaning for a "response" bit is dangerous, given existing
>    implementation. Such meanings may only be assigned by a Standards
>    Action.
>
>    [1] AD is expected to have seperate but related meanings in both the
>    query and response.

OK. I don't have a problem with the proposed text except that I'd like
to know where the expectation that AD has a meaning in queries comes
from...

>    2.2 OpCode Assignment
>
>    Status is reserved in RFC 1035 but not behaviour is defined.

OK. I can add "Although the Status OpCode is reserved in [RFC1035],
its behavior has not been specified."

>    2.3 RCODE Assignment
>
>         NOTAUTH is also overloaded and you need to look at the TSIG
>         result code to work out which.   If the TSIG result code
>         is zero or does not exist then it is not authoritative.
>
>         "Not authoritative"     [RFC 2136]
>         "Not authorised"        [RFC 2845]

OK. I can change the table entry to point to a note right after the
RCODE table saying that.

>    RRTYPE assignments need to say something about the rdata format
>    no longer being subject to change.  Its not for reserving a code
>    point as it will be coded into implementations.

I'm not quite certain what you mean above. That the RDATA format
approved as part of the RRTYPE assignment process can never be changed
later? Seems reasonable that it can't be changed unilaterally. But I
don't see why you shouldn't be able to change it by going through the
process again. Maybe there is some field or value or flag or something
that is just wrong or can't possibly work or whatever that wasn't
spotted when the application was initially processed. Or maybe even
for problems not that bad. Of course, you could always get another
RRTYPE but that has problems as well, with having to query both, etc.
There are various engineering trade offs so I don't think a flat
prohibition on any changes, if that is what you are saying, is
reasonable. Question B.1 on the RRTYPE Application temple already asks
if it is a new assignment or a modification of a previously assigned
RRTYPE.

Thanks,
Donald

> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Mon, 2 Jul 2012 15:01:23 +0000

> to know where the expectation that AD has a meaning in queries comes

It's in dnssec-bis-updates, and implemented in BIND at least a couple of years ago (as far as I can remember).

Ray

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 2 Jul 2012 11:08:46 -0400

OK, I'll add appropriate text and a reference to that RFC-to-be.

Thanks,
Donald

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Jul 2012 00:13:31 +1000

In message <[email-masked]>, Donald Ea
> >    point as it will be coded into implementations.

DANE thought that they had a code point that they could change the
internal structure about at will by going through the allocation
process.  They needed to be disavowed of this notion.  This should
not happen again.

> process again.

Because once you have code in the field that knows the internal
structure of a RR changing that structure breaks those implementations
that have implemented the RR. 

> Maybe there is some field or value or flag or something

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Jul 2012 07:45:50 -0700

> process.  They needed to be disavowed of this notion.  This should

Mark's sneering is one way to look at it. Another is that, with an RRtype in a mature draft that labelled as TBD, implementers will just pick one and then eventually squat on it, screwing up both the registry and implementations.

Standards-track protocols can be changed all the way through IESG review. Those changes could in fact change the internal structure of the data covered in an RRtype. This leaves exactly two choices:

- Force Internet-Drafts to keep their RRtype as TBD all the way until the IESG passes the Internet-Draft to the RFC Editor

- Allow WGs and document authors to request RRtype assignment earlier in the process and know that there might be a change based on technical review of the document

Pick one.

--Paul Hoffman

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 3 Jul 2012 08:05:36 -0700

> that have implemented the RR. 

So by this logic, why not just advise every future RTYPE requests include, as the first byte, a version number field, allowing all future RTYPE requests to enable updates without needing to register a new RTYPE?

And DANE can get this already:  Any changes to the certificate associate data should have a new usage number, and usage number 255 means that the first octet of the otherwise opaque certificate association data is the extended usage type.

Voila, problem solved.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 3 Jul 2012 11:31:51 -0400

Hi,

> - Force Internet-Drafts to keep their RRtype as TBD all the way until the IESG passes the Internet-Draft to the RFC Editor

But then the IESG can pull a draft back for the RFC Editor queue and
change it. Or, after it issues as an RFC, they can cause it to be
obsoleted by a revised RFC. Barring another Kobe revolution or the
like, the locus of power in the IETF is the IESG. Anyone who believes
some IANA Considerations in an RFC for an IETF parameter are more
powerful than the IESG is a fooling themselves. However,
notwithstanding that, the IANA Considerations should be something
reasonable that has WG consensus.

> - Allow WGs and document authors to request RRtype assignment earlier in the process and know that there might be a change based on technical review of the document

To avoid squatting and the like and consistent with the idea of making
it generally easier to get an RRTYPE code point, I think this is the
way to go.

There is already provision in the application template to indicate
whether you are submitted for a new RRTYPE or the modification of an
existing RRTYPE. I think about the best we can do is to add some
language like:

"An RRTYPE Allocation Template, indicating that it is for the
modification of an RRTYPE, MUST be submitted when any material change
is made to an existing RRTYPE specification. This includes any changes
that occur in the processing of an internet-draft after initial RRTYPE
allocation and before RFC publication."

Thanks,
Donald

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Jul 2012 18:59:16 +1000

In message <[email-masked]>, Paul Hoffman writes:
> >=20
> Mark's sneering is one way to look at it.

For a expert to be able to evaluate a RR type definition it needs
to be stable.  No expert can say a RR type definintion can be said
to be safe / good if it is still subject to change.

> Another is that, with an =
> RRtype in a mature draft that labelled as TBD, implementers will just =
> pick one and then eventually squat on it, screwing up both the registry =
> and implementations.

Then pick a private type for testing.  Been there, done that.  It is
not impossible to do.

> Standards-track protocols can be changed all the way through IESG =
> review. Those changes could in fact change the internal structure of the =
> data covered in an RRtype. This leaves exactly two choices:

And that ends up with a total review of the impact of the new
structure has on the old implementations.  This level of review
doesn't happen between I-D revisions.

> - Force Internet-Drafts to keep their RRtype as TBD all the way until =
> the IESG passes the Internet-Draft to the RFC Editor
> 
> - Allow WGs and document authors to request RRtype assignment earlier in =
> the process and know that there might be a change based on technical =
> review of the document
> 
> Pick one.
> 
> --Paul Hoffman=

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Jul 2012 07:33:10 -0700

On Jul 6, 2012, at 1:59 AM, Mark Andrews wrote:

> to be stable.  

The expert reviews a stable request, yes.

> No expert can say a RR type definintion can be said

Then don't ask the expert to say that. Isn't this obvious?

>> the process and know that there might be a change based on technical =

Humorously, you didn't reply to this.

--Paul Hoffman