[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt
Jan,
I am suggesting that, in whatever protocol is chosen as the successor
to IKEv1, it needs to have granular status and error codes -- the more
granular the better. Along those lines, I also recommended that, if
possible, error and status codes in the spec be classified
hierarchically to make diagnosing, and fixing, errors as easy as
possible.
Moreso than many protocols the IETF works on, IKEv1 and its successor
are *highly* visible to end-users, in particular non-technical
telecommuters and road-warriors. Granted, non-technical end-users may
not be directly responsible for troubleshooting problems with the
protocol, but for them to be able to relay specific information to
more technical security admins is absolutely necessary, particularly
if IKE's successor is to be wildly successful.
-shane
On Fri, Dec 21, 2001 at 02:15:02PM -0800, Jan Vilhuber wrote:
> 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.
[ snip ]
> > 7. Improve Simplicity
[ snip ]
> > 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.
[ snip ]
>
> 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
Follow-Ups:
References: