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

Jeffrey Altman jaltman@your-file-system.com
Thu, 16 Dec 2010 22:10:01 -0500


This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig44A9D00D2F6A44C6FF49F9F5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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:
>=20
>> We have a request to proceed with a call for consensus on:
>>
>> http://tools.ietf.org/html/draft-brashear-afs3-pts-extended-names-07
>=20
> 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:
>=20
> 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 discus=
s
> what the implicit mappings may be, right?=20

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/hostname@REALM principals?

Or should we permit a wildcard pattern mapping user/cron/*@REALM ->
user@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


--------------enig44A9D00D2F6A44C6FF49F9F5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQIcBAEBAgAGBQJNCtSLAAoJEPd6c1WStpoEpkYP/238Guvo7gaFRXgJWWoi15vh
VyfypYZEWyGPo5dP2YLspTJydHqomzteOB+3Ci/fEX50l6SUWgDESM7Z2YW0ogDv
pSjiD78uMWZRT1gXFADGRL0KL5TEQo98f4dQBbEd1WZDWWfHTY5mwlA0esPWMyLd
gRsRzlaC628584ZYWbqRRuDaPFFFKZLPUJ1fbEdBJucm1621coCNzmVUR5w+3xlf
gU6KSseciqavyGr/qCBuxKXjMNUFYWMEWEX4AmBBzZjbPRHdnWSTJ1l/rj1DiMRK
ORQ+TcvFH9BvW6cvwJX3aORuIN0ZhJteqIoMjas0Mv81px625p19sfTZPLgHY2XC
1L7ar+LlU7OhnntpRgagD7BhDmU1yUf9Vj69HGI/bZYE+ylVD7JrIjjzqZ1ei26A
b3en1PHxf4Weq2TqSHJNY24sZJ6/4Kt51RhZNZobkA0RRTR/gRvdhYGTZ67nBoE/
0SRo5/ETJ7Z0bJ/8pUTfRI1+PhavCTng3B+qVFJKErXgf4OGWeLGC8n1Ozn4YAmY
0RbKlDmsnGFXVgRRP/Vy+EZEnet6lcor6hIvgjnKiL1580Lj6ZW2NoYG8G/6tIy4
F6IBA148vy7xl1M+FiPkRJSo6F27XbL8dSNVTv7zu/cN2+Y1Kd5vWN/33Vft/FY9
rUPvan4f9D+WP9hhznf7
=uQ4e
-----END PGP SIGNATURE-----

--------------enig44A9D00D2F6A44C6FF49F9F5--