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

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.