At 02:42 AM 12/16/2005, Harald Tveit Alvestrand wrote:
Dan,
it seems to me that you're advocating splitting the document into two:
- Section 1-2, discussing the present mechanism
- Section 3, discussing requirements for a "permanent solution"
In the "section 3" document, you would also like to discuss the
option of tagging all outgoing DNS responses with the server ID.
Is that what you are proposing?
I'm proposing either that the document be split, OR that the
discussion of the present mechanism be removed or reduced to a
representation of one of the possible methods that could be
considered AFTER discussing the actual requirements. The document
does not read like a requirements document, but rather a "here's a
solution, how do we make it a bit more generic" with no consideration
for whether the solution meets a set of requirements.
Another option would be to rename and retarget the document as a
documentation of a current practice, and publish it as informational.
This would be similar to some of the NAT WG documents where we were
explaining an existing mechanism and attempting to provide a common
terminology for it rather than specifying a new protocol.
(BTW, I don't, off the bat, support such a split. It's "just too
many documents" - I'd prefer to get this one out the door.)
While I understand the desire to get documents out the door, and not
increase the document count, I think it would be a mistake to publish
this document as written, because it gives the impression that the
historical solution is in fact sufficient without providing for a
more thorough analysis of other techiques. While I too would like to
see the backlog of drafts in this WG cleared, it seems to me that
focusing discussion provides a way to improve the documents and
generate debate that may not have taken place and which may be warranted.
Harald
--On torsdag, desember 15, 2005 19:47:12 -0500 Daniel Senie
<[EMAIL PROTECTED]> 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.
The thinking is simple: if the DNS server is able to tag all outbound
packets with some uniqueness information, then there is no ambiguity
concerning tracking down which server responded. Any mechanism that
relies on a subsequent query will provide a less than perfect indication
of the server involved, as load balancing or similar could in fact shift
focus to a new server. When I've raised this issue previously, the
response has been that the result of the subsequent query will be "good
enough."
The introduction section of the document indicates folks are already
using the mechanism offered by BIND (which requires an additional query)
and that a rationale for this document is to codify practice. The
introduction also goes on to talk about there being shortcomings. A
requirements document must look forward and lay out the goals for a
sufficient solution. It is understood that the existing practice has
drawbacks, and so at this time I can't support having a requirements
document that settles for solutions that are not sufficient to solve the
problem. That this document does not explore more possible solutions says
to me this is NOT a requirements document as written.
If this document is reworked, it could indeed be a useful document. A
separate document could and should explore the present practice as one
possible solution to a set of requirements, just as other possible
solutions could and should be documented. The merits of the approaches
could then be compared to the requirements, and weighed. It may well be
that more than one mechanism could or should be considered together to
provide the best possible solution given constraints that exist.
Dan
--
-----------------------------------------------------------------
Daniel Senie [EMAIL PROTECTED]
Amaranth Networks Inc. http://www.amaranth.com
"George Orwell was only off by 20 years. Had he titled his book
2004 instead of 1984, he'd have been hailed as prescient.
War is Peace. Freedom is Slavery. Ignorance is Strength." -dts
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
