<div dir="ltr">Thank you for bringing this up.  I really think that some policy discussion is useful here.  I also 100% agree that forward compatibility should be our goal here.<div><br></div><div>When I think about incompatible changes I tend to group them into one of two categories:</div><div><div>1) A design change goes in the opposite direction than what previous versions offered, and the old feature needs to be shut off.</div><div></div></div><div>2) New features/designs are made, and supporting several different options at the same time is difficult</div><div><br></div><div>Security changes are often in the former category. I remember a few months back there was a thread about removing the DBus rest interface as a default service for security reasons.  Brad's point at the time was (I may be paraphrasing here) that we need to maintain support for any currently supported use case or be able to support their migration.</div><div><br></div><div>Now another point in that thread was that some users are going to care more about security than compatibility, and vice versa. One possible solution is to create a second secure phosphor reference implementation.</div><div><br></div><div>Here is the thread I'm talking about: <a href="https://lists.ozlabs.org/pipermail/openbmc/2020-February/020491.html">https://lists.ozlabs.org/pipermail/openbmc/2020-February/020491.html</a></div><div><br></div><div>Having two reference implementations (profiles, tracks, or whatever we want to call it) isn't without risk.  If things ever diverge too far, then the overhead might be larger than supporting forward compatibility.  However, I would like to get to a place where changes of that sort can be made accessible to early adopters, combined with a clearly communicated deprecation/migration plan.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 15, 2020 at 10:01 PM Andrew Jeffery <<a href="mailto:andrew@aj.id.au" target="_blank">andrew@aj.id.au</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">> Applicability.<br>
> <br>
> These guidelines are for the BMC's "intended external user interfaces".  <br>
> For example, its management interfaces including its web server and all <br>
> REST APIs.  I haven't given much thought to the BMC/host interfaces or <br>
> interfaces internal to the BMC.  IMHO, it is less important to maintain <br>
> compatibility in these areas. <br>
<br>
Lets split this. My feelings are<br>
<br>
1. Inband (BMC/Host) interfaces are in the same class as "intended<br>
external user interfaces" and therefore should not have incompatible<br>
changes unless _absolutely_ necessary. What we implement here should<br>
have passed through a specification process under e.g. DMTF.<br>
<br>
2. Interfaces between applications on the BMC (e.g. D-Bus interfaces)<br>
is the class where compatibility is less critical, on systems that do not<br>
expose the D-Bus interfaces via REST. However, while any system exists<br>
that exposes the D-Bus interfaces via REST we must constrain changes<br>
to these interfaces as well.<br>
<br>
> For example, if you need an incompatible <br>
> change in an internal interface, you have a smaller set of users who <br>
> ought to be active in the project, and can give you feedback and adapt <br>
> within a release cycle.<br>
> <br>
<br>
This is true for interfaces between BMC components, it's not true of the<br>
host firmware interfaces, hence my split above.<br>
<br>
When we remove the ability to directly access the D-Bus interfaces via<br>
REST we will gain a lot more freedom as the D-Bus interfaces then truly<br>
become internal.<br>
<br>
Andrew<br>
</blockquote></div>