[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.
- [Pearg] Spencer Dawkins' Yes on draft-irtf-pearg-… Spencer Dawkins via Datatracker
- Re: [Pearg] Spencer Dawkins' Yes on draft-irtf-pe… Fernando Gont
- Re: [Pearg] Spencer Dawkins' Yes on draft-irtf-pe… Spencer Dawkins at IETF
- Re: [Pearg] Spencer Dawkins' Yes on draft-irtf-pe… Fernando Gont