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). > 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? 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]
