Hmm, surprising comment a bit … RIFT draft has a serious security section in 6.9 and a serious security considerations sections in section 9 and IMO it belongs there. AFAIS those section cover extensively security models possible and all kind of threats/consdierations on secure implementations. Of course lots of that could be moved into applicability (should it? Is security “applicability” even and if so, which part of it? Guide how to deploy it securely? ) but I don’t think that’s the intention and I’m bits lost further what “specificity” means here specifically ;-) e.g. Key management considerations do not seem particularly specific to rift as a protocol AFAIS unless what is desired is some RFC reference that describes key management in routing protocols and the pluses/minuses . I understand the comment on the possible lack of glossary, the document is not an easy read without being familiar with at least the introduction parts of RIFT document itself and its glossary. It’s hard to find a balance between starting to replicate lots of RIFT text/glossary in this document and not saying enough. IP fabric routing done by RIFT introduces a lot of concepts that are not present in “traditional IP routing” and the familiarity with this novel lens is necessary to process lots of this document. — Tony > On 18 Apr 2024, at 21:01, Watson Ladd via Datatracker <noreply@xxxxxxxx> wrote: > > [External Email. Be cautious of content] > > > Reviewer: Watson Ladd > Review result: Not Ready > > I have completed the secdir review of draft-ietf-rift-applicability, part of > the secdir effort to review all documents progressing to this stage in the > IETF. These comments should be treated like any other in the the last call > process. The result of the review is not ready. > > I used to think I knew broadly what networking was, then I read this document. > There's a fair number of terms that are new to me, and some more references > might help develop understanding. But that's a minor editorial point. > > More concerning is the complete absence of discussion of security, choosing to > kick that to RIFT. That's despite a section about key management in the > document, as well as discussion of operational scenarios that have implications > for the choice of key management technology used. I'd like to see more here: > it's an opportunity to spell out security considerations applicable to the > scenarios with more specificity than in the RIFT drafts. > > Sincerely, > Watson Ladd > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
