Skip to main content

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

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-11-19
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 09 (document currently at 10)
Result Ready
Completed 2013-11-19
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-karp-ops-model-09
Reviewer: Ben Campbell
Review Date: 2013-11-19
IESG Telechat date: 2013-11-21

Summary: This draft is ready for publication as an informational RFC. All the
issues from my last call review, have been addressed, save 1 below.

Major issues:


Minor issues:

-- My last call review included a concern about a possible need for additional
guidance  around the idea of continuing to operate with an expired key. The
author mentioned that the draft reflect working group consensus, and I'm okay
with that. But I still think there might be value in documenting the tradeoffs
that the working group considered reaching that consensus. I'm not sure that
our correspondence on that matter reached a conclusion. I'm pasting the
relevant discussion below:

>>   genart> -- section 3.2, last paragraph: "Implementations SHOULD
>>   genart> permit a configuration i n which if no unexpired key is
>>   genart> available, existing security associations continu e using
>>   genart> the expired key with which they were established."
>>   genart> This may need further guidance. For example, it seems risky
>>   genart> to do this silently.
>> I think this was explicitly discussed in the WG and is where we got in
>> our discussions.
>> There's discussion of alerts for security events elsewhere.
>> However I think the current text represents a fairly informed WG
>> consensus.
> You are correct that there is separate text on notification of security
events (section 6.2), and that even mentions certificate expiration. But it
doesn't explicitly mention continuing to use an expired key. I think that's
important enough that it should be explicitly considered. > > If it was
explicitly discussed in the working group, it would be helpful to document the
trade-offs that were discussed.

Nits/editorial comments:

-- idnits reports some outdated references, please check.

-- section 1, paragraph 4, 2nd sentence: