IETF Logo Mail Archive

Re: [DNSOP] Question regarding RFC 8499

Michael De Roover <ietf@nixmagic.com> Wed, 05 August 2020 13:47 UTC

Return-Path: <ietf@nixmagic.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731E73A07D6 for <dnsop@ietfa.amsl.com>; Wed, 5 Aug 2020 06:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhyyAzP1GaMg for <dnsop@ietfa.amsl.com>; Wed, 5 Aug 2020 06:47:02 -0700 (PDT)
Received: from nixmagic.com (e3.nixmagic.com [212.237.5.239]) by ietfa.amsl.com (Postfix) with ESMTP id 766673A07D4 for <dnsop@ietf.org>; Wed, 5 Aug 2020 06:46:57 -0700 (PDT)
Received: from tp.lan (tp.lan [192.168.10.23]) by nixmagic.com (Postfix) with ESMTPS id DCD1311B43; Wed, 5 Aug 2020 13:46:55 +0000 (UTC)
Message-ID: <9fa12cfddbddbf7dda342564537934c3a244afdc.camel@nixmagic.com>
From: Michael De Roover <ietf@nixmagic.com>
To: Paul Vixie <paul@redbarn.org>, dnsop@ietf.org
Date: Wed, 05 Aug 2020 15:46:55 +0200
In-Reply-To: <1725851.NVhN7QJb2C@linux-9daj>
References: <86c18e80-88ab-5503-f63c-f788766a2675@ghnou.su> <5303244.dBo8Fx6Cfl@linux-9daj> <c535e2eba885a82fb4fd6e967884498473b6c099.camel@nixmagic.com> <1725851.NVhN7QJb2C@linux-9daj>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lpIB38S_x-gPOy-uhMUeIurbuMU>
Subject: Re: [DNSOP] Question regarding RFC 8499
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2020 13:47:04 -0000

Honestly I wouldn't change it at all. I mean.. why is the use of
master/slave controversial anyway? And how would changing a name in
technical nomenclature change this?

Particularly older documentation is something I'm concerned about, and
having to adjust any current documentation to accomodate this change,
as well as code and config files. And hearing the reasoning behind
master/slave... I think that it coming from the cylinders in a car's
brake and clutch system is actually quite amazing. Personally I don't
see anything controversial in it. If anything I find it intriguing.

On Wed, 2020-08-05 at 01:04 +0000, Paul Vixie wrote:
> i borrowed the initiator/responder terminology from iSCSI, and it
> seems 
> intuitive to me. this isn't a client/server situation, because a
> given host 
> might be both a client and a server, in a multi-level transfer graph.
> we need 
> terminology that describes the transaction, and not the host or
> hosts 
> participating in that transaction. we stopped using
> requester/responder when 
> the op codes stopped being limited to just QUERY and IQUERY and
> STATUS. (in 
> other words, UPDATE is technically a request, but not notionally so.)
> 
> what's your proposal?
> 
-- 
Met vriendelijke groet / Best regards,
Michael De Roover

v2.23.0 | Report a Bug | By Email