Hi, sorry for the delayed response. At Tue, 25 Jul 2017 16:53:12 -0400, Joe Abley <jab...@hopcount.ca> wrote:
> https://mailarchive.ietf.org/arch/msg/dnsop/zy86pvg139PaKFXo-BO6SPUfh3k > > > I've reviewed the 04 version. I still do not think it's ready to move > > forward as it still abuses HINFO. I understand some other people > > don't care about this point, and some others may even love the idea > > (those who are using it right now). But I've also seen yet some other > > people have the same concern, so it shouldn't be only me. I don't > > think we have a clear consensus on this point yet. > > The draft at present doesn't require an implementer to abuse HINFO; > it provides options to avoid doing so whilst still meeting the > described objectives of the proposal. Since abusing HINFO is not > mandatory, I presume you are objecting to the proposal sanctioning > such shenanigans at all. (If I understand the subtle nuance of this text:-) I think your understanding is correct. > > If I have that right (please correct me if I'm wrong) I don't think > I am the right person to make the call, being just a lowly document > scribe. If this remains a concern for you, I suggest that we defer > that question to our chairs and ask them to gauge consensus. My own Agreed - I think we have to agree to disagree here and I think neither of us can convince the other. It should better be left to the wg decision. > personal views of pragmatism vs. elegance shouldn't enter into it; > this is a working group document. > > To be hopefully a bit more productive, I have a specific counter > > proposal: remove the mandatory text about the use of HINFO, e.g., > > > > - remove this bullet from section 4 > > 2. A DNS responder can return a synthesised HINFO resource record. > > See Section 6 for discussion of the use of HINFO. > > - remove ', in which case...' from Section 4.2 > > If there is no CNAME present at the owner name matching the QNAME, > > the resource record returned in the response MAY instead be > > synthesised, in which case a single HINFO resource record SHOULD be > > returned. > > > > In fact, in terms of externally observable behavior, synthesizing > > HINFO is just one form of "selecting one RRset of the QNAME"; the > > HINFO is added and immediately removed at the time of answering the > > ANY query, so in that sense we don't have to bother to mention it with > > normative keywords. > > This text suggests that my interpretation above is wrong, and what > you are objecting to is just the way that the HINFO approach is > described. I think the specification is more clear if we spell out > the whole synth-HINFO approach in its entirety and don't try to > subsume it into the "return a subset of { RRSets that there } u { > RRSets that we just synthesised }". (As I said above) I believe you interpreted my objection correctly. This suggestion was an attempt of compromise, assuming people already (ab)using HINFO want to continue their practice. [...] > I am not sure I understand the benefit of not including it, given > that it is observable behaviour for a large number of domains today > (even if that is so due to the volume of domains hosted at a single > operator). I think we do better service to operators and > implementors by describing what is implemented. As you point out, > Cloudflare's implementation may be less general-purpose than BIND9 > or NSD, and that might be a reason for the implementation choices to > be different. Cloudflare is unlikely to be the last non-general > implementation, however, so perhaps the mechanism most appropriate > there will be relevant to others. I agree that being silent for existing deployment may not be ideal. If we (wg) can reach a consensus that the HINFO-based approach is an abuse, however, we can think of other way to address it. For example, we could mention it and clarify that it should be considered an abuse, should be discouraged, and newer implementations should use other approaches. My suggestion was just based on the anticipation that we can probably not reach this kind of consensus (especially about the discouragement). > > I've also noticed a couple of other points I raised in my previous > > review ( > > https://www.ietf.org/mail-archive/web/dnsop/current/msg18746.html > > ) > > were not yet addressed. These are (section numbers are for 03): > > > > - 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 > > I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset" > seems wrong, actually; since some vestigial fragment of a set theory lecture > in the depths of my pre-history is telling me that the empty set is always a > valid subset. > > > - 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). > > Agreed. That should be made consistent. Regarding these two, we've already discussed this on ML and I thought we had some consensus. I'd suggest you to look into the archive. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
