Hi Ines, Thanks for the routing directorate review. See inline.
From: Ines Robles <[email protected]<mailto:[email protected]>> Date: Tuesday, August 30, 2016 at 7:19 AM To: Jeff Tantsura <[email protected]<mailto:[email protected]>>, Chris Bowers <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: Jonathan Hardwick <[email protected]<mailto:[email protected]>>, Routing Directorate <[email protected]<mailto:[email protected]>>, Routing WG <[email protected]<mailto:[email protected]>> Subject: Routing Directorate QA review of draft-ietf-rtgwg-yang-key-chain Resent-From: <[email protected]<mailto:[email protected]>> Resent-To: Acee Lindem <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, Jeffrey Zhang <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, Helen Chen <[email protected]<mailto:[email protected]>> Resent-Date: Tuesday, August 30, 2016 at 7:19 AM 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)". Ok 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? I think TCP-AO is a better example since it is an RFC and explicitly supported by the model. 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]. Ok. ... 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] I’ll just include the notation section similar to other YANG drafts. 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 Actually this model is not dependent on any others (other than YANG types). It is to be referenced by any module requiring key-chain services (i.e., general purpose). I’ll add a statement regarding the applicability to section 2 (Problem Statement). 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] These would be tables of 1 ;^) I don’t see this as adding much value. However, if you send me working XML, I’d use it. - I would add an informative reference to RFC5226. "Guidelines for Writing an IANA Considerations Section in RFCs" It doesn’t reference RFC 5226. The allocations are based on RFC 3688. Additional questions: - Should RFC 6518 be mentioned in this document? like the Cryptographic Keys Life Cycle? This document is against key-chains and purports the benefits of an automated key management protocol. I don’t feel it is a good reference ;^) - What about ECC? Should it be included or it is not-related/out-of-scope? My intent was not to add every possible key-chain usage and I’ve already included a few things in the model which are not supported by any vendor (e.g., TCP-AO Key-chains and encrypted password strings). ECC associated algorithms could be added via augmentation. Thanks, Acee Thank you, Ines.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
