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

2020-07-20 Thread Greg Mirsky 
Hi Dan and Ben,
the updated text is below. I greatly appreciate your feedback.

NEW TEXT:
A STAMP
   Session-Sender MAY generate a locally unique STAMP Session Identifier
   (SSID).  The SSID is a two-octet-long non-zero unsigned integer.
   SSID generation policy is implementation-specific.
   [I-D.gont-numeric-ids-generation] thoroughly analyzes common
   algorithms for identifier generation and their vulnerabilities.  For
   example, an implementation can use algorithms described in
   Section 7.1 of [I-D.gont-numeric-ids-generation].  An implementation
   MUST NOT assign the same identifier to different STAMP test sessions.

Regards,
Greg

On Mon, Jul 20, 2020 at 7:01 PM Greg Mirsky  wrote:
>
> 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  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  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  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
> > > >> > >
> > > >> > > .
> > > >> > >
> > > >> > > 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

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

2020-07-20 Thread Greg Mirsky 
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  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  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  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
> > >> > >
> > >> > > .
> > >> > >
> > >> > > 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

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

2020-07-20 Thread Benjamin Kaduk 
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  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  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
> >> > >
> >> > > .
> >> > >
> >> > > 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

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

2020-07-18 Thread Dan Romascanu 
Greg's understanding of my comment is correct.

Regards,

Dan


On Sat, Jul 18, 2020 at 2:56 AM Greg Mirsky  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  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
>> > >
>> > > .
>> > >
>> > > 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

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

2020-07-17 Thread Greg Mirsky 
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  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
> > >
> > > .
> > >
> > > 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

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

2020-07-17 Thread Benjamin Kaduk 
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
> >
> > .
> >
> > 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