Subject: [Netconf] Requesting AD/IESG approval: new/revised NETCONF WG charter

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 04 Sep 2012 16:40:38 +0200

Benoit, hope you had a good vacation.

Below is the new WG charter that we have WG consensus
on. Pls get it approved by IESG.

We go from the assumption that IESG will approve and
we will start moving the documents as per the WG charter.
Hope that is OK.

Bert and Mehmet
Network Configuration (netconf)
-------------------------------

  Charter

  Current Status: Active

  Chairs:
      Bert Wijnen <[email-masked]>
      Mehmet Ersue <[email-masked]>

  Operations and Management Area Directors:
      Ronald Bonica <[email-masked]>
      Benoit Claise <[email-masked]>

  Operations and Management Area Advisor:
      Benoit Claise <[email-masked]>

  Mailing Lists:
      General Discussion: [email-masked]
      To Subscribe:       [email-masked]
         or:              https://www.ietf.org/mailman/listinfo/netconf
      Archive:            http://www.ietf.org/mail-archive/web/netconf/

Description of Working Group:

   Configuration of networks of devices has become a critical requirement
   for operators in today's highly interoperable networks. 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. Each of these mechanisms may be different in
   various aspects, such as session establishment, user authentication,
   configuration data exchange, and error responses.

   The NETCONF Working Group has produced a protocol suitable for
   network configuration, with the following characteristics:

   - Provides retrieval mechanisms which can differentiate between
     configuration data and non-configuration data
   - Is extensible enough so that vendors can provide access to all
     configuration data on the device using a single protocol
   - Has a programmatic interface (avoids screen scraping and
     formatting-related changes between releases)
   - Uses an XML-based data representation, that can be easily manipulated
     using non-specialized XML manipulation tools.
   - Supports integration with existing user authentication methods
   - Supports integration with existing configuration database systems
   - Supports multiple (e.g. candidate and running) data-stores to
     optimize configuration preparation and activation
   - Supports network wide configuration transactions (with features such
     as locking and rollback capability)
   - Runs over a secure transport; SSH is mandatory to implement while TLS,
     BEEP, and SOAP are optional transports.
   - Provides support for asynchronous notifications.
   - Supports an Access Control Model and a YANG module for configuring
     the Access Control parameters.
   - Supports a YANG module for System Notifications

   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.

   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.

Goals and Milestones:
   done     - Send with-defaults to IESG for consideration as Proposed Standard
   done     - WG Last Call on rfc4741bis
   done     - rfc4741bis to IESG for consideration as Proposed Standard
   done     - Send rfc4742bis to IESG for consideration as proposed Standard.
   done     - first WG draft (rev 00) on NACM posted
   done     - first WG draft (rev 00) on NETCONF specific YANG modules posted
   done     - WGLC for NACM document
   done     - WGLC for NETCONF specific notifications document
   done     - submit NACM document to IESG for consideration as Proposed Standard
   done     - submit NETCONF specific notifications  document to IESG for
              consideration as Proposed Standard
   Sep 2012 - submit initial WG draft for rfc5539bis
   Sep 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic.
   Sep 2012 - WGLC for rfc5539bis
   Sep 2012 - WGLC for RFC4743 and 4743 to historic
   Okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard
   Okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic
   Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242
   Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience
   Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
   Feb 2013 - possibly submit RFC6241/6242 implementation/deployment experience doc
              to IESG for publication as Informational RFC.
   Mar 2013 - Evaluate if more work needs to be done by NETCONF WG

---

From: Benoit Claise <[email-masked]>
Date: Thu, 06 Sep 2012 13:50:29 +0200

Hi Bert, Mehmet,

Thanks for your effortssss on getting some consensus on this charter. I 
will now progress it

One note regarding this item:
   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).

We should evaluate if the clarifications to RFC6241 and RFC6242 impact 
RFC 6244. In other words, if RFC6244 is still correct. What I have in 
mind is section 4.3 and 4.4 related to configuration data, operational 
data, and statistical data. To be discussed in the WG.

At this point, I believe the item 2 text is sufficient.

Regards, Benoit.

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 06 Sep 2012 13:54:29 +0200

ack

Bert

On 9/6/12 1:50 PM, Benoit Claise wrote:
> Hi Bert, Mehmet,
>
> Thanks for your effortssss on getting some consensus on this charter. I will now progress it
>
> We should evaluate if the clarifications to RFC6241 and RFC6242 impact RFC 6244. In other words, if RFC6244 is still correct. What I
> have in mind is section 4.3 and 4.4 related to configuration data, operational data, and statistical data. To be discussed in the WG.
>