<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";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-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;}
/* List Definitions */
@list l0
{mso-list-id:2063478629;
mso-list-type:hybrid;
mso-list-template-ids:1670538506 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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">Ok, I’ll give it a shot. I think we have a “Bill Clinton” issue with the word “is” here because it depends on what you mean by “is.” For DefCore, we define a project primarily by capabilities defined by the API.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> For example, in the case of an "OpenStack Powered" cloud <br>
> that offers an object store that is not swift, would they <br>
> be recommended/required to denote that actually that <br>
> particular bit was not "Openstack Powered"?<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">There are a few options based on the current recommendation:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">1)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>object store (not swift code) passes all the swift capabilities > YES, they can use the trademark<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">2)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>object store (not swift code) does not pass the swift capabilities > NO, they cannot use the trademark<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">3)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>object store (uses swift code) passes all the swift capabilities > YES, they can use the trademark<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">4)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>object store (uses swift code) does not pass the swift capabilities > NO, they cannot use the trademark<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If we change the recommendation to include designated sections for swift then case 1 becomes a NO.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Better?<o:p></o:p></p>
<p style="margin-bottom:12.0pt">> -----Original Message-----<br>
> From: Tom Fifield [mailto:tom@openstack.org]<br>
> Sent: Sunday, August 17, 2014 9:59 PM<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>
> Sorry to hear that Rob!<br>
> <br>
> Perhaps a direct reply to this example can assist?<br>
> <br>
> <br>
> > >> > >>> I'm also interested in any practical implementation <br>
> > >> > >>> concerns you think can arise based on the below suggestions.<br>
> > >> > >>><br>
> > >> > >>> For example, in the case of an "OpenStack Powered" cloud <br>
> > >> > >>> that offers an object store that is not swift, would they <br>
> > >> > >>> be recommended/required to denote that actually that <br>
> > >> > >>> particular bit was not<br>
> > >> > "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>
> <br>
> Regards,<br>
> <br>
> <br>
> Tom<br>
> <br>
> On 18/08/14 12:44, Rob_Hirschfeld@Dell.com wrote:<br>
> > Tom,<br>
> ><br>
> ><br>
> ><br>
> > I’m still missing it. I thought we’d been pretty specific in the <br>
> > examples. Perhaps we should setup a call.<br>
> ><br>
> ><br>
> ><br>
> > Really, users don’t see designated sections at all. It’s all about <br>
> > which code the vendor is required to include in their product. <br>
> > That’s not something the user would see at all and, in many cases, <br>
> > there’s no practical way to enforce it.<br>
> ><br>
> ><br>
> ><br>
> > For the capabilities, we have refstack. Users would be able to <br>
> > duplicate the test suite run against their OpenStack product and <br>
> > prove that it meets the core requirements.<br>
> ><br>
> ><br>
> ><br>
> > Does that help?<br>
> ><br>
> >> -----Original Message-----<br>
> >> From: Tom Fifield [mailto:tom@openstack.org]<br>
> >> Sent: Sunday, August 17, 2014 9:38 PM<br>
> >> To: Joshua McKenty; Hirschfeld, Rob<br>
> >> Cc:<br>
> >> Subject: Re: [OpenStack-DefCore] Please review, results from <br>
> >> Designated Sections review w/ recommendations. +1s needed<br>
> >><br>
> >> Cool - that's more like what I'm getting at - practical aspects of <br>
> >> the trademark license requirements as related to the below <br>
> >> 'designated sections', as they apply to what end users actually see.<br>
> >><br>
> >> So far I haven't seen anything remotely close to this written down, <br>
> >> and I believe it can really help with general understanding and comment.<br>
> >><br>
> >><br>
> >> Regards,<br>
> >><br>
> >><br>
> >> Tom<br>
> >><br>
> >><br>
> >> On 16/08/14 02:33, Joshua McKenty wrote:<br>
> >> > The other trademark license requirements (to publish the versions <br>
> >> > of the components being used, etc) still apply as well.<br>
> >> ><br>
> >> > Sent from my iPhone<br>
> >> ><br>
> >> > On Aug 14, 2014, at 11:09 PM,<br>
> >> > > wrote:<br>
> >> ><br>
> >> >> Tom,<br>
> >> >><br>
> >> >><br>
> >> >><br>
> >> >> I thought we had some pretty specific examples for public and <br>
> >> >> private clouds with references to specific projects. Remember, <br>
> >> >> the mark is all or nothing at this point. Vendors must pass the <br>
> >> >> required tests and use the required code to use the mark. There <br>
> >> >> is no subset or partial mark at this point.<br>
> >> >><br>
> >> >><br>
> >> >><br>
> >> >> Rob<br>
> >> >><br>
> >> >> > -----Original Message-----<br>
> >> >> > From: Tom Fifield [mailto:tom@openstack.org]<br>
> >> >> > Sent: Thursday, August 14, 2014 7:44 PM<br>
> >> >> > To: defcore-committee@lists.openstack.org<br>
> >> >><br>
> >> >> > Subject: Re: [OpenStack-DefCore] Please review, results from <br>
> >> >> > Designated Sections review w/ recommendations. +1s needed<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 <br>
> >> >> > >>> concerns you think can arise based on the below suggestions.<br>
> >> >> > >>><br>
> >> >> > >>> For example, in the case of an "OpenStack Powered" cloud <br>
> >> >> > >>> that offers an object store that is not swift, would they <br>
> >> >> > >>> be recommended/required to denote that actually that <br>
> >> >> > >>> particular bit was not<br>
> >> >> > "Openstack Powered"?<br>
> >> >> > >>><br>
> >> >> > >>> I could see that being confusing for users, and my guess <br>
> >> >> > >>> is there might be some similar cases that should be <br>
> >> >> > >>> managed :)<br>
> >> >> > >>><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<br>
> >> >> 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-openstacksummitatl201<br>
> >> >> > >> 4-<br>
> >> cor<br>
> >> >> > >> e-v ia<br>
> >> >> > >> -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-<br>
> >> >> > >> re<br>
> >> >> > >> v<br>
> >> >> > >> ie<br>
> >> >> > >> w)<br>
> >> >> > >><br>
> >> >> > >><br>
> >> >> > >><br>
> >> >> > >> These are also discussed on my blog at <br>
> >> >> > >> http://www.slideshare.net/rhirschfeld/oscon-2014-def-core-r<br>
> >> >> > >> ev<br>
> >> >> > >> i<br>
> >> >> > >> ew<br>
> >> >> > >><br>
> >> >> > >><br>
> >> >> > >><br>
> >> >> > >> Please let me know if those examples help explain the use <br>
> >> >> > >> of 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>
> >> >><br>
> >> >> > >>> Subject: Re: [OpenStack-DefCore] Please review, results <br>
> >> >> > >>> from Designated Sections review w/ recommendations. +1s <br>
> >> >> > >>> 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 <br>
> >> >> > >>> to the use of Keystone."<br>
> >> >> > >>><br>
> >> >> > >>><br>
> >> >> > >>> I'm also interested in any practical implementation <br>
> >> >> > >>> concerns you think can arise based on the below suggestions.<br>
> >> >> > >>><br>
> >> >> > >>> For example, in the case of an "OpenStack Powered" cloud <br>
> >> >> > >>> that offers an object store that is not swift, would they <br>
> >> >> > >>> be recommended/required to denote that actually that <br>
> >> >> > >>> particular bit was not<br>
> >> >> > "Openstack Powered"?<br>
> >> >> > >>><br>
> >> >> > >>> I could see that being confusing for users, and my guess <br>
> >> >> > >>> is there might be some similar cases that should be <br>
> >> >> > >>> managed :)<br>
> >> >> > >>><br>
> >> >> > >>><br>
> >> >> > >>> Regards,<br>
> >> >> > >>><br>
> >> >> > >>><br>
> >> >> > >>> Tom<br>
> >> >> > >>><br>
> >> >> > >>> On 15/08/14 04:54, Rob_Hirschfeld@Dell.com<br>
> >> >> wrote:<br>
> >> >> > >>>> DefCore,<br>
> >> >> > >>>><br>
> >> >> > >>>><br>
> >> >> > >>>><br>
> >> >> > >>>> We had a small turn out and very good discussions that <br>
> >> >> > >>>> were able to produce clear guidance for Designated <br>
> >> >> > >>>> Sections (see below). We also reviewed the Havana <br>
> >> >> > >>>> capabilities from the board meeting and the 10 designated <br>
> >> >> > >>>> sections principles approved by email. Finally, we setup <br>
> >> >> > >>>> a calendar for community review leading up to the <br>
> >> >> > >>>> 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<br>
> >> >> > >>>> 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 <br>
> >> >> > >>>> this<br>
> > 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<br>
> >> >> , *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>
> >> >><br>
> >> >> > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcor<br>
> >> >> > >>> e-<br>
> >> >> > >>> c<br>
> >> >> > >>> om<br>
> >> >> > >>> mit<br>
> >> >> > >>> te<br>
> >> >> > >>> e<br>
> >> >> > >><br>
> >> >> > ><br>
> >> >> > ><br>
> >> >> > > _______________________________________________<br>
> >> >> > > Defcore-committee mailing list <br>
> >> >> > > Defcore-committee@lists.openstack.org<br>
> >> >><br>
> >> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-<br>
> >> >> > > co<br>
> >> >> > > m<br>
> >> >> > > mi<br>
> >> >> > > tte<br>
> >> >> > > e<br>
> >> >> > ><br>
> >> >> ><br>
> >> >> ><br>
> >> >> > _______________________________________________<br>
> >> >> > Defcore-committee mailing list <br>
> >> >> > Defcore-committee@lists.openstack.org<br>
> >> >><br>
> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-co<br>
> >> >> > mm<br>
> >> >> > i<br>
> >> >> > tt<br>
> >> >> > ee<br>
> >> >><br>
> >> >> _______________________________________________<br>
> >> >> Defcore-committee mailing list<br>
> >> >> Defcore-committee@lists.openstack.org<br>
> >> >><br>
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-comm<br>
> >> >> it<br>
> >> >> t<br>
> >> >> ee<br>
> ><o:p></o:p></p>
</div>
</body>
</html>