Hi, Strong objections to this answer, or can we call it done?
ISTM that the avoidance of ambiguity for implementers is the key thing here, so I’m especially interested in hearing from anyone who’s not sure how to code this as written. Thanks all for a good discussion, and the suggestion that defining QNAME might be suitable for draft-ietf-dnsop-terminology-bis. best, Suzanne > On Sep 23, 2016, at 4:22 AM, Stephane Bortzmeyer <[email protected]> wrote: > > On Tue, Sep 20, 2016 at 06:13:50PM +0200, > Stephane Bortzmeyer <[email protected]> wrote > a message of 68 lines which said: > >> This issue was spotted by Peter van Dijk. It is about >> draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The >> problem is the definition of "QNAME" when there is a CNAME chain. > > OK, after reading the discussion, my opinion, as an author (but I'll > of course defer the decision to the working group, the WG chairs, the > RFC editor and the flying spaghetti monster): > > The re-definition of QNAME by RFC 2308 is awkward and does not match > the general usage, or the previous definitions. Therefore, I prefer to > keep the "common sense" usage "QNAME is the owner name of the record > in the Question Section". Which means that, in my example, the QNAME > is "www.afnic.fr" and the current text of > draft-ietf-dnsop-nxdomain-cut-05 is correct. > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
