[OPSEC] Martin Duke's Discuss on draft-ietf-opsec-probe-attribution-08: (with DISCUSS and COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

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



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

(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'. 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?

(S4) Is this meant to be an exhaustive list of transports for the URI, or are
they examples?


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

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.