<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Sorry for the slow response… I’m reviewing these.  There’s a approved refstack spec about this also that we should incorporate into any plans. 
<o:p></o:p></p>
<p style="margin-bottom:12.0pt">> -----Original Message-----<br>
> From: Tom Fifield [mailto:tom@openstack.org]<br>
> Sent: Tuesday, August 19, 2014 12:50 AM<br>
> To: Hirschfeld, Rob; joshua@pistoncloud.com<br>
> Cc: defcore-committee@lists.openstack.org<br>
> Subject: Re: [OpenStack-DefCore] Please review, results from <br>
> Designated Sections review w/ recommendations. +1s needed<br>
> <br>
> I'm pretty much blocked out until the ops meetup is over (say 1st <br>
> September or<br>
> so) - when is that board meeting again?<br>
> <br>
> but anyway, here's what I'm thinking:<br>
> <br>
> Simple webapp that does away with everything but components, <br>
> explaining the complex bits only in context for what a potential <br>
> trademark applicant is trying to do with components.<br>
> <br>
> so, two parts:<br>
> <br>
> 1) the form (static html) - what is the activity {run a cloud, make a <br>
> storage product etc}, what trademark {powered, compatible, etc}, and <br>
> which components are being used<br>
> <br>
> 2) the result page (a template, filled in by some code based on the <br>
> form<br>
> selections)<br>
> <br>
> that talks about whether the components they've ticked are enough, and <br>
> also about what they're allowed to do with those components.<br>
> Ideally, each component name would link off to a dedicated page for <br>
> that component explaining the 'designated sections' and required API things.<br>
> <br>
> mockups attached - very, very rough!<br>
> <br>
> <br>
> I'd propose to create this and circulate it so that the community can <br>
> understand the impact of the suggested designated sections before the board meeting.<br>
> <br>
> <br>
> <br>
> Regards,<br>
> <br>
> <br>
> Tom<br>
> <br>
> On 15/08/14 14:04, Rob_Hirschfeld@Dell.com wrote:<br>
> > Tom / Josh,<br>
> ><br>
> ><br>
> ><br>
> > We can update the examples; however, I think that we could use some <br>
> > help here. You can I are very close to the material and make <br>
> > assumptions about reader knowledge when explaining it.<br>
> ><br>
> ><br>
> ><br>
> > It would be helpful to have someone (Tom?) with a fresh perspective <br>
> > take a pass at it.<br>
> ><br>
> ><br>
> ><br>
> > Rob<br>
> ><br>
> >> -----Original Message-----<br>
> >> From: Tom Fifield [mailto:tom@openstack.org]<br>
> >> Sent: Thursday, August 14, 2014 7:52 PM<br>
> >> To: Joshua McKenty<br>
> >> Cc: defcore-committee@lists.openstack.org<br>
> >> Subject: Re: [OpenStack-DefCore] Please review, results from <br>
> >> Designated Sections review w/ recommendations. +1s needed<br>
> >><br>
> >> All good with me :) Though, I would note the timeframe here is short.<br>
> >> We obviously want the community to be able to understand the real <br>
> >> impact of these suggested designated suggestions and comment on <br>
> >> them well before any board meeting, so revisited sooner the better IMO!<br>
> >><br>
> >><br>
> >> Regards,<br>
> >><br>
> >><br>
> >> Tom<br>
> >><br>
> >><br>
> >> On 15/08/14 10:47, Joshua McKenty wrote:<br>
> >> > Tom, those examples we're put together before the trademark was <br>
> >> > changed<br>
> >> by the foundation staff. We may need to revisit those practical concerns.<br>
> >> ><br>
> >> > Sent from my iPhone<br>
> >> ><br>
> >> >> On Aug 14, 2014, at 7:43 PM, Tom Fifield wrote:<br>
> >> >><br>
> >> >> Hit send too soon :) I also didn't find any "practical <br>
> >> >> implementation concerns" in those slides - that would also be <br>
> >> >> appreciated :)<br>
> >> >><br>
> >> >><br>
> >> >>>>> I'm also interested in any practical implementation concerns <br>
> >> >>>>> you think can arise based on the below suggestions.<br>
> >> >>>>><br>
> >> >>>>> For example, in the case of an "OpenStack Powered" cloud that <br>
> >> >>>>> offers an object store that is not swift, would they be <br>
> >> >>>>> recommended/required to denote that actually that particular <br>
> >> >>>>> bit was<br>
> >> not "Openstack Powered"?<br>
> >> >>>>><br>
> >> >>>>> I could see that being confusing for users, and my guess is <br>
> >> >>>>> there might be some similar cases that should be managed :)<br>
> >> >><br>
> >> >><br>
> >> >> Regards,<br>
> >> >><br>
> >> >><br>
> >> >> Tom<br>
> >> >><br>
> >> >>> On 15/08/14 10:41, Tom Fifield wrote:<br>
> >> >>> Hi Rob,<br>
> >> >>><br>
> >> >>> Thanks for the reply :)<br>
> >> >>><br>
> >> >>> I actually find these pretty complicated - is there a chance <br>
> >> >>> for some simpler ones?<br>
> >> >>><br>
> >> >>><br>
> >> >>> Regards,<br>
> >> >>><br>
> >> >>><br>
> >> >>> Tom<br>
> >> >>><br>
> >> >>>> On 15/08/14 09:59, Rob_Hirschfeld@Dell.com wrote:<br>
> >> >>>> Tom,<br>
> >> >>>><br>
> >> >>>><br>
> >> >>>><br>
> >> >>>> I agree!<br>
> >> >>>><br>
> >> >>>><br>
> >> >>>><br>
> >> >>>> Josh and I did a presentation with examples in ATL<br>
> >> >>>> (http://www.confreaks.com/videos/3695-openstacksummitatl2014-<br>
> cor<br>
> >> >>>> e<br>
> >> >>>> -<br>
> >> v<br>
> >> >>>> ia-crowd-sourcing-defcores-tempest-in-a-docker-container-tcup<br>
> >> >>>> ) and I gave an updated version at OSCON <br>
> >> >>>> (http://www.slideshare.net/rhirschfeld/oscon-2014-def-core-rev<br>
> >> >>>> ie<br>
> >> >>>> w<br>
> >> >>>> )<br>
> >> >>>><br>
> >> >>>><br>
> >> >>>><br>
> >> >>>> These are also discussed on my blog at <br>
> >> >>>> http://www.slideshare.net/rhirschfeld/oscon-2014-def-core-revi<br>
> >> >>>> ew<br>
> >> >>>><br>
> >> >>>><br>
> >> >>>><br>
> >> >>>> Please let me know if those examples help explain the use of <br>
> >> >>>> the mark better.<br>
> >> >>>><br>
> >> >>>><br>
> >> >>>><br>
> >> >>>> Thanks<br>
> >> >>>><br>
> >> >>>>> -----Original Message-----<br>
> >> >>>>> From: Tom Fifield [mailto:tom@openstack.org]<br>
> >> >>>>> Sent: Thursday, August 14, 2014 6:14 PM<br>
> >> >>>>> To: defcore-committee@lists.openstack.org<br>
> >> >>>>> Subject: Re: [OpenStack-DefCore] Please review, results from <br>
> >> >>>>> Designated Sections review w/ recommendations. +1s needed<br>
> >> >>>>><br>
> >> >>>>> Hi Rob,<br>
> >> >>>>><br>
> >> >>>>> Can you provide a few example uses of the commercial marks <br>
> >> >>>>> based on<br>
> >> below?<br>
> >> >>>>><br>
> >> >>>>> eg "I can call my cloud "OpenStack Powered" without regard to <br>
> >> >>>>> the use of Keystone."<br>
> >> >>>>><br>
> >> >>>>><br>
> >> >>>>> I'm also interested in any practical implementation concerns <br>
> >> >>>>> you think can arise based on the below suggestions.<br>
> >> >>>>><br>
> >> >>>>> For example, in the case of an "OpenStack Powered" cloud that <br>
> >> >>>>> offers an object store that is not swift, would they be <br>
> >> >>>>> recommended/required to denote that actually that particular <br>
> >> >>>>> bit was<br>
> >> not "Openstack Powered"?<br>
> >> >>>>><br>
> >> >>>>> I could see that being confusing for users, and my guess is <br>
> >> >>>>> there might be some similar cases that should be managed :)<br>
> >> >>>>><br>
> >> >>>>><br>
> >> >>>>> Regards,<br>
> >> >>>>><br>
> >> >>>>><br>
> >> >>>>> Tom<br>
> >> >>>>><br>
> >> >>>>>> On 15/08/14 04:54, Rob_Hirschfeld@Dell.com wrote:<br>
> >> >>>>>> DefCore,<br>
> >> >>>>>><br>
> >> >>>>>><br>
> >> >>>>>><br>
> >> >>>>>> We had a small turn out and very good discussions that were <br>
> >> >>>>>> able to produce clear guidance for Designated Sections (see <br>
> >> >>>>>> below). We also reviewed the Havana capabilities from the <br>
> >> >>>>>> board meeting and the 10 designated sections principles <br>
> >> >>>>>> approved by email. Finally, we setup a calendar for <br>
> >> >>>>>> community review leading up to the September Board meeting<br>
> >> >>>>>><br>
> >> >>>>>><br>
> >> >>>>>><br>
> >> >>>>>> Here are the recommendations:<br>
> >> >>>>>><br>
> >> >>>>>> · Havana Nova is by default designated except scheduler, <br>
> >> >>>>>> filter, drivers, API extensions and networking.<br>
> >> >>>>>><br>
> >> >>>>>> · Havana Swift has no designated code due to lack of <br>
> >> >>>>>> consensus (see principles)<br>
> >> >>>>>><br>
> >> >>>>>> · Havana Keystone is not designated.<br>
> >> >>>>>><br>
> >> >>>>>> · Havana Glance designated sections are the API <br>
> >> >>>>>> implementation code and domain model.<br>
> >> >>>>>><br>
> >> >>>>>> · Havana Cinder designated sections are the API <br>
> >> >>>>>> implementation code<br>
> >> >>>>>><br>
> >> >>>>>> · Havana Neutron has no designated sections.<br>
> >> >>>>>><br>
> >> >>>>>> · Havana Heat is not a core capability, no position at this time.<br>
> >> >>>>>><br>
> >> >>>>>> · Havana Horizon is not a core capability, no position at <br>
> >> >>>>>> this<br>
> > time.<br>
> >> >>>>>><br>
> >> >>>>>> · other projects do not are not core capabilities and are <br>
> >> >>>>>> not reviewed at this time.<br>
> >> >>>>>><br>
> >> >>>>>><br>
> >> >>>>>><br>
> >> >>>>>> Please contribute to a discussion or +1<br>
> >> >>>>>><br>
> >> >>>>>><br>
> >> >>>>>><br>
> >> >>>>>> Rob<br>
> >> >>>>>><br>
> >> >>>>>> *______________________________*<br>
> >> >>>>>><br>
> >> >>>>>> *Rob Hirschfeld*<br>
> >> >>>>>><br>
> >> >>>>>> Sr. Distinguished Cloud Solution Architect<br>
> >> >>>>>><br>
> >> >>>>>> *Dell*| Cloud Edge, Data Center Solutions**<br>
> >> >>>>>><br>
> >> >>>>>> *cell*+1 512 909-7219 *blog* robhirschfeld.com, *twitter* <br>
> >> >>>>>> @zehicle<br>
> >> >>>>>><br>
> >> >>>>>> Please note, I am based in the CENTRAL (-6) time zone<br>
> >> >>>>><br>
> >> >>>>><br>
> >> >>>>> _______________________________________________<br>
> >> >>>>> Defcore-committee mailing list <br>
> >> >>>>> Defcore-committee@lists.openstack.org<br>
> >> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-c<br>
> >> >>>>> om<br>
> >> >>>>> m<br>
> >> >>>>> it<br>
> >> >>>>> tee<br>
> >> >>><br>
> >> >>><br>
> >> >>> _______________________________________________<br>
> >> >>> Defcore-committee mailing list<br>
> >> >>> Defcore-committee@lists.openstack.org<br>
> >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-com<br>
> >> >>> mi<br>
> >> >>> t<br>
> >> >>> te<br>
> >> >>> e<br>
> >> >><br>
> >> >><br>
> >> >> _______________________________________________<br>
> >> >> Defcore-committee mailing list<br>
> >> >> Defcore-committee@lists.openstack.org<br>
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-comm<br>
> >> >> it<br>
> >> >> t<br>
> >> >> ee<br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> Defcore-committee mailing list<br>
> >> Defcore-committee@lists.openstack.org<br>
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committ<br>
> >> ee<br>
> ><o:p></o:p></p>
</div>
</body>
</html>