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? In addition free-form text also allows for further detailing specifics that a simple reason code will never allow. Thanks, Chris. > On Jul 10, 2025, at 08:51, Valery Smyslov <smyslov.i...@gmail.com> 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 -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
