> Maybe concrete examples would be better than any description. How
> about, "being able to give a meaningful vanity name to a network
> interface (e.g., netmanagement0 for an interface dedicated to network
> management, or upstream2 for an ISP-facing interface.)"
>
Changed. Thank you!
>>> Hmm, this is something that we may want to discuss again prior to going
>>> to PSARC. We will undoubtedly be asked, "why won't Solaris choose
>>> useful vanity names by default from the start"? It's a valid question,
>>> and it's something that I'm sure some administrators would welcome.
>>>
>>>
>> I will make it in the scope of our project.
>
> Another thing to keep in mind as we discuss this aspect of the project
> is that if we don't have a default naming policy (other than
> driver-based naming), then administrators may never know that vanity
> naming exists unless someone tells them about it or they happen to be
> reading documentation. On the other hand, when they install a fresh
> system and see that the network interface is named net0, they may be
> interested and see that there's a new feature behind this change that
> they need to learn about.
>
> Anyway, we might get a better discussion on this topic if we pull it out
> into its own thread.
>
Okay.
>>> Are we going to state that the ibd GLDv3 port will be integrated prior
>>> to UV? Is that the current plan?
>>>
>>>
>> Is that in our control?
>
> We have some control over that, but the root of my question had more to
> do with whether we believe this is a prerequisite for UV. Does it make
> sense to putback UV when there are still ibd interfaces that cannot take
> advantage of GLDv3 features (contradicting some of UV's claims of
> unification)?
>
Yes, it is better that ibd can be ported to GLDv3 before we integrate, so
that all interfaces can be consistent and the consistency is a primary goal
of Clearview.
I will talk to Nitin and see what's his plan.
> How about, "Further, this project's design will allow vanity naming of
> VNICs as well"? "This" is more specific than "the", as "this" project
> is the one under review.
>
Changed.
>>>> - 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?
>>>>
>>>> N/A
>>>>
>>>>
>>> We may need to look deeper into this. Specifically, is renaming a
>>> network interface something that could be delegated separately from
>>> other networking administrative tasks? If so, do we need to create
>>> special authorizations or privileges for the rename tasks?
>>>
>>>
>> Why this needs different priviledge from giving a vanity name when
>> creating a VLAN, or a tunnel?
>
> I was asking the question more as the devil's advocate, because someone
> else may ask it, and we'll need an answer for it. If the answer is that
> we're not introducing anything more than what dladm uses today, then
> that's a fine answer. I'd put that information here.
>
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)."
> 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?
>>> On a related note, why are these Consolidation Private rather than
>>> Project Private? Are you expecting other parts of ON to call these
>>> directly?
>>>
>>>
>> I changed them to project private and added some comments.
>
> Since this is a rather large project, I would consider removing
> project-private interfaces from the interface table entirely unless you
> feel that someone will want to contract these in the future.
>
Removed.
>>>> 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."
Thanks
- Cathy
