Greg's understanding of my comment is correct. Regards,
Dan On Sat, Jul 18, 2020 at 2:56 AM Greg Mirsky <gregimir...@gmail.com> 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 <ka...@mit.edu> 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 < >> > nore...@ietf.org> 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 >> >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
