Subject: [eap] rfc2284bis-08: issue 35 redux

From: [email-masked] (James Carlson)
Date: Thu, 2 Jan 2003 07:56:24 -0500

It appears to me that issue 35 (Nak of an Identity message) was
resolved incorrectly.  RFC 2284 allowed an implementation to send Nak
for Identity messages.  The fact that common implementations don't
*use* this mechanism to any good effect is not a sufficient reason to
make Identity a special case in the protocol.

Submitter name: James Carlson
Submitter email address: [email-masked].
Date first submitted: January 2, 2003
Document: RFC2284bis
Comment type: T
Priority: S
Section: 5.1
Rationale/Explanation of issue: 

The change made in this draft breaks compatibility with the prior RFC,
and doesn't appear to add any benefit.  Worse, it means that there's
now a completely undefined corner in the protocol: what do you do if
the peer sends Nak for Identity anyway?  Do you terminate?  Try again?
This was once well-defined (process as you would for any Nak), and is
now undefined.

Requested change: 

from:

   An optional displayable message MAY be included within an Identity
   Request, to prompt the Peer in the case where there is an expectation
   of interaction with a user. An Identity Response MUST be sent to an
   Identity Request. A Peer MUST NOT respond to an Identity Request with
   a NAK.

to:

   An optional displayable message MAY be included within an Identity
   Request, to prompt the Peer in the case where there is an expectation
   of interaction with a user. An Identity Response MUST be sent to an
   Identity Request. A peer with no known identity to offer MAY send
   Nak instead.

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677