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). 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_Vulnerabili > > 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/vulnerab > > 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
