Hi Acee, Thanks for your comments, I understood your points.
Cheers, Ines. 2016-08-30 19:10 GMT+03:00 Acee Lindem (acee) <[email protected]>: > Hi Ines, > > Thanks for the routing directorate review. See inline. > > From: Ines Robles <[email protected]> > Date: Tuesday, August 30, 2016 at 7:19 AM > To: Jeff Tantsura <[email protected]>, Chris Bowers < > [email protected]>, "[email protected]" < > [email protected]> > Cc: Jonathan Hardwick <[email protected]>, Routing > Directorate <[email protected]>, Routing WG <[email protected]> > Subject: Routing Directorate QA review of draft-ietf-rtgwg-yang-key-chain > Resent-From: <[email protected]> > Resent-To: Acee Lindem <[email protected]>, <[email protected]>, < > [email protected]>, Jeffrey Zhang <[email protected]>, <[email protected]>, > Helen Chen <[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
