> > > 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 -- [email protected] To unsubscribe send an email to [email protected]
