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. 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? Should such an example be implemented as site specific implicit mapping? Thoughts? I am happy with the document in all other respects. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
