>>>>> On Tue, 27 Apr 2004 22:19:32 +0300 (EEST),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
> =======
> In other words, there are two kinds of additional data:
> 1. "critical" additional data; this must be included (all the
> possible RRsets) in all scenarios, and
> 2. "courtesy" additional data; this could be sent in full, with only
> a few RRsets, or with no RRsets, and can be fetched separately as
> well.
> An example of the latter are A/AAAA records in conjunction of MX
> records as shown in the next section; an example of the former is
> shown below:
> child.example.com. IN NS ns.child.example.com.
> ns.child.example.com. IN A 192.0.2.1
> ns.child.example.com. IN AAAA 2001:db8::Y
> In the case of too much additional data, [...]
> =======
> Is this better?
Yes, but I still have a couple of concerns:
1. it's not very clear how the first and second paragraphs relate each
other with the phrase 'In other words'. I guess you intended to
emphasize that the following sentence in the first paragraph
However, note that if too much additional information that is not
strictly necessary would be added, one should remove unnecessary
information instead of setting TC bit for this "courtesy" information
[19].
is the second one (item 2) in the classification of the second
paragraph. However, the first paragraph does not seem to talk about
the "critical" kind of additional data, so it is a little bit
strange to see "In other words" at the beginning of the second
paragraph.
Additionally, the first paragraph contains supplemental description
which is not directly related to the classification in the second
paragraph: the fact that RRsets cannot be broken up. This also
causes the confusion.
2. it is confusing to use "2001:db8::Y" without explaining what Y
means. In this context, I guess you could simply use an arbitrary
hex value, e.g., "2001:db8::2".
------------ end of concerns ------------
So, I'd totally revise the beginning of this section (including the
first and second paragraphs) as follows:
Consider the case where the query name is so long, the number of the
additional records (originated from "glue") is so high, or for other
reasons that the entire response would not fit in a single UDP packet.
In some cases, the responder truncates the response with the TC bit
being set (leading to a retry with TCP), in order for the querier
to get the entire response later.
However, note that if too much additional information that is not
strictly necessary would be added, one should remove unnecessary
information instead of setting TC bit for this "courtesy" information
[19].
Also notice that there are two kinds of additional data:
1. "critical" additional data; this must be included (all the
possible RRsets) in all scenarios, and
2. "courtesy" additional data; this could be sent in full, with only
a few RRsets, or with no RRsets, and can be fetched separately as
well.
Meanwhile, resource record sets (RRsets) are never "broken up",
so if a name has 4 A records and 5 AAAA records, you can either
return all 9, all 4 A records, all 5 AAAA records or nothing.
Notice that for the "critical" additional data all the latter three
cases can be critical.
In other words, there are two kinds of additional data: the kind that
must be included (all RRsets) no matter what (an example of this is
below), and the kind which could be omitted in full or in part, but
could cause nonoptimal results (an example of this is in the next
section):
An example of the "courtesy" additional data is A/AAAA records in
conjunction of MX records as shown in the next section; an example
of the "critical" additional data is shown below:
child.example.com. IN NS ns.child.example.com.
ns.child.example.com. IN A 192.0.2.1
ns.child.example.com. IN AAAA 2001:db8::2
(where the lack of either A or AAAA RRsets can be critical)
-------------
One additional comment: reconsidering the entire context, I guess the
first sentence of the following paragraph should be clarified:
In the case of too much additional data, it might be tempting to not
return the AAAA records if the transport for DNS query was IPv4, or
not return the A records, if the transport was IPv6.
to, e.g.,
In the case of too much "courtesy" additional data, ...
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
