Network Configuration
charter-ietf-netconf-20

[Ballot comment]
I read this  to allow other working groups to work on models related to their protocols, as long as their protocols are not "network management protocols". Is this the intent?

As usual, I do not in general love the idea of standing WGs with open ended charters. But I think I'm an outlier on that point and will not get in the way of approval.

Since this recharter removes the more extensive history lesson from the later paragraphs, maybe it's also time to remove the history of the name from the first sentence? That is, just start with "The NETwork CONFiguration Working Group (NETCONF) is responsible..."

[Ballot comment]
Probably editorial comments on point 5:
- Maybe s/protocol-neutral/protocol-independent/
- And what's a transport message?

Regarding the milestones:
- Is it correct that not all points listed are covered by milestones? Is that on purpose?
- Is it really needed to call out the WGLC as a separate milestones? I've seen wg adoption as milestones but WGLC seems close enough to he final publication/send to IESG that I don't think a separate milestone is actually valuable.

[Ballot comment]
I agree with Spencer's comments.

Also, I have trouble suspending disbelief with those milestone dates. (Especially the ones in the past.) If those are real, it means the WG will be doing lots of work in parallel over the next couple of months. Is that reasonable?

[Ballot 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?

[Ballot comment]
The first paragraph...

The NETCONF Working Group, previously named after the NETCONF protocol, now renamed as the NETwork CONFiguration Working Group, is responsible for the development and maintenance of protocols for YANG data model driven management, for the necessary framework where these protocols run, and for the YANG modules that formalize protocol behavior and are required from a protocol perspective.

...seems to have significantly widened what the netconf  WG is responsible for beyond NETCONF/RESTCONF, but the rest of the charter only talks about those two protocols.  If the intent is to allow the WG to work on other protocols (or at least consider them if they exist, are brought to the WG, etc.), then it may be a good idea to include text that specifically mentions it.

[Ballot comment]
The first paragraph...

The NETCONF Working Group, previously named after the NETCONF protocol,
now renamed as the NETwork CONFiguration Working Group, is responsible for
the development and maintenance of protocols for YANG data model driven
management, for the necessary framework where these protocols run, and for
the YANG modules that formalize protocol behavior and are required from a
protocol perspective.

...seems to have significantly widened what the netconf  WG is responsible for beyond NETCONF/RESTCONF, but the rest of the charter only talks about those two protocols.  If the intent is to allow the WG to work on other protocols (or at least consider them if they exist, are brought to the WG, etc.), then it may be a good idea to include text that specifically mentions it.

[Ballot comment]
The first paragraph...

The NETCONF Working Group, previously named after the NETCONF protocol, now
renamed as the NETwork CONFiguration Working Group, is responsible for the
development and maintenance of protocols for YANG data model driven management,
for the necessary framework where these protocols run, and for the YANG modules
that formalize protocol behavior and are required from a protocol perspective.

...seems to have significantly widened what the netconf  WG is responsible for beyond NETCONF/RESTCONF, but the rest of the charter only talks about those two protocols.  If the intent is to allow the WG to work on other protocols (or at least consider them if they exist, are brought to the WG, etc.), then it may be a good idea to include text that specifically mentions it.

[Ballot comment]
I think this is ready for external review, which I understand to be the intent. I do not think it is ready for approval until the external review occurs.

[Ballot block]
This charter uses the term "I2RS protocol" and I2RS isn't doing its own protocol.

Now, what I heard secondhand is that the intent is for NetConf to defined the needed
capabilities so that the I2RS WG can define the necessary extensions - probably to
RestConf - to support the well-documented requirements.

As Responsible AD for I2RS, I need to actually hear and understand the change and intended
split of work.  This change is going to require a recharter for I2RS, since it is explicitly not
chartered to do any protocol work; the expectation has been that this would be done in NetConf
and NetMod, as needed.

I am quite positive on the idea of letting the I2RS WG define the necessary extensions and
finally be able to move at the speed appropriate to the active contributors - but we need
to be correct in terminology, clear on the work split, and understand how this will proceed.

[Ballot comment]
Does "which can be used to hold onto asymmetric private keys and certificates" mean "which can be used to hold asymmetric private keys and certificates"?

[Ballot comment]
Can you please reflow this sensibly so that each paragraph is not one giant line?

Editorial comments:

"Working Groiup" -> "Working Group"

4. "the YANG 1.1 constructs" -> "YANG 1.1 constructs"

5. Remove "e.g." as it is redundant with "including"

"Following specifications" -> "The following specifications"

remove "i.e."

These milestones seem crazy aggressive unless the documents are basically already done.

Changed charter milestone "Submit server configuration data model to AD/IESG for consideration as", set description to "Submit server configuration data model to AD/IESG for consideration as Proposed Standard "

[Ballot comment]

Hmm - how is the push mechanism going to work? There
is a chance such a proposal might cause a fuss later, so
could be useful to ensure we have a sane starting point
now - do we?

[Ballot comment]
Could you expand on "secure HTTP"?  Does this mean session encryption and authentication will be secure, one or the other, or something else?  Thanks.

[Ballot comment]
You might consider moving the paragraph about producing a status report in a later stage to after the text about work items for the current phase.

Item 1: Can you give the full draft names for the mentioned drafts?

item 2: This seems like several items.

[Ballot comment]
One question:
For work item 2, is it intended to have that be https-only?  If so, should the charter say that?  If not, why not?

[Ballot comment]
No objection because I believe more than a couple of people got together that implemented SSH and felt that the solution was okay.  this is not to say that sailing will be smooth on the reverse SSH draft.  I would request that the ssh list, which is still active, at least be kept in the loop.

Changed charter milestone "Submit Reverse SSH and and zero touch configuration to AD/IESG for consideration as Proposed Standard", set description to "Submit Reverse SSH to AD/IESG for consideration as Proposed Standard"

[Ballot comment]
Milestone nit:

  May 2014  Submit zero touch configuration to AD/IESG for consideration as Proposed Standard
[...]
  May 2014  Submit Reverse SSH and and zero touch configuration to AD/IESG for consideration as Proposed Standard

The first is a duplicate of the second. Change the second to:

  May 2014  Submit Reverse SSH to AD/IESG for consideration as Proposed Standard

[Ballot comment]

I'm with Pete on zero-touch and can imagine that being a
source of contention. I'd be fine if the WG had to define
it after being re-chartered or if it were defined in the
charter (and definition via reference would be fine if
that's better).

Changed charter milestone "Submit Reverse SSH and zero touch configuration to AD/IESG for consideration as Proposed Standard", set description to "Submit Reverse SSH and and zero touch configuration to AD/IESG for consideration as Proposed Standard"

Changed charter milestone "Submit initial WG drafts for RESTCONF and patch operation as WG item", set description to "Submit initial WG drafts for RESTCONF and patch operation as WG items"

Changed charter milestone "Submit initial WG drafts for zero touch configuration as WG item", set description to "Submit initial WG draft for zero touch configuration as WG item"

[Ballot comment]
Agree with hacking back the descriptive text as suggested by Stewart. Probably replace with pointer to an RFC or two.

---

Would be interesting to add a note that the RestConf work will consider requirements suggested by the I2RS working group. That is, not a demand to listen to I2RS, and not a statement that I2RS will use RestConf, but an intermediate position that say that the Netconf WG will look to see what I2RS is working on.

[Ballot comment]
Should be fixed before external review, but not showstoppers:

  2. Develop a zero touch configuration document, specific the NETCONF use case.

- I have no idea what "zero touch configuration" is, and the charter doesn't define it at all. It really should be described.
- The second clause is ungrammatical. Do you simply mean, "specific to the NETCONF use case"?

Milestone nits:

  Feb 2014  Submit initial WG drafts for zero touch configuration as WG item

"drafts"? There must be more than one? If so, s/item/items. Otherwise, s/drafts/draft.

  Feb 2014  Submit initial WG drafts for RESTCONF and patch operation as WG item

These need to be done as separate drafts but submitted together? Either make them two separate milestones, or s/item/items.

  May 2014  Submit zero touch configuration to AD/IESG for consideration as Proposed Standard
[...]
  May 2014  Submit Reverse SSH and zero touch configuration to AD/IESG for consideration as Proposed Standard

Seems to me the second should strike "and zero touch configuration".

[Ballot comment]
I have no objection to the re-chartering.

A couple of notes

Reason for rechartering is stated as: 1st meeting at the 54th IETF in Yokohama, Japan

I imagine that no longer to be the reason for the charter text change.

Of greater substance, the charter spends a lot of time talking about the details of the protocol, that must be well known and well documented. It might be worth trimming it back to the current matters of substance.

[Ballot comment]
The following looks a little strange and the point is solely for the IESG tools team folks:

Reason for rechartering: 1st meeting at the 54th IETF in Yokohama, Japan

[Ballot comment]
Shouldn't the references to BEEP and SOAP here be removed because those mechanisms were made historic:

- Runs over a secure transport; SSH is mandatory to implement while TLS,
  BEEP, and SOAP are optional transports.

[Ballot comment]
Is it necessary to have a long list of promotional aspects of Netconf
in the charter? Netconf is already published, the RFCs say what it is
and how it flies.

And I'm not sure it is necessary to advertise YANG either.

Changed charter milestone "Evaluate if more work needs to be done by NETCONF WG", set description to "Submit rfc5539bis to AD/IESG for consideration as Proposed Standard", set due date to August 2013 from March 2013

Changed charter milestone "possibly submit RFC6241/6242 implementation/deployment experience doc to IESG for publication as Informational RFC", set description to "WGLC for Reverse SSH", set due date to July 2013 from February 2013

Changed charter milestone "Initial I-D for RFC6241/6242 implementation/deployment experience", set description to "Submit initial WG document on Reverse SSH", set due date to May 2013 from December 2012

[Ballot comment]
[I changed my mind and decided that this issue shouldn't block external review. I would like to see it addressed before going out for External review, but we can always remove it later.]

  3. Since Netconf over BEEP and over SOAP seem not being deployed
    the WG will write a document that makes those 2 protocols
    (RFC4743 and RFC4744) HISTORIC.

Aside from my usual complaint about documents "making" other documents Historic, I'm not clear on why a document is needed here at all. Is there some review or documentation that needs to be done by the WG? If not, the IESG should simply issue a Last Call for 4743 and 4744 to move to Historic and remove this item from the charter. If there *does* need to be WG review and documentation of the reasons that these two are no longer relevant and should be moved to Historic, please rewrite this item as:

  3. Since Netconf over BEEP and over SOAP seem not to be deployed,
    the WG will write a document that explains why these 2 protocols
    (RFC4743 and RFC4744) are no longer used and recommending to
    the IESG that they be moved to HISTORIC.

Again, I don't know that such a document (and therefore this work item) is necessary.

[Ballot block]
  3. Since Netconf over BEEP and over SOAP seem not being deployed
    the WG will write a document that makes those 2 protocols
    (RFC4743 and RFC4744) HISTORIC.

Aside from my usual complaint about documents "making" other documents Historic, I'm not clear on why a document is needed here at all. Is there some review or documentation that needs to be done by the WG? If not, the IESG should simply issue a Last Call for 4743 and 4744 to move to Historic and remove this item from the charter. If there *does* need to be WG review and documentation of the reasons that these two are no longer relevant and should be moved to Historic, please rewrite this item as:

  3. Since Netconf over BEEP and over SOAP seem not to be deployed,
    the WG will write a document that explains why these 2 protocols
    (RFC4743 and RFC4744) are no longer used and recommending to
    the IESG that they be moved to HISTORIC.

Again, I don't know that such a document (and therefore this work item) is necessary.

[Ballot comment]
For simplicity and clarity, I suggest deleting the bullet list
of netconf features and substitute:

The NETCONF Working Group has produced a protocol for
network configuration, which is documented in RFC6241.

[Ballot comment]
Some nits:

r/interoperable/interconnected ?

I thought the following was a little hard to parse (might I suggest):

OLD:

Operators from
  large to small have developed their own mechanisms or used vendor
  specific mechanisms to transfer configuration data to and from a
  device, and for examining device state information which may impact
  the configuration.

NEW:

Large and small operators alike have developed their own mechanisms or have used vendor specific mechanisms to transfer configuration data to and from a device and to examine device configuration data.

I guess I'd go with the thought that's it's more than suitable ;)

r/The NETCONF Working Group has produced a protocol suitable for
  network configuration, with
/The NETCONF protocol has

r/independent/indepentently

How about this:

OLD:

  The NETCONF protocol has been designed independent of the data modeling
  language.  The IETF recommends to use YANG as the NETCONF  modeling
  language, which introduces advanced language features for configuration
  management.

NEW:

The NETCONF protocol is data modeling language independent, but YANG is the recommended NETCONF  modeling language, which introduces advanced language features for configuration  management.

OLD:

  In the current phase of the incremental development of NETCONF the
  workgroup will focus on following items:

1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
    This means that RFC5593 needs to be updated.

  2. Based on the implementation, deployment experience and interoperability
    testing, the WG will document the status of NETCONF in a report.
    Based on this, the WG may decide to make some clarifications to
    RFC6241 and RFC6242 (then also fixing any reported errata).

  3. Since Netconf over BEEP and over SOAP seem not being deployed
    the WG will write a document that makes those 2 protocols
    (RFC4743 and RFC4744) HISTORIC.

NEW:

  In the current phase of NETCONF's incremental development the
  workgroup will focus on following items:

1. Advance NETCONF over TLS to be in-line with NETCONF 1:1
    (i.e., update RFC5593).

  2. Based on the implementation, deployment experience and interoperability
    testing, the WG will produce a NETCONF status report.
    The result may be clarifications for RFC6241 and RFC6242 and addressing
    any reported errata.

  3. Since Netconf over BEEP and over SOAP is not deployed
    the WG will write a document that makes those 2 protocols
    (RFC4743 and RFC4744) HISTORIC.

RFCs for the old charter have been produced. Here is the new set of milestones for NETCONF. After much debates on the mailing list, the minimal charter has been agreed upon.
The first four paragraphs, i.e. introductory text, are unchanged (except a few bullet points in the third paragraph, which have been produced lately).
So really, your focus should be on the text below:
  In the current phase of the incremental development of NETCONF the
  workgroup will focus on following items: