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

[Benjamin Kaduk <[e-mail]>]

On Sun, 19 Apr 2015, Nico Williams wrote:

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

It sounds like the main objection to the current proposed erratum text is
in the COMMENT, "Calls which are not explicitly permitted to block are
assumed to be not permitted to block."  Though the new text which
explicitly calls out the attrs output of GSS_Inquire_name() does still
have some implicit implications that some calls do not block, as well.

I am not tied to the comment text; we could remove it and still have an
erratum which stands on its own.  It is a bit harder to excise the
implicit implication from the new text.

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

These both are getting to seem like fairly substantial changes which do
not seem appropriate for an erratum, to me.  It's also unclear that the WG
has sufficient energy to do a full 6680bis right now.

I will also note that we can choose to mark the current (small) 6680
erratum as Verified or Hold for Document Update, if we want to accept it;
the latter may be more appropriate given Sam's concerns.

-Ben