Hello Dan,
On Dec 16, 2005, at 01:47 , Daniel Senie wrote:
I read Brad's comments on this draft with interest. I've had some concerns about the mechanism recommended by this draft for some time, and would urge a bit of expansion in one area. I would like to see at least an optional, but standardized way to include an identifier in all response packets sent by the server, provided there's room in the packets. This could be accomplished by placing the information in the additionals section after ensuring the addition would not cause an overflow.
How can you be sure that that "extra information" does not break existing clients or makes middle boxes drop the packet on the floor? I think that including an identifier in _all_ response packets sent by a server _only_ provided there is room in the packets is a _bad_ idea.
The request to have the identifier in "all" response packets is already in section 3:
That is, it needs to allow the query for the server's identifying
information to be part of a normal, operational query.
The detail here is that the client needs to request for the
additional information, thereby indicating it can deal with that
extra information returned. It could be argued that failsafe behavior
in the presence of broken middle-boxes is a requirement that should
be made explicit. I am agnostic about the need for such argument.
Note that the propose implementation of this mechanism (draft-ietf- dnsext-nsid-00.txt, which, except for one minor issue, has finished last call in DNSEXT) uses EDNS which has the appropriate failure mechanism.
BTW. I committed to review this document. Which I just did.I agree with the content, I support this being published. But I find the first sentence of requirement 2 in section 3
almost incomprehensible: 2. The new mechanism SHOULD not require dedicated namespaces orother reserved values outside of the existing protocol mechanisms
for these, i.e. the OPT pseudo-RR.
I suggest a rewrite.
2-a. The new mechanism SHOULD not require dedicated namespaces.
2-b. The new mechanism SHOULD not require reserved values outside
of the existing protocol mechanisms such as EDNS0.
I think that means the same :-)
--Olaf
-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/
PGP.sig
Description: This is a digitally signed message part
