[Gen-art] Genart last call review of draft-ietf-ippm-stamp-option-tlv-06

[Dan Romascanu via Datatracker <[e-mail]>]

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