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

Benjamin Kaduk <kaduk@mit.edu> Tue, 21 July 2020 01:48 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00E83A128F; Mon, 20 Jul 2020 18:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Few9_wxTubzV; Mon, 20 Jul 2020 18:48:15 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596D23A128C; Mon, 20 Jul 2020 18:48:15 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06L1m9pS019404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jul 2020 21:48:12 -0400
Date: Mon, 20 Jul 2020 18:48:09 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Dan Romascanu <dromasca@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>
Cc: last-call@ietf.org, gen-art <gen-art@ietf.org>, draft-ietf-ippm-stamp-option-tlv.all@ietf.org, IETF IPPM WG <ippm@ietf.org>
Message-ID: <20200721014809.GA41010@kduck.mit.edu>
References: <159344297273.15718.9292174200591066435@ietfa.amsl.com> <CA+RyBmVjSezyTs=r4zL4OjzzK5eG1SMZHLs+5NoNhwniZYx18w@mail.gmail.com> <20200717223913.GD41010@kduck.mit.edu> <CA+RyBmWhCOzuCYBDPeyywjaiR-vsvRQavBVo7xzYEOEgdBvnZQ@mail.gmail.com> <CAFgnS4Ub0jyp2RL8UOZvWNGAgEZpGpgM2KwZLqP=RjUGo81epw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAFgnS4Ub0jyp2RL8UOZvWNGAgEZpGpgM2KwZLqP=RjUGo81epw@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/N5CL6FyXaC2MmxK_L03B01pY0w0>
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-ippm-stamp-option-tlv-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2020 01:48:17 -0000

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@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 <kaduk@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 <
> >> > noreply@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
> >>
> >