On 8/24/2010 2:02 PM, Derrick Brashear wrote: > I have again revised this draft based on feedback, and -03 is available. > > https://datatracker.ietf.org/doc/draft-brashear-afs3-pts-extended-names/ > > I declined to abridge the explanatory text regarding AFS history at > this time, as there is no suitable work to refer to at this time. > > Aside from that, I know of one outstanding issue, which in addition to > any comment I would like to explicitly seek feedback on. > > One commenter (who I will allow to out themselves if they wish) says: > "I'm still uneasy about requiring the rewriting of GSSAPI-obtained > Kerberos names to use the Kerberos name type. If we believe that > GSSAPI is the future, then I would prefer that we use the GSSAPI > exported name for all GSSAPI mechanisms, rather than special casing > Kerberos. > > If I am building a hypothetical AFS product which only supports > GSSAPI, I'm not sure why I should be forced to have my server convert > from GSSAPI to Kerberos v5 names, when I actually have no interest at > all in the Kerberos v5 name. > > I think a better approach would be to require ptservers in cells which > support multiple implementations of the same underlying security > mechanism to perform the mapping. So, if you have a cell which > supports both native Kerberos v5, and GSSAPI, then the ptserver should > be responsible for mapping from the GSSAPI name to the Kerberos v5 > one, and vice versa." > > As long as we have chosen a single consistent mechanism for > representing Kerberos 5 names there should not be an issue, and this > proposal does so; As such I would be willing to incorporate it if > consensus is behind it.
I support this change. It is after all the PTS servers responsibility to understand whether two names refer to the same PTS ID. If the PTS server wants to treat all existing Kerberos v4 names as automatically having synonyms that are Kerberos v5 and GSS-KRB5 name forms, that is an implementation detail. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
