[ippm] Ben Campbell's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-ippm-6man-pdm-option-09: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive Comments:

- 1.4, 2nd to last paragraph: Please don't make assumptions about
organizational models; different organizations do it differently. Does
the motivation still make sense if the organization doesn't follow this
model?

- 1.5, first paragraph: "The purpose of the PDM is not to supplant all
the variables present
   in all other headers but to provide data which is not available or
   very difficult to get."
How is that different than for any other extension?

3.2.1, PSNTP definition:

What are the consequences if people "spoof and insert such
   packets."?

- 3.2.2: Are there really use cases for attosecond precision?

- 4.1, last paragraph: Can you provide guidance on selecting a reasonable
limit? At least a lower bound so that the limit does not negatively
impact the PDM function?

-4.2: 
Could PDM be used to (help) deduce the nature of the application, or
possibly network topology? The last paragraph says it will be unhelpful
in deducing content; I suspect otherwise. Section 4.4 talks about how it
might help timing attacks against key material.

Does PDM really offer no more information to an observer than they could
get by observing packet intervals of otherwise encrypted traffic? For
example, it seems like one could not differentiate between wire-time and
processing-time from observation alone.

-4.4, 2nd paragraph: Why does the attacker need to induce the host to
turn on PDM? What about cases where the host already uses PDM?

-- last paragraph:The text recommends that a user SHOULD consent. I think
you mean to say that user consent SHOULD be required. They mean very
different things.

But along those lines, do you expect the average user to make informed
consent decisions? At what scope should such decisions be made? Some OSs
ask a user if they are willing to share diagnostic info at a global
level. Does the guidance about using PDM on limited IP addresses or ports
suggest consent apply at a smaller granularity?

Editorial Comments:

-General: Much of the text reads more like a white paper than an IETF
standards-track RFC. This makes some sections seem like advertisements.
The heavy use of "we" calls into question whether it documents the
opinions of the WG, or the opinions of the authors. It also makes some
sections longer than they need to be (e.g. the discussions related to
time scaling factors read more like a classroom lecture than a
specification.) I recognize that fixing this would require a re-write. I
will leave it to the authors, chairs, and AD to decide if that is
worthwhile this late in the process.

- Abstract: Last sentence is long and convoluted. Please consider
breaking it up.

- 1.4, list of advantages: How is 5 different than 2?
-- 2nd paragraph after end of list: s/"to do"/"to"

- 3.2, 2nd paragraph: Please expand DTN

- 3.2, last paragraph:
The reference to Appendix A is worded in a way that suggests you have to
read that section to understand how to implement time scaling factors.
That led me to wonder why the appendix was not part of the body. But when
I read the appendix, I realized that it really was additional
explanation, and not a normative part of the process. Please consider
something like the following:

OLD:
For a full description of this process...
NEW:
For additional discussion about this process...

- 3.4.1, first paragraph: The MAY seems like a statement of fact, not a
normative requirement. (Same for 3.4.2)