Dear RSSAC Caucus Members, Myself, Ken, and Robert S had a meeting yesterday to discuss the Security Incident Reporting Work Party working document. We decided to cancel the meeting on Monday July 22 because it conflicts with IETF 120. Our next work party meeting will be on August 5. We accepted some Suggestions to the working document that the work party had discussed previously and made a few more. There has been a lot of new comments and good discussion in the document so if you haven't looked at it in a while please do so if you have the time. The big edit was to accept the new text in Section 4 that the work party has been discussing. The old, now deleted text is included at the bottom of this mail so we have a record of it. https://docs.google.com/document/d/1NvSw7PoLGYhXPuMEjiBgqjCtp_khTGGEh0DaHkNJ... Thanks, Andrew Old text from Section 4: Security incidents that adversely and materially affect the availability, confidentiality, or integrity of the RSS should be reported by the affected RSO(s). This does not preclude the reporting of incidents that do not materially affect the RSS. The decision to report, or not, an incident is a context-specific decision made by the reporter based on their experience, knowledge of the RSS, understanding of the incident’s material implications for the RSS, and to be more transparent. Not all security incidents affecting the availability, confidentiality, or integrity, or availability of RSS instances come under the scope of this report. RSOs should keep in mind that reporting too many false-positive security incidents could generate “noise” and obscure real incidents. On the other hand, reporting too few incidents risks missing critical incidents. Any RSO may publish information about events that do not meet the definition or threshold of being security incidents. These reports will be published at the discretion of the RSO for additional transparency. Reports may be periodic or ad-hoc.