[03:05:30] 2.6Gbit/sec [04:01:56] 2.8Gbit/sec [05:10:13] --- mvitale has become available [06:36:01] --- meffie has become available [06:38:49] --- meffie has left [06:44:22] --- meffie has become available [06:54:20] --- deason has become available [07:05:39] --- Simon Wilkinson has left [07:36:00] --- kula has left [07:36:17] --- kula has become available [07:50:57] --- dev-zero@jabber.org has become available [07:51:03] --- dev-zero@jabber.org has left: offline [07:54:55] --- Simon Wilkinson has become available [07:58:54] --- jakllsch has become available [09:56:16] --- meffie has left [09:57:39] --- meffie has become available [11:33:42] --- meffie has left [11:50:19] --- mmeffie has become available [11:50:36] --- mmeffie has left [11:50:37] --- mmeffie has become available [12:00:35] --- mmeffie has left [12:05:30] --- meffie has become available [12:47:58] --- kula has left [12:48:23] --- kula has become available [13:24:31] --- jakllsch has left [13:38:43] --- kula has left [13:39:30] --- kula has become available [13:44:36] Simon: did you want discussion on the new error codes to be on the list, or in the document? [13:45:03] On the list, I think. [13:45:14] Okay. [13:45:39] Ken Raeburn has a paper on com_err that I'm linking to, which I found in ... Greg Hudson's thesis. [13:45:46] My feeling is that if we're going to define different error codes, rather than just a generic RXGK_FUBAR, then they need to be detailed sufficiently well that two implementations will use the same error code for the same condition. [13:46:14] That seems wise. I'll send mail. [13:46:50] I'm impressed about the com_err reference - I took a quick look and drew a blank. [13:47:13] Do the Kerberos RFCs just give numbers, without explaining their derivation? [13:48:31] The first place I checked for potential com_err references was kerberos RFCs. I didn't search the body text for where the numbers are described, though. [13:50:39] Kerberos doesn't use com_err codes on the wire. Its defines errors with 0 being no error and 1..76 assigned to various errors. The use of com_err values is an API choice. [13:57:32] From MIT's krb5_err.et: # The Kerberos v5 library error code table. # Protocol error codes are ERROR_TABLE_BASE_krb5 + the protocol error # code number; other error codes start at ERROR_TABLE_BASE_krb5 + 128. [13:58:41] That does sound familiar. [14:08:42] RFC4120 does not provide a good description of the conditions under which error codes will be sent or how they should be interpreted by the receiver. It would be useful if the assumptions that trigger an error would be documented along with the actions that the receiver is expected to perform or may perform. [14:10:21] By "documented", do you mean "in the document"? [14:10:30] yes [14:10:42] In general, the actions a receive may perform are "give up" [14:11:52] "give up rxgk?" or "give up establishing a connection at all?" [14:12:11] They're equivalent. [14:14:36] I don't think that the AFS-3 registry concerns section is necessarily the right place for an extended discourse on what error codes should be used when. [14:15:50] It either includes the description or states for each entry in the registry where the definition of the error can be found. [14:15:54] Agreed. The rest of the document can detail what the error codes mean - the registry section just needs ry.to form a base for the regist [14:16:47] jhutz mentions on zephyr that we need to pick a base and assign numbers. I guess that's the standard algorithm on "RXGK"? [14:18:38] That would seem reasonable. [14:27:19] I believe it would be good to ensure that there are separate error code spaces associated with wire protocol errors and other internal api errors. one of the problems that mit's krb5 implementation suffers from is that it maps the wire protocol errors into the same error code space as the internal api errors. Not that I expect rxgk to have as many error codes as krb5 but no one thought that krb5 would approach 127 errors back in the RFC 1510 days. [14:28:42] If RXGK will represent the wire protocol error space, a separate prefix could be selected for the non-wire error space. [14:29:40] That seems relatively natural. [14:31:46] I'm pointing it out because RXKAD errors and krb5 errors conflate wire and non-wire errors. It would be good to avoid it here. Then the implementation can assert that non-wire error codes should not be placed on the wire. Something that is not easy to do today. [14:32:15] Relatively natural to us a prefix other than RXGK for non-wire stuff, that is. [14:51:20] --- mvitale has left [15:34:24] Oh huh. PAGs aren’t working at all on Linux 3.7 with OpenAFS 1.6.1 plus minimal patches. I guess I should try 1.6.2pre2. [15:38:51] Yes - if it is a problem, would be good to know before 1.6.2 final [15:39:18] I assume your kernel is built with keyring support? [15:40:16] Yeah, it’s Ubuntu raring’s generic amd64 kernel. I even see the keyrings change in ‘keyctl show’ in different PAGs, but tokens seem to be shared across all PAGs anyway. [15:40:52] Wierd. I wonder what broke. [15:41:26] There are patches in 1.6.2 targetting 3.7 support, so it _might_ be fixed there. [15:42:40] Yeah, I had to take several of them to get 1.6.1 to even build. But I’m building 1.6.2pre2 now. [15:44:49] (The patches I took are https://github.com/sipb/openafs/commits/linux-3.7 .) [15:57:31] Okay, 1.6.2pre2 works. [16:08:57] --- deason has left [16:12:14] --- jaltman/FrogsLeap has left: Disconnected [16:25:24] --- jaltman/FrogsLeap has become available [16:27:46] --- meffie has left