The consensus call time period has ended. We have 10 responses with
ready to proceed. But Andrew Deason has brought up one issue
on "Implicit fallback mapping".

Jeffrey Altman has asked about "wildcards patterns in mappings".

The "Implicit fallback mapping" might be easily resolved with a few
words added to the document, and we could proceed with adoption.

The "wildcards patterns in mappings" might need a lot more, discussion,
as I personally can think of these side issue:

 How are wildcards defined? regex? simple "*"?

 In Jeff's example, user/cron/*...@realm would map to u...@realm
 and looks Kerberos specific. How would names from different GSS mechs
 work with patterns? What if the GSS name can contain one of the pattern
 matching characters?

 At sites that to have separate u...@realm and user/cron/hostn...@realm
 principals, do they really want this mapping? Or do users limit access
 from selected hosts using AFS groups and ACLs. I could see some of my crons
 being able to write to selected directories based on the hostname, but not
 touch my dot files.

So I would like to ask Andrew and Jeff in particular if they feel that we
need to add these items to the document?



On 12/16/2010 9:10 PM, Jeffrey Altman 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.

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


--

 Douglas E. Engert  <[email protected]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization

Reply via email to