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

Reply via email to