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

[Benoit Claise <[e-mail]>]

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.
> 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 <[e-mail]>
>      Mehmet Ersue <[e-mail]>
>
>  Operations and Management Area Directors:
>      Ronald Bonica <[e-mail]>
>      Benoit Claise <[e-mail]>
>
>  Operations and Management Area Advisor:
>      Benoit Claise <[e-mail]>
>
>  Mailing Lists:
>      General Discussion: [e-mail]
>      To Subscribe:       [e-mail]
>         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
>
>