--On Thursday, December 16, 2010 10:10:01 PM -0500 Jeffrey Altman
<[email protected]> wrote:
On 12/16/2010 5:05 PM, Andrew Deason wrote:
On Tue, 07 Dec 2010 13:07:29 -0600
"Douglas E. Engert" <[email protected]> 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/hostn...@realm principals?
Or should we permit a wildcard pattern mapping user/cron/*...@realm ->
u...@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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
