Reviewer: Dan Romascanu Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ippm-stamp-option-tlv-06 Reviewer: Dan Romascanu Review Date: 2020-06-29 IETF LC End Date: 2020-07-06 IESG Telechat date: Not scheduled for a telechat Summary: Ready with issues This is a clear, well-written document. There are a few minor issues that would benefit from clarifications and possible edits before approval. Major issues: Minor issues: 1. Section 3. Is there any recommended strategy to generate SSIDs? Are these supposed to be generated sequentially? Randomly? How soon is the 16 -bit space supposed to wrap-up? Some clarification would be useful I believe. 2. Section 4.5 - how is the value Session-Sender Tx counter (S_TxC) determined by the sender? 3. Section 4.5 - (R_RxC) and (R_TxC) MUST be zeroed by the Session-Sender - Is this verified at reception? What happens if a Session-Reflector detects a non-zero value in one of these fields? 4. Section 4.6 - it seems that understanding [TS23501] is needed to properly implement this section and interpret the content of the TLV. Should not this reference be Normative rather than Informative? 5. Section 5.2 - as the values for Synchronization Sources in Table 4 refer to 'this document', it seems to be necessary to include in this document references to the documents that define the respective terms / sources 6. Section 6 - Security Considerations: Is not sending of test packets to a reflector that does not support SSID a potential sourse for DoS attacks? Same question about sending packets with unsupported TLV types. How do Reflectors protect against such situations? As such attacks would be beyond STAMP base specifications, it may be good to discuss these. Nits/editorial comments: 1. Section 2.1 - it's more convenient for future users of the document if acronyms were listed in alphabetical order 2. Sections 4.6, 4.7 - inconsistent use of capitalization: Reserved - ... must be zeroed on transmission and ignored on receipt. It's a 'must' in 4.6, and a 'MUST' in 4.7 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
