Re: [dnsext] WGLC: RFC6195bis IANA guidance

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Donald Ea
stlake writes:
> [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.

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.

> 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.

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
> 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]
-- 
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