> >> humans are capable of reading text in a language w/o needing a tag to > > identify it. > > > > I emphatically disagree. If I send you the following reason message, > > will it help you? > > > > Сервер отключен для пусконаладочных работ на три часа > > This example doesn't make sense to me, it seems contrived to make some point > but it's not realistic. > > People aren't contacting random IPsec servers that are mis-configured for > their > users. If the user wouldn't understand the above language then the operator > wouldn't configure it.
There are a lot of VPN services in the wild that provide access to the Internet worldwide from where it is restricted. Some of them use IKEv2/IPsec and they don't care about the languages their users understand. For the users it is a just a "random IPsec server". Regards, Valery. > Thanks, > Chris. > > > > > You will probably use Google translate and it will ask you what > > language it is in? > > Sometimes it can correctly guess the language (and the text above is > > an easy example), but often not. > > I also want to point out that some languages (e.g. Finnish) are very > > difficult for machine translation. > > > > FWIW, using language tags is not my whim. If we leave human-readable > > text in the protocol, then we MUST support multiple languages and MUST > > be able to transfer language information to be compliant with BCP18 > > (RFC 2277, Section 4.2, Section 4.4). > > I don't want to deal with all this issues, so I'd rather to not > > include fields with human-readable text in IKEv2. > > > > Regards, > > Valery. > > > >> I do think the encoding might need to be specified, since that is > > something the > >> computer may need to understand. > >> > >> Thanks, > >> Chris. > >> > >> > >> > >> > > >> > In general, I think it is a bad idea to transmit text strings > >> > to be read by users in a low level > >> > protocol which IKEv2 is. This is an UI issue, and it is the UI > >> > that should properly display to the user in a user > >> > chosen language what is happening. > >> > > >> > 2. The list of reasons looks to me both incomplete and excessive at > >> > the same time. > >> > For example, CONFIGURATION_CHILD_REMOVED and > >> CONFIGURATION_IKE_REMOVED > >> > are not needed, since you either delete IKE SA or Child SA in a > >> > single exchange, so it is > >> > always clear what configuration is removed and only one such > >> > reason would suffice. > >> > SIMULTANEOUS_REKEY adds no new information, > >> > since you always understand this reason from local logs. On the > >> > other hand, > >> > it is not specified what to indicate in the reason when ESP SA > >> > is being deleted > >> > in response to deleting the tied ESP SA for the other direction. > >> > > >> > In general, I think that indicating the reason the SA is deleted > >> > doesn't help much the user much. > >> > In many cases it can be inferred from local logs. And if it > >> > cannot, then you probably > >> > will to contact the other end in any case to get more detailed > >> > information on the reason, > >> > in which case sending the reason on the wire has little value. > >> > > >> > 3. Perhaps the most useful field is Downtime. But thinking more > >> > about > > this, > >> > I believe that since this value is only a hint, you will > >> > probably not trust it. > >> > For example, if you have to communicate to the peer ASAP and it > > deletes > >> > SA indicating that downtime is 1 hour, you will not wait for all > >> > this time, > >> > you will try to establish new SA every minute (it costs you > >> > nothing, > > but > >> > you have a chance to get it up earlier). > >> > > >> > Regards, > >> > Valery. > >> > > >> > _______________________________________________ > >> > 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
