Nicolas,

On 02/ 1/10 01:02 PM, Nicolas Williams wrote:
> On Mon, Feb 01, 2010 at 11:59:56AM -0500, Sebastien Roy wrote:
>> 4.  Opinion
>>
>
> No opinion?

Yes, it's contained in the three subsequent sections that had incorrect 
numbering.  I've just fixed the numbering.

>
>> 5.  Futures
>>
>> A substantial amount of the discussion  centered  on  issues
>> that the project team considers to be items for future work,
>> including servers, automated  installers,  VLANs,  and  NTP.
>> The  project team explained that there are still more phases
>> coming,  and  that  this  one,  like  the  previous   phase,
>> addresses  lower-end  users,  so  these  concerns are out of
>> scope for this project.  The ARC members  agreed  with  this
>> explanation.
>>
>> An important distinction to note is that the Nevada  instal-
>> lation   (including  Jumpstart)  does  not  enable  NWAM  by
>> default.  The only installer that enables it by  default  is
>> the new OpenSolaris Caiman.
>
> Er, "Nevada installation", "JumpStart"?  Isn't Nevada (SXCE/SXDE and
> builds between releases thereof) dead?
>
> There's only the OpenSolaris installer and AI to consider.  Presumably
> AI does not enable NWAM by default, while the OpenSolaris installer
> does.

I think the opinion is still valid given the context in which the review 
happened.  The bigger point is that NWAM was only enabled by default on 
the OpenSolaris releases, and the philosophy behind that was that NWAM 
isn't ready for the enterprise and more complex networking features. 
That's still true today; NWAM isn't any more ready for the enterprise, 
and the project management teams of networking and install need to think 
about how this is going to be handled.  AFAIK, this is in fact being 
talked about.

>
>> 5.1.  VNIC Problems
>>
>> An ARC member noted that with the  existing  NWAM  Phase  0,
>> VNICs  are not brought online at boot time.  While the users
>> for which this project is designed may not have a  need  for
>> these  more advanced features, it would be desirable to have
>> the features not be in direct conflict with each other.  The
>> discussion  of  this  issue  led  to  the  technical  change
>> advised, described below.
>
> Not the right place, I know, but ISTM that there are two kinds of VNICs
> as far as NWAM should be concerned: those that should always be brought
> online (and be usable via NWAM as any other interface), and those that
> should be brought online only for specific location profiles.  (A third
> category: VNICs that should only be manually brought online and which
> should be ignored by NWAM at all times.)

Okay, I think this would be a good discussion for 
nwam-discuss at opensolaris.org.

>
>> 8.2.  Appendix B: Technical Changes Advised
>>
>>       1.   NWAM should be able to  coexist  with  VNICs.   It
>>            need  not  configure  them  in  this  phase of the
>>            project, but it should not prevent them from being
>>            used on the system by manual configuration.
>
> The first part of this TCA sounds rather ambiguous.  What does "coexist"
> imply in this context?

It means that VNICs should be brought online at boot time.

>
> The second part of this TCA sounds like a TCR to me -- it should be a
> TCR, at any rate.  That is: nothing in this or any phase of NWAM should
> "prevent [VNICs] from being used on the system by manual configuration",
> but it should be OK for this phase of NWAM to do nothing more about
> VNICs.  The TCA should cover the desire that NWAM actually do more about
> VNICs than merely ignore them.  No?

The opinion is meant to summarize what was voted on at the time of the 
review (the review happened in March of 2009).  Going back and changing 
the requirements imposed by the ARC isn't really in scope of the opinion 
review.  In this case, however, I don't think it really matters whether 
this is a TCA or a TCR.  The project team is doing the right thing and 
bringing up VNICs at boot time (if this were a TCR, they'd adhere to it 
anyway), but ignoring them as datalinks.

-Seb

Reply via email to