[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber
> Sent: Friday, December 21, 2001 2:15 PM
> To: Shane Amante
> Cc: ipsec@lists.tislabs.com
> Subject: Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt
>
>
>
> On Fri, 21 Dec 2001, Shane Amante wrote:
>
> > The following comments and suggestions relate to requirements offered
> > in: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt.
> >
> >
> > 7. Improve Simplicity
> >
> > [NOTE: this is kind of touched upon in Section 6 "Documenting Errors",
> > but I think the following point needs to be called out in specific
> > detail in Section 7.]
> >
> > There MUST be clear, concise definition of errors reported to
> > end-users during or after a failed IKE negotiation. I recommend
> > something along of the lines of SMTP or HTTP status codes be tailored
> > specifically to the IKE state machine and its transactions.
> >
> > Furthermore, an end-user should NOT have to enable IKE debugging on a
> > IPSec device in order to expose the specific reason (IKE status code)
> > why an IKE negotiation failed.
> >
> > The goal here is to _consistently_ deliver clear, concise messages to
> > the "common [wo]man" to make it easy to spot, relay and/or
> > troubleshoot error messages.
> >
>
> Surely you don't think that belongs on a protocol spec. However you
> choose to implement this is up to you.
>
> I certainly don't object to clarifying error codes, but a protocol
> spec doesn't need to spell out how these should be displayed to the
> user.
>
> jan
>
You are right in that a protocol spec need not spell out how the error
message should be displayed to the user, but it could define a message
format that enables better trouble-shooting. For example the notification
message can be format 'error code + error string', where the string
allows the sender to add more error detail. For example today a notification
such as 'no proposal chosen' does not exactly convey why the proposal was
rejected. An error string could furthur identify the problem such as group
or lifetime attribute is not acceptable..
-- sankar --
References: