Hi, I posted -06 document, which appears to be good for now.
On Wed, 28 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H wrote: > > - 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. OK. (There are certainly arguments both ways, but my main point was that the integrity of _all_ the information should be most important, except if there is no other choice.) > > - 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". Changed. > >> 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. There are tradeoffs each way whether to expand these right now or not. It seems to me that in order to do that, we'd have to gain WG consensus on the approach to go forward, and that's always difficult and time-consuming.. so I've avoided doing that for now. I'll consider posting a separate thread on the subject to gauge opinions when we get into the "waiting for IESG evaluation" stage. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
