Network Configuration
charter-ietf-netconf-20

s/5593/5539/  (!)

[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.

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.

  Typo: "NETCONF 1:1" --> "NETCONF 1.1"

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.