On Feb 21, 2013, at 1:10 PM, Jim Schaad <jim...@augustcellars.com> wrote:
> 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.
>
[Joe] Thanks, well look at this and try to make the usage consistent with
2119 and move other usages to different words
> 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.
>
[Joe] This needs to be clarified. Even if there is only one inner method the
server needs to send and intermediate result TLV. How about
OLD (section 3.3)
It MUST be included with the
Intermediate-Result TLV to perform Cryptographic Binding after each
successful EAP method in a sequence of EAP methods, before proceeding
with another inner EAP method.
NEW
The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
to perform Cryptographic Binding after each
successful EAP method in a sequence of one or more EAP methods.
> 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.
>
[Joe] Good catch:
OLD
If the server ignores the
request, it proceeds with termination of the tunnel and send the
clear text EAP Success or Failure message based on the value of the
peer's result TLV.
NEW
If the server ignores the
request, it proceeds with termination of the tunnel and send the
clear text EAP Success or Failure message based on the status field of the
peer's request-action TLV.
> 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.
>
[Joe] I think it would be preferable to keep the current format that is used
by other methods.
> 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)
>
[Joe] OK
> 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"
>
[Joe] Correct
> 7. section 4.3 s/multiple multiple Basic/multiple Basic/
>
[Joe] OK
> 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.
>
[Joe] We could add the note from 5295
where:
| denotes concatenation
"EMSK" consists of the 4 ASCII values for the letters
"\0" = is a NULL octet (0x00 in hex)
length is the 2-octet unsigned integer 8 in network byte order
> 9. Section 5.2 - s/thendoesn/?????/
>
>
[Joe] s/thendoesn/then
>
>
>
>
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
