[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: updated NETCONF charter text (replace instead of merge this t ime)
Hi,
While I sympathize with the desire for a granular locking
mechanism, in the absence of a mandatory standard data model
for NetConf, the _meaning_ of a fine-grained lock is anyone's
guess.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Balazs Lengyel
> Sent: Thursday, December 08, 2005 10:45 AM
> Cc: Netconf (E-mail)
> Subject: Re: updated NETCONF charter text (replace instead of
> merge this
> time)
>
>
> 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 netconf-request@ops.ietf.org 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: +36 1 4377792
> Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com
>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>