[Gen-art] Genart last call review of draft-ietf-opsec-probe-attribution-05

Peter Yee via Datatracker <noreply@ietf.org> Wed, 07 June 2023 16:50 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57148C151B00; Wed, 7 Jun 2023 09:50:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Peter Yee via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: draft-ietf-opsec-probe-attribution.all@ietf.org, last-call@ietf.org, opsec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 10.5.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168615663634.33016.16335583889761548966@ietfa.amsl.com>
Reply-To: Peter Yee <peter@akayla.com>
Date: Wed, 07 Jun 2023 09:50:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/9yYfZIpDOm9M52-Q7C8Tl80FPN8>
Subject: [Gen-art] Genart last call review of draft-ietf-opsec-probe-attribution-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jun 2023 16:50:36 -0000

Reviewer: Peter Yee
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-opsec-probe-attribution-05
Reviewer: Peter Yee
Review Date: 2023-06-07
IETF LC End Date: 2023-06-08
IESG Telechat date: Not scheduled for a telechat

Summary: This informative specification indicates how good-intentioned
researchers may alert receivers (or intermediaries) of their probe traffic as
to what the probes are and how to contact the researchers. The document is
reasonably well written, but it has some nits that should be corrected prior to
publication. [Ready with nits]

Major issues: None

Minor issues: None

Nits/editorial comments:

Page 1, Abstract, last sentence: rearrange “what is its purpose” to “what its
purpose is” for parallel construction and ease of reading.

Page 3, 1st paragraph, 1st sentence: change “parties” to “parties’” (if this
should be plural) or “party’s” (if this should be singular).

Page 3, 1st paragraph, 2nd sentence: change “where” to “that”.

Page 3, 2nd bullet item: change “what is its purpose” to “what its purpose is”
for the same reasons as in the abstract.

Page 4, 1st paragraph after the two bullet items: change “one line” to
“one-line”.

Page 3, section 3, 1st paragraph, 1st sentence: Probe inclusion hasn’t even
been discussed at this point, so “As an alternative” is not appropriate here.
Either swap the in-band and out-of-band sections or reword. I prefer swapping,
but it’s possible this already happened once and hence the odd phrasing
considering the current ordering.

Page 5, 1st, 2nd, and 5th bullet items: change the first “a” to “an” if the
[RFCxxxx] reference is considered silent or all of them to “an” if the
reference is expected to be read as part of the sentence.

Page 6, 1st paragraph, last sentence at “multiple possibilities”: Are multiple
in-band options allowed or suggested? Is there “concatenation” of multiple
probe methods applied by different probe generators or for different research
purposes? If so or even if not, a discussion here might be worthwhile.

Page 6, section 5, 1st paragraph, 1st sentence: I’m not sure what is meant by
“will”. Do you mean “intent”?

Page 6, section 5, 2nd paragraph, last sentence: regarding “dynamic source
addresses”, why would this be a problem? The web server would presumably be on
the same IP address as probe generation, so, as the IP address changes, the web
server would appear on the new address. There might be a short period where
this isn’t the case, but it seems the overall inability to reach a web server
for the out-of-band option is small unless the address changes frequently.

Page 7, section 6, 1st paragraph: move “unsolicited” before “transit”.

Page 7, section 6, 2nd paragraph: change “identity” to “identify”.

Page 7, section 6, 2nd paragraph: It’s not clear to me that unsolicited transit
parties necessarily have much recourse or that the probe sender can effect much
change in their use other than not sending probes at all.

Page 7, section 6, 3rd paragraph, 1st sentence: remove the space between
“valid” and “?”.

Page 7, section 7, 2nd paragraph, 3rd sentence: move “would” before “this”.