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

Alejandro Perez Mendez <alex@um.es> Mon, 20 April 2015 14:55 UTC

Return-Path: <alex@um.es>
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 58F401B2E26 for <kitten@ietfa.amsl.com>; Mon, 20 Apr 2015 07:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 4ndUlTzR3LkD for <kitten@ietfa.amsl.com>; Mon, 20 Apr 2015 07:55:48 -0700 (PDT)
Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id D64E91B2C1E for <kitten@ietf.org>; Mon, 20 Apr 2015 07:55:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 472EFD1A2 for <kitten@ietf.org>; Mon, 20 Apr 2015 16:55:46 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon24.um.es
Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2XQRM6SLR1qp for <kitten@ietf.org>; Mon, 20 Apr 2015 16:55:46 +0200 (CEST)
Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id 1EFA8CE51 for <kitten@ietf.org>; Mon, 20 Apr 2015 16:55:45 +0200 (CEST)
Message-ID: <55351371.70403@um.es>
Date: Mon, 20 Apr 2015 16:55:45 +0200
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: kitten@ietf.org
References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <tsl7ft7zx9f.fsf@mit.edu> <20150419230843.GP13041@localhost> <tsly4lmyl7i.fsf@mit.edu>
In-Reply-To: <tsly4lmyl7i.fsf@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/RC8QE0-qtjrmpC52_u4NcMheo6A>
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: Mon, 20 Apr 2015 14:55:50 -0000


El 20/04/15 a las 15:37, Sam Hartman escribió:
>>>>>> "Nico" == Nico Williams <nico@cryptonector.com> writes:
>      Nico> 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.
>
>      Nico> I did think about it, though I don't recall specific
>      Nico> on-the-list discussions about it, I'm certain I discussed it
>      Nico> with someone.  In particular I had wanted to consider
>      Nico> UID/GID/SID lookups.  My intention was roughly as per-Ben's
>      Nico> proposed text.
>
> Well, I agree that we did think that things might block.
> I am less clear that we thought about anything specific that wouldn't
> block, and I'm concerned introducing this text implies there are things
> that don't block.

I agree with Sam's view. How can we assure that something doesn't block 
on a pending network interactions? Is a DNS query a pending network 
interaction? Or retrieving a DTD for XML validation? Or querying a SQL 
database using a connection to localhost. In principle, we could assume 
that any call to the "open/read/write" functions are potentially blocking.

 From my point of view, since the GSS is an API, one might assume the 
caller should not be aware of how each specific call is actually 
implemented. What's the purpose of knowing that something does not 
block? If the purpose is avoiding the caller to wait too much (or even 
forever) for a result, probably the best option would be to allow 
specifying some sort of timeout after which the caller will either 
receive a valid result, or obtain an ERROR (e.g. GSS_C_CALL_TIMEOUT).

Regards,
Alejandro

> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten