Peter Dunlap writes: > > - The exception lists include the directories themselves as separate > > entries. Is that necessary, particularly for usr/include/sys/iscsit? > > > > I was trying to follow the model I saw elsewhere in the file (e.g. > usr/include/smbsrv, usr/include/sys/sdcard). So the directory entries > themselves are unnecessary?
Where you're delivering the directory in a package, they should be. > > - Why is RADIUS authentication buried in the middle of this driver? > > Isn't RADIUS a common protocol that could reasonably be used by > > more than one project? > > > > The RADIUS code is adapted from the iSCSI initiator. That seems a little curious to me. RADIUS is generally asymmetric: it has features that an authenticator can use to offload work, but it doesn't have features for the authenticatee. Why would the *initiator* need RADIUS? > I think there is > substantial opportunity for code sharing between the two and I agree > with you that a general RADIUS implementation would be valuable. We > were planning to rationalize the code sharing between iSCSI initiator > and target back when we were going to do a single iSER initiator and > target. The situation we find ourselves in is that we are delivering > the iSCSI target on its own without iSER and without delivering any > iSCSI initiator modifications. At the same time the NWS consolidation > (which contained the iSCSI initiator) is merging into ON so we opted not > to attempt to coordinate a reorganization of the iSCSI initiator code at > the same time. I see. I think the ordinary ON response to a situation like that would probably be, "ok, then, let us know when the project is done and ready for review." Not what you'd want to hear, though. I'm a little uncomfortable finishing up a review where there are basic issues like this, because my observation is that project teams tend to disband and disappear shortly after integration, so the first delivery is often the last. I know that's not what you're intending here, and I'll just go along with this being follow-up material, but there's some risk here. (As a side issue, I'm guessing that you're also being pushed by the upcoming release, as others are. It seems a shame that one of the implications of more frequent OpenSolaris releases might be _less_ of a belief in the train model of releases as we all crowd onto "special" drops.) > I agree with your follow-on e-mail that this functionality should be in > user-space. I'll include more commentary in response to that e-mail. OK. > > - Is lbolt really a good source of random numbers for crypto > > applications? > > > > > > Again this code is adapted from existing code so I can't explain the > original rationale for using lbolt. I would be happy to file an RFE to > address this -- what should we use in place of lbolt? It's unclear to me what this code is attempting to do, because it uses both lbolt (which isn't particularly "random") plus the actual kernel random data in order to cook the hash. I was hoping there was some rationale behind it that would make it clearer (and that could probably substitute for the existing comment -- which doesn't say much at all besides what the code obviously does). If you file an RFE, it should say something like "investigate and either document _why_ the code does what it does, or fix." -- 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]
