> On Nov 28, 2016, at 5:25 AM, Matthijs Mekking <matth...@pletterpet.nl> wrote: > > Hi, > > I have read the draft and have two comments. Both of these have been called > out before, but I don't see them addressed in this version (-03): > > 1. In case of a DNS responder selecting one or a subset of the RRsets at the > QNAME, The draft does not give clear guidance on which RRset(s) to pick. In > previous discussions there was yes nodding to provide text that the RRset > picking should be determinative, even perhaps providing guidance on the > selection method to use. Such text has not made it to the draft yet. I am not > sure if adding a single line "the RRset selection method SHOULD be > determinative" is sufficient, or if more text is wanted.
There have been some discussion on this topic, It is fair to say that there are 3 camps a) answer with the smallest RRSET b) pick one at “random" c) select bases on what is most useful (i.e. deterministic selection) I would be happiest to go with b) and add text that says that. > > 2. People expressed that they would like to see ANY over TCP stick to the > original (undefined) behavior, that is to return all RRsets at the QNAME. Joe > replied that this is still possible with this document because the mechanism > is "a big giant MAY", but still I think it makes sense to call out explicitly > that the behavior MAY differ depending on the transport protocol. This is operational choice, if we call that out do we also call out that answer may depend on address, TSIG etc ? > > One more nit comment, I would like to see explicitly called out in section 7 > that "DNS implementations are free to not return all RRSIGS *in case > QTYPE=RRSIG*”. Current text: RRSIG queries have the same potential as ANY queries of generating large answers as well as extra work. DNS implementations are free to not return all RRSIGS. In the wild there are implimentations that return REFUSE, others return single RRSIG, etc. Proposed text: RRSIG queries have the same potential as ANY queries of generating large answers as well as extra work. DNS implementations MAY return some but not all RRSIGS when QTYPE=RRSIG. In the wild there are implimentations that return REFUSE, others return single RRSIG, etc. Is this better ? > > And I prefer `minimal-any` over `refuse-any`, agreeing with the logic Ondrej > provided. > I do not care > Best regards, > Matthijs thanks Olafur > > On 26-11-16 01:50, tjw ietf wrote: >> >> All >> >> The authors have addressed all the outstanding issues with this draft, >> and the chairs feel this is ready for Working Group Last Call. >> >> There has been one issue raised which we feel the working group may have >> some opinion on this. >> >> Ondrej Sury raised this point: >> >> >> There's a small procedural thing - the last name of the draft >> appears on both datatracker.i.o and tools.i.o. I believe it >> would be better to reupload the draft with name changed to >> >> draft-ietf-dnsop-minimal-any >> >> to prevent the people who might thing the name of the draft >> bears any significance. As this requires almost no effort >> I think it would be better to this now than fend of the >> questions "why is this refuse-any while it doesn't refuse >> ANY" later. >> >> >> >> The authors and the Chairs support this in principle, but the working >> group should comment on this during the WGLC process. >> >> --------- >> This starts a Working Group Last Call for >> draft-ietf-dnsop-refuse-any >> >> Current versions of the draft is available here: >> >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ >> >> 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. >> >> >> This starts a two week Working Group Last Call process, and ends on 10 >> December, 2016 >> >> thanks >> tim >> >> >> >> _______________________________________________ >> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
