[Terminology] Need guidance on interpreting NISTIR 8366
Daniel Franke <dfoxfranke@gmail.com> Wed, 12 May 2021 17:59 UTC
Return-Path: <dfoxfranke@gmail.com>
X-Original-To: terminology@ietfa.amsl.com
Delivered-To: terminology@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315D53A07D6; Wed, 12 May 2021 10:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 zWF1xFrYiqCg; Wed, 12 May 2021 10:58:56 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 45C503A07CE; Wed, 12 May 2021 10:58:56 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id h20so12917234plr.4; Wed, 12 May 2021 10:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=nHaONIX3pVuwDKu13dARNcD51JvHsMk+TZ/e2rLPPPM=; b=RcaFBdROnOlOBmVufxo2wfvB9wjxUdr0cXtuvXFyA0DimpCnpL0Be5VCSLSNDrJwYR 03649xO7G8g+HFYPm4iT+niYx9PCXxr2hyEqSZZlaEhckCC41bx6goP/l/B7LCr4Ia6f zSb291USMzb4QvUNK7uWxh/7RRr3gmnIQPh8+OyC6jhuIXlXnzTFvEOJKiHYu4LPAJNQ hQPkeHRiGdLjMN95Aegqq0/7/tfxu+XKuN+vRe+qzqa1gi/Wx5KWWduZC/m7o/eh9XBY +I/xswKs32xzVHmgIMLzBAGIJD1bvWlN31f/qLR7N1U91hAnfEC6Hy0DKNe68QWYxfo9 j5qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=nHaONIX3pVuwDKu13dARNcD51JvHsMk+TZ/e2rLPPPM=; b=QjDmZh4W4tNxmvG6+MFGE8oGxSQ5BxRZJ8+opfQFShaSVIXv+mr/iH1yTOibJ3Dj3y IVqAIh+JOZOTmtFkPX04AMAX4gC+kLtM0xSj93YwPihk4NRSwkJFfoSRGB4dvKrrd2mL 49h5Iy+Qidpq9rMlC7G1FCevtaT5qvF7rLAx2aGN0ei11N15hofonxNs+2t57fClyogL VU4rWM+a3RYTXBPoovcJqixnWAH9sIXan/UguFhN9UtRlxoUCS6PIaF2P2c1jmTy9DUI iTWoIzypbcFnts8uGttIfLsQazxAFn+JTpx+yzX0278UPGr3P97SnKWxAOZYxF6ZVU7D fT3Q==
X-Gm-Message-State: AOAM533SepDFKc4MtGlD2lGzvqTkXzpjQaGPZwWDagACkor91x+0NL0n A0OdoBlwrM7IVMLLgCMAQUaAvAl/fbwP8lFINTGTrSaePP4ZXQ==
X-Google-Smtp-Source: ABdhPJxgtqDMU6ZwuW+TDQAclIWyk73WD64JfWANBAXgVU2oyYLaoCMu4MtsZnBFdUhS4MPI/2DJP06VAkBDd6VbZuc=
X-Received: by 2002:a17:90a:df08:: with SMTP id gp8mr41597487pjb.199.1620842334282; Wed, 12 May 2021 10:58:54 -0700 (PDT)
MIME-Version: 1.0
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Wed, 12 May 2021 13:58:43 -0400
Message-ID: <CAJm83bB_4YK42O_na24MH1k+zzV1EEJ9_Y=CErkGuP+OqqgSzQ@mail.gmail.com>
To: terminology@ietf.org
Cc: NTP WG <ntp@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000092696605c225c3c7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/terminology/L517hr-i6qASoTDWbeuH23XSZvM>
Subject: [Terminology] Need guidance on interpreting NISTIR 8366
X-BeenThere: terminology@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Effective Terminology in IETF Documents <terminology.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/terminology>, <mailto:terminology-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/terminology/>
List-Post: <mailto:terminology@ietf.org>
List-Help: <mailto:terminology-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/terminology>, <mailto:terminology-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2021 17:59:01 -0000
(CCed recipients, see < https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/> for context) I'm writing for guidance on interpreting NISTIR 8366 as it pertains to my work and that of the NTP working group, and in particular on several matters surrounding the following language from section 4.1: "Avoid terms that perpetuate negative stereotypes or unequal power relationships Examples: master/slave; smart/dumb; right/left" with the footnote, "In this example, avoid using right to mean 'good' or 'normal,' and left to mean 'bad' or 'abnormal.'" The NTP working group is presently discussing extending RFC 8915 ("Network Time Security for the Network Time Protocol") to support PTP (the Precision Time Protocol, IEEE 1588). IEEE 1588 makes pervasive use of master/slave terminology to describe fundamental concepts of the protocol. (As a historical aside, the terms and concepts of "master clock" and "slave clock" are much older than PTP; see <http://www.hvtesla.com/masters/masters_index.html> for some examples from as early as 1838). What should we consider to be best practice for dealing with this sort of situation, where we're building on work that originates from a non-IETF standards body and uses terminology that is plainly non-compliant with NISTIR 8366? Any work that builds on IEEE 1588 can't reasonably avoid using the technical concepts that IEEE 1588 uses "master/slave" to represent. It could continue using the same terminology, either with or without an acknowledgement that it is violating NISTIR 8366 in doing so. Or, it could define its own synonyms, but would still need to use the original terms at least one when defining the new ones in order to make the synonymy clear to the reader. What's the correct approach? Taking this a little further: "unequal power relationships" is an awfully broad concept and I don't think any time synchronization protocol can ever get away from it no matter what euphemisms it chooses. I happen to have written Byztime <https://github.com/akamai-contrib/byztimed> which is a truly peer-to-peer protocol, but NTP and PTP are inherently hierarchical. They have to be, because they exist to support a hierarchical social function. The answer to "what time is it?", in the context of TAI or any timescale based on it (such as UTC) ultimately derives from a central authority, BIPM, and the network of reference clocks coordinated under it. And even with Byztime, there's still power inequality between the set of configured peers, which are authorized to participate in consensus, and the rest of the world which is unauthorized. I think we can find some principled middle ground here. I take for granted that everyone reading this agrees that slavery is evil, but only a tiny minority, mostly the intellectual heirs of Proudhon, favor the complete abolition of *all* power hierarchies. I would be very surprised if NIST, a bureau of the United States government, intended to officially endorse anarchism, so I think a more moderate reading is justified. I propose that the text be understood as being limited in scope to power relationships in which participation is non-consensual (FSVO, recognizing that different political philosophies have different notions of what consent means). Hence, "master/slave" is still out but we can use "client/server", "controller/agent", and other such terms that still imply unequal power relationships but lack connotations of coercion. Finally, as to that footnote about "left/right". This seems to be telling me that RFC 8280 ought not have spoken approvingly about "human rights" and that we ought to rename our "intellectual property rights" disclosures. "Right" as in "right-handed", "right" as in "correct", and "right" as in "just entitlement" are not merely homonyms; they're the same word with the same etymology, tracing to the Proto-Indo-European "h₃reǵtós" which had all the same meanings. The same root, with all its meanings preserved, shows up in other modern Indo-European languages as well, such as the Spanish word "derechos". Now, this is obviously ridiculous and not an intended reading. I've never encountered anyone who sincerely thinks that phrases like "human rights" are problematic, and surely I've gotten too literal. But I'm struggling to come up with any more reasonable interpretation. How am I to take this footnote seriously and give it meaning, while avoiding this sort of inference?
- Re: [Terminology] Need guidance on interpreting N… Salz, Rich
- [Terminology] Need guidance on interpreting NISTI… Daniel Franke
- Re: [Terminology] [Ntp] Need guidance on interpre… Karen O'Donoghue
- Re: [Terminology] [Ntp] Need guidance on interpre… John Levine