On 2 Jan 2013, at 22:17, Benjamin Kaduk wrote: > Further discussion with Jeff convinced me that we should not try to > standardize RPC-specific error codes, and instead use com_err tables for > everything. This makes us have RXGK-specific codes instead of RPC-specific > codes, which is probably a good thing, and also lets application error codes > come in naturally without a separate reserved block. The com_err table is > pretty easy to extend, so it doesn't have to be perfect or comprehensive > right away. Commits > 3d56ed GSSNegotiate policy errors are com_err > 7a9155e CombineTokens errors are com_err errors > on https://github.com/kaduk/openafs/commits/prot make these changes for the > language of the CombineTokens and GSSNegotiate RPCs, moving the list of error > codes to an AFS-3 Registry Concerns section at the end. Thanks to Simon for > pulling up YFS's error table.
e3d56ed22fcbd08200033192b87ed04f6cb96e64 adds the reference to com_err codes, but doesn't add any reference explaining what com_err is - I think we need something here - hopefully there's an easy reference we can steal? 7a9155e373320bfce4f3f1e87807fa11c7520b78 adds a number of error codes - I'd like to have a discussion in more detail about these, including the situations that they might be seen in the wild. I don't think the short descriptions provide enough detail for two implementations to be sure that they will use the same errors in the same situations. Also, neither of these address Jeff's concern about why we're bothering with having an 'errorcode' field in ClientInfo, rather than using the RX abort code. If we're going to specify errors in detail, we need to provide guidance about when negotiation errors should be sent in an abort packet, and when sending them within ClientInfo makes sense. Cheers, Simon. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
