Subject: [Netconf] WGLC for proposed new WG charter - pls comment by Aug 8th

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 02 Aug 2010 09:59:39 +0200

WG participants, as discussed during our session at the
IETF meeting in Maastricht, we are planning to start work
on the Netconf Access Control Model (NACM) and also do some
work on the netconf-system-specific data model.

Below is the proposed charter text for that that your
chairs want to present to our AD.

This is a 1 week WGLC to comment on that.
Pls send your comments asap,m but no later than 8 Aug 2010.

If you suggest changes, then pls try to provide proposed
text as well.

Bert and Mehmet

----- draft new charter text as proposed on Aug 1 2010.

Network Configuration (netconf)
-------------------------------

 Charter

 Current Status: Active

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

 Operations and Management Area Directors:
     Dan Romascanu <[email-masked]>
     Ronald Bonica <[email-masked]>

 Operations and Management Area Advisor:
     Dan Romascanu <[email-masked]>

 Tech Advisor:
     Charlie Kaufman <[email-masked]>

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

Description of Working Group:

  Charlie Kaufman is Technical Advisor for Security Matters

  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 is chartered to produce 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 will 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 a textual data representation, that can be easily manipulated
    using non-specialized text manipulation tools.
  - Supports integration with existing user authentication methods
  - Supports integration with existing configuration database systems
  - Supports network wide configuration transactions (with features such
    as locking and rollback capability)
  - Is as transport-independent as possible
  - Provides support for asynchronous notifications.

  The NETCONF protocol is using XML for data encoding purposes, because
  XML is a widely deployed standard which is supported by a large number
  of applications.

  The NETCONF protocol should be independent of the data definition
  language and data models used to describe configuration and state
  data.

  However, the authorization model used in the protocol is dependent on
  the data model. Although these issues must be fully addressed to
  develop standard data models, only a small part of this work will be
  initially addressed. This group will specify requirements for standard
  data models in order to fully support the NETCONF protocol, such as:

  - identification of principals, such as user names or distinguished names
  - mechanism to distinguish configuration from non-configuration data
  - XML namespace conventions
  - XML usage guidelines

  The initial work started in 2003 and has already been completed and was
  restricted to following items:

    a) NETCONF Protocol Specification, which defines the operational model,
       protocol operations, transaction model, data model requirements,
       security requirements, and transport layer requirements.
    b) NETCONF over SSH Specification: Implementation Mandatory,
    c) NETCONF over BEEP Specification: Implementation Optional,
    d) NETCONF over SOAP Specification: Implementation Optional.

    These documents define how the NETCONF protocol is used with each
    transport protocol selected by the working group, and how it meets
    the security and transport layer requirements of the NETCONF Protocol
    Specification.

    e) NETCONF Notification Specification, which defines mechanisms that
       provide an asynchronous message notification delivery service for
       the NETCONF protocol.  NETCONF Notification is an optional
       capability built on top of the base NETCONF definition and
       provides the capabilities and operations necessary to support
       this service.

    The NETCONF notification specification has been finished now as well.

  At re-chartering time (Aug 2010), the WG also had completed these work
  items:

  f) Fine-grain locking: The base NETCONF protocol only provides a lock
     for the entire configuration datastore, which is not deemed to meet
     important operational and security requirements. The NETCONF working
     group will produce a standards-track RFC specifying a mechanism for
     fine-grain locking of the NETCONF configuration datastore.

  g) NETCONF monitoring: It is considered best practice for IETF working
     groups to include management of their protocols within the scope of
     the solution they are providing. The NETCONF working group will
     produce a standards-track RFC with mechanisms allowing NETCONF
     itself to be used to monitor some aspects of NETCONF operation.

     Schema advertisement: Currently the NETCONF protocol is able to
     advertise which protocol features are supported on a particular
     netconf-capable device. However, there is currently no way to discover
     which XML Schema are supported on the device. The NETCONF working
     group will produce a standards-track RFC with mechanisms making this
     discovery possible (this item may be merged with "NETCONF monitoring"
     into a single document).

     Note: The schema-advertisement material has been merged into the
     NETCONF monitoring document based on WG consensus.

  h) NETCONF over TLS: Based on implementation experience there is a
     need for a standards track document to define NETCONF over TLS as an
     optional transport for the NETCONF protocol.

  i) NETCONF default handling: NETCONF today does not define whether
     default values should be returned by the server in replies
     to requests for reading configuration and state data. Different
     clients have different needs to receive or not to receive
     default data. The NETCONF working group will produce a
     standards-track RFC defining a mechanism that allows
     NETCONF clients to control whether default data is returned
     by the netconf server.

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

  1. NETCONF implementations have shown that the specification in RFC4741
     is not 100% clear and has lead to different interpretations and
     implementations. Also some errors have been uncovered. So the WG
     will do an rfc4741bis with following constraints:

       - bug fixes are to be done
       - clarifications can be done
       - extensions can be done only when needed to fix bugs
         or inconsistencies (i.e. we are not doing a NETCONF V2)
       - The work was started based on the discussion in IETF #73 (see
         http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf).

  2. A technical errata has been posted on rfc4742. The work on
     rfc4741bis also uncovered some additional fixes/clarifications that
     need to be made to rfc4742, the WG has been working on rfc4742bis
     and is nearly done with this work item.

  3. Netconf Access Control Model (NACM) Requirements and Solution.
 
     There is a need for standard mechanisms to restrict
     NETCONF protocol access for particular users to a pre- 
     configured (by operator) subset of all available NETCONF
     operations and content.

     The WG will produce a document which identifies the access
     control requirements specific to the NETCONF protocol, as
     defined in [4741bis].  This document will also provide a
     standard YANG data model which addresses these
     requirements.
 
     It is possible that the WG will not reach solution consensus
     on every possible requirement identified in the document.
     In this case, it is expected that the solution will evolve
     over time to meet the the remaining unmet requirements.

  4. The NETCONF protocol and the NETCONF server may want to
     allow a client to check the status at the server end.
     In addition, the server may want to notify interested
     clients about particular NETCONF protocol/server events.
     The WG will work on a NETCONF specific YANG module(s) to
     address this requirement. It is specific for NETCONF
     protocol and server information.

Goals and Milestones:
  Done     - Working Group formed
  Done     - Submit initial Netconf Protocol draft
  Done     - Submit initial Netconf over (transport-TBD) draft
  Done     - Begin Working Group Last Call for the Netconf Protocol draft
  Done     - Begin Working Group Last Call for the Netconf over 
(transport-TBD) draft
  Done     - Submit final version of the Netconf Protocol draft to the IESG
  Done     - Submit final version of the Netconf over SOAP draft to the IESG
  Done     - Submit final version of the Netconf over BEEP draft to the IESG
  Done     - Submit final version of the Netconf over SSH draft to the IESG
  Done     - Update charter
  Done     - Submit first version of NETCONF Notifications document
  Done     - Begin WGLC of NETCONF Notifications document
  Done     - Submit NETCONF Notifications document to IESG for 
consideration as Proposed Standard
  Done     - -00 draft for NETCONF Monitoring
  Done     - -00 draft for Schema Advertisement
  Done     - -00 draft for Fine Grain Locking
  Done     - -00 draft for NETCONF over TLS
  Done     - Early Review of client authentication approach (for NETCONF 
over TLS) with the
             security community at IETF 71
  Done     - WG Last Call on NETCONF Monitoring after IETF72
  Done     - WG Last Call on NETCONF over TLS after IETF72
  Done     - WG Last Call on Fine Grain Locking after IETF72
  Done     - Send Partial Locking to IESG for consideration as Proposed 
Standards
  Done     - Initial WG draft for with-defaults capability
  Done     - Initial WG draft for rfc4741bis
  Done     - WG Last Call on NETCONF Monitoring after IETF73
  Done     - Submit first WG draft for rfc4742bis
  Done     - WG Last Call on with-defaults
  Done     - Send NETCONF monitoring to IESG for approval as Proposed 
Standard
  Done     - WG Last Call for rfc4742bis
  Done     - with-defaults capability to IESG for considerations as 
Proposed Standard
  Aug 2010 - WG Last Call on rfc4741bis
  Sep 2010 - rfc4741bis to IESG for consideration as Proposed Standard
  Sep 2010 - Send rfc4742bis to IESG for consideration as proposed Standard.
  Sep 2010 - first WG draft (rev 00) on NACM posted
  Sep 2010 - first WG draft (rev 00) on System Monitoring posted
  Jan 2011 - WGLC for NACM document
  Jan 2011 - WGLC for System Monitoring document
  Mar 2011 - (if needed last) WGLC for NACM document
  Mar 2011 - (if needed last) WGLC for System Monitoring document
  Apr 2011 - submit NACM document to IESG for consideration as Proposed 
Standard
  Apr 2011 - submit System Monitoring document to IESG for consideration 
as Proposed Standard

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Aug 2010 10:37:17 +0200

> If you suggest changes, then pls try to provide proposed

Do we have to keep all the historic garbage for procedural reasons or
are we allowed to cut the charter to say one third, removing all the
stuff that is not relevant anymore because it is already part of RFCs.

I am happy to make a concrete proposal but before going there and
spending time on it, I thought I first ask whether there is anyone who
believes that keeping all the historic noise is a feature worth to
preserve.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 02 Aug 2010 11:10:20 +0200

> believes that keeping all the historic noise is a feature worth to
I guess I sort of do that (got used to do that) because in the past, we 
would easily loose such
information. Now that we in fact have all old charters archived and 
accessible from the
WG charter page, I would have no problem to remove all the old and 
completed stuff.

Dan, can you shed some light on this as well?

Bert

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 2 Aug 2010 11:20:48 +0200

Bert is correct. With the archiving capabilities no need to carry full
text of previous charter nor old milestones. I would just write a new
paragraph resuming the previous stages of standardization the current
stage builds upon, and I would keep from the old milestones only the
publication of the RFCs which helps newcomers to the Web page (who may
also not be too exercised in looking back in archives). 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bert (IETF) Wijnen
> Sent: Monday, August 02, 2010 12:10 PM
> To: Bert (IETF) Wijnen; netconf
> Subject: Re: [Netconf] WGLC for proposed new WG charter - pls 
> comment by Aug 8th
> 
> >> If you suggest changes, then pls try to provide proposed text as 
> >> well.
> >>     
> >
> I guess I sort of do that (got used to do that) because in 
> the past, we would easily loose such information. Now that we 
> in fact have all old charters archived and accessible from 
> the WG charter page, I would have no problem to remove all 
> the old and completed stuff.
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>