<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">Tom – this is turning out to be a good dialog and hopefully we can generalize.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin-bottom:12.0pt">> > If we change the recommendation to include designated sections for
<br>
> > swift then case 1 becomes a NO.<br>
> <br>
> What I am seeking to confirm is any additional steps this cloud <br>
> provider would have to perform, other than "passing the capabilities".<br>
> <br>
> My guess is that they would have no obligation to (for example):<br>
> * inform the user that the object storage is not swift<br>
> * publish swift as a line item in the "versions of openstack components"<br>
> list that Joshua reminded us about (eg "swift: not used")<br>
> <br>
Good question! Sorry for the long answer.<o:p></o:p></p>
<p style="margin-bottom:12.0pt">You are correct. There is no obligation to disclose anything except “met core requirements” at this point (which include both capabilities and designated sections).
<o:p></o:p></p>
<p style="margin-bottom:12.0pt">We have discussed vendor disclosures in DefCore and at Board meetings. Generally, we believe that vendors will be eager to show OpenStack capabilities beyond core as a differentiator. So we did not feel a need to create a lot
of formalities around this part of the process.<o:p></o:p></p>
<p style="margin-bottom:12.0pt">We have not discussed any specific negative disclosure requirements like you list in DefCore. I think that may create a slippery slope of declaring things from the integrated release that are not used. To use the trademark,
vendors have to pass/include the core and can add beyond that. IMHO, they are likely to be very transparent about additions since they are differentiators. For example, the vendors using Ceph over Swift have no desire to hide that substitution.<o:p></o:p></p>
<p style="margin-bottom:12.0pt">We’re getting to enough content for a nice blog post !<o:p></o:p></p>
</div>
</body>
</html>