eap Mailing List: Re: Some (minor) editorial comments on RFC 3748b

[Jari Arkko (jari.arkko]

Hi,

I agree with the edits that Florent and Henrik
propose below. I don't think we should change the
MIC definition, or rearrange text parts (comment #3)
now.

--Jari

Henrik Levkowetz wrote:
> Hi Florent,
>
>     You're rather impressive in your ability to see mistakes in details,
> aren't you! :-)
>
> On Thursday, 10 Jun 2004, Florent Bersani wrote:
> ...
>
> > Comment #1
> >
> > Section 1.2
> >
> > Some entries start with a capital letter (e.g. Supplicant, Displayable 
> > Message, ...) while others do not (authenticator, peer,...).
> > Suggested change: adopt a constant behavior (namely start all entries 
> > with a capital letter)
> >
> > This capitalization problem is all the more shocking with 
> > "authenticator" because this entry is written "authenticator" and in the 
> > definition text we may read authenticator with a capital A ("The term 
> > Authenticator is used in [IEEE-802.1X], 
> > and has the same meaning in this document.")
> > Suggested change: adopt a constant behavior for this term throughout the 
> > document.
>
>
> Proposed change:
> Section 1.2, para. 2:
> OLD:
>
>    authenticator
>       The end of the link initiating EAP authentication.  The term
>       Authenticator is used in [IEEE-802.1X], and has the same
>       meaning in this document.
>
> NEW:
>
>    authenticator
>       The end of the link initiating EAP authentication.  The term
>       authenticator is used in [IEEE-802.1X], and has the same
>       meaning in this document.
>
>
>
> > Comment #2
> >
> > Section 1.2
> >
> > I disagree with the RFC 3748 definition of MIC:
>
> ....
>
> Someone else will have to take a position on this one, I can't argue
> strongly either way.
>
>
> > Comment #3
> >
> > Section 1.2
> >
> > Rearrange section 1.2 with the entries sorted in alphabetical order to 
> > improve readability
>
>
> I'd rather not do this now...
>
>
> > Comment #4
> >
> > Section 5.1 2nd paragraph typo: replace "Some EAP implementations 
> > piggy-back various options into the Identity Request after a 
> > NUL-character" with "Some EAP implementations piggy-back various options 
> > into the Identity Request after a NULL-character" (the typo is on NULL IINM)
>
>
> Nope, here the name of the ASCII character is "NUL", not "NULL".  Other
> places in the document the term "null" is used as a term in itself, and
> then I've spelled it "null", indeed.  There's one place where I've missed
> this distinction though, giving this correction:
>  
> Appendix A., para. 12:
> OLD:
>  
>     o  It is now required in Section 5.1 that if the Type-Data field of
>        an Identity Request contains a null character, only the part
>        before the null is displayed.  RFC 2284 prohibits the Null
>        termination of the Type-Data field of Identity messages.  This
>        rule has been relaxed for Identity Request messages and the
>        Identity Request Type-Data field may now be null terminated.
>  
> NEW:
>  
>     o  It is now required in Section 5.1 that if the Type-Data field of
>        an Identity Request contains a NUL-character, only the part
>        before the null is displayed.  RFC 2284 prohibits the null
>        termination of the Type-Data field of Identity messages.  This
>        rule has been relaxed for Identity Request messages and the
>        Identity Request Type-Data field may now be null terminated.
>
>
>
>
> > Hope this helps and you aren't upset by my being so particular about EAP 
> > WG documents,
>
>
>     Sooner (during last call, for instance :) would have been better,
> but now is better than never, as far as I'm concerned.  No upsets.
>
> 	Regards,
>
>                 Henrik
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap