Skip to main content

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

Request Review of draft-ietf-ippm-stamp-option-tlv
Requested revision 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 "Footer" Foote , Adi Masputra , Ernesto Ruffini
I-D 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
Request Last Call review on draft-ietf-ippm-stamp-option-tlv by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 06 (document currently at 10)
Result Ready w/issues
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