[Pearg] Spencer Dawkins' Yes on draft-irtf-pearg-numeric-ids-history-09: (with COMMENT)

Spencer Dawkins via Datatracker <noreply@ietf.org> Thu, 16 June 2022 22:33 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: pearg@irtf.org
Delivered-To: pearg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B4CC14CF18; Thu, 16 Jun 2022 15:33:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Spencer Dawkins via Datatracker <noreply@ietf.org>
To: The IRSG <irsg@irtf.org>
Cc: draft-irtf-pearg-numeric-ids-history@ietf.org, pearg-chairs@ietf.org, pearg@irtf.org, sara@sinodun.com, sara@sinodun.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Message-ID: <165541878753.59903.8018667065000800390@ietfa.amsl.com>
Date: Thu, 16 Jun 2022 15:33:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/j5QnxjsSLKKtTTjSi4Voua0dhxQ>
Subject: [Pearg] Spencer Dawkins' Yes on draft-irtf-pearg-numeric-ids-history-09: (with COMMENT)
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.39
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jun 2022 22:33:07 -0000

Spencer Dawkins has entered the following ballot position for
draft-irtf-pearg-numeric-ids-history-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-irtf-pearg-numeric-ids-history/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

At a 10K meter level, I love everything about this document. I remember
probably 60-70 percent of this history, some of which I was reading about
before I started participating in the IETF in 1997, I learned from the parts I
didn't remember and had probably never seen, and there's no way I could have
described all of it as well as you did.

I wish we had more documents explaining why the IRTF is doing research on
aspects of widely deployed protocols.

I do have two or three nits about readability and consistency, but I'm already
a Yes, so Do The Right Thing - I can't say "it's ready" any more clearly than
balloting "Yes".

- Honest question here. In this text from the Introduction,

“For more than 30 years, a large number of implementations of the TCP/IP
protocol suite have been subject to a variety of attacks, with effects ranging
from Denial of Service (DoS) or data injection, to information leakages that
could be exploited for pervasive monitoring [RFC7258]. The root cause of these
issues has been, in many cases, poor selection of transient numeric
identifiers, usually as a result of insufficient or misleading specifications.”

Does “TCP/IP protocol suite” mean what you intend it to mean?

You follow this with a list of examples that (if I understand correctly)
include IPv4, IPv6, “transport protocols”, TCP, and DNS. Just poking at one of
the references, The Introduction of RFC 6056 calls out

   TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP
   [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550] (provided the RTP
   application explicitly signals the RTP and RTCP port numbers with,
   e.g., [RFC3605]).

Perhaps those protocols should be part of what I think of when I hear “TCP/IP
protocol suite”, but they aren’t.

- I might have suggested “implementations of Internet network-layer and
transport-layer protocols”, but even that doesn’t include DNS, which is on your
list. And a quick peek at Section 4.4 mentions problems with NTP Reference IDs
(REFIDs), which is NOT mentioned in the Introduction, but is described later in
the document, while problems with DNS TxIDs, which is mentioned in the
Introduction, is NOT described in Section 4 (the detailed discussion of DNS in
Section 4 is about predictable port numbers used by DNS implementations). Maybe
the transient numeric identifier problems with those two application-level
protocols could be treated consistently in Section 1 and Section 4?

- In Section 4,the phrase “A number of protocol specifications” is used. Is
that a better way to say what you mean in Section 1 and Section 5? Or is there
a better way to describe the protocols you’re thinking of in the Introduction,
without attempting to list them exhaustively?

- I should also mention that Section 5 also uses the phrase “large number of
implementations of the TCP/ IP protocol suite”. Whatever you do with this
phrase in Section 1, you should probably consider doing in Section 5 as well.

- I also have a point of confusion with the phrase “sample transient numeric
identifiers” in Section 1, and in Section 4. "sample" seems like an adjective
in those usages. I THINK (correct me if I’m wrong) that this phrase is intended
to mean “some transient numeric identifiers that have been found to be
problematic” - because this isn’t a complete list of the problematic
identifiers, right? But that's not what I'm getting from the text.

And it doesn’t help that in Section 3, “sample transient numeric identifiers”
means “to sample transient numeric identifiers” - so, there, “sample” is a verb.