[dnsext] WGLC: RFC6195bis IANA guidance

[Donald Eastlake <[e-mail]>]

[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 <[e-mail]> 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
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext