[Ntp] 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: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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/ntp/B7E2oz9EAJC9cw1RqP-NWZpMHfU>
Subject: [Ntp] Need guidance on interpreting NISTIR 8366
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2021 17:59:01 -0000

(CCed recipients, see <
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?