>> >> "Security issues with respect to these reports are similar to those >> >> found in [DSN]." >> >> >> >> The reference to DSN could be normative. >> > >> > Security Considerations are never normative, so I'm not sure I agree >> > that this should be. >> >> It should. Just because the Security Considerations section doesn't >> usually use normative language doesn't mean that it's not normative. >> People reading the document and implementing the protocol certainly >> have to read and understand the Security Considerations section, along >> with any transitive sections in other documents. > > The reason I didn't make it normative when I drafted that section is because > this isn't a DSN, it's an ARF, thus the similar to. If people think it should > be normative, I think it's fine to change it. Yes, but think about the difference between these two statements: 1. Security issues with respect to these reports are similar to those found in [DSN]. 2. Security issues with respect to these reports are similar to those found in [DSN]. Specifically, X and Y. Also Z, when that situation is applicable. In the second case, you can understand the security issues here without going and reading [DSN]. It really is just saying that these are similar to those, so the reference is informative. In the first case, how can you know *anything* about the security issues without reading the referenced document? If sections 6.1 and 6.2 really do say everything that needs to be said, and the sentence in 6. could be removed without loss of important information, then leave it as an informative reference. If one really has to go to [DSN] to see what some of the issues are, make it normative. That's the test. Barry _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf