Re: updated NETCONF charter text (replace instead of merge this time)

[Balazs Lengyel <[e-mail]>]

Hello Andy,
I believe that a granular locking mechanism should be included in the second phase.
Balazs

Andy Bierman wrote:
> Description of Working Group:
> Wes Hardaker 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 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 the following support for asynchronous notifications:
>     - Specify the <hello> message (capability exchange) details to
>       support notifications.
>     - Specify the application mapping details to support notifications.
>     - Specify the protocol syntax and semantics of a notification message.
>     - Specify or select a notification content information model.
>     - Specify a mechanism for controlling the delivery (turn on/off)
>       of notifications during a session.
>     - Specify a mechanism for selectively receiving a configurable 
> subset of
>       all possible notification types.
> 
> The Netconf protocol will use XML for data encoding purposes,
> because XML is a widely deployed standard which is supported
> by a large number of applications. XML also supports hierarchical data
> structures.
> 
> 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
> 
> It should be possible to transport the Netconf protocol using several
> different protocols. The group will select at least one suitable
> transport mechanism, and define a mapping for the selected protocol(s).
> 
> The initial work will be restricted to the following items:
> 
>  - Netconf Protocol Specification, which defines the operational
>    model, protocol operations, transaction model, data model
>    requirements, security requirements, and transport layer
>    requirements.
> 
>  - Netconf over <Transport-TBD> Specification, which defines how
>    the Netconf protocol is used with the transport protocol
>    selected by the group, and how it meets the security and
>    transport layer requirements of the Netconf Protocol
>    Specification.. There will be a document of this type for
>    each selected transport protocol.
> 
> The working group will take the XMLCONF Configuration Protocol
> <draft-enns-xmlconf-spec-00.txt> as a starting point.
> 
> Additional Notification work will be addressed after the initial work
> is completed.
> 
> An individual submission Internet Draft has been proposed to the WG
> as the starting point for the Notification work.  The WG shall adopt the
> document identified as 'draft-chisholm-netconf-event-01.txt' as the
> starting point for this work.
> 
> 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  Dec 05   Update charter
> Jan 06   Submit first version of NETCONF Notifications document
> Sep 06   Begin WGLC of NETCONF Notifications document
> Dec 06   Submit final version of NETCONF Notifications document to IESG for
>              consideration
> 
> 
> 
> 
> 
> -- 
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager & AXD Operational Suite (AOS) OPM
ECN: 831 7320                        Fax: [phone]
Tel: [phone]     email: [e-mail]

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>