> -----Original Message----- > From: Jim Schaad [mailto:jim...@augustcellars.com] > Sent: Thursday, February 21, 2013 1:10 PM > To: draft-ietf-emu-eap-tunnel-met...@tools.ietf.org > Cc: emu@ietf.org > 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/?????/ > > > > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
