Re: draft-manning-dnssvr-criteria-01.txt

Randy Bush <randy@psg.com> Mon, 06 May 1996 07:00 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07746; 6 May 96 3:00 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07736; 6 May 96 3:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02868; 6 May 96 3:00 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07706; 6 May 96 3:00 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07651; 6 May 96 2:57 EDT
Received: from rip.psg.com by CNRI.Reston.VA.US id aa02816; 6 May 96 2:57 EDT
Received: by rip.psg.com (Smail3.1.29.1 #1) id m0uGKEF-00083MC; Sun, 5 May 96 23:57 PDT
Message-Id: <m0uGKEF-00083MC@rip.psg.com>
Date: Sun, 05 May 1996 23:57:00 -0700
X-Orig-Sender: ietf-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Randy Bush <randy@psg.com>
To: ietf <ietf@CNRI.Reston.VA.US>
Subject: Re: draft-manning-dnssvr-criteria-01.txt
References: <m0uG5b7-00083RC@rip.psg.com> <VIXIE.96May5224732@wisdom.vix.com>
Source-Info: From (or Sender) name not authenticated.

Evenin' Paul,

>>  o we should specify protocols, not which implementation should be used.
>>    i am especially shocked by point 4, which enshrines a mis-feature in
>>    BIND into an operational restriction.
> No, it doesn't, and no, it isn't.  This isn't a misfeature of BIND, and your
> own draft-ietf-dnsind-clarify-01.txt (section 3 and especially section 3.1)
> enshrine the same thing that draft-manning-dnssvr-criteria-01.txt is trying
> to say.  Unfortunately, your draft is clearer on this point than ours is, and
> so it appears that you and Bill are in disagreement when you're actually not.

the disagreement is not whether the response should be from the address to
which the query was sent, but whether this should be specified as protocol,
or whether the inability of some implementation(s) on some platform(s) to
meet that protocol requirement should be translated into banning servers
with multiple interfaces.

the differece between specifying how an abstraction should appear to act
and the mechanism by which it simulates that action is an interesting bit
of the art of specification.  it is a magic curtain.  we should not confuse
the desire to [design and] test a specification by implementing it with the
necessity of having specification sufficiently abstract so as to allow a
wide variety of implementation.

as we discussed elsewhere, we should also beware having specifications so
formal and abstract that they become academic exercises of no practical
use.  but i don't think that's the issue here.

randy