Thanks Dan. Greg, my recommendation would be to refer to the appopriate section of https://tools.ietf.org/html/draft-gont-numeric-ids-generation-03 for the needs in question. My understanding is that STAMP needs only unique (not ordered) session IDs, and that furthermore, an occasional accidental collision would not be catastrophic, in which case we can use the "Uniqueness (soft failure)" characterization of Section 7.1 of the linked document. -Ben On Sat, Jul 18, 2020 at 09:37:08AM +0300, Dan Romascanu wrote: > Greg's understanding of my comment is correct. > > Regards, > > Dan > > > On Sat, Jul 18, 2020 at 2:56 AM Greg Mirsky <gregimirsky@xxxxxxxxx> wrote: > > > Hi Ben, > > thank you for the reference, very helpful. As you've noticed, this method > > mentioned as an example. Would you suggest referencing another technique? > > As I understood, Dan's comment was not specific to the sequential increment > > allocation policy but to provide some guidance to an implementor. > > > > Regards, > > Greg > > > > On Fri, Jul 17, 2020 at 3:39 PM Benjamin Kaduk <kaduk@xxxxxxx> wrote: > > > >> 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
