Subject: [Netconf] Spencer Dawkins' No Objection on charter-ietf-netconf-18-13: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Mon, 05 Jun 2017 14:05:55 -0700

Spencer Dawkins has entered the following ballot position for
charter-ietf-netconf-18-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-netconf/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a few minor comments, but this looks clear and plausible.

In this text,

1. Finalize the YANG data module for a system-level keystore mechanism,
which can be used to hold asymmetric private keys and certificates that
are
trusted by the system advertising support for this module. Based on the
known
dependencies this draft has the highest priority for the WG. 

I thought it might be helpful to say who has these dependencies, not in
detail, but just at the "other working groups", "other SDOs", "open
source community", "all of the above" level.

I counted something like seven items that apply to both NETCONF and
RESTCONF/HTTP2. Is the intention that these are two protocols that will
continue to evolve, but in lockstep? I think you're headed that way, but
I'm not sure. If so, saying that would be good.

For all the other RFCs listed in the charter, the name of the RFC is also
provided (sometimes the name is in parens, other times the RFC number is
in parens, but they're always together), except for RFC 5277 which is
invoked without providing its name. Could you adjust the first mention of
RFC 5277 to match the others?

---

From: Benoit Claise <[email-masked]>
Date: Thu, 8 Jun 2017 15:03:49 +0200

Hi Spencer,
> https://datatracker.ietf.org/doc/charter-ietf-netconf/
All dependencies are within NETCONF WG
Details here:
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-tls-client&modules[]=ietf-tls-server&modules[]=ietf-ssh-client&modules[]=ietf-ssh-server&modules[]=ietf-restconf-client&modules[]=ietf-restconf-server&modules[]=ietf-key-store&modules[]=ietf-netconf-client&modules[]=ietf-netconf-server&orgs[]=ietf&recurse=0&rfcs=1&show_subm=1

In the charter text, I added the parentheses to the sentence:
     Based on the knowndependencies (multiple NETCONF documents), this 
draft has the highest priority for the WG.
> I'm not sure. If so, saying that would be good.
It depends what we mean by lockstep.
NETCONF and RESTCONF have different protocol capabilities. However, what 
is common is that both must transport YANG encoded information.
> RFC 5277 to match the others?
Done.

Thanks for your feedback.

Regards, B.
> .

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 12 Jun 2017 08:54:16 -0500

Hi, Benoit,

On Thu, Jun 8, 2017 at 8:03 AM, Benoit Claise <[email-masked]> wrote:

> https://www.yangcatalog.org/yang-search/impact_analysis.php?
> modules[]=ietf-tls-client&modules[]=ietf-tls-server&modules[
> ]=ietf-ssh-client&modules[]=ietf-ssh-server&modules[]=
> ietf-restconf-client&modules[]=ietf-restconf-server&modules[
> ]=ietf-key-store&modules[]=ietf-netconf-client&modules[]=
> ietf-netconf-server&orgs[]=ietf&recurse=0&rfcs=1&show_subm=1
>

That's much clearer (and not what I thought the original text was saying at
all - thanks!)

If this is a cut and paste, there's a missing space between "known" and
"dependencies".

> is common is that both must transport YANG encoded information.

I'm sorry for asking a poorly formed question. I think a more coherent
version would be, "is it the intention that the YANG encoded information
transported by both protocols will be the same", but that's probably not
quite right, either. What I'm asking is, are you expecting that both
protocols will carry any new extensions, maybe?

But I was asking whether you expected the working group to take on new work
that didn't apply to both NETCONF and RESTCONF.

> Thanks for your feedback.

Oh, thank you :-)

Spencer