JINMEI-san, all, With reference to:
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 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 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 }". Again, I am not entirely confident that I understand your concern, so both my reactions above might be nonsense. Please try again if it seems that I don't understand your point. > Regarding the choice of HINFO in case of synthesizing, it may make > sense to specify a particular type as part of normative spec if many > other implementations are going to implement it. But, as Section 8 > explains two major general purpose open source implementations, NSD > and BIND 9, seem to only support the "subset" approach. I suspect > it's actually not feasible for those generic implementations to > hardcode HINFO as long as their users could also use that type as > "real zone data". Some special purpose implementation with full > control on what it configures, like in the case of Cloudflare, may > freely explore the approach of synthesizing HINFO at their discretion. > But I don't think it necessarily has to be a part of normative part of > this spec, at least at this moment. 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'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. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
