> On Jul 10, 2025, at 06:21, Christian Hopps <cho...@chopps.org> wrote: > > > >> On Jul 10, 2025, at 04:39, Valery Smyslov <smyslov.i...@gmail.com> wrote: >> >> Hi Chris, >> >>> I thought the whole point was that the normal error procedure left >> something to be >>> desired for operators looking at a log message trying to figure out what >> went >>> wrong? >> >> Exactly. >> >>> I support the idea of including text reason. All the reasons against it so >> far sound >>> like wonky academia vs operators actually trying to Get Stuff Done. >> >> I support the idea of including reason code and some supplementary >> information. >> I do not support the idea of including free form text message instead. >> >> And the reasons for my preference are not related to "wonky academia", they >> are practical: >> 1. Reason codes would allow some automatic actions on receiving side >> 2. They can be displayed to operators in locally selected language >> >> To the contrary, if reason text is intended to be shown to human beings, >> then, in my understanding, the IETF's policy is that >> BCP18 (RFC2277) should apply. In particular: >> 1. All protocols MUST identify, for all character data, which charset is in >> use. (Section 3.1) >> 2. Protocols that transfer text MUST provide for carrying information about >> the language of that text. (Section 4.2) >> 3. Protocols where users have text presented to them in response to user >> actions MUST provide for support of multiple languages. (Section 4.4) >> >> As implementer, I do not want to deal with all this stuff in IKE, I believe >> the added complexity is unjustified. >> >> And yes, RFC2277 also allows to use default language (understood as English) >> in cases >> "where the sender has no knowledge of the recipient's language preferences >> (such >> as login failures or E-mailed warnings, or prior to language negotiation) ", >> but you have then to persuade the IESG that you cannot negotiate the >> preferred >> language in IKE or that you do not do this because all operators in the >> world >> can understand English. > > None of this is required for correct operation of the protocol. The extra > text may be helps an operator out, but if not it doesn’t hurt. Putting a > bunch of requirements on top of “could be helpful, but if not no big deal” is > exactly wonky acedamia. :)
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. Thanks, Chris. > > Thanks, > Chris. > > >> >> Regards, >> Valery. >> >>> Thanks, >>> Chris. >>> >>> >>> "Valery Smyslov" <smyslov.i...@gmail.com> writes: >>> >>>>>>> I like how some Cloudflare messages include a transaction ID and a >> brief >>>>>>> explanatory message. That kind of diagnostic feedback can make a >> real >>>>>>> difference. >>>>>> >>>>>> On the other hand, HTTP only normatively defines error codes, and we >>>>>> all know what 404 means without any supplementary text. >>>>> >>>>> The messages I am referring are Cloudflare 5xx error messages. >>>>> Which is more descriptive than http error codes. >>>>> >>>>> For e.g. here is one I found via google. >>>>> >>>>> https://i.sstatic.net/EhGbL.png >>>>> >>>>> And this one focus on 521. >>>>> https://www.cloudpanel.io/tutorial/error-code-521/ >>>>> >>>>> These messages have useful info. Such as which instance you hit, how >> far it >>>>> works. Note the Ray ID and timestamp. I imagine these can be used to >> open >>>>> support cases with Cloudflare. >>>> >>>> I don't think this is a good example. Additional information Cloudflare >> provides >>>> is not for you as an end user (for example, I have no idea what to do >> with Ray ID >>> :-(), >>>> this information is for themselves. In case you open ticket with their >> support, they >>> would ask >>>> you to get them this information. This is a blob, it can be in any >> language or >>> contain >>>> only digits. >>>> >>>> If your goal is to open a ticket with your peer's support, then it is >> enough >>>> to provide them with SPI of the SA that was deleted - it is unique. >>>> >>>>> I understand IKE is not text-based. However, isn't it time to evolve? >> We >>>>> need to exchange message that is more than normative error code list! >>>>> Once the peer authenticated I see no reason to stick to minimal >> normative >>>>> list. >>>> >>>> If the possible set of reasons fixed and documented somewhere, >>>> then I see no difference between reason codes and strings >>>> (except that strings are more subjective in interpretation). >>>> If you think that peer's administrator can manually enter >>>> reason strings, then... oh... I don't want to think about this :-) >>>> >>>>> See the CloudFlare example above. Their proxy can gather state >> information >>>>> and send it over the https. I am envisioning IKE peer that decided to >> delete >>>>> a connection has more info. This details along with some timestamp and >>>>> transaction id can be send to the remote peer. Most case there is no >> need >>>>> for manually entering these. >>>> >>>> Some additional information can be provided in additional fields >>>> in binary format. For example, the related SPI (e.g., in situation >>>> when SA is deleted due to INITIAL_CONTACT in the other SA). >>>> >>>>>> (Each time I want to reboot a Windows Server, it requires me to >> enter a >>> reason. >>>>>> I usually enter something like ";lsadyihKLJHNSC" to make it happy. >>>>>> I don't care if anybody reads this.) >>>>> >>>>> I am not proposing delete info is a must. >>>>> that is should not be reason to stop have something more modern:) >>>> >>>> I'm from oldskool, sorry :-) >>>> >>>> >>>> _______________________________________________ >>>> IPsec mailing list -- ipsec@ietf.org >>>> To unsubscribe send an email to ipsec-le...@ietf.org _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
