<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Mike</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Apologies if this sounds harsh. I want to be open and clear. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">We have a draft proposal on the table. Re-using an existing protocol was the basis that Kathleen Moriarty agreed to proceed(the secevents area director). The IESG specifically wanted us to use NETCONF. Apparently, the IETF is sensitive to the number of mgmt protocols being defined for specific purpose. The agreement with IESG to proceed was based on profiling scim which is closest to our community's stacks with many open source implementations available. Code is available now. All that is needed is agreement on the configuration schema and people can implement and try it out. <br><br>Despite all this, Dick seems to want to ignore individual contributions without debate and start fresh with no technical reason for doing so. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">If we are going to design yet another protocol there needs to be a strong technical and/or legal reason to make the amount of work worthwhile. Do not underestimate what it takes to write interoperable http CRUD/Restful specs when there as many server implementers as clients. Restful protocols are using implementer by one party. RISC and SECEVENTS is different. There are as many service providers as clients. I for one do not want want to implement a bunch of custom connectors that are only loosely interoperable. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Best regards,</div><div id="AppleMailSignature"><br>Phil</div><div><br>On Feb 20, 2017, at 2:58 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
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]-->
<div class="WordSection1">
<p class="MsoNormal">I have some observations and recommendations to share from the RISC face-to-face meeting that I attended on Thursday. I’ll say up front that I believe that the mission of RISC is incredibly important, which is why I’m taking the time to
write this now.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The thing that most surprised me about the working group meeting was that none of the time was used to enable trial exchanges of incident and compromise data among the working group participants. I had expected that to be the working group’s
highest priority – especially in light of the preliminary exchanges between Google and Microsoft being so encouraging. As such, I expected that work on producing standard representations of RISC data would be foremost on the agenda – something that didn’t
occur.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Instead, my observation was that essentially all the time was spent on defining mechanisms for establishing and administering feeds of data (and defining terminology for those feeds). I would assert that this is not where the RISC WG can
add the most value. Indeed, I would suggest that the working group <i>make a deliberate decision not to work on delivery mechanisms</i>, but instead to encourage the IETF SecEvent working group to do that work. Instead, choose to spend your time doing whatever
it takes to make numerous data exchanges happen as soon as possible, so the working group can learn from them. Heck, FTP or HTTPS are fine transports for these initial exchanges. Actual feeds aren’t needed yet.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It would be my hope that the working group can make a goal to have completed at least 20 bi-lateral RISC data exchanges involving at least 8 participants by the Internet Identity Workshop in October, 2017 – with at least half of these exchanges
using draft-standard RISC data representations. And hopefully talk about the lessons learned during IIW. That would be something to get truly excited about!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I hope that RISC will choose to focus first on Risk and Incident Sharing and Coordination and leave defining transports to others, as that is not where RISC adds the most value.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> -- Mike<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Openid-specs-risc mailing list</span><br><span><a href="mailto:Openid-specs-risc@lists.openid.net">Openid-specs-risc@lists.openid.net</a></span><br><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-risc">http://lists.openid.net/mailman/listinfo/openid-specs-risc</a></span><br></div></blockquote></body></html>