I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-karp-ops-model-07.txt Reviewer: Ben Campbell Review Date: 2013-08-16 IETF LC End Date: 2013-08-18 IESG Telechat date: Summary: This draft is almost ready for publication as an informational RFC. I have a few clarity related comments that might be worth considering prior to publication. Major issues: None. Minor issues: -- This abstract claims that this draft is a discussion of issues. From that perspective, I don't think the use of 2119 language is appropriate. There are some specific areas (mentioned below) where 2119 language is used in imprecise ways, and may do harm to the reader's understanding. There are other uses that may be more reasonable. But I think the draft would be better off dispensing with 2119 language altogether. -- Section 3, paragraph 4: This seems like a place where descriptive language would be better than 2119 language. In particular, "and so on" leaves things too open ended and imprecise. Also, the use of 2119 language in an example seems a bit off. -- section 3.1, last paragraph: I'm not sure what guidance is intended in this paragraph. It offers an example, then refutes it. Are there better examples to offer? Is the point that one shouldn't make such checks? -- section 3.2, paragraph 2: What distinguishes SHOULD from "desirable" in this context? That is, why use 2119 language for one and not the other? -- section 3.2, last paragraph: "Implementations SHOULD permit a configuration in which if no unexpired key is available, existing security associations continue using the expired key with which they were established." This may need further guidance. For example, it seems risky to do this silently. -- section 3.3, last paragraph: "... then there is complexity in key management protocols." Can you elaborate? Too much complexity? Are there key management systems that are not complex? -- section 4, 2nd to last paragraph: Seems like other disadvantages are worth mentioning. For example, the potential impact of a compromised CA. -- 4.1: I understand why one might choose not to include a real-world example here, but is there something that can be referenced? -- 4.4, 2nd paragraph: "... it will be critical to make sure that they are not required during routine operation or a cold-start of a network." Can you elaborate on why? Nits/editorial comments: Abstract: Might be worth mentioning KARP and how this draft fits with others. -- Section 1, paragraph 1: Please expand KARP on first mention. -- Section 1, paragraph 3: Missing punctuation. -- section 3: The text seems to rather abruptly start talking about key considered actions with little background. A quick summary of how these keys re used would be helpful. -- section 3, paragraph 2: "Each OSPF link needs to use the same authentication configuration, ..." Same configuration as what? The sentence appears to say keys must be the same among links but can be different. -- section 3.2, first 2 paragraphs: I'm not sure how a configuration management system and a configuration interface differ for the purposes of this discussion. -- 4.1, paragraph 4: "Preshared keys that are used via automatic key management have not been specified for KARP." I'm not sure what's intended here--if they are not specified why does the paragraph go on to talk about them? -- 4.4, 1st paragraph: "... like RADIUS or directories." Is there a word missing? -- 5, bullet list of management objects: There may be management objects implied by the second and third bullets, but they are not mentioned as such. Can you explicitly state them? For example, in bullet 2 is the "peer" the object being discussed? Or is it the "name or key". In bullet 3, is "group" the managed object, rather than "routing protocol"? -- 5, paragraphs 7 and 8: s/what/which (two occurrences)