Skip to main content

Last Call Review of draft-ietf-rtgwg-yang-key-chain-17
review-ietf-rtgwg-yang-key-chain-17-genart-lc-miller-2017-04-07-00

Request Review of draft-ietf-rtgwg-yang-key-chain
Requested revision No specific revision (document currently at 24)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-04-07
Requested 2017-03-17
Authors Acee Lindem , Yingzhen Qu , Derek M. Yeung , Ing-Wher (Helen) Chen , Zhaohui (Jeffrey) Zhang
I-D last updated 2017-04-07
Completed reviews Rtgdir Early review of -02 by Ines Robles (diff)
Yangdoctors Early review of -13 by Ladislav Lhotka (diff)
Genart Last Call review of -17 by Matthew A. Miller (diff)
Secdir Last Call review of -17 by Vincent Roca (diff)
Genart Telechat review of -20 by Matthew A. Miller (diff)
Assignment Reviewer Matthew A. Miller
State Completed
Request Last Call review on draft-ietf-rtgwg-yang-key-chain by General Area Review Team (Gen-ART) Assigned
Reviewed revision 17 (document currently at 24)
Result Almost ready
Completed 2017-04-07
review-ietf-rtgwg-yang-key-chain-17-genart-lc-miller-2017-04-07-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-rtgwg-yang-key-chain-17
Reviewer: Matthew A. Miller
Review Date: 2017-04-07
IETF LC End Date: 2017-04-07
IESG Telechat date: 2017-04-13

Summary:

This document is almost ready to be published as a Proposed Standard,
once the issues noted herein are resolved.

Major issues:

NONE

Minor issues:

* Forgive me for my limited knowledge of YANG, but is there a reason
key-strings are only representable as either a YANG string or
hex-string type, and not the YANG binary type?

* This document does not provide much guidance around AES key wrap
other than it can be used and the KEK is provided out-of-band/-context.
For instance, AES key-wrapped key-strings probably require using
"hexidecimal-string".  Also, assuming I'm reading the model correctly,
it appears this feature applies to the whole chain, which I think is
worth calling out.

* This document warns against using the "clear-text" algorithm, which the
reader is lead to understand is for legacy implementation reasons.
However, is there not a similar concern with cryptographically weak
algorithms, such as md5 and (arguably) sha1?

Nits/editorial comments:

* In Section 3.2. "Key Chain Model Features", the word "of" is missing
between "configuration" and "an" in the phrase "support configuration an
acceptance tolerance".

Non-nits:

* I note that idnits is calling out some odd spacing issues, but I think
they are safe to ignore.