On 28-11-16 16:43, Olafur Gudmundsson wrote: > >> On Nov 28, 2016, at 5:25 AM, Matthijs Mekking <matth...@pletterpet.nl >> <mailto: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 ?
No, just TCP :) >> 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 ? Yes, although if I may make also an suggestion: RRSIG queries have the same potential as ANY queries of generating large answers as well as extra work. DNS implementations MAY choose to not return all RRSIG records when QTYPE=RRSIG. Best regards, Matthijs >> >> 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 <mailto: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