Subject: Routing Directorate QA review of draft-ietf-rtgwg-yang-key-chain

From: Ines Robles <[email-masked]>
Date: Tue, 30 Aug 2016 14:19:00 +0300

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 30 Aug 2016 16:10:52 +0000

Hi Ines,

Thanks for the routing directorate review. See inline.

From: Ines Robles <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 30, 2016 at 7:19 AM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Chris Bowers <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>, Routing Directorate <[email-masked]<mailto:[email-masked]>>, Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: Routing Directorate QA review of draft-ietf-rtgwg-yang-key-chain
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Jeffrey Zhang <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Helen Chen <[email-masked]<mailto:[email-masked]>>
Resent-Date: Tuesday, August 30, 2016 at 7:19 AM

Hi,

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:

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

Ok.

...

1.1.1.  Tree Diagrams

     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 ;^)

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.

---

From: Ines Robles <[email-masked]>
Date: Tue, 30 Aug 2016 19:38:15 +0300

Hi Acee,

Thanks for your comments, I understood your points.

Cheers,

Ines.

2016-08-30 19:10 GMT+03:00 Acee Lindem (acee) <[email-masked]>:

> From: Ines Robles <[email-masked]>
> To: Jeff Tantsura <[email-masked]>, Chris Bowers <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> Cc: Jonathan Hardwick <[email-masked]>, Routing
> Directorate <[email-masked]>, Routing WG <[email-masked]>
> Resent-From: <[email-masked]>
> Resent-To: Acee Lindem <[email-masked]>, <[email-masked]>, <
> [email-masked]>, Jeffrey Zhang <[email-masked]>, <[email-masked]>,
> Helen Chen <[email-masked]>
>      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
> 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
>
> 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.
>
> 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 ;^)
>
>
>
> 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.
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 30 Aug 2016 16:40:45 +0000

Hi Ines,
Thanks - I’m going to publish a version of the draft which addresses your comments.
Acee

From: rtg-dir <[email-masked]<mailto:[email-masked]>> on behalf of Ines Robles <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 30, 2016 at 12:38 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Routing Directorate <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Chris Bowers <[email-masked]<mailto:[email-masked]>>, Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [RTG-DIR] Routing Directorate QA review of draft-ietf-rtgwg-yang-key-chain

Hi Acee,

Cheers,

Ines.

2016-08-30 19:10 GMT+03:00 Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>:
Hi Ines,

Hi,

Some comments:

Abstract:

Ok

Section 1. Introduction:

Section 1.1-

Ok.

...

1.1.1.  Tree Diagrams

Section 5:

Section 7

Additional questions:

Thanks,
Acee

Thank you,

Ines.