Hi, Justin,
The changes are acceptable to me. None of my points were strongly enough held to be considered more than nits. Thank you for considering them.
Kind regards,
-Peter
On 6/18/23, 12:13 AM, "Justin Iurman" <justin.iurman@xxxxxxxxx> wrote:
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”.
>
>
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
