Early Review of draft-ietf-rtgwg-yang-key-chain-02
review-ietf-rtgwg-yang-key-chain-02-rtgdir-early-robles-2016-09-01-00

Team Routing Area Directorate (rtgdir)
Title Early Review of draft-ietf-rtgwg-yang-key-chain-02
Request Early - requested 2016-08-15
Reviewer Ines Robles
Review result Has Nits
Posted at https://www.ietf.org/mail-archive/web/rtg-dir/current/msg03106.html
Last updated 2016-09-01

Review
review-ietf-rtgwg-yang-key-chain-02-rtgdir-early-robles-2016-09-01

Hi,

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

Some comments:

Abstract:

 

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

https://tools.ietf.org/html/draft-vanderstok-roll-mpl-yang-01

 

- 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 

https://tools.ietf.org/html/draft-ietf-netconf-server-model-09#section-3

 

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 [

http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns

]

 

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

http://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml#yang-parameters-1

]

 

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

Ines.