[AFS3-std] Re: A call for consensus on draft-brashear-afs3-pts-extended-names-07

[Jeffrey Hutzelman]

--On Thursday, December 16, 2010 10:10:01 PM -0500 Jeffrey Altman 
<jaltman@your-file-system.com> wrote:

> On 12/16/2010 5:05 PM, Andrew Deason wrote:
>> On Tue, 07 Dec 2010 13:07:29 -0600
>> "Douglas E. Engert" <deengert@anl.gov> wrote:
>>
>>> We have a request to proceed with a call for consensus on:
>>>
>>> http://tools.ietf.org/html/draft-brashear-afs3-pts-extended-names-07
>>
>> I really _really_ don't want to hold this up at the 11th hour, and I
>> think this is deserving of consensus, but if one little thing could be
>> clarified for me:
>>
>> I do not think we discuss anywhere the 'implicit fallback mappings'
>> referred to in 7.4.2. AuthNameToIDFallback. I take it this is something
>> we are regarding as implementation-defined and we do not need to discuss
>> what the implicit mappings may be, right?
>
> The implicit mappings referred to are those similar to hard coded
> principal conversions found in the OpenAFS src/rxkad/ticket5.c.  I agree
> that additional text defining "implicit mapping" vs "explicit mapping"
> would be useful with the definition of "implicit mapping" stating that
> it is implementation specific.

In fact it's not just implementation-specific, but at least potentially a 
matter of policy.  In fact, I was sort of hoping that implementations would 
(eventually) provide a plugin mechanism so that as a site admin, I can 
provide code that implements the mappings I want.

> On a separate topic, should this specification support wildcard
> patterns.  For example, if an organization has separate user principals
> for per host cron jobs that are meant to have access to AFS as the user,
> should the organization be forced to AddAuthName for all valid
> user/cron/hostname@REALM principals?
>
> Or should we permit a wildcard pattern mapping user/cron/*@REALM ->
> user@REALM?

It might be useful to add such a facility in the future, but I don't think 
we should try to do so at this time.  Wildcard mapping raises a number of 
questions, such as the behavior when multiple patterns match.  It's also 
not trivial to implement and may have considerable performance 
implications, which means it probably shouldn't be mandatory.  However, if 
we define this but don't make it mandatory, then there are potential 
interop and user-expectation issues which, while manageable, will require 
additional protocol design work.

At present, I think the "implicit mapping" language provides more than 
enough rope for servers to do wildcard mapping where site admins need that 
and have thought about how it should behave (plus, an admin-maintained 
flat-file list of mappings could have an ordering rule which resolves the 
multiple-match ambiguity more easily).  Let's not let the "perfect" be the 
enemy of the good.

-- Jeff