Re: [OPSEC] Genart last call review of draft-ietf-opsec-probe-attribution-05

[Justin Iurman <[e-mail]>]

Hi Peter,

We just published a new version (-06) that should address your review.

Thanks,
Justin

On 6/7/23 18:50, Peter Yee via Datatracker wrote:
> 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”.
> 
> 
>