On 28-11-16 16:43, Olafur Gudmundsson wrote:
>
>> On Nov 28, 2016, at 5:25 AM, Matthijs Mekking <[email protected]
>> <mailto:[email protected]>> 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
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
