On Tue, 2006-08-22 at 17:08 +0800, Cathy Zhou wrote: > >As a result, I'd try and be clear about what incompatible > >changes would make this project unsuitable for a patch. For example, > >"Because x and y will be incompatible changes unsuitable for a patch or > >micro release of Solaris, this project is targeting a minor release." > > > > > Changed. Please have a look.
This is exactly the kind of information PSARC will want to have. Thanks. > >> * Vanity naming > >> > >> Today, the network names are tied to the underlying network hardware > >> (e.g., bge0, ce0). Because configuring the system requires network > >> interface names to be referenced in various administrative tasks and > >> a wide range of configuration files, being able to give a meaningful > >> vanity name to a network interface (for example, based on its > >> functionality or its topology) will help to make network configuration > >> > >> > > > >The word "topology" here might be confusing without context. Perhaps, > >"its relationship with the network topology" would be better? Other > >opinions? > > > > > I am not sure. I changed to "based on its functionality or its network > connection topology", but Meem said it hasn't been any clearer. 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.)" > >>2. Describe how your project changes the user experience, upon > >> installation and during normal operation. > >> > >> There will be no changes to installation. In the future, some follow > >> up work can be done to make configuring network interface names part > >> of the installation (optionally), therefore allowing network vanity > >> naming to be used by default. > >> > >> > > > >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. > >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)? It may be fine to do that as long as we have a transition plan for the ibd driver (which we do). > >> Although Crossbow can be implemented independently from this project, > >> with Nemo unification, Crossbow will be able to support VNICs on > >> non-GLDv3 devices. Further, the design of the project will allow the > >> vanity naming support for VNICs as well. > >> > >> > > > >That last sentence is awkward. Which project? > > > > > Changed to "the vanity naming design will allow the vanity naming > support for VNICs as well.". 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. > >>- 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. > >>- The Solaris BSM configuration carries a Common Criteria (CC) Controlled > >> Access Protection Profile (CAPP) -- Orange Book C2 -- and a Role Based > >> Access Control Protection Profile (RBAC) -- rating, does the addition > >> of your project effect this rating? E.g., does it introduce interfaces > >> that make access or privilege decisions that are not audited, does it > >> introduce removable media support that is not managed by the allocate > >> subsystem, does it provide administration mechanisms that are not audited? > >> > >> No. > >> > >> > > > >Are dladm operations audited? > > > > > What exactly does this question mean? One source of information is the Solaris Auditing section of the Security Services guide: http://docs.sun.com/app/docs/doc/816-4557/6maosrjog?q=BSM&a=view This is a 10000 foot overview. > Plus we are not the one who > introduce dladm. We just add some new sub-commands to it. 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. > >> - What parts of the project are active upon default install and how it > >> can be turned off. > >> > >> TBD. > >> > >> > > > >I suppose there could be a default vanity naming scheme that could be > >turned off... > > > > > I will put N/A for now, and add this as a question that we expect to get > opinion from PSARC. Okay. > >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. > >>16. How do the interfaces adapt to a changing world? > >> > >> TBD. > >> > >> > > > >This is a great place for you to brag about how great UV will be for > >future development of MAC and link-layer features. For example, in the > >future, new nifty features will be developed (such as Crossbow VNICs), > >and UV will have made it possible for these features to apply to _all_ > >networking interfaces, not just those that were written directly using > >GLDv3. > > > > > But this is already discussed in question 4, is it too duplicate to > repeat this here? I don't think the duplication will hurt. Some people may not read these 20 questions front-to-back, and may be looking for answers to specific questions. You could remove some duplication by referring to a previous section, but I wouldn't leave the answer blank. Thanks, -Seb
