Subject: [DNSOP] Review of draft-ietf-dnsop-respsize-10

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 19 Mar 2008 15:42:24 +0100

Hi,

I've volunteered in Philly to do a review of the response size drafts -
i have seperated my comments into "content" and "nits" issues. 

content
-------

- The first sentence in 2.1 should probably start with "A positive
delegation response.." because a negative response could for example
also include a SOA RR in the Authority section.

- In 2.2, there is some redundancy about the importance of zone
reachability by all IP protocols in common use. There are two almost
identical sentences about this in the third paragraph (although one of
them says "should" while the other says it's "important to ensure"). I
suggest removing one of those sentences.

- In 2.3, i'd suggest changing the first sentence of the last paragraph
into "If any 'necessary' content cannot be fit... " instead of " .. is
not able to fill in.." - at least to me that would be more clear.

- I wonder whether 2.3 should include some text suggesting that the
preference of A vs. AAAA records could also depend on the transport
protocol over which the query was received? At first glance, it would
make more sense to prefer AAAA records in the additional section if the
query itself was received via IPv6, and prefer A records if the query
wFrom [email-masked]  Wed Mar 19 07:44:57 2008
Content-class: urn:content-classes:message
Date: Wed, 19 Mar 2008 15:42:24 +0100
From: "Alexander Mayrhofer" <[email-masked]>
To: <[email-masked]>
Subject: [DNSOP] Review of draft-ietf-dnsop-respsize-10
Sender: [email-masked]

Hi,

I've volunteered in Philly to do a review of the response size drafts -
i have seperated my comments into "content" and "nits" issues. 

content
-------

- The first sentence in 2.1 should probably start with "A positive
delegation response.." because a negative response could for example
also include a SOA RR in the Authority section.

- In 2.2, there is some redundancy about the importance of zone
reachability by all IP protocols in common use. There are two almost
identical sentences about this in the third paragraph (although one of
them says "should" while the other says it's "important to ensure"). I
suggest removing one of those sentences.

- In 2.3, i'd suggest changing the first sentence of the last paragraph
into "If any 'necessary' content cannot be fit... " instead of " .. is
not able to fill in.." - at least to me that would be more clear.

- I wonder whether 2.3 should include some text suggesting that the
preference of A vs. AAAA records could also depend on the transport
protocol over which the query was received? At first glance, it would
make more sense to prefer AAAA records in the additional section if the
query itself was received via IPv6, and prefer A records if the query
was received over IPv4? I haven't looked into more detail regarding
this, though.

- I have really a hard time understanding the last paragraph of Section
4. It might be me, but i can't grasp what this paragraph intends to say.

Nits
----

the online idnits checker reports a few issues - it complains about the
GTLD-SERVERS and ROOT-SERVERS domains, and the associated IP addresses.
However, i guess that it would not make much sense to change those
"special" domain names into example.com (i think it is clear from the
purpose of the document, too)

I found a couple of acronyms that are neither on the RFC editors "well
known" list nor expanded / referenced anywhere in the document. Those
include "EDNS", "RRset", "CNAME", "DNAME", "RRs".

I'm missing a ToC (although i know it's not required, i'd appreciate
one).

Section 1 (Introduction) contains just one subsection (1.1 Introduction
and Overview). I suggest removing the sub-section title, and probably
changing the Title of section one into "Introduction and Overview", if
desired.

that's all i found --

cheers

Alex
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

as received over IPv4? I haven't looked into more detail regarding
this, though.

- I have really a hard time understanding the last paragraph of Section
4. It might be me, but i can't grasp what this paragraph intends to say.

Nits
----

the online idnits checker reports a few issues - it complains about the
GTLD-SERVERS and ROOT-SERVERS domains, and the associated IP addresses.
However, i guess that it would not make much sense to change those
"special" domain names into example.com (i think it is clear from the
purpose of the document, too)

I found a couple of acronyms that are neither on the RFC editors "well
known" list nor expanded / referenced anywhere in the document. Those
include "EDNS", "RRset", "CNAME", "DNAME", "RRs".

I'm missing a ToC (although i know it's not required, i'd appreciate
one).

Section 1 (Introduction) contains just one subsection (1.1 Introduction
and Overview). I suggest removing the sub-section title, and probably
changing the Title of section one into "Introduction and Overview", if
desired.

that's all i found --

cheers

Alex
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 19 Mar 2008 15:51:54 +0100

> that's all i found --

hm. i knew i forgot something:

References: I guess that most of the "Normative" References in the draft
could be made "Informative". The only normative ones i see are RFC1034,
RFC1035, and RFC2181. The others should be moved to an Informative
References section.

thanks,

Alex

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 19 Mar 2008 15:51:54 +0100

thanks,

Alex

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 26 Mar 2008 15:26:41 +0100

On Wed, Mar 19, 2008 at 03:42:24PM +0100,
 Alexander Mayrhofer <[email-masked]> wrote 
 a message of 66 lines which said:

> protocol over which the query was received?

It seems it has been often discussed and always rejected, because the
DNS server does not see the original client, but an intermediate
server. 

The fact that my resolving BIND talks IPv4 or not when querying the
authoritative servers of nic.at does not imply that *my* machine has
IPv6 or not.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 26 Mar 2008 15:26:41 +0100

---

From: Jim Reid <[email-masked]>
Date: Wed, 26 Mar 2008 15:00:49 +0000

> protocol over which the query was received?

No. Absolutely not. If any text is to be added here it must say the  
exact opposite. ie The transport protocol used to deliver a query/ 
response MUST NOT be used to make assumptions about whether the  
client prefers A or AAAA records.

If this assumption was made, it would violate the end-to-end  
principle. And potentially the basic principle of universal response  
from the DNS since a query over IPv6 might just get AAAA records and  
one over IPv4 only gets A records. Besides, the transport service  
used to send the query has no bearing on the transport service used  
to make the original request. Suppose my IPv6 client speaks IPv6 to  
the local dual stack resolving server. It sends the queries to an  
authoritative server over IPv4. That server then suppresses the AAAA  
records because it thinks the query is only interested in IPv4, so my  
client never gets to find out that the host it wanted to contact From [email-masked]  Wed Mar 26 08:04:16 2008
From: Jim Reid <[email-masked]>
Date: Wed, 26 Mar 2008 15:00:49 +0000
To: Alexander Mayrhofer <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] Review of draft-ietf-dnsop-respsize-10
Sender: [email-masked]

> protocol over which the query was received?

No. Absolutely not. If any text is to be added here it must say the  
exact opposite. ie The transport protocol used to deliver a query/ 
response MUST NOT be used to make assumptions about whether the  
client prefers A or AAAA records.

If this assumption was made, it would violate the end-to-end  
principle. And potentially the basic principle of universal response  
from the DNS since a query over IPv6 might just get AAAA records and  
one over IPv4 only gets A records. Besides, the transport service  
used to send the query has no bearing on the transport service used  
to make the original request. Suppose my IPv6 client speaks IPv6 to  
the local dual stack resolving server. It sends the queries to an  
authoritative server over IPv4. That server then suppresses the AAAA  
records because it thinks the query is only interested in IPv4, so my  
client never gets to find out that the host it wanted to contact was  
is reachable over IPv6 or even has an IPv6 address.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

was  
is reachable over IPv6 or even has an IPv6 address.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop