Re: slot attributes & last call

Nico Williams <nico@cryptonector.com> Thu, 18 December 2014 16:11 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09A31A8AD4; Thu, 18 Dec 2014 08:11:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 T7coqlhk8B84; Thu, 18 Dec 2014 08:11:01 -0800 (PST)
Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF181A8A98; Thu, 18 Dec 2014 08:11:00 -0800 (PST)
Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 5A93220047B8A; Thu, 18 Dec 2014 08:11:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=tW8MWxr4rpHEyS tHDL97ZMknDvM=; b=I2P/cMXyEcSXpQ7qTp4LHqSQ1LpWQoAvvtSHqQPDGDgyCK foeLEzASGS8DuwaDMF8CooLmHgK3Y86YcERo5P8b92CmDkq/rqzyfagV3I98HtC7 AEUoTxqlTBL3UQhWXvMbE6XbaDh6ckwAffF2+yqdmRF0yfLmpgk0mIcPeVc3w=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id BAE7320047B89; Thu, 18 Dec 2014 08:10:59 -0800 (PST)
Date: Thu, 18 Dec 2014 10:10:59 -0600
From: Nico Williams <nico@cryptonector.com>
To: Darren J Moffat <Darren.Moffat@Oracle.COM>
Subject: Re: slot attributes & last call
Message-ID: <20141218161054.GQ9443@localhost>
References: <alpine.GSO.2.00.1412161359100.4549@keflavik> <CAB6OCMvGxT99cGGBSBbz=XU2+F1xRzBa97z6dY-qPSJk1GWXyQ@mail.gmail.com> <20141217230150.GB9443@localhost> <CAB6OCMvkPSfNYqftAgbcN5KrG7kxb5ooico205O6EffcsU8SwQ@mail.gmail.com> <20141218000736.GL9443@localhost> <alpine.GSO.2.00.1412171614240.4549@keflavik> <5492B8E1.6010709@Oracle.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5492B8E1.6010709@Oracle.COM>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/RLkbtpEXVWdtgAmra1S2TzcgwQc
Cc: Stef Walter <stef@thewalter.net>, Jaroslav Imrich <jaroslav.imrich@gmail.com>, ietf@ietf.org, saag@ietf.org, Jan Pechanec <jan.pechanec@Oracle.COM>, Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Dec 2014 16:11:03 -0000

On Thu, Dec 18, 2014 at 11:22:09AM +0000, Darren J Moffat wrote:
> On 12/18/14 00:15, Jan Pechanec wrote:
> >	for example, metaslot on Solaris is always 0 so slot-id=0
> >would be reliable there to use to access the soft token.  Jan.
> 
> It is the zeroth slot in the list of slots not a slotid with a value
> of 0 - the distinction is subtle.

But it still works to speak of the nth slot.  Perhaps the attrbite
should be called 'slot', without the '-id', 'slot-list-offset' perhaps.

> I don't think we should have slot-id, it isn't stable and I know
> that some vendors use random values.

But there's still a list with a zeroth element.  The list could be
returned in different order every time, but that would just make this
attribute useless (and so unused) with such a provider, but not harmful.

Perhaps we should say that this attribute should always be used in
conjunction with the provider library attributes, to ensure that this
attribute has the desired semantics.  I.e., unless coupled to a library
that gives it semantics, this attribute has none.

Nico
--