[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Robert Elz <kre@munnari.OZ.AU>
Cc: dnsop@cafax.se
From: Edward Lewis <lewis@tislabs.com>
Date: Mon, 14 Aug 2000 10:11:34 -0400
In-Reply-To: <16202.966149652@mundamutti.cs.mu.OZ.AU>
Sender: owner-dnsop@cafax.se
Subject: Re: wrt: draft-ietf-dnsop-inaddr-required-00.txt

At 2:54 AM -0400 8/13/00, Robert Elz wrote:
>Making any requirements in this area is close to hopeless, and attempting
>to do so by specification is completely hopeless, those who don't care
>will continue to not care, those who do care, don't need a requirement
>like this.

This isn't about the contents of the draft, but rather the justification
for including this in the working group...

I am not sure whether I completely disagree with this, or agree
whole-heartedly.

On one hand, the IETF has no enforcement mechanism.  There is no "RFC 3872
compliant" branding that is acheived by passing some round of
interoperability tests.  In that sense, the IETF can never really require
anything.

Besides the lack of enforcement of conformance, many specifications are not
written in a style that is easily translated into a set of requirements and
into a set of testing documents.  I know of one case where an organization
wanted software to conform to an RFC, but determinted that it would take a
lot of time to determine if the/any software was actually compliant becuase
of the looseness of the wording in the RFC.

(BTW, is there a hard/legal/contractural requirement to use IP on the
Internet?)

With that said, I agree with the comment.  However, there is another way in
which this draft can be "used."

I think it is important that a document specify "good behavior" of a
well-run and well-configured element of the network (in this case DNS,
specifically reverse map).  This is important to have so that an ISP can be
held accountable for failing to provide this service.  (I'm thinking of an
ISP "playing dumb" to avoid costs, or an ISP that is insufficiently
prepared to do their job.)

This document will not give the IETF (whatever *that* is) the legal muscle
to go to an ISP and shut them down because they aren't running reverse
maps.  This document should be a resource by which a customer or network
peer of an ISP can refer when trying to get reverse map service instituted.

So, in that sense, I disagree with the original comment.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.



Home | Date list | Subject list