Early Review of draft-ietf-rtgwg-yang-key-chain-02

Request Review of draft-ietf-rtgwg-yang-key-chain
Requested rev. no specific revision (document currently at 24)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-09-01
Requested 2016-08-15
Other Reviews Yangdoctors Early review of -13 by Ladislav Lhotka (diff)
Genart Last Call review of -17 by Matthew Miller (diff)
Secdir Last Call review of -17 by Vincent Roca (diff)
Genart Telechat review of -20 by Matthew Miller (diff)
Review State Completed
Reviewer Ines Robles
Review review-ietf-rtgwg-yang-key-chain-02-rtgdir-early-robles-2016-09-01
Posted at https://www.ietf.org/mail-archive/web/rtg-dir/current/msg03106.html
Reviewed rev. 02 (document currently at 24)
Review result Has Nits
Draft last updated 2016-09-01
Review completed: 2016-09-01



Thank you for this work. I find the document readable and understandable.

Some comments:



- In this sentence "A key chain is... algorithm", I would add "A key chain is... algorithm (authentication or encryption)". 

Section 1. Introduction:


I would like to have an example on this statement:


" In some applications, the protocols do not use the key chain element key


   directly, but rather a key derivation function is used to derive a


   short-lived key from the key chain element key. e.g...." --> maybe draft-bhatia-karp-short-lived-keys-00?


Section 1.1-


-I would add here the reference to RFC 6020, something like:


 "The terminology for describing YANG data models is found in [RFC6020].




1.1.1.  Tree Diagrams


   A simplified graphical representation of the data model is used in


   the YANG modules specified in this document.  The meaning of the


   symbols in these diagrams is as follows:


      Brackets "[" and "]" enclose list keys.


      Abbreviations before data node names: "rw" means configuration


      data (read-write) and "ro" state data (read-only).


      Symbols after data node names: "?" means an optional node, "!"


      means a presence container, and "*" denotes a list and leaf-list.


      Parentheses enclose choice and case nodes, and case nodes are also


      marked with a colon (":").


      Ellipsis ("...") stands for contents of subtrees that are not


      shown." source of the text: 



- even when it is pretty obvious, I would add a reference to the key definition [RFC4949 - page 171]

Section 5:

     It is empty, you mention some related work in section 2, but maybe you could add in here a tree diagram such as the one showed in 



Section 7


-For the XML-REGISTRY I would add a table with suggested values for the respective columns of ns registry: ID, URI, Filename, Reference [




-For YANG Module Names registry, you have name, namespace, prefix and reference, only there is a column missing which is module,  [




- I would add an informative reference to RFC5226. "Guidelines for Writing an IANA Considerations Section in RFCs"

Additional questions:

- Should RFC 6518 be mentioned in this document? like the Cryptographic Keys Life Cycle?

- What about ECC? Should it be included or it is not-related/out-of-scope?

Thank you,