Hi Michael, Although EAP/SIM is an Internet-Draft, there are implementations and other documents that depend on it. So in general, we would like to maintain compatibility and interoperability with implementations of old draft versions, unless there is a very good reason to break compatibility. We have version numbers in order to help us make new incompatible versions of the protocol, but we'd like to avoid doing that unless we really have to.
I believe that these three issues are not critical but rather they are matters of opinion, nicer ways of doing the same thing. I agree that your proposals would be as good as or better than what we currently have. But there isn't anything fundamentally wrong in the current ways that would justify an incompatible change. So I think we should not change the document with regard to these issues. By the way, do you have a separate comment B3? Best regards, Henry > -----Original Message----- > From: ext Michael Richardson [mailto:[EMAIL PROTECTED] > Sent: 15 September, 2003 22:40 > To: eap; freeradius-users > Cc: [EMAIL PROTECTED] > Subject: [eap] wire related comments on eap-sim-11.txt > > > > *** PGP Signature Status: unknown > *** Signer: Unknown, Key ID = 0xE99DD5FD > *** Signed: 15.09.2003 10:39:47 PM > *** Verified: 16.09.2003 11:12:23 AM > *** BEGIN PGP VERIFIED MESSAGE *** > > > > B1) why is the TLV format different from the RADIUS one? > The length is the only difference. (being /4) > How often do we need attributes longer than 253 bytes? > What happens if the length is 0? (Yeah, it is illegal, > but why have such a situation) > > The 4* the length is there so that one can have 1022 byte > attributes. These don't fit into single EAP-Message payloads in > radius, is the situation better in LCP? > > The 4* length seems to simply result in there needing > to be another > length in many packets. That probably cancels any advantage in > encoding the length as a byte. > > The rounding up to 32-bit size also seems to waste a > lot of bytes > needlessly - the EAP messages won't be aligned when they arrive > in at a radius server, which is likely the end that > will biggest load > due to EAP messages, so why bother here? > > I suggest that the TLV format be junked in favour of one that is > either identical to PPP or identical to radius. > > This is gratuitously different. > > B2) why are there boath IV and ENCR attribues? > Just put the IV at the front of cipher text. This makes > much more > sense. > > B4) It appears that AT_FULLAUTH_ID_REQ, PERMANEND_ID_REQ and > ANY_ID_REQ are always mutually exclusive. I strongly suggest > that there be an "ID_REQ" attribute, with three values: > FULLAUTH/PERMANENT/ANY > > In fact, these three cases seem like they are really three > different "Start" situations, and I suggest that they be > turned into three "Start" messages. This would be much easier > to document and analyze. > > ] Out and about in Ottawa. hmmm... beer. > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] [EMAIL PROTECTED] > http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another Debian/notebook using, kernel hacking, > security guy"); [ > > > *** END PGP VERIFIED MESSAGE *** > _______________________________________________ > eap mailing list > [EMAIL PROTECTED] > http://mail.frascone.com/mailman/listinfo/eap > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
