Extensible Authentication Protocol (EAP) Password Authenticated Exchange
Note: This ballot was opened for revision 11 and is now closed.
(Jari Arkko) Yes
(Russ Housley) Yes
(Ross Callon) No Objection
(Brian Carpenter) No Objection
Comment (2006-08-31 for -)
From Gen-ART review by Elwyn Davies. I don't want to delay the document, but the first two points could benefit from small clarifications. > Issues: > ======= > s2.2: > >> >> If the underlying >> EAP transport protocol is known, then the client SHOULD differentiate >> between these values. >> > What are the consequences of not doing... under what circumstances would > it be reasonable or necessary not to differentiate? > What is the mapping between types of EAP transport protocol and field > values ( straight PPP is obvious but what other types map to the two > kinds?). What happens if other certificate types are defined? And other > transports? I actually suspect the author meant MUST, because this is the object of an IF. But since the IF is there, I assume that the consequences of not doing so are not viewed as serious - so I won't make this a DISCUSS. > > s3.2: The len field is still not precisely defined. It appears that it > is the length in octets of the corresponding value field in octets > encoded as a two octet binary integer. Since everything is described in bytes (or inconsistently, in octets) I don't think another interpretation is possible, so again I will refrain from a DISCUSS. But it would be better to be more precise. Brian > > Editorial: > ========== > s1.2: Expand NAI. A reference to a suitable RFC that explains > Diffie-Hellman generators would be useful. > > s3.2: I think it would be good to emphasise that the MAC is computed > just over the value field and not the length field [If I was an > implementor I am not sure how happy I would be about this!]. > >