Re: [DNSOP] Question regarding RFC 8499

Warren Kumari <warren@kumari.net> Thu, 23 July 2020 21:38 UTC

Return-Path: <warren@kumari.net>
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 943F03A0E1A for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 14:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 NuE0pJe-pLuy for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 14:38:24 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B4A3A0E18 for <dnsop@ietf.org>; Thu, 23 Jul 2020 14:38:23 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id e8so7949690ljb.0 for <dnsop@ietf.org>; Thu, 23 Jul 2020 14:38:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ydGzPal15DWE67Xt1gav+Q16VVEcPkg99wW9GOtM5hM=; b=AbXCGoWwkHc5hP+zwedGT7V4k/MffJMW8MD9NFULUTaFUBppPrxnMqm6mk4C3g2CHI yQ0FZDdv/gBD8QYyL1mhvbKBbrVRju4u5cR9r2TIzB1zCt3eoZYW7lVHGqF8m9kNF4M/ f2Tgd18ekmK1n5dJV9KZHAAwjl5OrjRDyoa/KiWVejPlHIsL6mSrfvFZEs7mdTN9/WA3 SIoL4UamRMSry62qzl5M/ECsc01je5KEb7OhcyuJP3cAjZDe8Mvo1mKGwdMOkr8dV58h +wwfwh3on2s2q0on39zXeoFhTlWPM6uMLCspmqcAOlDYLiw4fygOaIic+L4ZNsxkFL+d Abng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ydGzPal15DWE67Xt1gav+Q16VVEcPkg99wW9GOtM5hM=; b=QJBL77PcVmHAs85xc8RLf1YEHgUqjLl8WqbFM5IFcItGrXACgV5V3i/pksBuEF6qwU PUg8pONYdU5Uxlc8Zzeay6HPfnJZJRrcCyZrOowSwL/T+VWWpE4gvduZY9uo8vV6gKBZ no9zT2vQGsnilja1eqUJrOBmoIDSbTnd7SfEM+JLQrNPUUq2gRdRIThPB2zCWye5PpfS Kzd9G0GSknVpnAHwff/P06I757KSJ5t4gRhhmBUoe4rDIqsj8LXu2A1eJIYNpdyoS/Da xTTfvgrw/Bee8yM6ABpkDPnubZ2hIm4m870fkLUuZwcju25y1uZOyTH+rIBgIci7M456 H0fA==
X-Gm-Message-State: AOAM531or2sNBZEj+EQpebAfZbynsGDUK4QI8wNPIix48FknnhurdcB6 +4WQlEof//j9rworSqzlSwjl1KTlD168vWS6z21DUg==
X-Google-Smtp-Source: ABdhPJxJaurdllppM7IuHLmA0mXcmJZ+hnZlBlmtF0D8Pi5tNbBvzdI0XMkmmvmtAbDfbg0OJZkGugbuHZrO5XJ38mw=
X-Received: by 2002:a2e:9ac4:: with SMTP id p4mr3060285ljj.143.1595540301278; Thu, 23 Jul 2020 14:38:21 -0700 (PDT)
MIME-Version: 1.0
References: <86c18e80-88ab-5503-f63c-f788766a2675@ghnou.su> <1C6ACEA9-CCC5-41F5-AEAD-432B48370D12@hopcount.ca> <20200723183407.GB34140@isc.org> <2141383.qLNa8zf0Xv@linux-9daj> <20200723213149.GD34140@isc.org>
In-Reply-To: <20200723213149.GD34140@isc.org>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 23 Jul 2020 17:37:44 -0400
Message-ID: <CAHw9_iJ8EixaWSGwBGe68gHVbFSS7ZG3N8iAA3=GKccBYL5ppw@mail.gmail.com>
To: Evan Hunt <each@isc.org>
Cc: Paul Vixie <paul@redbarn.org>, Robert Edmonds <edmonds@mycre.ws>, dnsop <dnsop@ietf.org>, Joe Abley <jabley@hopcount.ca>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/miiajpqt8rbanx_ZVK6AXg098Y0>
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: Thu, 23 Jul 2020 21:38:26 -0000

Hi all,

I wanted to point at a recently published (today!) IESG statement --
https://www.ietf.org/about/groups/iesg/statements/statement-on-oppressive-exclusionary-language/
which contains:
"We wanted to highlight that initial discussions about this topic are
taking place in the general area (a draft is slated for discussion in
GENDISPATCH at IETF 108)."

If you are interested in the topic, please attend the GENDISPATCH session...

W

On Thu, Jul 23, 2020 at 5:32 PM Evan Hunt <each@isc.org> wrote:
>
> On Thu, Jul 23, 2020 at 07:40:25PM +0000, Paul Vixie wrote:
> > -1. there are zones lacking primaries, and a secondary which can also
> > talk to other secondaries gives a second role to those other secondaries.
> > we must not simply revert to the STD 13 terminology. the role of an
> > authority server depends on what zone we're talking about and what other
> > server they're talking to. that's why i've recommended we stop talking
> > about "primary servers" or "secondary servers", and instead talk about
> > "transfer initiators" and "transfer responders", where the transfer
> > pertains to a zone and the initiator or responder is a server's role with
> > respect to that zone and that transfer.
>
> I am visualizing a newly-hired and inexperienced administrator being
> shown the ropes, and told:
>
> - "this server is the master and that one is the slave",
> - "this server is the primary and that one is the secondary", or
> - "this server is the responder and that one is the initiator"
>
> ....and I think either of the first two versions would be clearer and
> more informative to them than the third.
>
> Within the specific context of discussing a zone transfer operation,
> "initiator" and "responder" are clear enough, but in the broader context of
> servers, service providers, and zone configurations, I don't see it as an
> improvement.  (Come to think of it, even in that specific context, there's
> potential confusion in the fact that a primary server could meaningfully be
> said to "initiate" a transfer operation when it sends a NOTIFY.)
>
> On the other hand, you can say "server A acts as primary for server B",
> and it's fairly easy to understand even if technically neither one of
> them is *the* primary.
>
> --
> Evan Hunt -- each@isc.org
> Internet Systems Consortium, Inc.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf