Re: [kitten] [Technical Errata Reported] RFC6680 (4337)

Nico Williams <nico@cryptonector.com> Sun, 19 April 2015 23:08 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8811A0163 for <kitten@ietfa.amsl.com>; Sun, 19 Apr 2015 16:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 aanZzgpAIt0m for <kitten@ietfa.amsl.com>; Sun, 19 Apr 2015 16:08:50 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 211901A0104 for <kitten@ietf.org>; Sun, 19 Apr 2015 16:08:50 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id CED7C674058; Sun, 19 Apr 2015 16:08:49 -0700 (PDT)
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=wVN9t74O+I0z2l rj4f7G5qAPr2A=; b=jZwM3iNRzIE8PCrj2w3Ax8xxVqVmsixtZ58dqpc0bpl2uT 56hkmg9aPek/RcFxOoB6XtKC7KYVc85Zw6jN6CX4Mb1qHFQ8nVgXk+olZWQ47Tff IxQbrzpuc5RG1z+YcRCIO/zNkkOVTobmh6mIGzI0AD67iBKKOI7GmS0f94oW0=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id 115F8674057; Sun, 19 Apr 2015 16:08:48 -0700 (PDT)
Date: Sun, 19 Apr 2015 18:08:48 -0500
From: Nico Williams <nico@cryptonector.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Message-ID: <20150419230843.GP13041@localhost>
References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <tsl7ft7zx9f.fsf@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <tsl7ft7zx9f.fsf@mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/cODutzo175pxzT0CXDRiZPZuFqc>
Cc: "kitten@ietf.org" <kitten@ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, RFC Errata System <rfc-editor@rfc-editor.org>, "leifj@sunet.se" <leifj@sunet.se>
Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Apr 2015 23:08:51 -0000

On Sun, Apr 19, 2015 at 04:19:40PM -0400, Sam Hartman wrote:
> I really don't think we considered blocking when developing 6680.
> I think this is something that if we're going to discuss we need a full
> IETF consensus to say.

I did think about it, though I don't recall specific on-the-list
discussions about it, I'm certain I discussed it with someone.  In
particular I had wanted to consider UID/GID/SID lookups.  My intention
was roughly as per-Ben's proposed text.

> I think that the proposed text would be a good starting point, for this
> API.
> My concern is that other APIs in the document might block, and that I
> think that a WG such as kitten should fully consider the issue rather
> than using the erata process for this issue.

I object neither to the erratum, nor to an update.  I think this erratum
is sufficient for now, and we can work on an update to specify blocking
behavior in more detail.

We could update the erratum to add a list of what should be
non-controversial non-blocking behaviors:

 - GSS_Inquire_name() (of course, otherwise Ben's text doesn't work)
 - GSS_Get_name_attribute() for attributes listed by GSS_Inquire_name()
 - GSS_Export_name_composite()
   (and any call to GSS_Import_name() to import an exported composite
   name token)

We might also want to say that specific attributes not listed by
GSS_Inquire_name() may yield blocking or non-blocking behavior in
GSS_Get/Set_name_attribute() according to the attributes'
specifications.

> I'll note that we cannot really say that a call never blocks.  An
> implementation may have network swap or executable segments that are
> demand page over a network filesystem.  An implementation may use
> nsswitch resources that consult network databases, etc.
> The best we can say is that it's reasonable to write applications
> assuming certain APIs do not generally block.

Yes.  Defining "non-blocking" and "blocking" is non-trivial.  What kinds
of I/O are slow (network) or fast (per-Unix: file I/O is fast)?  Does a
long-running CPU-bound computation count as blocking?

Nico
--