Subject: [Ietf-krb-wg] IANA: error handling

From: Sam Hartman <[email-masked]>
Date: Wed, 04 May 2011 10:09:30 -0400

At the Prague meeting, the chairs took an action item to figure out why
Love recommended in draft-lha-krb-wg-some-numbers-to-iana that we
require standards action for error numbers.

The reason is that for com_err based implementations (MIT and Heimdal)
the number space is constrained effectively to 8 bits. Unfortunately,
MIT at least makes things somewhat worse and actually constrains things
to 128 possible errors.

So, it would be significantly expensive for some of the implementations
to deal with error codes greater than 128.  N Note that it would be
possible for those implementations to revise how they handle errors;
doing so would involve a fair bit of refactoring of any code that deals
with KRB5 protocol errors.  

If we go with Love's suggestion, then people can return fairly generic
errors but can include additional information in padata/typed data in
the returned error.  That's consistent with what one implementation
already does in a number of cases.

I'd appreciate comments from the WG on whether standards action is the
appropriate registration procedure for krb5 errors given these
constraints.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Wed, 04 May 2011 10:56:11 -0400

> appropriate registration procedure for krb5 errors given these

As an implementor, I'd prefer we treat error numbers as precious right
now (that is, I agree with Love that they should require standards
action).