Darren Reed writes: > James Carlson wrote: > > Darren Reed writes: > > > >> I agrree, Jim, and I'd like to reiterate that we have an obligation to > >> follow > >> what the IEEE specification says is allowed here. Anything else introduces > >> arbitrary restrictions that may introduce interoperability problems. > >> > > > > What IEEE specification says something about security object names? I > > thought these names (unlike the keys stored inside) were an internal > > Solaris implementation detail, not something that conformed to any > > standard. > > > > I should have quoted the entirity of your email where you were > talking about how we're using the ESSID/BSSID for the secobj > name. If we're not going to use those, then we don't need to be > concerned with what IEEE says. But if we are, then we do.
I still don't think we care. The IEEE governs how the ESSID and BSSID themselves work. They don't govern how we name our internal objects or the character set we use for those names. In this case, we happen to use a *modified* form of ESSID (we irreversibly translate ':' to '.', because dladm '-k' uses colon to delimit slot numbers from a secobj), and a particular string representation of BSSID (I don't think IEEE has a position on upper or lower case hex or on zero pad, but we do when we're creating this string), separated by '-', and we truncate the string because secobj names are length-limited. We'd probably be better off just to hash ESSID and BSSID together and use some printable form of the hash as the secobj name. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
