On (10/17/07 10:26), Garrett D'Amore wrote: > > A few quick comments on the Brussels case. > > 20q, question #8. I think the answer here should have been Yes, because > Brussels provides a consistent interface to NIC management, thereby > improving Serviceability. (Not impacting the R and A components of RAS, > though.)
Accept, and some of that is implied by the answer to the subsequent question on diagnosing failures. > 20q, question #9. It appears that kstats are a Phase II deliverable. > Does it deserve mention here? The Phase II deliverables have not been scoped out to fine granularity, but so far, the main objective there is to change the "under-the-hood" implementation of kstats themselves, rather than to export any new kstats. We may end up doing the latter, but those details will be provided by the PSARC case associated with this work. > 20q, question #10. I think that the security implication here is that > Brussels uses RBAC to control access to NIC configuration. That's not > precisely the same as "none". right- Gary and I had an earlier discussion about this; we are planning to leverage on the same RBAC infrastructure currently used by dladm for managing wifi and aggr interfaces. Perhaps I should mention this explicitly? > I still want to address my issue of power management that I raised > separately earlier this week, during the review. I'm not sure whether it > is fair to edit the issues file in the commitment materials directory or > not? (Sorry, Brussels folk, you have the dubious distinction of being the > first case I've interned on to go for commitment review.) I think (other PSARC members can confirm) the usuual procedure is to add to the issues file, and bring it up during review. --Sowmini
