At 10:52 AM 12/16/2005, Olaf M. Kolkman wrote:
*** PGP SIGNATURE VERIFICATION ***
*** Status: Unknown Signature
*** Signer: Unknown Key (0x76092287)
*** Signed: 12/16/2005 10:53:00 AM
*** Verified: 12/16/2005 11:01:07 AM
*** BEGIN PGP VERIFIED MESSAGE ***
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.
Good, some debate. Today, the server can send information in the
additionals section. It's not clear to me whether or not additional
information there would or would not affect resolver libraries. I
suspect that any such approach would need to be worked on and debated
by DNSEXT. My concern is that if this is a requirements document,
then requiring some means of identification in the packets is one of
the possible solutions that should be discussed.
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.
Good. Especially good if that document is close to publication, as it
could be referenced by this one. (Indeed there are NO references in
this draft to anything else, something that probably could be improved upon).
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 or
other 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/
*** END PGP VERIFIED MESSAGE ***
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
