Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Jari Arkko]

Ralph, Stephane,

I have no strong opinion on Exp/Inf, although I do sympathise with some of the 
points Ralph is making. Are the change that you are discussing in your opinion 
sufficient, or do we need further discussion?

jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Ralph Droms (rdroms)]

> On Dec 7, 2015, at 1:31 PM 12/7/15, Stephane Bortzmeyer  
> wrote:
> 
> On Tue, Dec 01, 2015 at 01:55:46PM +,
> Ralph Droms (rdroms)  wrote
> a message of 128 lines which said:
> 
>> Would you consider adding a little text somewhere to make it clear
>> that the Appendix is intended as a guide to implementors?
> 
> Done,
> 
> 
>> My recommendation to improve the document would be the inclusion of
>> another appendix, describing the algorithm to use if zone cuts are
>> known.
> 
> It already exists, this is the second paragraph of section 2. (The
> ideal case.)

For the inexperienced implementor, a little more detail might be useful.

> But I do not find useful to add more text: for a real resolver, the
> algorithm in appendix A suffices (it works if the zone cuts are known,
> see step 1).
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Stephane Bortzmeyer]

On Tue, Dec 01, 2015 at 01:55:46PM +,
 Ralph Droms (rdroms)  wrote 
 a message of 128 lines which said:

> Would you consider adding a little text somewhere to make it clear
> that the Appendix is intended as a guide to implementors?

Done,


> My recommendation to improve the document would be the inclusion of
> another appendix, describing the algorithm to use if zone cuts are
> known.

It already exists, this is the second paragraph of section 2. (The
ideal case.)

But I do not find useful to add more text: for a real resolver, the
algorithm in appendix A suffices (it works if the zone cuts are known,
see step 1).

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Ralph Droms (rdroms)]

> On Nov 26, 2015, at 7:41 AM 11/26/15, Stephane Bortzmeyer  
> wrote:
> 
> On Fri, Nov 20, 2015 at 04:22:21PM +,
> Ralph Droms (rdroms)  wrote
> a message of 97 lines which said:
> 
>> I am the assigned Gen-ART reviewer for
>> draft-ietf-dnsop-qname-minimisation-07.txt.
> 
> Hello. Glad to have reviewers.

This document is well-written and easy to read.  It's a pleasure to do the 
review.

> 
>> Has the working group considered publishing this document as
>> "Informational" rather than "Experimental"?  If the document is
>> published as "Experimental", is the intention to publish a
>> subsequent proposed standard or BCP?
> 
> [See Tim's answer.]

OK.

> 
>> I found the descriptions in the document understandable, but not
>> quite detailed enough to build an interoperable implementation.
> 
> There is something very important about qname minimisation: it is a
> local technique, not a protocol. It works with unmodified authoritative
> name servers. So "interoperability" is not a concern because it does
> not change the DNS protocol. Consequence: each resolver MAY implement
> it slightly differently (see appendix B).

OK, I understand this is a local technique and does not represent a change to 
the DNS protocols.  Even so, in my opinion there are some details that are not 
provided in the document (see below).

>> Is Appendix A intended as the specification for the QNAME
>> minimization techniques described in this document?
> 
> No. That's why it's in an appendix. Most resolvers already can find
> the zone cuts (they need it to do DNSSEC), this appendix is to give
> ideas to developers of the other resolvers.

Would you consider adding a little text somewhere to make it clear that the 
Appendix is intended as a guide to implementors?

>> The appendix is titled "An algorithm to find the zone cut" and the
>> introductory text indicates the algorithm is intended for locating
>> the zone cut.  However, as I read the algorithm, it finds and
>> traverses all zone cuts until the original QNAME can be resolved.
> 
> The title may be misleading. What about "An algorithm to perform QNAME
> minimisation in presence of zone cuts?"

Perhaps "unknown zone cuts"?  Otherwise, that title sounds good.

My recommendation to improve the document would be the inclusion of another 
appendix, describing the algorithm to use if zone cuts are known.  In my 
opinion, what's missing from the document for an inexperienced implementor is a 
summary of how to build the resolver you refer to in section 2: "The minimising 
resolver works perfectly when it knows the zone cut"

>> In section 2, is the phrase "closest known parent of the original
>> QNAME" something that most DNS developers would understand?
> 
> Well, "parent" could be misleading because it is rather "ancestor"
> (the example in the draft show a grand-parent).
> 
>> Would the phrase "closest enclosing NS RRset" from Appendix A be
>> more precise?
> 
> "Known" is very important here. What about "closest known enclosing NS
> RRset"?

OK, that text would be good.

>> I wasn't sure at first whether "(section 6)" in the 4th paragraph of
>> section 2 referred to section 6 of RFC 2181 or section 6 of this
>> document.
> 
> OK, fixed in my local copy.

Great.

> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Stephane Bortzmeyer]

On Thu, Nov 26, 2015 at 01:41:17PM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 57 lines which said:

> Well, "parent" could be misleading because it is rather "ancestor"
> (the example in the draft show a grand-parent).

I changed "parent" for "ancestor" in the algorithm, to stay aligned
both with the definition of parent in english, and with standard
terminology tree data structures.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Stephane Bortzmeyer]

On Fri, Nov 20, 2015 at 04:22:21PM +,
 Ralph Droms (rdroms)  wrote 
 a message of 97 lines which said:

> I am the assigned Gen-ART reviewer for
> draft-ietf-dnsop-qname-minimisation-07.txt.

Hello. Glad to have reviewers.

> Has the working group considered publishing this document as
> "Informational" rather than "Experimental"?  If the document is
> published as "Experimental", is the intention to publish a
> subsequent proposed standard or BCP?

[See Tim's answer.]

> I found the descriptions in the document understandable, but not
> quite detailed enough to build an interoperable implementation.

There is something very important about qname minimisation: it is a
local technique, not a protocol. It works with unmodified authoritative
name servers. So "interoperability" is not a concern because it does
not change the DNS protocol. Consequence: each resolver MAY implement
it slightly differently (see appendix B).

> Is Appendix A intended as the specification for the QNAME
> minimization techniques described in this document?

No. That's why it's in an appendix. Most resolvers already can find
the zone cuts (they need it to do DNSSEC), this appendix is to give
ideas to developers of the other resolvers.

> The appendix is titled "An algorithm to find the zone cut" and the
> introductory text indicates the algorithm is intended for locating
> the zone cut.  However, as I read the algorithm, it finds and
> traverses all zone cuts until the original QNAME can be resolved.

The title may be misleading. What about "An algorithm to perform QNAME
minimisation in presence of zone cuts?"

> In section 2, is the phrase "closest known parent of the original
> QNAME" something that most DNS developers would understand?

Well, "parent" could be misleading because it is rather "ancestor"
(the example in the draft show a grand-parent).

> Would the phrase "closest enclosing NS RRset" from Appendix A be
> more precise?

"Known" is very important here. What about "closest known enclosing NS
RRset"?

> I wasn't sure at first whether "(section 6)" in the 4th paragraph of
> section 2 referred to section 6 of RFC 2181 or section 6 of this
> document.

OK, fixed in my local copy.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Ralph Droms]

> On Nov 23, 2015, at 9:01 AM 11/23/15, Tim Wicinski  wrote:
> 
> Ralph
> 
> Thanks for the detailed review. Commeinline
> 
> On 11/20/15 11:22 AM, Ralph Droms (rdroms) wrote:
>> 
>> I am the assigned Gen-ART reviewer for 
>> draft-ietf-dnsop-qname-minimisation-07.txt.
>> 
>> For background on Gen-ART, please see the FAQ at 
>> .
>> 
>> Please resolve these comments along with any other Last Call comments you 
>> may receive.
>> 
>> 
>> Document: draft-ietf-dnsop-qname-minimisation-07
>> Reviewer: Ralph Droms
>> Review Date: 2015-11-20
>> IETF LC End Date: 2015-11-23
>> IESG Telechat date: unknown
>> 
>> Summary:
>> 
>> This draft is on the right track but has open issues, described in the 
>> review.
>> 
>> Major issues:
>> 
>> The document is well-written and easy to understand.  Thank you.
>> 
>> Has the working group considered publishing this document as "Informational" 
>> rather than "Experimental"?  If the document is published as "Experimental", 
>> is the intention to publish a subsequent proposed standard or BCP?
>> 
> 
> The WG has considered several options. I believe we settled on "Experimental" 
> because passing the entire QNAME all the way to the root servers has always 
> existed, and it was unclear what unintended consequences would happen if this 
> was deployed.
> 
> We do plan  on producing a Standards Track document.

OK, glad to hear the WG thought through the alternatives.
> 
>> In my opinion, the document needs a little more work if it is to be 
>> published as "Experimental", especially if the intention is to publish a 
>> proposed standard based on the results of experiments with the techniques 
>> described in this document.  I found the descriptions in the document 
>> understandable, but not quite detailed enough to build an interoperable 
>> implementation.
>> 
> 
> Do you have anything in particular on details?  I can revisit with the 
> authors on this.

In my opinion, the document provides a collection of techniques but doesn't 
explicitly define a specific, testable mechanism to implement.  (continued 
below)

>> Is Appendix A intended as the specification for the QNAME minimization 
>> techniques described in this document?  The appendix is titled "An algorithm 
>> to find the zone cut" and the introductory text indicates the algorithm is 
>> intended for locating the zone cut.  However, as I read the algorithm, it 
>> finds and traverses all zone cuts until the original QNAME can be resolved.

   Here is the text I would focus on if I were writing an implementation:

   A resolver which implements QNAME minimisation, [...],
   sends a request to the name
   server authoritative for the closest known parent of the original
   QNAME.

   [...]

   The minimising resolver works perfectly when it knows the zone cut
   [RFC2181] (section 6). [...] (Appendix A describes this algorithm
   in deeper details.)

As I wrote in my review, it appears to me that Appendix A gives a specification 
of the resolver behavior.  If that's the case, it would be helpful to make that 
explicit statement in section 2.

>> If Appendix A is not the specification for the QNAME minimization 
>> techniques, then I don't know exactly what specific behavior or algorithm is 
>> referred to by "minimising resolver" in this sentence from section 2: "The 
>> minimising resolver works perfectly when it knows the zone cut [...]".
>> 
>> My suggestion would be to include another algorithm description, similar to 
>> that in Appendix A, but that describes how to use knowledge of zone cuts.
>> 
> 
> OK
> 
>> Editorial
>> -
>> 
>> In section 2, is the phrase "closest known parent of the original QNAME" 
>> something that most DNS developers would understand?  Would the phrase 
>> "closest enclosing NS RRset" from Appendix A be more precise?
>> 
> 
> "closest enclosing NS RRset" may be more relevant.

OK.

> 
>> I wasn't sure at first whether "(section 6)" in the 4th paragraph of section 
>> 2 referred to section 6 of RFC 2181 or section 6 of this document.
>> 
> 
> This is RFC2181, so perhaps it can be reworded like this:
> 
>   The minimising resolver works perfectly when it knows the zone
>   cut, as described in section 6 of [RFC2181].

That wording would eliminate the confusion.

> 
> thanks
> tim



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Tim Wicinski]

Ralph

Thanks for the detailed review. Commeinline

On 11/20/15 11:22 AM, Ralph Droms (rdroms) wrote:


I am the assigned Gen-ART reviewer for 
draft-ietf-dnsop-qname-minimisation-07.txt.

For background on Gen-ART, please see the FAQ at 
.

Please resolve these comments along with any other Last Call comments you may 
receive.


Document: draft-ietf-dnsop-qname-minimisation-07
Reviewer: Ralph Droms
Review Date: 2015-11-20
IETF LC End Date: 2015-11-23
IESG Telechat date: unknown

Summary:

This draft is on the right track but has open issues, described in the review.

Major issues:

The document is well-written and easy to understand.  Thank you.

Has the working group considered publishing this document as "Informational" rather than 
"Experimental"?  If the document is published as "Experimental", is the intention to 
publish a subsequent proposed standard or BCP?



The WG has considered several options. I believe we settled on 
"Experimental" because passing the entire QNAME all the way to the root 
servers has always existed, and it was unclear what unintended 
consequences would happen if this was deployed.


We do plan  on producing a Standards Track document.


In my opinion, the document needs a little more work if it is to be published as 
"Experimental", especially if the intention is to publish a proposed standard 
based on the results of experiments with the techniques described in this document.  I 
found the descriptions in the document understandable, but not quite detailed enough to 
build an interoperable implementation.



Do you have anything in particular on details?  I can revisit with the 
authors on this.



Is Appendix A intended as the specification for the QNAME minimization techniques 
described in this document?  The appendix is titled "An algorithm to find the zone 
cut" and the introductory text indicates the algorithm is intended for locating the 
zone cut.  However, as I read the algorithm, it finds and traverses all zone cuts until 
the original QNAME can be resolved.

If Appendix A is not the specification for the QNAME minimization techniques, then I don't know 
exactly what specific behavior or algorithm is referred to by "minimising resolver" in 
this sentence from section 2:  "The minimising resolver works perfectly when it knows the zone 
cut [...]".

My suggestion would be to include another algorithm description, similar to 
that in Appendix A, but that describes how to use knowledge of zone cuts.



OK


Editorial
-

In section 2, is the phrase "closest known parent of the original QNAME" something that 
most DNS developers would understand?  Would the phrase "closest enclosing NS RRset" from 
Appendix A be more precise?



"closest enclosing NS RRset" may be more relevant.


I wasn't sure at first whether "(section 6)" in the 4th paragraph of section 2 
referred to section 6 of RFC 2181 or section 6 of this document.



This is RFC2181, so perhaps it can be reworded like this:

The minimising resolver works perfectly when it knows the zone
cut, as described in section 6 of [RFC2181].

thanks
tim

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Ralph Droms (rdroms)]

I am the assigned Gen-ART reviewer for 
draft-ietf-dnsop-qname-minimisation-07.txt.

For background on Gen-ART, please see the FAQ at 
.

Please resolve these comments along with any other Last Call comments you may 
receive.


Document: draft-ietf-dnsop-qname-minimisation-07
Reviewer: Ralph Droms
Review Date: 2015-11-20
IETF LC End Date: 2015-11-23
IESG Telechat date: unknown

Summary:

This draft is on the right track but has open issues, described in the review.

Major issues:

The document is well-written and easy to understand.  Thank you.

Has the working group considered publishing this document as "Informational" 
rather than "Experimental"?  If the document is published as "Experimental", is 
the intention to publish a subsequent proposed standard or BCP?

In my opinion, the document needs a little more work if it is to be published 
as "Experimental", especially if the intention is to publish a proposed 
standard based on the results of experiments with the techniques described in 
this document.  I found the descriptions in the document understandable, but 
not quite detailed enough to build an interoperable implementation.

Is Appendix A intended as the specification for the QNAME minimization 
techniques described in this document?  The appendix is titled "An algorithm to 
find the zone cut" and the introductory text indicates the algorithm is 
intended for locating the zone cut.  However, as I read the algorithm, it finds 
and traverses all zone cuts until the original QNAME can be resolved.

If Appendix A is not the specification for the QNAME minimization techniques, 
then I don't know exactly what specific behavior or algorithm is referred to by 
"minimising resolver" in this sentence from section 2:  "The minimising 
resolver works perfectly when it knows the zone cut [...]".

My suggestion would be to include another algorithm description, similar to 
that in Appendix A, but that describes how to use knowledge of zone cuts.

Editorial
-

In section 2, is the phrase "closest known parent of the original QNAME" 
something that most DNS developers would understand?  Would the phrase "closest 
enclosing NS RRset" from Appendix A be more precise?

I wasn't sure at first whether "(section 6)" in the 4th paragraph of section 2 
referred to section 6 of RFC 2181 or section 6 of this document.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art