Dear all, I was asked to do a OPSDIR review of  draft-ietf-karp-isis-analysis-06. I've read this document. However, I'm not sure it's ready for publication. More specifically,  most of the document (pages 1-7, sections 1-2.3.3 seen to be an overview of existing documents) -- and ne might say that part of the rest of the document still is kind of a discussion of existing documents. Section 3, which is where the "meat" is supposed to be, doesn't seem to contain much information, other than some high level discussion. So I wonder if the contents of this document warrant the publication of an RFC in the first place. I'd note that if this document is supposed to be a security assessment of IS-IS, I'd expect it to be way more lengthy, and more specific when it comes to the attack vectors (again, this I-D seems to be very/too high-level in this respect) That said, below you'll find some technical comments and nits. If we proceed with the publication process for this document, I'd expect at least the comments flagged as technical to be discussed/addressed prior to publication. **** Technical **** * Meta: Is there any reason why this document is not e.g. a BCP? * Section 2.1.1, page 4:   Since authentication is performed on the LSPs transmitted by an IS,   rather than on the LSP packets transmitted to a specific neighbor, Not sure what you mean... Do you mean all nodes must authenticate all LSPs? -- i.e., it's not clear what you mean. * Sections 2.3.2 and 2.3.3 Most of the attacks that you describe in Section 2.3.2 are actually DoS attacks (that's the actual goal). I'd probably even say that spoofing is usually not a goal in itself, but actually the means for achieving other goals (whether exploiting IP-address-based trust relationships, or something else). * Section 3.1: This Section contains some "requirements" with RFC2119 keywords. However, this document is an Informational document, so it shouldn't be using RFC2119 keywords. **** Nits **** * Section 1, page 2:   This draft summarizes the current state of cryptographic key usage in   IS-IS protocol and several previous efforts to analyze IS-IS   security. s/in IS-IS/in the IS-IS/ * Section 1, page 2: This includes base IS-IS specification [RFC1195],   [RFC5304], [RFC5310] and the OPSEC working group document [RFC6039]. s/base IS-IS/the base IS-IS/ Besides, "the opsec wg document" doesn't sound right. PLease refer to RFC6039 in a different way. * Section 1, page 3:   Authors would like to acknowledge all the previous work done in the   above documents. Not sure what this means here. I'd say you should probably remove this sentence. If there's any credit to be give, please do it in the "Acknowledgements" section. * Section 1, page 3:   This document also analyzes applicability of various threats as   described in [RFC6862] to IS-IS, lists gaps and provide specific This should be rephrased to:   This document also analyzes applicability of various threats to   IS-IS (as described in [RFC6862]), lists gaps and provide specific * Section 2.1, page 4:   IS-IS can be provisioned with a per interface, peer-to-peer key for   IS-IS HELLO PDUs (IIH) Please s/IS-IS HELLO PDUs (IIH)(IS-IS HELLO (IIH) PDUs/ Besides, "PDU" is not listed in Section 1.2. * Section 2.1.1 page 4: with in an area or domain. s/with in/within/ (there's another instance of this in the same paragraph) * Section 2.3.1,  page 6: Partial       Sequence Number packet Should you s/packet/Packet/? Thank you, Tina