Christian Hopps <[email protected]> wrote: > A programmer can add text with zero extra effort, your solution while > you might think is easy (sure when compared to *other* IETF processes), > will almost never be undertaken by the programmer when they are in the > zone writing their code, and so no useful reason will actually be > provided.
This. FCFS still takes at least a week.
As a programmer, I might not even keep the message.
(I might need it for one WTF with this subsystem, do a patch release, and then
once one figures out which clients are getting *which* message (maybe there
are five possible outcomes), then remove them all)
> I'm not against this idea of registered reason codes, I just don't
> think making them a free-for-all is the right way. I would actually
> argue for the registration to be more restricted (expert review at
> least) than FCFS. I imagine these reason codes more like "errno" and
> think they should be better organized than an FCFS allocation would
> achieve.
+1
errno is a good example of a disaster. EINVAL is useless.
> So a programmer might return an ERESOURCE error to indicate some
> resource shortage, but importantly also include some text related to
> the exact situation they are staring at in their code. This has a much
> better chance of helping the operator deduce an immediately deployable
> fix.
ERESOURCE. "Your 102400 bit RSA key is dumb"
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
