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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
