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

[Peter Yee]

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"  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
> 
> .
> 
> 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
> [RFC] 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”.
> 
> 
> 


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Justin Iurman]

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

.

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
[RFC] 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”.





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Justin Iurman]

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

.

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
[RFC] 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”.





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Peter Yee via Datatracker]

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

.

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
[RFC] 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”.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art