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

Andy Bierman <ietf@andybierman.com> Sat, 10 December 2005 02:05 UTC

Message-ID: <439A35E1.1070800@andybierman.com>
Date: Fri, 09 Dec 2005 17:56:49 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: "McDonald, Ira" <imcdonald@sharplabs.com>
CC: 'Balazs Lengyel' <balazs.lengyel@ericsson.com>, "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: updated NETCONF charter text (replace instead of merge this time)
References: <CFEE79A465B35C4385389BA5866BEDF00C7E42@mailsrvnt02.enet.sharplabs.com>
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7E42@mailsrvnt02.enet.sharplabs.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

McDonald, Ira wrote:

>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.
>  
>

Ira is quite correct.
Without a standard for object and instance naming,
there cannot be a standard for identifying which subset of the
configuration datastore is being locked.

Has anyone implemented partial locking yet?
Are you doing it by adding an Xpath expression parameter
to the lock command (hint, hint)?  What about instance naming though?

Sidebar:  I'm not impressed with the way ANY of the XML modeling
languages handle instance naming, but more on that another day...

>Cheers,
>- Ira
>
>  
>

Andy

>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/>
>
>
>  
>


--
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/>

RE: updated NETCONF charter text (replace instead… McDonald, Ira
Re: updated NETCONF charter text (replace instead… Andy Bierman