> Basically the choices presented are make it really simple for implementors to
> add
> some text that may help some vast majority of the operators — and see that get
> implemented, or make it so onerous (on the standardized side — either b/c its
> too
> hard to standardize or you can't think of all the reasons and end up with
> EINVAL
> being the default reason always given) that no reason is included or isn’t
> useful and
> for sure no-one is helped.
Not true, the choices are use reason codes with supplementary information or
use free-form reason
text. I still would like to hear technical reasons for the latter. What I've
heard so far
was along the lines: "Since we can do it, why not do it? It won't hurt.".
The advantages of using reason codes are:
1. No problems with language - reason codes can be locally converted to
messages in operator's preferred language
2. Less ambiguity in interpreting messages - description of what a reason code
means is well documented
2. Some automatic actions can be taken (e.g., introduce a pause with connection
attempts if server is said to be down)
3. It would allow to display logs in more sensible way (e.g., if reason code is
REKEY and supplementary information
contains SPI of the new SA, then log viewer can automatically link old and
new SA).
For extensibility it is possible to create an IANA registry for reason codes
with First Come First Served policy.
Regards,
Valery.
> Thanks,
> Chris.
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
