"Valery Smyslov" <smyslov.i...@gmail.com> writes:
>> 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".
Then those providers should probably pick English, and 99.99% of these users
don't care anyway.
Thanks,
Chris.
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
