Commitment
==================
Name:           Brussels - enhanced network driver configuration via dladm
Submitter:      Sowmini Varadhan
Owner:          James Carlson
Intern:         Garrett D'Amore
Interest:       brussels-interest@sun.com
Status:         commitment scheduled 10/17/2007
Exposure:       open
Comment:

SUMMARY
=======

        Dynamic configuration of network drivers on Solaris is done primarily
        via ndd(1M). This approach, and the general methods available for
        network driver configuration in Solaris, suffer from several
        problems:

        * changes made by ndd(1M) are not persistent across reboot/modunload.
        * There are too many ways to modify a given property,
          e.g., ndd, driver.conf(4)
        * each method has its own syntax and semantics, and it is
          easy to encounter conflicting semantics (e.g., CR 6504688)
        * Some of these methods are very complicated and inflexible.
          For example, driver.conf(4) is over-written on upgrade,
          and updates to driver.conf files require a reboot/update_drv
          of the driver. (See CR 6396173, CR 6430731).

        Project Brussels aims to fix these problem for GLDv3 drivers by
        providing a dladm based standardized interface. Specifically,
        this project will provides a cleaner solution by using the dld
        layer as the intermediary. 

ISSUES
=======
jdc-1   Why does the release note say: "to be marked Obsolete in an
        [sic] future release"?  Shouldn't users start using dladm as
        soon as it integrates?  If so, then ndd is obsolete _now_.

        Same issue for ndd(1m) man page update: if users are supposed
        to switch now, then ndd for L2 admin is obsolete now, not
        later, and should be called out as obsolete.

        "Obsolete" means "still present in the system, but discouraged
        for use."

ANSWER: 	AGREED by Project Team
SUGGESTION: 	Create a fast-track to make a wrapper around ndd, to remove 
		some of this from Nevada, command line call to ndd.
ANSWER: 	Out of scope for this project.


ged-05 What about power management of link interfaces? (e.g. switching down to
 		100Mbps when traffic conditions permit it.) This will require some new 
		properties, and maybe changes to the proposed adv_xxx properties. 

ANSWER: The adv properties are known. We don't have power mgmt widely prevalent. 
	Leave adv for auto-negotiations and add aditional set of variable such 
	as  for power mgmt so it will tell you what pm was avail at that time 
	for the link. 
SUGGESTION: Defer separation of this until we need it. You and project team 
	should talk about this more. 

Conclusion: 
TCA -command line interface should have separate configuration and
obeservation, set/reset properties.

gw - Are Auditing and priveleges orthoganal to the Wifi audit and authorization. Correct?
sv - Yes.

kb - Change docs to show NDD to configure network devices in obsolete. 
sv -The properties are in the design document.

====
Approve - Kais Belgaied, Glenn Skinner, Gary Winiger, Jim Carlson
Deny - 
Abstain - 
Not Participating (NP) - 



THE NEXT STEP
=============
The hardware checksum facilities are nice to have for future projects.
TCA -command line interface should have separate set/reset properties.

Garrett to write draft opinion.