>Thank you for writing this, it's excellent. Comments in-line: > > Thank you for your comments! Please see my replies inline. Note that some of your comments are clear so I accepted them directly.
>>1. What specifically is the proposal that we are reviewing? >> >I'd mention up front in this section that this is part of the Clearview >project and is thus part of the umbrella case. > > Added. >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. >> * Nemo unification >> >> While GLDv3 provides a new network driver framework with enhanced >> features such as link aggregation, it also introduces a confusing >> administrative model, since only GLDv3-based devices can be managed >> by dladm(1M). Further, legacy devices can not make use of the >> performance enhancement or fancy features GLDv3 provides, such as >> the DL_CAPAB_POLL and DL_CAPAB_SOFT_RING capabilities. >> >> > >Seeing as how we are fairly certain at this point that softmac over >legacy devices will not result in a performance improvement over vanilla >legacy devices, I'm not sure I'd include that last sentence. It makes >it sound as if softmac will result in a net improvement in performance. >That's certainly not the goal. > >I'd mention VLANs as a GLDv3 feature here as well. > > Changed. >> * 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. >>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. >>- What does the user perceive when the system is upgraded from a >> previous release? >> >> None. >> >> > >This is an understatement. :-) If the system had interfaces using >legacy drivers, the administrator will have some new GLDv3-related >administrative tools at his disposal to manage his network interfaces. >The perception will be that all network interfaces have the same set of >features. > > Changed. >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? >> 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 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 would not say, "This file should not be corrupted by failures". I >>don't know what that means. Instead, I would simply say, "If this file >>is corrupted, then the system ..." >> >> Fixed >>- 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? Plus we are not the one who introduce dladm. We just add some new sub-commands to it. >> - What privileges beyond what a common user (e.g. 'noaccess') can >> perform does this project require and why those are necessary. >> >> > >PRIV_SYS_NET_CONFIG? > > added "The dladm utility currently requires both PRIV_SYS_NET_CONFIG and PRIV_NET_RAWACCESS to successfully invoke its subcommands. This will not be changed in this project." > > >> - 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. > > >>- Command line or calling syntax: >> What options are supported? (please include man pages if available) >> >> This project will introduce several new subcommands and options to >> dladm(1M). See details in section 4.5.1 in the one pager. >> >> > >It would be extremely helpful to provide the man page changes as part of >the materials in this case, and they could be referred to directly here. >The one pager really shouldn't be the primary architectural >specification. The design document would at least be a much better >source of information than the one pager. > > I changed to referring to the design spec. >> Interfaces Exported >>Interface Classification Comments >>--------------- >>mac_open() >>mac_close() Consolidation Private >> >> > >Why are these included as exported interfaces? > > it should be: mac_open_t mc_open; mac_close_t mc_close; >>----------------- >>net_postattach >>net_predetach Consolidation Private >>------------------- >>softmac_create >>softmac_destroy Consolidation Private >> >> > >Same comment for these, most reviewers will have no idea what these >strings mean without some minimal context (a reference to a >specification would be appropriate). > >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. > > >>--------- >>libdladm Consolidation Private >> >> > >The library itself is not something this project exports. Are we >exporting new functions? > > Yes, the new functions. I've made that clear. > > >>--------------- >>dacf_get_dev() Consolidation Private >>--------------- >>DL_IOC_VLAN_CAPAB Consolidation Private >> >> > >Pointers to specs will be needed. Same comment for other exported >interfaces. (i.e.: design doc section numbers) > > Done. >>- Is there a public namespace? (Can third parties create names in your >> namespace?) How is this administered? >> >> Yes, the /dev/net namespace. It will be used to keep all of the >> available interfaces on the system. Each interface will have a DLPI >> style-1 /dev/net node with the same name as its interface name. >> >> Interface names will be administered using dladm(1M) utility. >> >> > >Here, you should provide a pointer to the specification that describes >what ends up in /dev/net. The semantics behind what ends up in which >subdirectories under /dev was a point of contention during the devname >review. > > Okay. >>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? >>19. Please identify any issues that you would like the ARC to address. >> >>- Interface classification, deviations from standards, architectural >> conflicts, release constraints... >>- Are there issues or related projects that the ARC should advise the >> appropriate steering committees? >> >> None. >> >> > >If we can't come to an agreement about the default behavior of vanity >naming on a fresh install (e.g., automatic naming using net0, net1), >then perhaps the ARC can provide some guidance. > > Added. I attached the updated doc here and the one in http://clearview.east/docs/uv_20q.txt is also updated. Thanks - Cathy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uv_20q.txt URL: <http://mail.opensolaris.org/pipermail/clearview-discuss/attachments/20060822/2b5d91aa/attachment.txt>
