On Wed, 2006-08-23 at 12:05 +0800, Cathy Zhou wrote: > >>>> - How does this project's administrative mechanisms fit into Sun's system > >>>> administration strategies? E.g., how does it fit under the Solaris > >>>> Management Console (SMC) and Web-Based Enterprise Management (WBEM), how > >>>> does it make use of roles, authorizations and rights profiles? > >>>> Additionally, how does it provide for administrative audit in support of > >>>> the Solaris BSM configuration? > >>>> > Added: > > " Note that dladm is currently part of Network Management execution profile, > and users must be granted access to a role with that profile in order to > successfully invoke its subcommands. The dladm rename-link subcommand will > need the same profile. We don't think it needs additional priviledge as > renaming an interface is not much different from specifying a name when > creating an interface (a tunnels, a VLAN or an aggregation)."
Looks good (except s/priviledge/privilege). > > Right, but I'm not comfortable enough with how auditing actually works > > to authoritatively state that the new sub-commands will be audited or > > not. Renaming objects is explicitly something that the auditing guide > > states must be audited, so I'm a bit uncomfortable answering "No" to the > > question without understanding why that's a good answer. > > > But creating the object is not audited, I don't see why rename-link is > special. > > It looks auditing should recording security-relevant events. Does dladm > belongs to this category? I'm not sure, I'd have to learn more about auditing to be able to say how this relates. > >>>> 16. How do the interfaces adapt to a changing world? > >>>> > > I don't think the duplication will hurt. > > Okay. Here is the wording: > > " As discussed in question 4, this project allows the future development > of MAC and link-layer features, like Stack Instances and Crossbow, to > apply to all network interfaces, not just those were written directly > using GLDv3." Looks good. Thanks, -Seb
