"Valery Smyslov" <[email protected]> writes:
Hi Chris,
Imagine you are coding your implementation and you encounter a place in the code
for which you cannot recover and have to abort and need to return an error.
Now imagine that no reason code perfectly maps to your condition.
Starting a years long process to document your implementations specific
condition
through the IETF, updating your software to match this new standard, then taking
years to push this software update out to actual customers ...
Yes, that is certainly one way to do this; however, I’m suggesting in the
meantime
(years!) how about we let the implementation *also* return text that people can
use
in the meantime?
As I already said, the proposed IANA registry for reason codes should have
policy First Come First Served. In my understanding it should take IANA a day
or two to register.
The registration template could include the explanatory text and a reference to
any
documentation (if it is available), not necessary RFC or I-D. If we are
concerned with
unclear explanation text or duplicate reason codes, then Expert Review policy
could be appropriate. In this case the registration usually takes two weeks
(if I remember correctly - this is a time period IANA requires experts to
review a request).
FCFS registries are .. interesting. Ask BGP. :)
I suspect with FCFS you are just trying to come up with "free-form-reason-codes" simply
to avoid using "free-form-text".
I say KISS use text and avoid all this hassle. Text will actually be used by
programmers, and so you'll see better results actually deployed.
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.
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.
In addition free-form text also allows for further detailing specifics that a
simple
reason code will never allow.
As I already said, I propose reason code _and_ some supplementary data.
Usually most significant information is SPI of related SA (e.g., those, that
somehow caused
deletion of this SA). Thus, it could be: reason code, related SPI, possibly
timestamp.
Anything else really important?
The obvious supplementary info to provide is *text*, that is what I'm saying.
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.
Thanks,
Chris.
Regards,
Valery.
Thanks,
Chris.
> On Jul 10, 2025, at 08:51, Valery Smyslov <[email protected]> wrote:
>
>> Basically the choices presented are make it really simple for implementors to
add
>> some text that may help some vast majority of the operators — and see that
get
>> implemented, or make it so onerous (on the standardized side — either b/c its
too
>> hard to standardize or you can't think of all the reasons and end up with
EINVAL
>> being the default reason always given) that no reason is included or isn’t
useful
and
>> for sure no-one is helped.
>
> Not true, the choices are use reason codes with supplementary information or
use free-form reason
> text. I still would like to hear technical reasons for the latter. What I've
heard so
far
> was along the lines: "Since we can do it, why not do it? It won't hurt.".
>
> The advantages of using reason codes are:
> 1. No problems with language - reason codes can be locally converted to
messages in operator's preferred language
> 2. Less ambiguity in interpreting messages - description of what a reason code
means is well documented
> 2. Some automatic actions can be taken (e.g., introduce a pause with
connection
attempts if server is said to be down)
> 3. It would allow to display logs in more sensible way (e.g., if reason code
is
REKEY and supplementary information
> contains SPI of the new SA, then log viewer can automatically link old and
new
SA).
>
> For extensibility it is possible to create an IANA registry for reason codes
with
First Come First Served policy.
>
> Regards,
> Valery.
>
>> Thanks,
>> Chris.
>
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
