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

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