Subject: [Netconf] a couple zerotouch-21 issues

From: Kent Watsen <[email-masked]>
Date: Tue, 8 May 2018 19:25:04 +0000

A couple Last Call comments were re-raised off-list and, since the
draft is still waiting for shepherd write-up, there's an opportunity
(according to the shepherd/chair) for us to do something if desired.
Here are the issues:

1) should the "zero touch device data model" in Section 8 be normative
   or non-normative and, if normative, what should its contents be?

   Please note that a non-normative module allows for the keystore 
   (or maybe trust-anchors now) reference to be informational, so 
   this draft won't blocked in the MISREF state for as long as it
   takes for those other works to get published.  [ps: this draft
   also has a normative ref to yang-data-ext, which we thought was
   going to be a shoo-in, but now seems to be stalled in NETMOD WG]

   Options:

     a) leave as is (non-normative)

     b) just move the section to an Appendix (still non-normative)

     c) make a tiny normative module, having just the config true 
        leaf "enabled" and its parent container. (normative, but
        avoids the MISREF, but maybe too simple?)

     d) make roughly what's there now be normative (this will cause
        this draft to block on those others works in progress). [we
        would likely also want to improve it some: perhaps convert
        the idevid node to a keystore-reference and also perhaps 
        make the whole module config true to support pre-staging]

     e) remove it (note, this module was added at the very end via
        a Last Call comment.  It was essentially thrown into the
        draft as an afterthought.  It has value, but it's limited.)

2) should the "script" typedef codify any signaling mechanism?

   Currently, the description statement for "typedef script" on page
   34 says:

          No attempt is made to standardize the contents, running
          context, or programming language of the script, other than
          that it can emit an exit status code and stderr/sdtout.

   And then goes on to describe how positive exit status codes means
   "warning" and negative exit status codes means "error" and how the
   output can be sent to bootstrap server.

   The idea is to rewrite this text to just talk about "warnings" and
   "errors" instead of exit status codes and, likewise, to just
   talk about "output" instead of "stderr/stdout" specifically.

   Note: this update seems like common sense to me, and somewhat 
   editorial, so, I'll plan to make this change unless someone 
   specifically objects to it.

Any thoughts, especially with regards to issue #1?

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 May 2018 12:40:31 +0200 (CEST)

Hi,

>         draft as an afterthought.  It has value, but it's limited.)

If it wasn't for the timing issue, I'd vote for (d); I think that is
the proper thing to do.  But I really want to see this draft
published, so I think it is best to do (e).  We can always do (d) in a
future bis version, or in a future separate document.

>    specifically objects to it.

I have made this comment in my earlier reviews of this document, so I
support this change.

Regarding the yang-data reference, I suggest you change the draft to
use rc:yang-data, and split the current "zerotouch-information" into
two separate rc:yang-data "redirect-information" and
"onboarding-information".

/martin

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 May 2018 17:05:55 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> 
> Hi Martin,
> 
> Just cherry-picking on a few comments:
> 
> 
> > If it wasn't for the timing issue, I'd vote for (d); I think that 
> > is the proper thing to do.  
> 
> agreed.
> 
> > But I really want to see this draft
> > published, 
> 
> yes
> 
> > so I think it is best to do (e).  We can always do (d) 
> > in a future bis version, or in a future separate document.
> 
> removing is better than having a non-normative example?  Note that,
> in both cases, (d) can be done in the future...

Yes I think so, since there's a high risk that the modules that the
example use evolve.  For example, currently it uses the keystore
module, which might disappear.

> > Regarding the yang-data reference, I suggest you change the draft
> > to use rc:yang-data, and split the current "zerotouch-information"
> > into two separate rc:yang-data "redirect-information" and
> why? will that draft not get published soon enough?  I expect this
> draft will go through a long SecDir review, yang-data-ext should be
> done by then.  I know that some on the netmod list are talking about
> abandoning that draft, but no decision has been made yet.

No but that might happen.

> The zerotouch draft has way too much text invested in the "zerotouch-
> information" artifact being polymorphic nature to seriously consider
> having two unrelated artifacts

I don't think it would require any significant changes to the draft.
You can still use the term "zerotouch-information", and explain that
it means either "redirect-information" or "onboarding-information".

> , when the easier answer is to agree 
> that, in this case, the yang-data does in fact contain "data definition 
> statements that result in exactly one container data node definition".
> We don't even need to change any text, in this document or in RFC 
> 8040, in order to have this agreement.  We would only need `pyang` 
> to stop flagging it as an error.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 9 May 2018 14:36:17 +0000

Hi Martin,

agreed.

yes

having two unrelated artifacts, when the easier answer is to agree 

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Wed, 9 May 2018 16:56:19 +0000

> it means either "redirect-information" or "onboarding-information".

But more than needed when we only need to agree that the existing 
situation is okay with rc:yang-data.  You've never explained why
this can't be so.  Juergen said on the netmod thread that the 
statement in RFC 8040 is not clear.  Why is this even an issue?

Kent

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 9 May 2018 14:37:00 -0700

> On May 8, 2018, at 12:25 PM, Kent Watsen <[email-masked]> wrote:
> 
> 

In the interest of time, and the need to publish this document sooner than later, my vote would be for b). I agree that a non-normative example is better than no example at all, however evolved or not evolved the current example is.

Thanks.

Mahesh // as contributor.

---

From: Kent Watsen <[email-masked]>
Date: Sat, 19 May 2018 01:31:41 +0000

Regarding what to do with the "zero touch device data model" in Section 8:

a) Everyone agrees on not delaying this draft any longer waiting for the keystore drafts to complete.

b) There is a difference in opinion as to if we should move Section 8 to the Appendix, or delete it altogether.  We don't have consensus.

c) There is new information since the above comments were made.  The new information is that the WG will likely adopt the crypto-types and trust-anchors drafts and, thus the dependencies change.  The type "cms" becomes "ct:cms", and the path "/ks:keystore/pinned-certificates/name" becomes " /ta:trust-anchors/pinned-certificates/name".  This changes the equation in that the probability is higher now that this non-normative module will remain valid longer.  Do we still think that it is "high risk" and, even if it is, is it really a problem?  Have we ever published an example module that imported modules that were works-in-progress before?  [I can't think of one, but I don't follow every draft either]

d) On the flip side, why is having a non-normative example better than no example at all, however evolved or not evolved the current example is?   There is a tradeoff between having something (which is nice) and the risk that it will become invalid (which would be a nuisance).  How nice is nice and how big of a nuisance would it be?  [it seems like nice > nuisance]

Thoughts?

Kent // contributor

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 19 May 2018 10:15:12 +0200

Hi Kent,

> On May 19, 2018, at 3:31 AM, Kent Watsen <[email-masked]> wrote:
> 
> 

My personal preference is that an example, in a appendix, which is non-normative, is better than no example.

mj as contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 23 May 2018 20:47:45 +0000

Hi Kent,

> Kent Watsen, May 8, 2018 3:25 PM
> 
> A couple Last Call comments were re-raised off-list and, since the draft is still
> waiting for shepherd write-up, there's an opportunity (according to the
> shepherd/chair) for us to do something if desired.
> Here are the issues:
> 
> 

(a), (b), & (e) all seem reasonable to me.  Although if (a) or (b), a fix the single container yang-data question in NETMOD would seem to be needed anyway.  Has that been resolved?   If not, per the NETMOD yang-data threads, it doesn't seem like the choice in the yang-data is something which is trivial to resolve.  If that is the case, it seems like Martin's proposal to do (e) delivers something quickly, which would be helpful.   

Note: Also in the model, listing "port" within a device model where a transport protocol is known has proven surprisingly controversial.  (e) avoids the potential for delays from revisiting that as well.

>    specifically objects to it.

Getting away from actions on the range of error status codes is a good idea within the description, although this might not matter is (e) is chosen above.

Eric

---

From: Kent Watsen <[email-masked]>
Date: Thu, 24 May 2018 01:00:51 +0000

Hi Eric,

>> <snip/>
> (a), (b), & (e) all seem reasonable to me.  Although if (a) or (b), a fix the single 
> container yang-data question in NETMOD would seem to be needed anyway.  Has that been
> resolved?   If not, per the NETMOD yang-data threads, it doesn't seem like the choice
> in the yang-data is something which is trivial to resolve.  If that is the case, it
> seems like Martin's proposal to do (e) delivers something quickly, which would be helpful.   

The yang-data discussion is regards a different module (ietf-zerotouch-information), I
only mentioned it before by way of saying that there is yet something else unresolved...

Any of the above options are equally quick IMO.

> Note: Also in the model, listing "port" within a device model where a transport
> protocol is known has proven surprisingly controversial.  (e) avoids the potential
> for delays from revisiting that as well.

I am not surprised.  I ran into similar headwinds before.

>> <snip/>
> Getting away from actions on the range of error status codes is a good idea within
> the description

Indeed, and so I'll take it that this is more support for the plan

> although this might not matter is (e) is chosen above.

Issue #1 above is independent of this issue.  We could choose (e) above but still be
left discussing this issue.  No matter, I just wanted to clarify this for anyone
following along.

> Eric

Kent // as a contributor