> 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. :) 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
