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)