[ippm] Re: Erik Kline's No Objection on draft-ietf-ippm-capacity-protocol-17: (with COMMENT)

[[e-mail]]

Hi Erik,

thanks for your review. Comments of the authors are marked [Authors] below. All changes suggested by the authors are applied to draft version -18, which is soon published. All, please note that there are changes pending to comments of Magnus and Brian (going to draft -19 or later).

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: Erik Kline via Datatracker <[e-mail]> 
Gesendet: Mittwoch, 28. Mai 2025 06:39
An: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Betreff: Erik Kline's No Objection on draft-ietf-ippm-capacity-protocol-17: (with COMMENT)

<snip>


### S4

* I think this document should say something about how the DF bit should be
  set (or unset) when IPv4 is in use.

  At first glance I would recommend saying that the DF bit SHOULD be set,
  but I'll leave that to the working group/community.

[Authors] end of 1st para S4, ADD
.... design and implementation. Unless IP fragmentation is expected and is one of the attributes being measured, the IPv4 DF bit SHOULD be set for all tests.


### S4.2.2

* The bar for this mode seems low enough that if it's kept in this document
  it ought to be possible to remove Mode 0 (S4.2.1) altogether.  This would
  allow the S4.5 Optional Checksum to be dropped as well, I think.

  I could see that SHA256 calculations at line rate for "low oomph" devices
  means that SHA256 for data mode (S4.2.3) should remain optional, but I
  don't see a reason to keep Mode 0 when every device should be able to do
  Mode 1 for just the control packets.

[Authors]
One reason for this is backward compatibility with older implementations. A second one is the potential lack of an adequate security library on some small communication controllers. The software has been ported to systems with old RISC processors and chipsets. We hope, that by making the unauthenticated mode optional AND requiring that it cannot be functional while the secure methods are also being utilized allows to still support both situations.

CHANGE (added "only"): This mode is only intended for a lab or limited domain [RFC8799] hosting very low-end devices lacking accurate clock synchronisation



## Nits  [Authors] Thanks, corrected.    ----------- End ----------------

### S3

* "are used exchangeable" ->
  "are used interchangeably" or "are exchangeable"

* "keeps the keep the pinhole (or mapping, resepcitvely)" ->
  "helps to keep the pinhole (or mapping, respectively)"