Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-ippm-stamp-option-tlv-06

[Greg Mirsky <[e-mail]>]

Hi Ben,
thank you for the suggestions. Would the Informational reference to
draft-gont-numeric-ids-generation be reasonable?

Regards,
Greg

On Mon, Jul 20, 2020 at 6:48 PM Benjamin Kaduk <[e-mail]> wrote:
>
> 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 <[e-mail]> 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 <[e-mail]> 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 <
> > >> > [e-mail]> 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
> > >>
> > >