Subject: [Emu] FW: Last call comments on emu-eap-tunnel-method-05

From: "Jim Schaad" <[email-masked]>
Date: Thu, 21 Feb 2013 15:23:36 -0800

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: Thursday, February 21, 2013 1:10 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Last call comments on emu-eap-tunnel-method-05
> 
> I have no comments that I would consider to be blocking.  There are couple
> of issues that should be considered to be dealt with in the last call.
> 
> Jim
> 
> 
> 
> 1.  Lower case must/may in the document.  There are disputes about the
role
> of a lower case must in a document.  Some people consider it to be an RFC
> 2119 usage and some people don't.  If it is then these all need to be
looked
> at, if it doesn't then I would suggest putting in text as part of the
RFC2119
> boiler plate to say that lower case versions of these words have their
natural
> language meaning.
> 
> 
> 2.  I am not completely clear on this, but don't know if it needs to be
clarified.
> Server and client rune one inner EAP method.
> Server sends Crypto-Binding TLV and Result TLV Client sends Crypto-Binding
> TLV, Request-Action TLV [Negotiate EAP] Server sends EAP-Payload [EAP
> start method] Does the server also needs to send an Intermediate-Result
> TLV per section 3.3.1?
> ---- Note - in section 3.3.3 - it would appear that there is a "may"
> recommendation that the server actually send Crypt-Binding TLV,
> Intermediate-Result TLV, Result TLV thus making the problem not a problem.
> However this is not required behavior.
> 
> 3.  Not completely sure the second to last paragraph in 3.3 is correct.
Should
> the server return the EAP success or failure based on the peer's result
TLV or
> the peer's request-action tlv?  I think that either could be a correct
answer I
> just want to verify that the text presented is correct.
> 
> 4.  Last chance to change our minds and allocate an extra flag in section
4.2.1
> just in case we needed it.  I have no idea which is going to be the more
scarce
> resource.  But only one reserve flag might be an issue.
> 
> 5.  It is technically incorrect to say that the TLV Type is two octets
(section
> 4.2.2).  I don't know that there is any reason to correct this as it is
essentially
> correct.  Just a we need to be sure we don't want to fix it.  (Note: text
is
> different in section 4.2.2)
> 
> 6.  section 4.2.13 - I think that the received version number is supposed
to
> say "set to the TEAP version number received" not the "EAP version
> number"
> 
> 7.  section 4.3 s/multiple multiple Basic/multiple Basic/
> 
> 8.  Section 5.2  There are two possible confusions that could result in
the
> computation of the text string for the IMSK
>    a) It is possible that the string "\0" could be misinterpreted.   This
could be
> stated as 0x00.
>    b) It is possible that the 64 could be misinterpreted as being longer
than a
> byte and thus could be stated as 0x40.  (Oops just looked at the
referenced
> document and it is 0x00 0x40).
>    Not clear if this really needs to be changed.
> 
> 9.  Section 5.2 - s/thendoesn/?????/
> 
> 
> 
> 
>