>>>>> On Wed, 28 Apr 2004 10:53:33 +0300 (EEST),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
>> So, I'd totally revise the beginning of this section (including the
>> first and second paragraphs) as follows:
> I agree with you.
> I've taken almost all of what you suggest, with a few touches; the
> most important of them were:
> - remove the mostly redundant "In other words" paragraph, integrate
> it with the earlier numbered list.
Ah, that should have been removed from the proposed text of mine. I
was not careful enough. Removing this is of course fine.
> - add an explicit note that it would be better to omit all of
> courtesy additional data (now that we have a semantic difference)
> rather than returning only some RRsets.
Okay. I'm not sure if it is a good practice to remove the entire
RRsets, but I don't oppose to suggesting that.
> - I didn't understand what you wrote about the all "all the
> latter three cases", so I reworded that.
Okay. Perhaps the confusion came from that I intended to use the word
"critical" for "critically bad" whereas you seem to have intended to
use the same word for "critically important". I'm fine with rewording
that part, but then in the following sentence
(where the lack of
either A or AAAA RRsets can be critical):
it might be better to say "where getting both the A and AAAA RRsets is
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, ...
> Did we (as WG) already agree that it's better to set TC bit than
> return only some RRsets of critical additional data? I'd love that
> kind of resulution, but for now, I put "(whether courtesy or
> critical)" there. If folks have strong feelings of this, let's start
> a new thread explicitly only about this.
What I wanted to say is that in the critical case (particularly in the
case of the glue for a delegation), it might make sense to organize
the additional section based on the transport. In fact, if the
respondiner is going to return a delegation to a caching (or
recursive?) resolver using IPv4 transport, it is probably better to
prefer A RRset (as glue) to AAAA.
I basically support your opinion, though. As the draft says, it
should be better to not combine the content with transport, based on
the basic model of DNS. Also, we can even construct a case where the
querier that receives the delegation in the above example can be just
a "middle-node" and the real "user" exists behind the node. (e.g.,
there is a simple DNS forwarder to help IPv4<->IPv6 translation, which
does not act as a recursive resolver - though this might be a tricky
example).
We could probably describe the subtle points, but this might be a
minor detail, so, as a result, I can live with the current wording of
yours.
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
