On Tue, Jul 14, 2015 at 10:59 AM, David Woolf <da...@iol.unh.edu> wrote:
> Hi Matt, > Thanks for commenting, my initial thoughts are inline below in blue: > > > - Second is full holding strong transparency & privacy <snip> > > > Agree on the transparency for scripts, procedures, config files etc...I > will add that to the proposal, its an important point. Results (I believe) > should be treated differently however. > > I'm wary of publicly listing failures, but an open discussion here is > worthwhile. A couple points to consider > - we want our public list to show what's working. If a product (or certain > combination of products) isn't listed, its already a red flag that its > either a) not yet tested b) failed. Either way there's work to be done. > - We want people to look at this list/matrix as evidence of what works, > not scouring it looking for the failures. > - the possibility that failures may be publicly aired, may become a > deterrent for companies to even participate. > - not listing the failures eliminates the last issue you raise, i.e. a > module is listed as failing because a NOS programmed it incorrectly > Agree that results need special treatment and don't "go public by default". The obvious end goal of "Consumer Report" is clear, however language is needed to specify that exact scenario you mention. Advertising a failing item isn't doing a positive service for anyone, however members need to be encouraged to remedy problems when they arise. Not sure how to word some equal ground here, maybe a negative test is given a "TTL" or timeout to become compliant with all the parties involved, otherwise it never makes it to the public site. It may also seem a bit weird if all of public matrix data is 100% positive with no defects or failures, maybe some generic reporting is a half-way common ground "X number of pluggables had issues with Y and Z number of switch unique pairs" - without listing the member or organization by name? > - A clause or some wording around the use of press - generally UNH-IOL > events and activities have strict rules against any participant from doing > media capture (video, photos, etc). This makes sense for a traditional > consortium that may have pre-release or pre-production equipment, however > in the case of Open Networking - many of the products are GA and existing > mass market. It seems incredibly important for us (under the OCP charter) > to continue education in the industry, presenting media is crucial to this > effort. Obviously members could opt out if requested, but generally I'd > like to see something a bit more flexible then "request UNH-IOL staff to > operate the camera, only group shots, no close-ups" norm. This could be > worded under the Public Relations section. > > Ahhh! Change scares me! Just kidding. Sort of. I'd like to hear other > opinions on this as well. I get that education is important, and we need to > have a way to enable that. Speaking for myself, much of my role at > UNH-IOL has been ensuring confidentiality and protecting confidential > information about products at plugfests and in our test beds. So, going in > the other direction is disconcerting for me, but I recognize that the Open > Networking community is unique in this regards. I see the value in opening > this up, but I do think their should be some limits in place, but relax > those limits from where were are today (the 'no close ups' norm you > mentioned). Do you have any proposed wording for this? > I'm not a lawyer, so my wording isn't useful here ;) It's important from a marketing prospective that we get improved media access then the past two plugfests, how this is crafted I'd defer to you and Carlos. For example, we had an impressive gathering of pluggable, NOS, and end-users in a conference room - even capturing that collaboration with no audio but only video would be useful. Thank you for the prompt response. --Matt
_______________________________________________ opencompute-networking mailing list Unsubscribe: http://lists.opencompute.org/mailman/options/opencompute-networking opencompute-networking@lists.opencompute.org http://lists.opencompute.org/mailman/listinfo/opencompute-networking
