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

[Nico Williams <[e-mail]>]

On Mon, Apr 20, 2015 at 12:34:53PM -0400, Sam Hartman wrote:
> I agree that we should write applications assuming they will be fast.
> That's very different from non-blocking for reasons including the ones I
> already explained: network swap, demand paging over the net, database
> lookups for things like nss etc that you'd expect to be fast but
> sometimes aren't.

My take is this: if reading [what should be] a local configuration file
results in slow I/O, then all is lost when it comes to being
non-blocking.  The same applies to swapping.

So, if I ask for "fast" behavior, I should get "fast" behavior given the
constraints of the running environment.  E.g., bare metal with close-by
local storage all cached in memory anyways, vs. VM guests with
all-remote "local" storage.  Using standard, portable APIs, the
implementation can't tell if reading a "local" configuration file, or a
memory allocation of some non-trivial size, will be slow, but it also
doesn't have to.

> Basically, I don't think the IETF is in a position to say something is
> non-blocking because there are many reasonable implementations where
> that's simply impossible to implement.

We don't have to be too exact.

> We can talk about whether an application should be prepared for an API
> to take a while.

That's what my I-D does.

> I think that attributes listed in the return from inquire_name are
> things an application can assume will be relatively fast compared to
> ones not in inquire_name.

Yes, but consider an attribute prefix that demands "relatively fast"
service.  A mechanism must fail if it doesn't understand that prefix.
And if it does understand it, then it must fail if it can't satisfy the
requested constraint.

Nico
--