<div dir="ltr">This is an area where I think we need to make some clearer distinctions on what OEM means.  By that I mean there are two main use cases of OEM fields:<div><br></div><div>1) OEM fields that are directly part of the phosphor reference implementation used in all of OpenBMC</div><div>2) OEM fields that are used for individual projects or corporations.</div><div><br></div><div>Minimizing number 1 is a really good goal, because we should be able to use Redfish by default in OpenBMC without needing any OEM fields. Moreover any fields that are generally needed in OpenBMC should be adopted by DMTF.</div><div><br></div><div>However, that second use case is really really different.   For example, we have some incredibly specific requirements about providing a detailed physical model of the machine to the rest of the datacenter.  When we approached DMTF about this, their recommendation was to graft this metadata into the assemblies (which is a very reasonable way to accomplish that).  As it stands right now, I don't have a really clear idea on how to sustainably add that into bmcweb.  This problem gets more thorny if a company wants to add Redfish support for a custom ASIC.</div><div><br></div><div>This is a balancing act that I think needs to be addressed in some fashion.  One possible way to square this circle is to work with DMTF on creating Redfish profiles.  That way we can have a core library that allows for the easy pluggability and ad-hoc support, but then have standard profiles that clients can design around.  I know that DMTF is very interested in creating profiles, and this might be a use case that helps drive that.</div><div><br></div><div>Regards,</div><div>Richard</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 13, 2020 at 12:36 AM Ratan Gupta <<a href="mailto:ratagupt@linux.vnet.ibm.com">ratagupt@linux.vnet.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div>On 22/01/20 3:28 AM, Patrick Williams
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>On Mon, Jan 20, 2020 at 12:43:57PM +0530, Ratan Gupta wrote:
</pre>
      <blockquote type="cite">
        <pre>1) Introduce a compile time flag in the bmcweb
</pre>
      </blockquote>
      <pre></pre>
      <blockquote type="cite">
        <pre>2) Put all the OEM specific interface functionalities in the new files.

3) Include the new files under the compile time flag as majority of the code
in bmcweb written in header file.

</pre>
      </blockquote>
      <pre>Do we want OEM commands to be in bmcweb also? </pre>
    </blockquote>
    <tt>Yes Redfish has a support for the same, However we want to
      minimize the need as much as possible by</tt><tt><br>
    </tt><tt>1) Put across your need in the community and find out if
      this is a common requirement</tt><tt><br>
    </tt><tt>2) If it is a common requirement across the openBMC
      community then propose it in the DMTF.</tt><br>
    <blockquote type="cite">
      <pre> Or more of a plugin
nature like the IPMI implementation?</pre>
    </blockquote>
    <tt>We tried the same earlier in the community call and discussed
      that we should avoid it for the following reason</tt><tt>.<br>
    </tt>
    <ul>
      <li><tt>People will start using the Oem here and there and the
          community will never know the requirement which can be
          standardized.</tt><br>
      </li>
    </ul>
    <br>
    <blockquote type="cite">
      <pre>It seems to me that there will be OEM commands that are not open source
either due to NDAs on certain hardware or secret sauce in data center
management software that various cloud vendors have.
</pre>
    </blockquote>
    <tt>Yes certain OEM cmds would be there which can not be
      standardized.</tt><br>
    <blockquote type="cite">
      <pre></pre>
    </blockquote>
    Ratan<br>
  </div>

</blockquote></div>