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 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
>