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

Nico Williams <> Sun, 19 April 2015 23:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EF8811A0163 for <>; Sun, 19 Apr 2015 16:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aanZzgpAIt0m for <>; Sun, 19 Apr 2015 16:08:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 211901A0104 for <>; Sun, 19 Apr 2015 16:08:50 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id CED7C674058; Sun, 19 Apr 2015 16:08:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=wVN9t74O+I0z2l rj4f7G5qAPr2A=; b=jZwM3iNRzIE8PCrj2w3Ax8xxVqVmsixtZ58dqpc0bpl2uT 56hkmg9aPek/RcFxOoB6XtKC7KYVc85Zw6jN6CX4Mb1qHFQ8nVgXk+olZWQ47Tff IxQbrzpuc5RG1z+YcRCIO/zNkkOVTobmh6mIGzI0AD67iBKKOI7GmS0f94oW0=
Received: from localhost ( []) (Authenticated sender: by (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 <>
To: Sam Hartman <>
Message-ID: <20150419230843.GP13041@localhost>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Cc: "" <>, Kathleen Moriarty <>, RFC Errata System <>, "" <>
Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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'

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