Last Call Review of draft-ietf-ippm-stamp-option-tlv-06

Request Review of draft-ietf-ippm-stamp-option-tlv
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-07-06
Requested 2020-06-22
Authors Greg Mirsky, Xiao Min, Henrik Nydell, Richard Foote, Adi Masputra, Ernesto Ruffini
Draft last updated 2020-06-29
Completed reviews Secdir Last Call review of -06 by Charlie Kaufman (diff)
Genart Last Call review of -06 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu 
State Completed
Review review-ietf-ippm-stamp-option-tlv-06-genart-lc-romascanu-2020-06-29
Posted at
Reviewed rev. 06 (document currently at 10)
Review result Ready with Issues
Review completed: 2020-06-29


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


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