Hi Chris, > > Hi, > > > > I have some comments on draft-pwouters-ipsecme-delete-info that I > > tried to express at IETF120, but due to lack of time they were not > > responded to. > > > > 1. I'm very much concerned with the "Delete Reason Text" field. My > > primary question - > > in what language this free text explanation is supposed to be? I > > suppose > > > > it is assumed to be English, but why do you think all customers in > > the world understand English well enough > > for this field to be really useful? If arbitrary language is > > allowed, then we need to add a language tag, > > otherwise it is generally impossible to even recognize what > > language the text is in. > > And allowing arbitrary language makes this field even less useful. > > This text is for humans to read not computers, I understood that it's been asked for > by users to help them understand better why something was deleted. > > The language can be left up to the implementation it should not be standardized. > One could easily imagine the language being one of the following: > > 1) Multiple language choices (perhaps set by Locale) configured by user.
The problem is that the locale is configured on the sending host, while the reader of the text is on the receiving host. > 2) English I suspect not all customers in the world understands English well enough. Also see below. > Supporting locale's (or not) is something that implementations differentiate > themselves in the market on. > > In any case a computer is not parsing the language, so there's no need for a tag > identifying the language. Again the message is meant for humans to read and > 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? Сервер отключен для пусконаладочных работ на три часа 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
