Subject: [Netconf] WGLC comments on draft-ietf-netconf-keystore

From: Robert Wilton <[email-masked]>
Date: Thu, 13 Jul 2017 11:21:37 +0100

Hi,

Here are my comments on draft-ietf-netconf-keystore:

I found this draft well written and straight forward to read and 
understand.  Subject to suitable consideration to the comments below I 
support publication of this draft.

1) Sec 2. The Keystore model:

i) The title here is "model" but the draft then talks about the 
"module", it might help if these are consistent.

ii) Rather than "list of lists of trust anchor certificates", I would 
give this some more explicit structure, e.g. a list of trust anchor 
groups, where each trust anchor group contains a list of trust anchor 
certificates".  Is there a defined ordering between trust anchor 
certificates groups, or trust anchor certificates? If not, and the 
section is writing about the model rather than the module then "sets" 
may be more appropriate than "lists".  Either way I think that it may be 
helpful for the draft to document the relevance (of lack thereof) of any 
ordering requirements.

iii) There is no mention here of "trusted-host-keys".  It would probably 
help to have some introduction text here as well. Actually, it looks 
like the abstract and introduction might want to be updated to cover 
trusted host keys as well.

iv) 2.1 Overview
I would possible rename this section to something like "YANG Module Tree 
Diagram", since the initial text in section 2 reads like the overview.

v) Sec 2.2. Example usage
In both drafts various YANG examples have text along the lines of 
"<value>Base64-encoded PKCS#7</value>".  My assumption is that this is 
not literal text but a comment as to what the contents would look like.  
If so, I think that it would be useful to make this clear somehow, 
perhaps with an asterisk and foot note at the bottom of the diagrams?

vi) REQUEST and RESPONSE XML examples.
In these examples it looks like they include the actual Base-64 encoded 
values.   Should these use a description (like above) instead for 
consistency?

2) 2.3 YANG Module

It looks like there are still a couple of comments/questions that need 
to be resolved in the YANG module text:

i)             // no 'params' like inRFC 5912 <https://tools.ietf.org/html/rfc5912>? - none are set for
              // algs we care about, but what about the future?

ii)        // no key usage (ref:RFC 5912 <https://tools.ietf.org/html/rfc5912>, pg 101 -- too X.509 specific?)

iii)        leaf certificate {  // rename to 'data'?

iv)        leaf host-key {  // rename to 'data'?

v) I didn't quite like the structure/naming for the trusted-certificates 
list and trusted-certificate list.  It seems to be mixing the XML and 
JSON YANG naming style for list elements.

Instead, I would suggest, putting all certificates in their own top 
level "certificates container".
Rename "trusted-certificates" to something like 
"trusted-certificate-group[s]".
Probably put "trusted-certificate" into a "trusted-certificates" container.
Possibly rename "trusted-certificates" to "trusted-certificate" 
depending on which style of list naming is being used.  Is there YANG 
guidelines guidance for what should be done here?  E.g. should the lists 
be optimized to read well in XML or JSON?

vi) I think that the same comments in (v) for trust certificates equally 
apply to "trusted-host-keys" as well.

3) Design considerations
I would normally expect "design considerations" to come before the 
actual design.  So I wonder whether this text wouldn't be better earlier 
in the document, i.e. after the "overview text" and before the tree 
diagram, and YANG module.  Related to this, I wonder whether it wouldn't 
be better for the examples to be moved to an appendix.  This would allow 
the tree diagram and YANG module to be more closely co-located in the 
document.

4) Security considerations:
This section looked good to me, but I'm not a security expert.

5) Minor N=nits:
i) Section 2: The Keystore model: "is MAY" => "MAY"
ii) You have some spare blank lines at the end of your YANG model that 
could be removed.
iii) I presume that the "Change Log" will be struck on publication as an 
RFC.

Thanks,
Rob

On 29/06/2017 23:08, Mehmet Ersue wrote:
>
> Dear NETCONF WG,
>
> we hereby issue a WG Last Call for 2 weeks for the drafts below:
>
> https://tools.ietf.org/html/draft-ietf-netconf-keystore-02
>
> https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-14
>
> Please review and send your comments to the NETCONF WG mailing list by 
> July 13, 2017 EOB PT.
>
> Please be aware that the Keystore and Zerotouch drafts are planned to 
> publish as standard track documents.
>
> We would like to ask WG members to state explicitly that you have 
> read/reviewed and whether you support the publication of the drafts.
>
> Please indicate also if you plan to implement or have already 
> implementation experience with these drafts.
>
> Authors:
>
> Please indicate with an email on the maillist explicitly whether you 
> are aware or you are not aware of any IPRs related to the drafts.
>
> PS: Next in the row are the 4 client-server drafts going to WGLC on 
> July 10^th .
>
> Thank you,
>
> Mehmet and Mahesh
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Robert Wilton <[email-masked]>
Date: Thu, 13 Jul 2017 18:35:18 +0100

Hi,

I've read through the zerotouch draft, but found it much more hard going 
that the keystore draft, but then it relates to stuff that I'm not 
particularly familiar with!

I would say that this draft it a long way out of my domain of expertise, 
so I'm not sure that I'm really qualified to judge whether this draft is 
ready for publication.  In particular, I think that a through founding 
in the security aspects are probably key to knowing whether this draft 
is right.

So, my comments are more to do with the structure/readability of the 
document rather that whether the proposed technological solution is 
right.  Hopefully they are still of use.

Main comments:

1) I found that the draft is long, with quite lengthy descriptions in 
the early part of the document, which often seemed to overlap in the 
concepts that they are describing.  E.g. whether some data is trusted or 
untrusted, and how that trust can be established could possibly be dealt 
with early in the document, and then just referenced later.

I.e. data is untrusted unless it has been received over a secure 
connection to a trusted server, or is appropriately signed.

Then in section 2.1, the 3 paragraphs on trust could be simplified to:

Redirect data may be trusted or untrusted.  If trusted, then it can be 
used to establish a secure connection to a trusted server by including 
the bootstrap server's trust anchor certificate.  If untrusted, then the 
device MUST discard any included trust anchor certificates.  The text 
about a provision connection could be left to a reference to section 7.5.

Likewise, in section 2.2, the paragraph starting "Bootstrap information 
is trusted if ..." could be deleted.

2) Section 4. Artifact Groupings:
2i) I think that the second paragraph of 4.1, starting "unsigned 
information is useful ..." is probably superfluous and could be deleted.
2ii) I wonder if sections 4.2 Signed Information (without Revocations) 
and 4.3 Signed Information (with Revocations) could be coalesced 
together.  I.e. covering signed information, and then a subsection of 
revocations?

3) Section 5: Sources of Bootstrapping Data
I also think that these sections could also possible be made more concise:
3i) Some of the text on "Removable Storage" seems unnecessary given that 
it is out of scope for this draft.
3ii) As per previous comments the comments about trust could potentially 
be curtailed if it previously been covered in a generic way.

4) Section 6. Workflow
4 i) Would it make sense to put the Workflow text as an appendix? It 
seems to be giving examples of how it could be implemented.
4 ii) The diagram on page 23, point 2 seems incomplete: "for each source 
supported, check"

5) Section 7. Device Details
5 i) The diagram at the top of section 7.2 doesn't come across as 
obviously being a diagram.  Perhaps if it was less wide it would be 
centered and hence be more obvious.

Minor comments:

1) In the terminology section, it might be useful to add definitions for 
"fingerprint" and "webhook".  Perhaps also "trusted", "untrusted", 
"trusted device".

2) section 7.6, force the reinstallation of its boot image.
Is this forcing re-installation of the original boot image, or an 
updated one, or does it not matter?

3) Do the YANG examples that state "Base64-encoded xxx" need further 
clarification that they are not verbatim text.

Nits:

1) I would suggest using "bootstrap from" instead of "bootstrap off of" 
- in several places in the draft.

2) section 1.1 "out to network" -> "out to the network".

3) section 6.2., page 24, "if the device is ever able to complete the 
bootstrapping process successfully," -> " if the device successfully 
completes the bootstrapping process,"

4) section 7.3, "variable algorithm variable" -> "algorithm variable"

5) section 7.3, should "POST" be in capitals (two places)?  I.e. is this 
an HTTP POST request?

6) section 7.6 "execute the script" -> "execute the post-configuration 
script"?

7) page 34 example seems to be much greater than 72 chars (at least in 
the PDF version that I printed from).

Thanks,
Rob

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 13 Jul 2017 20:04:02 +0000

Hi Kent Mikael, & Ian,

Good stuff in the draft.  Some questions (many perhaps educational for me).

(1) DDos of Bootstap server?
In Section 6.3, #5 > can a bootstrap server be overwhelmed?  Should there be a back-off in the retries towards a bootstrap server?

(2) Future device reallocation
Related to (1), lots of devices end up running a factory default config.  Is the assumption that a zero touch device will never do this, even if reallocated elsewhere later in its life?  Should this impact retry algorithms?

(3) ANIMA differentiation
Very glad to see the ANIMA integration, with the use of Vouchers.  In Section 13, you note that with draft-ietf-anima-bootstrapping-keyinfra there different use cases which have different value propositions.   My belief is that this could be read as draft-ietf-anima-autonomic-control-plane provides different types of location based validation than are viable with zerotouch, and therefore these solutions should be kept separate.  Is that a correct reading?

(4) Recognizing partial Bootstapping?
My reading of Section 6.3 is that Bootstrapping as an all-or-nothing process.  And therefore it is important that connectivity is available to desired bootstrap servers before configuration commences.  Is the assumption correct? I.e., do you ever know in this context as to whether the bootstrap was successful?  If no, how does the system indicate if part of the Bootstrap has failed?  Is this assumed to be an independent configuration audit?

Eric

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Jul 2017 18:07:37 +0000

Hi Rob,

Thanks for the review.  Please see my comments below.

Kent

--

Hi,

Main comments:

<KENT> okay, point taken, I'll see how this can be simplified.

<KENT> or perhaps stated differently?  I'm trying to provide the use
case.  Similar paragraphs are in 4.2 and 4.3 as well...

<KENT> Perhaps, but then wouldn't that make the three variations less
obvious?  Currently, each variation has its own section, which I think
helps them to stand out...

<KENT> what do you think is out of scope?

<KENT> right, I'll look to tighten this up

4) Section 6. Workflow

<KENT> certainly could, as it's not meant to be normative.  That
said, I think Andy said that he really appreciated that section
being there...

<KENT> If we use another line, we could have a more complete sentence.
E.g. for each source supported, check if bootstrapping data is available.
But then again, that's pretty much what #2 under the diagram says.  Is
this what you want?

<KENT> I was able to squeezed 6 spaces out of it.

Minor comments:

<KENT> is "fingerprint" not commonly known?   I'll grant you that "webhook"
is less well-known, but it's only used in the non-Normative Section 6, 
which we might move to the Appendix. A google-search brings up a nice
definition, maybe it's good enough?

<KENT> it's the boot-image specified by the bootstrapping process.
Reading this section, the intent seems clear, but I wrote it.  Can
you re-read this section and see if you still feel the same way?

<KENT> a similar comment is on my other drafts.  Originally, I had
the actual content, but it seemed very long and less easy to read.
I think the concern raised there was that folks would copy/paste
the example and.  I don't have a great answer for this yet...

Nits:

<KENT> fixed.

<KENT> fixed.

<KENT> fixed.

<KENT> fixed.

<KENT> good catch, no lowercase.

<KENT> yes, fixed.

<KENT> It was, fixed.

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Jul 2017 18:30:56 +0000

Hi Eric,

Thank you for your review.
Below are my responses to your comments.

Thanks,
Kent

--

Hi Kent Mikael, & Ian,

<KENT> It is unlikely that real devices bootstrapping would
DDoS a bootstrap server.  For extreme deployment scenarios,
The deployment should ensure that the DNS record for a 
bootstrap server returns randomly-sorted IP addresses
for some number of bootstrap servers.

<KENT> I don't understand the question, but certainly a device
could be reset to its factory default.  1st-time vs Nth-time, 
the bootstrapping logic is identical...

<KENT> I wouldn't say "location-based validation"...ANIMA is 
just different.  To be honest, I'm itching to remove this 
section, but you're saying you like it?

<KENT> Almost all-or-nothing, in that it either works or it 
doesn't, but there is a potential that a device could install
a boot-image and then, after reboot, it can't connect to any
bootstrap servers again - so it's half-updated in this case.
But, if this were to occur, the device would fall back the 
standard logic of looping forever and waiting for operator
input.  The only mechanism defined for devices to report
errors is for them to post them to a bootstrap server, but
this assumes that 1) a bootstrap-server is being used and 2)
the bootstrap server is trusted.  In all other cases, the
device likely wrote messages to an audit-logging mechanism,
but that's out of scope for this draft.

Eric

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Jul 2017 22:16:57 +0000

Hi Robert,

Thanks for your review.  Please see below for my comments.

Kent

On 7/13/17, 12:21 PM, "Robert Wilton" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I found this draft well written and straight forward to read and understand.  Subject to suitable consideration to the comments below I support publication of this draft.

i) The title here is "model" but the draft then talks about the "module", it might help if these are consistent.

<KENT> changed, but I'm unsure if the net-result is better.    Sec 2 "The Keystore Module" and Sec 2.3 "YANG Module".  Maybe we should flatten Sec 2 altogether, since there is no pressing need to group these subsections together.  What do you think?

ii) Rather than "list of lists of trust anchor certificates", I would give this some more explicit structure, e.g. a list of trust anchor groups, where each trust anchor group contains a list of trust anchor certificates".

<KENT> this naming issue was raised by Martin and Juergen as well.

Is there a defined ordering between trust anchor certificates groups, or trust anchor certificates? I

<KENT> no.

If not, and the section is writing about the model rather than the module then "sets" may be more appropriate than "lists".  Either way I think that it may be helpful for the draft to document the relevance (of lack thereof) of any ordering requirements.

<KENT> it is a YANG 'list', and it does not specify ordered-by user, therefore its ordered-by system (e.g., unordered).

iii) There is no mention here of "trusted-host-keys".  It would probably help to have some introduction text here as well.  Actually, it looks like the abstract and introduction might want to be updated to cover trusted host keys as well.

<KENT> I updated the abstract and intro, but I don't know which section "here" is...

iv) 2.1 Overview
I would possible rename this section to something like "YANG Module Tree Diagram", since the initial text in section 2 reads like the overview.

<KENT> Done.

v) Sec 2.2. Example usage
In both drafts various YANG examples have text along the lines of "<value>Base64-encoded PKCS#7</value>".  My assumption is that this is not literal text but a comment as to what the contents would look like.  If so, I think that it would be useful to make this clear somehow, perhaps with an asterisk and foot note at the bottom of the diagrams?

<KENT> this was caught by Juergen as well.  He had an alternate idea, but it resulted in very long lines, which I'd have to wrap, producing a worse result.  The asterisk and footnote idea seems workable, but I'll wait for others to weigh-in before making a change...

vi) REQUEST and RESPONSE XML examples.
In these examples it looks like they include the actual Base-64 encoded values.   Should these use a description (like above) instead for consistency?

<KENT> done.

2) 2.3 YANG Module

It looks like there are still a couple of comments/questions that need to be resolved in the YANG module text: <snip/>

<KENT> these where all removed per Martin's review

v) I didn't quite like the structure/naming for the trusted-certificates list and trusted-certificate list.  It seems to be mixing the XML and JSON YANG naming style for list elements.
<KENT> Juergen and Martin also raised the naming issue, which we're still looking for a fix.  I don't understand you XML/JSON comment, but we have forever had container "widgets" with descendent list "widget"...

Instead, I would suggest, putting all certificates in their own top level "certificates container".
Rename "trusted-certificates" to something like "trusted-certificate-group[s]".
Probably put "trusted-certificate" into a "trusted-certificates" container.
Possibly rename "trusted-certificates" to "trusted-certificate" depending on which style of list naming is being used.  Is there YANG guidelines guidance for what should be done here?  E.g. should the lists be optimized to read well in XML or JSON?

<KENT> I'm using the strategy mentioned above.  I'm not aware of any guidelines (e.g., 6087bis).

vi) I think that the same comments in (v) for trust certificates equally apply to "trusted-host-keys" as well.

<KENT> right.

3) Design considerations
I would normally expect "design considerations" to come before the actual design.  So I wonder whether this text wouldn't be better earlier in the document, i.e. after the "overview text" and before the tree diagram, and YANG module.  Related to this, I wonder whether it wouldn't be better for the examples to be moved to an appendix.  This would allow the tree diagram and YANG module to be more closely co-located in the document.

<KENT> regarding Design Considerations, I don't think that information needs to come before the module itself, especially as it mostly regards why certain things were *not* done.  I've always had the sequence diagram->examples->module since I find it really helpful to see the examples before diving down into module details.  What do other people think?

5) Minor N=nits:

ii) You have some spare blank lines at the end of your YANG model that could be removed.
<KENT> fixed in all my drafts.
iii) I presume that the "Change Log" will be struck on publication as an RFC.
<KENT> yes.

Thanks,
Rob

Please review and send your comments to the NETCONF WG mailing list by July 13, 2017 EOB PT.
Please be aware that the Keystore and Zerotouch drafts are planned to publish as standard track documents.

We would like to ask WG members to state explicitly that you have read/reviewed and whether you support the publication of the drafts.
Please indicate also if you plan to implement or have already implementation experience with these drafts.

Authors:
Please indicate with an email on the maillist explicitly whether you are aware or you are not aware of any IPRs related to the drafts.

PS: Next in the row are the 4 client-server drafts going to WGLC on July 10th.

Thank you,
Mehmet and Mahesh

Netconf mailing list

[email-masked]<mailto:[email-masked]>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 20 Jul 2017 10:10:02 +0200

Hi Kent,

On 20/07/2017 00:16, Kent Watsen wrote:
> <KENT> changed, but I'm unsure if the net-result is better.    Sec 2 
> "The Keystore Module" and Sec 2.3 "YANG Module".  Maybe we should 
> flatten Sec 2 altogether, since there is no pressing need to group 
> these subsections together.  What do you think?
>
Yes, I would flatten the structure to make these sections top level, 
particularly given that the draft is quite short.

> certificates".
OK.

> or trust anchor certificates? I
OK.  Would it help if the doc is explicit on this point?

> If not, and the section is writing about the model rather than the 
> module then "sets" may be more appropriate than "lists".  Either way I 
> think that it may be helpful for the draft to document the relevance 
> (of lack thereof) of any ordering requirements.
>
> <KENT> it is a YANG 'list', and it does not specify ordered-by user, 
> therefore its ordered-by system (e.g., unordered).
>
So I guess what I mean is something along these lines:

The keystore model that has an unordered set of trust anchor certificate 
groups, where each certificate group contains an unordered set of trust 
anchor certificates.  In the YANG module these sets are represented as 
"ordered-by-system" lists.

>
> iii) There is no mention here of "trusted-host-keys".  It would 
> probably help to have some introduction text here as well.  Actually, 
> it looks like the abstract and introduction might want to be updated 
> to cover trusted host keys as well.
>
I was thinking: abstract, intro, and the text currently at the beginning 
of section 2. The Keystore Model.

>
> iv) 2.1 Overview
> I would possible rename this section to something like "YANG Module 
> Tree Diagram", since the initial text in section 2 reads like the 
> overview.
>
> <KENT> Done.
>
>
>
> not literal text but a comment as to what the contents would look 
> like.  If so, I think that it would be useful to make this clear 
> somehow, perhaps with an asterisk and foot note at the bottom of the 
> diagrams?
>
> <KENT> this was caught by Juergen as well.  He had an alternate idea, 
> but it resulted in very long lines, which I'd have to wrap, producing 
> a worse result.  The asterisk and footnote idea seems workable, but 
> I'll wait for others to weigh-in before making a change...
>
OK.

> In these examples it looks like they include the actual Base-64 
> encoded values.   Should these use a description (like above) instead 
> for consistency?
>
> <KENT> done.
>
>
> 2) 2.3 YANG Module
>
> to be resolved in the YANG module text: <snip/>
>
OK.

> v) I didn't quite like the structure/naming for the 
> trusted-certificates list and trusted-certificate list.  It seems to 
> be mixing the XML and JSON YANG naming style for list elements.
>
> <KENT> Juergen and Martin also raised the naming issue, which we're 
> still looking for a fix.  I don't understand you XML/JSON comment, but 
> we have forever had container "widgets" with descendent list "widget"...
>
OK.

IIRC, the widgets/widget naming convention works well for the XML 
representation in YANG, but the naming looks a bit strange in the JSON 
representation.

> guidelines guidance for what should be done here?  E.g. should the 
> lists be optimized to read well in XML or JSON?
>
> vi) I think that the same comments in (v) for trust certificates 
> equally apply to "trusted-host-keys" as well.
>
> <KENT> right.
>
>
> 3) Design considerations
> actual design.  So I wonder whether this text wouldn't be better 
> earlier in the document, i.e. after the "overview text" and before the 
> tree diagram, and YANG module.  Related to this, I wonder whether it 
> wouldn't be better for the examples to be moved to an appendix.  This 
> would allow the tree diagram and YANG module to be more closely 
> co-located in the document.
>
> <KENT> regarding Design Considerations, I don't think that information 
> needs to come before the module itself, especially as it mostly 
> regards why certain things were *not* done.  I've always had the 
> sequence diagram->examples->module since I find it really helpful to 
> see the examples before diving down into module details.  What do 
> other people think?
>
>
Thanks,
Rob

>     Please indicate with an email on the maillist explicitly whether
>     you are aware or you are not aware of any IPRs related to the drafts.
>
>     PS: Next in the row are the 4 client-server drafts going to WGLC
>     on July 10^th .
>
>     Thank you,
>
>     Mehmet and Mahesh
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 20 Jul 2017 10:45:53 +0200

Hi Kent,

> Thanks for the review.  Please see my comments below.
My thought was to try and make the normative part of the document (i.e. 
to actually implement zerotouch) shorter and more concise.

If trusted vs untrusted and signed/unsigned data is covered once near 
the top of the document then it may not be necessary to comment about 
signed vs unsigned, and trusted vs untrusted in the subsequent sections.

> helps them to stand out...
Yes, perhaps.

But possibly you could see this as really just 2 options, one of which 
has 2 sub options:

1) Unsigned data
2) Signed data.  If signed, then revocation certificates may or may not 
be provided.

> <KENT> what do you think is out of scope?
Sorry, I mean that the text is perhaps not normative.

E.g. picking up this comment "

The format of the removable storage device's filesystem and the
    naming of the files are outside the scope of this document.
"

I wonder if this section could be summarized as:

"Removal storage can be a source of untrusted bootstrap artifacts. The 
specific details of how those artifacts are encoded is outside the scope 
of this draft."

Perhaps that text is a bit too short, but given it is implementation 
specific I'm not sure how much needs to be stated.

> said, I think Andy said that he really appreciated that section
OK.  My goal is just to try and get the normative text to be shorter.

> But then again, that's pretty much what #2 under the diagram says.  Is
I don't mind.  It just seemed that the current description ended mid flow.

> <KENT> is "fingerprint" not commonly known?
I don't know, within security circles I would assume yes, outside of 
that I'm not sure.  I do know that my children leave lots of 
fingerprints on our windows ;-)

>     I'll grant you that "webhook"
Yes.

> you re-read this section and see if you still feel the same way?
It's still not entirely clear to me, but if I was interpreting this text 
I my best guess would match your description above.

Thanks,

Rob

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 26 Jul 2017 12:26:58 -0400

The same message applies to these documents in WG LC. Even though the LC has timed out, we are extending this by one week to get your vote in.

We saw support for these documents in the WG meeting, but we need that support expressed on the mailing list. Note, that Kent has already indicated that he will resolve the issue of whether to keep identifiers in the keystore draft as part of the LC.

Authors please indicate whether you are aware of any IPRs.

> On Jun 29, 2017, at 6:08 PM, Mehmet Ersue <[email-masked]> wrote:
> 
> Dear NETCONF WG,
>  
> https://tools.ietf.org/html/draft-ietf-netconf-keystore-02 <https://tools.ietf.org/html/draft-ietf-netconf-keystore-02>
> https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-14 <https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-14>
>  
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
Mahesh Jethanandani
[email-masked]

---

From: "t.petch" <[email-masked]>
Date: Thu, 27 Jul 2017 11:12:47 +0100

'Other people' agrees with Robert, that Design Considerations, for or
against, should come before the module.  I want to read about it first,
dip into it later.  (It is unfortunate that 'Security Considerations'
come at the end but that is forced on us by the IETF.)

I agree with Kent that
         <certificates>
           <certificate>
is the usual convention, which I would not change.

On module v model, Benoit said

" The term 'YANG models' is likely simply an abbreviation of 'YANG data
models' and we could get rid of this by not using an abbreviation.

Let's apply this rule from now: no more "YANG models".
"

(and I agree)

Tom Petch

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Robert Wilton" <[email-masked]>; "'Netconf'" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, July 19, 2017 11:16 PM

> On 7/13/17, 12:21 PM, "Robert Wilton"
"The Keystore Module" and Sec 2.3 "YANG Module".  Maybe we should
flatten Sec 2 altogether, since there is no pressing need to group these
subsections together.  What do you think?
module then "sets" may be more appropriate than "lists".  Either way I
think that it may be helpful for the draft to document the relevance (of
lack thereof) of any ordering requirements.
> iii) There is no mention here of "trusted-host-keys".  It would
probably help to have some introduction text here as well.  Actually, it
looks like the abstract and introduction might want to be updated to
cover trusted host keys as well.
> <KENT> this was caught by Juergen as well.  He had an alternate idea,
but it resulted in very long lines, which I'd have to wrap, producing a
worse result.  The asterisk and footnote idea seems workable, but I'll
wait for others to weigh-in before making a change...
> v) I didn't quite like the structure/naming for the
trusted-certificates list and trusted-certificate list.  It seems to be
mixing the XML and JSON YANG naming style for list elements.
> <KENT> regarding Design Considerations, I don't think that information
needs to come before the module itself, especially as it mostly regards
why certain things were *not* done.  I've always had the sequence
diagram->examples->module since I find it really helpful to see the exam
ples before diving down into module details.  What do other people
think?
could be removed.
July 13, 2017 EOB PT.
> PS: Next in the row are the 4 client-server drafts going to WGLC on
July 10th.
> Mehmet and Mahesh

------------------------------------------------------------------------
--------

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Jul 2017 13:24:38 +0200

> On 27 Jul 2017, at 12:12, t.petch <[email-masked]> wrote:
> 

This has been discussed several times before but I don't think there is any widely accepted convention. For instance, ietf-yang-library in RFC 7895 doesn't use the wrapper containers. As Rob writes, it is related to the representation that the module author prefers. In XML representation it indeed makes sense because otherwise list entries may be interspersed with instances of other sibling nodes. In contrast, the wrapper container is useless in JSON representation and just adds an extra level of hierarchy:

{ "certificates":
  {
    "certificate": [ ... ]
  }
} 

> models' and we could get rid of this by not using an abbreviation.

I've been using "data model" for what is described by an instance of YANG library, i.e. a coherent collection of YANG modules of specific revisions + feature and deviation definitions. I think we need a term for this.

Lada

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Jul 2017 20:19:38 +0000

Hi Tom,

> dip into it later.  

Done, but I still wonder if these are design considerations or excuses
for why certain things are the way they are...

Your other items had already been taken care of.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Jul 2017 20:58:20 +0000

Hi Robert,

On 7/20/17, 4:10 AM, "Robert Wilton" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

Kent

Hi,

<KENT> changed, but I'm unsure if the net-result is better.    Sec 2 "The Keystore Module" and Sec 2.3 "YANG Module".  Maybe we should flatten Sec 2 altogether, since there is no pressing need to group these subsections together.  What do you think?
Yes, I would flatten the structure to make these sections top level, particularly given that the draft is quite short.

<KENT> Done.

<KENT> it is still an open issue how best to resolve this, but I'd rather use the existing thread for it...

The keystore model that has an unordered set of trust anchor certificate groups, where each certificate group contains an unordered set of trust anchor certificates.  In the YANG module these sets are represented as "ordered-by-system" lists.

<KENT> done.

<KENT> I updated the abstract and intro, but I don't know which section "here" is...
I was thinking: abstract, intro, and the text currently at the beginning of section 2. The Keystore Model.

<KENT> fixed.

The remainder of the message was removed as there was nothing more to respond to.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Jul 2017 21:05:16 +0000

Hi Lada,

> I've been using "data model" for what is described by an instance of 
> YANG library, i.e. a coherent collection of YANG modules of specific
> revisions + feature and deviation definitions. I think we need a term
> for this.

Is this comment meant to be directed at the rfc7895bis (yang library)
draft?  I don't understand your comment, what are you trying to say?

Kent

---

From: "t.petch" <[email-masked]>
Date: Fri, 28 Jul 2017 11:00:39 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Sent: Thursday, July 27, 2017 10:05 PM

Kent

It makes sense to me as a comment on netconf-keystore.

You queried the use of model versus module.

I quoted Benoit as saying
"
Let's apply this rule from now: no more "YANG models".
"

Lada now says he has a use for 'data model' (which is similar but
different).

Tom Petch