Hi,
While I was not waiting for WG last call, it is a while ago since I have
read this draft. Positive is that I read it without it leading to a lot
of confusion or outrage.
I have some small comments though.
Negative response:
I and some others have been using the term 'Negative response' to
indicate that the response does not contain any records in the Answer
section. Current definition seems to imply that this is only the case if
the RCODE is NXDOMAIN, NOERROR, SERVFAIL or if there was a timeout
(unreachable). The definition I have been using includes responses with
other RCODEs too, for example FORMERR or REFUSED.
I wonder if this is just me and my bubble or if others also a slightly
different meaning of 'Negative response' as it is defined now. If there
are others, is it worth spending a line or two about this here?
RRsets:
Raised by a discussion I had at the Hackathon, I think it would be
useful to add some clarification about RRSIGs and their role with
respect to RRsets. Perhaps a quote from RFC4035 will do:
An RRset MAY have multiple RRSIG RRs associated with it. Note that
as RRSIG RRs are closely tied to the RRsets whose signatures they
contain, RRSIG RRs, unlike all other DNS RR types, do not form
RRsets. In particular, the TTL values among RRSIG RRs with a common
owner name do not follow the RRset rules described in [RFC2181].
Last, I don't fully understand the meaning of the cryptic comment about
QTYPE=ANY that is under the RRset definition:
(This definition is definitely not the same as "the
response one gets to a query for QTYPE=ANY", which is an
unfortunate misunderstanding.)
Can you explain why this comment is here?
Thanks, best regards,
Matthijs
On 05-03-18 17:14, Paul Hoffman wrote:
Greetings. As you can see, draft-ietf-dnsop-terminology-bis-09.txt is
out. Reading the diff might be a bit difficult because of the
reorganization of some sections that y'all asked for, but I think the
result is worth the extra effort.
We're still not done yet. I took a hiatus from finishing the list of
definitions that people wanted more scrutiny on, but will start that
again soon. I hope we'll be done with that list by mid-April and then be
ready for WG last call.
As a side note, some of the changes in this version came from people
reading the document fresh. I encourage folks who were maybe waiting for
WG Last Call to do a first deep reading of the document to instead do so
now. The work that everyone is doing on this document will go a long way
to making the final RFC more valuable for lots of folks entering the field.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
