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

[Justin Iurman <[e-mail]>]

Hi Peter,

Thanks for the review. A few comments inline ([JI]).

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”.

[JI] Changed "where" to "through which" instead, are you ok with 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.

[JI] If I remember correctly, there was a preference for having 
out-of-band first, since it already exists and is already used. We 
rephrased: "A possibility for probe attribution is to build [...]" (for 
out-of-band), then, "Another possibility for probe attribution, when the 
measurement allows for it, is to include a probe description URI in the 
payload [...]" (for in-band). Thoughts?

> 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.

[JI] We'll rephrase and add some text to clarify.

> 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.

[JI] Not without dynamic DNS or if you try to reach the (old) address 
directly (you might not check the probe attribution before the address 
changes). Do you think we should add something to clarify?

> 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.

[JI] Third parties do not have much recourse, unfortunately. This is why 
the security section mentions that you cannot fully trust the probe 
attribution (especially for in-band technique only). In the end, it's 
all about providing a way to identify probes. It might be fake, but I 
guess it's the tradeoff here. Any suggestion on how to clarify this part?

Thanks,
Justin

> 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”.
> 
> 
>