"Valery Smyslov" <smyslov.i...@gmail.com> writes:
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?
Сервер отключен для пусконаладочных работ на три часа
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.
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
