Skip to main content

Last Call Review of draft-ietf-karp-ops-model-07

Request Review of draft-ietf-karp-ops-model
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-08-18
Requested 2013-08-08
Authors Sam Hartman , Dacheng Zhang
I-D last updated 2013-08-08
Completed reviews Genart Last Call review of -07 by Ben Campbell (diff)
Genart Last Call review of -09 by Ben Campbell (diff)
Secdir Last Call review of -07 by Radia Perlman (diff)
Secdir Telechat review of -09 by Radia Perlman (diff)
Opsdir Telechat review of -09 by Benoît Claise (diff)
Assignment Reviewer Ben Campbell
State Completed
Request Last Call review on draft-ietf-karp-ops-model by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07 (document currently at 10)
Result Ready
Completed 2013-08-08
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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

Major issues:


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

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

-- 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)