Subject: [abfab] com_err and error codes

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Mar 2012 13:55:25 -0500

So, I'm looking at registration procedures for error codes for the
GSSEAP registry.

Our implementation uses a library called com_err to handle error codes
for GSSEAP.
This is commonly used in Kerberos implementations as well.

It has the kind of undesirable side effect that it splits error codes
into  255-entry tables.
If you use that library you can easily get into a situation where you
have difficulty dealing with errors greater than 255.  Kerberos made
things worse and actually got into a situation where two of the major
implementations have trouble with errors greater than 127. I recommend
we do not make that mistake.

I was thinking of addressing com_err concerns in the following way:

1) Add a note that implementations need to be able to deal with the
entire range of error codes.
In practice all this means is that you should design your APIs for
mapping from protocol errors to whatever errors your implementation uses
so that they will work if you're trying to map say more than 255 errors
that you might encounter.

2) Reserve the lower 127 values for standards action.

3) Say 128-255 specification required.

4) Reserve the rest of the range noting that future registration
policies may permit assignment from the greater range.

Thoughts?

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 Mar 2012 14:24:01 -0600

The idea of leaking implementation details into the registry and/or
its registration rules makes me gag.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Mar 2012 16:04:32 -0500

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> The idea of leaking implementation details into the registry
    Nico> and/or its registration rules makes me gag.

I hear your frustration because you'd like to keep a clean orderly
 registration.
I feel happy about the registration  I proposed because I think it
 avoids leaking  com_err details.

I chose to reserve codes above 255 because I'm concerned we may
need/want an IETF review range or may decide that specification required
is too loose for the future.
My intent was to provide a registration  process that was flexible while
acknoowledging that we don't understand what policy we may want years
from now.

How do you feel about this registration process?

--Sam

---

From: Leif Johansson <[email-masked]>
Date: Sat, 10 Mar 2012 07:42:34 +0100

On 03/09/2012 10:04 PM, Sam Hartman wrote:
> registration. I feel happy about the registration  I proposed
> because I think it avoids leaking  com_err details.
> 
> need/want an IETF review range or may decide that specification
> required is too loose for the future. My intent was to provide a
> registration  process that was flexible while acknoowledging that
> we don't understand what policy we may want years from now.
> 

The only question I have is that since this is a pretty scarce resource
we might want specification required + expert review and give the expert
pool explicit review instructions that we are only looking for a "is not
crazy"-check.

I'm guessing that you don't want to introduce a high bar of entry so as
to encourage innovation. If so, I concur but we might want to raise the
bar just a little bit so that nobody eats up the 127 error codes with a
cleverly crafted cronjob+xml2rfc.

	Cheers Leif

---

From: Nico Williams <[email-masked]>
Date: Sat, 10 Mar 2012 01:15:36 -0600

>> because I think it avoids leaking  com_err details.

This is the problem I have with letting an implementation detail like
this leak into the IANA process.  I won't go along with expert review
for error codes because of com_err.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 10 Mar 2012 02:44:40 -0600

Actually, can you clarify something?  Are we talkign about protocol
errors or API (minor_status) errors?

If the former, then sure, I think expert review is fine.  If the
latter then I don't.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 10 Mar 2012 10:05:08 +0100

On 03/10/2012 09:44 AM, Nico Williams wrote:
> Actually, can you clarify something?  Are we talkign about
> protocol errors or API (minor_status) errors?
> 

I'd like to understand this: are you objecting because you think
expert review would produce poor results or some other reason?

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Sat, 10 Mar 2012 10:05:10 -0500

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> Actually, can you clarify something?  Are we talkign about
    Nico> protocol errors or API (minor_status) errors?

Protocol errors over the wire.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 10 Mar 2012 10:09:57 -0500

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> The only question I have is that since this is a pretty scarce
    Leif> resource we might want specification required + expert review
    Leif> and give the expert pool explicit review instructions that we
    Leif> are only looking for a "is not crazy"-check.

I don't think it is particularly scarce actually.
By requiring implementations to deal with error codes greater than 255,
here's what I'd do if I were using com_err:

1) have all mapping from protocol error to com_err code in one function

2) have the inverse in another function

3) Until we use up the first 3255  you can just add or subtract the
error table base.

4) If we get beyond tht then have a set of bases based on what IANA has
currently assigned.

So, I don't think it is particularly scarce  and thus I think
specification required is good enough.
However I'd be equally happy with expert review.