[Gen-art] Gen-ART Telechat Review of draft-ietf-karp-ops-model-09

Ben Campbell <ben@nostrum.com> Tue, 19 November 2013 20:46 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080C71AE157 for <gen-art@ietfa.amsl.com>; Tue, 19 Nov 2013 12:46:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWmnSRFPnFsa for <gen-art@ietfa.amsl.com>; Tue, 19 Nov 2013 12:46:13 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 751C61AE140 for <gen-art@ietf.org>; Tue, 19 Nov 2013 12:46:13 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAJKk5Wj050926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Nov 2013 14:46:06 -0600 (CST) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 19 Nov 2013 14:46:04 -0600
Message-Id: <3414BF25-86EF-43F2-8807-D98EE6E3E196@nostrum.com>
To: draft-ietf-karp-ops-model.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "gen-art@ietf.org Team (gen-art@ietf.org)" <gen-art@ietf.org>
Subject: [Gen-art] Gen-ART Telechat Review of draft-ietf-karp-ops-model-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2013 20:46:15 -0000

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

None

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:

s/routers/Routers