Your English literacy is fine. I believe sentences which are logically
connected into one super-sentence have been accidentally severed into one
sentence and one non-sentence.
That super-sentence would be:
"In the case where a zone that contains HINFO RRSets is served from an
authority server that does not provide conventional ANY responses, it is
possible that the HINFO RRSet in an ANY response, once cached by the initiator,
might suppress subsequent queries from the same initiator with QTYPE=HINFO."
This is then followed by another, largely redundant sentence:
"The use of HINFO in this proposal would hence have effectively mask [sic] the
HINFO RRSet present in the zone."
I suggest a rewording that collapses the whole paragraph into a single, tighter
sentence:
"The HINFO RRset provided as an ANY response, as per this specification, when
cached by the initiator, may suppress subsequent QTYPE=HINFO queries for the
same QNAME, thus effectively masking, from that initiator, an explicit HINFO
RRset present in the zone."
- Kevin
-----Original Message-----
From: DNSOP [mailto:[email protected]] On Behalf Of ????
Sent: Friday, December 02, 2016 2:55 PM
To: tjw ietf
Cc: dnsop
Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any
At Fri, 25 Nov 2016 19:50:48 -0500,
tjw ietf <[email protected]> wrote:
> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out
> with your reasons.
>
> *Also*, if you have any opinion on changing the document named from
> 'refuse-any' to 'minimal-any', please speak out.
I've read the 03 version of the document. I do *not* think this is ready for
publication since I still believe we should not abuse HINFO for this purpose as
I argued a year ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
(But other than that I think the document is quite well written).
As for renaming the file, I don't have a strong opinion, but we expect a bigger
issue like HINFO can lead to more revisions, it would be good to rename it at
this opportunity in order to avoid confusion for future readers.
Some specific comments on the text:
- Section 3
1. A DNS responder can choose to select one or subset of RRSets at
the QNAME.
'one or subset of RRSets' sounds a bit awkward to me, partly because
'a subset of RRSets' should include 'one of RRSets' and can thus be
redundant, and partly because 'subset of RRSets" might sound related
to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
So I'd suggest changing this one of the following:
- "one or a few of RRSets (but not all of them)"
- "one or a few of RRSets"
- "a subset of RRSets"
I personally prefer the first most although it may be too verbose.
- Section 4
A DNS responder which receives an ANY query MAY decline to provide a
conventional response, or MAY instead send a response with a single
RRSet in the answer section.
"a single RRSet" doesn't seem to be fully consistent of "one or
subset of RRSets" stated in the preceding section (see the previous
bullet).
- Section 4
If the DNS query includes DO=1 and the QNAME corresponds to a zone
that is known by the responder to be signed, a valid RRSIG for the
RRSets in the answer (or authority if answer is empty) section MUST
be returned.
Does this also apply to a synthesized HINFO (if so, by dynamically
signing it?)?
- Section 6
In the case where a zone that contains HINFO RRSets is served from an
authority server that does not provide conventional ANY responses.
This may be just because of my English literacy, but on my first
read it was quite confusing to me; I first thought the second 'that'
was a relative pronoun, which would make this text an incomplete
sentence. If there was a comma after 'server' that would be more
readable for me.
- Section 7: a minor typo, s/implimentations/implementations/
not return all RRSIGS. In the wild there are implimentations that
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
