[ippm] Intdir telechat review of draft-ietf-ippm-stamp-on-lag-05

[Antoine Fressancourt via Datatracker <[e-mail]>]

Reviewer: Antoine Fressancourt
Review result: Ready with Issues

I am an assigned INT directorate reviewer for
draft-ietf-ippm-stamp-on-lag-05.txt. These comments were written primarily for
the benefit of the Internet Area Directors. Document editors and shepherd(s)
should treat these comments just like they would treat comments from any other
IETF contributors and resolve them along with any other Last Call comments that
have been received. For more details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as
DISCUSS.

* I have the following DISCUSS/ABSTAIN level issues:

** In Section 3.2, the behavior of the Session-Sender and of the
Session-Reflector regarding the value of the Reflector Micro-session ID field
is problematic. Indeed, the 3rd paragraph of Section 3.2 states that the
Session-Sender MUST set the Reflector Micro-session ID field if he knows it, or
set it to ZERO otherwise. Yet, the conditions in which this field is supposed
to be known are unclear, and the last sentence of the paragraph states that how
the Reflector is supposed to know this ID is outside the document's scope. As a
potential implementer of this protocol, I find this description puzzling, and
let me wonder when the Session-Reflector is supposed to know this ID. The 5th
paragraph of Section 3.2 mentions that the Session-Reflector MUST check the
value of the Reflector Micro-session ID if it is not set to ZERO, but is rather
unclear about what is the benefits one can take out of this verification. This
use and management of the Reflector Micro-session ID is even more confusing
when reading the last sentence of Section 3.2 which mentions that any procedure
with regards to the Micro-session ID is stateless.

The document should either mention the benefit that can be taken from having
the Session-Sender set the proper value for the Reflector Micro-session ID and
give some more details about how and when the Session-Sender are supposed to
learn about this ID, or be more relaxed with regards to the value of this
field. Besides, given that, to the best of my knowledge, RFC 8972 does not give
any constraint about the length of STAMP optionnal TLVs (even if the examples
given in RFC 8972 are all aligned to 4 bytes...), I wonder what is the benefit
from keeping the Reflector Micro-session ID in the TLV, so the overall
Micro-session ID TLV could be 6 bytes long.

* The following are other issues I found with this document that SHOULD be
corrected before publication:

** In Section 2, in the 4th paragraph, it is stated that "each micro STAMP
session MUST be assigned with a unique SSID", yet, if I read correctly, in RFC
8972 this MUST is a MAY (3rd paragraph in Section 3 of RFC 8972: "A STAMP
Session-Sender MAY generate a locally unique STAMP session Identifier
(SSID)."). This should be either harmonized or, if there is a reason for
requiring a MUST here, it should be clearly stated.

* The following are minor issues (typos, misspelling, minor text improvements)
with the document:

** In Section 1, the document should include a clear reference to OWAMP and
TWAMP to help the reader refer to the document describing those protocols.