Hi Valery, Thanks for your thoughts. I'd like to offer a different perspective—as someone who has spent a lot of time debugging IKE in operational environments. In those situations, I’ve often found IKE error codes difficult to interpret and diagnose. This draft aims to improve that situation for delte message. Note in this case there less chace abouse. The peer is already authenticated... Simple registries alone are not sufficient. A short, optional free-text diagnostic message—with strict length limits, of course—could have saved me considerable time and effort, especially in cases where connections were administratively blocked.
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. I understand your concern about English being the default, but I don’t believe that should prevent us from including diagnostic messages. Many Internet protocols began with English and continue to use it effectively. Leaving room for future multilingual support seems more constructive than excluding the feature altogether. Regarding IKE being a low-level protocol—I agree, and that’s often a strength and weakness. But that same low-level nature also makes it harder to diagnose. As the protocol has grown in complexity, the need for better diagnostics has only become more evident? Wearing my author hat: I’ve also heard strong support from others that free-form text is sometimes the only practical way to communicate unexpected or unregistered errors. Especially in secure environments, where logs may be sparse or inaccessible, an optional text message can be invaluable. I’m open to suggestions on how to make this safe and interoperable. In my view, concerns about English-only support shouldn’t be used to dismiss the idea outright. The only reason the current draft uses English is due to author's lack of expertise in internationalization. I’d welcome input from others who can help define a more flexible or extensible approach. Would anyone like share some pointer how to send messages in low lever protocol? At one point, I considered dropping the free-text message to help advance the draft as a Standards Track document. To take path of least resistance. But since this is currently positioned as experimental, I now feel there’s no reason to compromise. Let’s run the experiment. If the outcome is that free text turns out to be a bad idea, we’ll have the data to justify removing it later when it goes to standard. best regards, -antony On Mon, Jun 30, 2025 at 10:45:36AM +0300, Valery Smyslov wrote: > Hi Paul, > > I prefer option 3) - without text fields regardless of the intended status :-) > > The argument is not "strings are hard", sometimes they are easier than reason > codes. > The actual reasons why I think this idea is bad are: first, these strings are > intended to be read > by humans and only in one language (English), which I think is not > appropriate for > the Internet-wide protocol. And second - I think that IKE is a low-level > enough protocol > to not deal with strings at all (e.g., you don't have strings in ICMP). > > Regards, > Valery. > > > Hi, > > > > [ speaking wearing only by Authors hat ] > > > > The authors have a question on https://datatracker.ietf.org/doc/html/draft- > > pwouters-ipsecme-delete-info > > > > We had some discusison about the text field for "delete reason" in > > draft-pwouters-ipsecme-delete-info. Some people liked it and some did > > not. Mostly it was regarding fear of security and internationalization. > > This resulted in -02 having the field and -03 having the field removed: > > > > https://author-tools.ietf.org/iddiff?url1=draft-pwouters-ipsecme-delete-info- > > 02&url2=draft-pwouters-ipsecme-delete-info-03&difftype=--html > > > > However, the authors didn't agree with each other on which is best, > > especially in the light of the document also moving from -02 as Standards > > Track to -03 as Experimental. Since the reasons for removal of the text > > field was "strings are hard, dont do it", one could argue that if we are > > Experimental, why not try the strings and see how it works, then decide > > later when/if it moves to Standards track on whether the text field was > > a success or not. > > > > So the authors would like some input. Which do you prefer (and why): > > > > 1) Standards Track without text field > > 2) Experimental Track with text field > > 3) Other > > > > We hope to get some feedback this week so we can push a new draft before > > the cut-off and maybe have some running code for IETF 123. > > > > Paul, on behave of all the authors :) > > > > _______________________________________________ > > IPsec mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > IPsec mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
