Hi Dan! > -----Original Message----- > From: Roman Danyliw > Sent: Monday, October 26, 2020 7:51 PM > To: 'Dan Harkins' <dharkins@xxxxxxxxxx>; ietf@xxxxxxxx > Subject: RE: Call for Community Feedback: Guidance on Reporting Protocol > Vulnerabilities > > Hi Dan! > > Thank you for the feedback! > > > -----Original Message----- > > From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Dan Harkins > > Sent: Monday, October 26, 2020 12:52 AM > > To: ietf@xxxxxxxx > > Subject: Re: Call for Community Feedback: Guidance on Reporting > > Protocol Vulnerabilities > > > > > > Howdy, > > > > Not all RFCs are the product of a working group so I think the > > section dealing with "Expectations from the IETF" should address what > > the IETF feels it should do wrt to RFCs published by the IETF that > > were not products of a working group. The existing text seems to only > > address issues with RFCs that were the produce of a (possibly closed) > > working group. This probably has an influence on Figure 1 too-- to be > > specific, before the decision of "4" there should be a decision on the > > question of whether this is about an RFC that the IETF feels it needs to > address. > > Good point. Let me figure out how to best finesse the existence of AD > sponsored documents, without adding too much (more) complexity. > > Regardless of the editorial approach, let me know if the possible end states > aren't "errata" (8) or "using the general alias" (10), perhaps with a trip through > "is there an active working group on the topic" (3). Please see the revised text to address a workflow for individual submission: https://github.com/ietf/vul-reporting-guidance/commit/9698c728b900307f74a2649720755b35c6b0523b Let me know if this doesn't address your feedback. Thanks, Roman > Regards, > Roman > > > regards, > > > > Dan. > > > > On 10/23/20 11:46 AM, Roman Danyliw wrote: > > > Hi! > > > > > > The Internet Engineering Steering Group (IESG) is seeking community > > > input on > > reporting protocol vulnerabilities to the IETF. Specifically, the > > IESG is proposing guidance to be added to the website at [1] to raise > > awareness on how the IETF handles this information in the standards > > process. The full text (which would be converted to a web page) is at: > > > > > > https://www.ietf.org/media/documents/Guidance_on_Reporting_Vulnerabi > > > li > > > ties_to_the_IETF_sqEX1Ly.pdf > > > > > > This text is intended to be written in an accessible style to help > > > vulnerability > > researchers, who may not be familiar with the IETF, navigate existing > > processes to disclose and remediate these vulnerabilities. With the > > exception of creating a last resort reporting email alias > > (protocol-vulnerability@xxxxxxxx), this text is describing current > > practices in the IETF, albeit ones that may not be consistently applied. > > > > > > This guidance will serve as a complement to the recently written > > > IETF LLC > > infrastructure and protocol vulnerability disclosure statement [2]. > > > > > > The IESG appreciates any input from the community on the proposed > > > text and > > will consider all input received by November 7, 2020. > > > > > > Regards, > > > Roman > > > (for the IESG) > > > > > > [1] This guidance text would be added to a new URL at > > > https://www.ietf.org/standards/rfcs/vulnerabilities, and then > > > referenced from www.ietf.org/contact, > > > https://www.ietf.org/standards/process/, > > > https://www.ietf.org/standards/rfcs/, and > > > https://www.ietf.org/topics/security/ > > > > > > [2] > > > https://www.ietf.org/about/administration/policies-procedures/vulner > > > ab > > > ility-disclosure > > > > > > > > > > -- > > "The object of life is not to be on the side of the majority, but to > > escape finding oneself in the ranks of the insane." -- Marcus Aurelius
