[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

[Valery Smyslov <[e-mail]>]

> >> 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 -- [e-mail] To unsubscribe send an email
> >> > to [e-mail]