Hello Martin, Thanks for your review of this informational draft.
Please find below some replies to your points, look for EV> If required, then Justin will follow up with a revised I-D. Regards -éric On 10/07/2023, 18:52, "Martin Duke via Datatracker" <[email protected] <mailto:[email protected]>> wrote: Martin Duke has entered the following ballot position for draft-ietf-opsec-probe-attribution-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-probe-attribution/ <https://datatracker.ietf.org/doc/draft-ietf-opsec-probe-attribution/> ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Is this meant to be an interoperable design or not? Sections of this document propose "some techniques" which might inform a future protocol design, while others are very specific about terminating bytes and so on. Some of these objections might not apply depending on the answer. EV> I would not qualify this as interoperable as there is a human being in the loop: the security/forensic analyst that will act on the in-band or out-of-band probe attribution. EV> I.e., there is no automatic replies required by a device receiving or forwarding probe packets *beyond* the already specified behavior, e.g., RFC 4443 for ICMP ECHO_REQUEST. We tried to be clear on this based on previous directorate reviews but it seems that we are still unclear. (S2.2) RFC9116 defines the "Canonical" field as "the canonical URIs where the 'security.txt' file is located, which is usually something like 'https://example.com/.well-known/security.txt' <https://example.com/.well-known/security.txt'>. Obviously you do not mean that this field should be the location of that file! But maybe you mean the "probing.txt" file instead, as that is the well-known name. But then the example has "measurement.txt"? Is this an intentional difference, or the result of an incomplete revision? EV> We simply wanted to re-use the syntax of RFC 9116 EV> and nothing in RFC 9116 says that the actual filename must be security.txt EV> hence, in our example, we use "measurement.txt" on purpose (S4) Is this meant to be an exhaustive list of transports for the URI, or are they examples? EV> unsure whether it should rather be a comment ;-) but you are correct: these are examples (and we should accordingly update the draft). Thanks. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Magnus Westerlund for the TSVART review. I note that Magnus's last message in the thread makes some good (non-DISCUSS) points that do not have a public reply. EV> I think we did our best to reply to all points (of course, sometimes with a disagreement). Sorry if we skip a reply or two. I wonder if it would be better for the UDP and TCP versions to use an option, instead of just putting it in the payload. EV> Using TCP or UDP options (especially the latter IMHO) could actually bias the measurement itself. But, this is debatable of course. _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
