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

[Kathleen Moriarty <[e-mail]>]

As Sam said, we can put a note in it and can edit the text of the proposed errata.  Tell us what this changes are and either Stephen or I will update and mark the errata.

Thanks,
Kathleen 

Sent from my iPhone

> On Apr 20, 2015, at 7:36 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Mon, 20 Apr 2015, Sam Hartman wrote:
> 
>>>>>>> "Nico" == Nico Williams <[e-mail]> writes:
>> 
>>    Nico> On Mon, Apr 20, 2015 at 09:37:37AM -0400, Sam Hartman wrote:
>>>> 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.
>> 
>>    Nico> I always thought that attributes listed in GSS_Inquire_name()
>>    Nico> wouldn't block: because they are would be "raw" things in
>>    Nico> Kerberos authorization-data or similar.
>> 
>> 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.
> 
> I do not disagree.
> 
> I used the term "block" in the erratum submission because that is the
> terminology used in RFC 2743, and the erratum should be consistent with
> the current base spec.
> 
>> 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 can talk about whether an application should be prepared for an API
>> to take a while.
> 
> That's probably a better set of language to use, yes.  We should keep it
> in mind when we pick up a 6680bis or 2743bis.
> 
> -Ben