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