Subject: [eap] Issue 35: Notification Usage

From: [email-masked] (Bernard Aboba)
Date: Sat, 5 Oct 2002 19:13:09 -0700 (PDT)

Issue 34: Notification Usage
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: October 5, 2002
Reference:
Document: RFC2284bis-06
Comment type: T
Priority: S
Section: 5.2
Rationale/Explanation of issue:

RFC 2284bis doesn't answer basic questions about Notification, such as:

a. Whether you are Notification is part of the method (e.g. Notification
Request is delivered to the method)

b. Whether Notification can be sent at any time (e.g. in the middle of a
method exchange)

c. Whether Notification results in a state change within the EAP state
machine or not

Change:

"   The Notification Type is optionally used to convey a displayable
   message from the Authenticator to the peer. The Peer SHOULD display
   this message to the user or log it if it cannot be displayed.  It is
   intended to provide an acknowledged notification of some imperative
   nature.  Examples include a password with an expiration time that is
   about to expire, an OTP sequence integer which is nearing 0, an
   authentication failure warning, etc.   In most circumstances,
   notification should not be required."
To:

" The Notification Type is optionally used to convey a displayable
message from the authenticator to the peer. An authenticator MAY
send a Notification Request to the peer at any time, including
in the middle of an ongoing method conversation. The peer MUST
respond to a Notification Request with a Notification Response;
a NAK response MUST NOT be sent. A Notification Response is
typically generated automatically by the EAP layer, so that
methods MUST NOT use Notification as an inband communication
mechanism.

The Peer SHOULD display this message to the user or log it if it
cannot be displayed. The Notification Type is intended to provide
an acknowledged notification of some imperative nature, but it is
not an error indication, and therefore does not change the state
of either the authenticator or the peer. Examples include a
password with an expiration time that is about to expire,
an OTP sequence integer which is nearing 0, an authentication
failure warning, etc. In most circumstances, notification should
not be required."

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 08 Oct 2002 12:43:34 -0400

A small change suggestion

> methods MUST NOT use Notification as an inband communication

Change      
                       A Notification Response is
 typically generated automatically by the EAP layer, so that
 methods MUST NOT use Notification as an inband communication
 mechanism.

To 
                         A Notification Response is 
typically generated by the EAP layer; the Notification Data MUST NOT be
forwarded to methods other than Notification.

> of either the authenticator or the peer. Examples include a

Change 
does not change the state of either the authenticator or the peer

to 
does not change the state of the peer. 

[explanation -- the authenticator is going through a sequence of
methods, and where it is in the sequence is part of the state. 
therefore sending the Notification message would have to change state of
the Notification message would be sent over and over and over]

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 8 Oct 2002 21:56:28 -0700 (PDT)

> forwarded to methods other than Notification.

How about this?

"A Notification Response is typically generated automatically by the EAP
layer; therefore the contents of a Notification Request MUST NOT be
delivered to a peer method other than Notification."

> does not change the state of the peer.

Done.

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 09 Oct 2002 07:20:54 -0400

> delivered to a peer method other than Notification."
sounds good to me