"Valery Smyslov" <smyslov.i...@gmail.com> writes:
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.
2) English
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 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
