Hi again Greg :) Reading Dan's review reminded me of one other point (inline)... On Thu, Jul 02, 2020 at 12:22:04PM -0700, Greg Mirsky wrote: > Hi Dan, > thank you for your review, detailed questions, and helpful suggestions. > Please find my answers and notes below tagged GIM>>. > > Regards, > Greg > > On Mon, Jun 29, 2020 at 8:02 AM Dan Romascanu via Datatracker < > noreply@xxxxxxxx> wrote: > > > 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. > > > GIM>> Because test sessions, in general, will be performed for different > periods of time, implementation will need to manage the pool of available > identifiers. I agree, the initial allocation may use sequential ascending > increment by one method, but at some point, it will be > "get-the-next-available number". I propose to update the text as follows: > OLD TEXT: > A STAMP > Session-Sender MAY generate a locally unique STAMP Session Identifier > (SSID). SSID is two octets long non-zero unsigned integer. > NEW TEXT: > A STAMP > Session-Sender MAY generate a locally unique STAMP Session Identifier > (SSID). SSID is two octets long non-zero unsigned integer. SSID > generation > policy is implementation-specific. For example, sequentially ascending > incremented by one method could be used for the initial allocation of > SSID. > Because of test sessions lasting different time an implementation that > uses > SSID MUST monitor the pool of available identifiers. An implementation > SHOULD NOT assign the same identifier to different STAMP test sessions. I would actually recommend against mentioning the "sequential increment" strategy. There's some justification for why in draft-gont-numeric-ids-sec-considerations (and more in the references), which I just completed my AD Evaluation of with intent to AD sponsor as a BCP. Thanks, Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
