eap Mailing List: Re: Editorial issue with state machine: clarify "altAccept"&"altReject"

[Jari Arkko (jari.arkko]

I agree with this.

--Jari

Florent Bersani wrote:
> Issue #TBC
>
> Submitter name: Florent Bersani
>
> Submitter email address: florent.bersani [at] rd.francetelecom.fr
>
> Date first submitted: 06/29/2004
>
> Document: Document Requiring change State Machine
>
> Comment type: E
>
> Priority: '1' Should fix
>
> Rationale/Explanation of issue:
>
> altAccept and altReject may be confused with protected result 
> indications and their definition as "alternate indications" do not match 
> with RFC 3748 (There is not a single occurrence of the word "alternate" 
> in RFC 3748 - this was previous wording that disappeared, see e.g., 
> issue #2).
>
> Requested change:
> Use instead the notation lowerLayerAccept and lowerLayerReject (or 
> lowerLayerSuccess and lowerLayerFailure)
> Point to section 3.4 of RFC 3748 ("Lower layer indications")
>
> BTW, I believe there is a bug in section 3.4 of RFC 3748, which says: 
> "if a peer receives a lower layer success indication as defined in 
> Section 7.2"
> I do not see such a definition in section 7.2 (I see some related 
> discussion in section 7.12 though)
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap