Subject: [NGO] What work should we charter next?

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 20 Mar 2007 04:49:39 -0400

X-Mailman-Verse obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-chisholm-netconf-monitoring-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C76ACC.CAC150A2
Content-Type: application/octet-stream;
	name="ATT600533.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT600533.TXT
Content-Disposition: attachment;
	filename="ATT600533.TXT"

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl
cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy0zLTExNTI1NTcuSS1EQGlldGYub3JnPg0KDQpFTkNP
RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2hpc2hvbG0tbmV0Y29uZi1t
b25pdG9yaW5nLTAwLnR4dA0K

------_=_NextPart_001_01C76ACC.CAC150A2
Content-Type: application/octet-stream;
	name="draft-chisholm-netconf-monitoring-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-chisholm-netconf-monitoring-00.URL
Content-Disposition: attachment;
	filename="draft-chisholm-netconf-monitoring-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1jaGlzaG9sbS1uZXRjb25mLW1vbml0b3JpbmctMDAudHh0DQo
------_=_NextPart_001_01C76ACC.CAC150A2
Content-Type: text/plain;
	name="ATT600534.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT600534.txt
Content-Disposition: attachment;
	filename="ATT600534.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo
------_=_NextPart_001_01C76ACC.CAC150A2
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

------_=_NextPart_001_01C76ACC.CAC150A2--

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 20 Mar 2007 11:21:32 +0200

AD hat on: 

1. BOFs need to be approved by the IESG and IAB (well, ADs approve
formally, but the IAB and IESG discuss and have a saying). Expect
scrutiny and prepare well. A well defined proposal needs to be ready at
least one and a half month before the meeting. I will let you know exact
dates when I will know them. 
2. If you believe that having a designated XML expert support the data
model activity we can ask for one from the directorate. Please write a
short problem statement so that they can have an idea of the problems
that we are trying to solve

AD hat off: 

1. I believe that standardizing a data model is high priority for the
success of NETCONF
2. NGO could deal with things not completed by original NETCONF charter.
For example specific transport mapping issues. 

Dan

> -----Original Message-----
> From: Sharon Chisholm [mailto:[email-masked]] 
> Sent: Tuesday, March 20, 2007 10:50 AM
> To: [email-masked]
> Subject: [NGO] What work should we charter next?
> 
> Hi
> 
> There seems to be lot of interest in building on the base 
> Netconf to address various gaps that people have identified 
> while implementing. If we were to do a BOF in Chicago and 
> present a charter for a new working group to address some 
> issues, what sort of problems should that charter solve?
> 
> Here are some of the items I'd like to see
> 
> 1. Standardized learning of what XML Schema and versions are 
> supported on a system
> 	I get asked this question a *lot*. We have a solution 
> in my organization but an IETF solution would be much  better.
> 2. Using XML Schema to define Netconf Content (draft 
> available) 3. Monitoring Netconf protocol (draft available)
> 
> Other topics I think are important
> 1. Access control (draft available), although in practice 
> this doesn't seem gating. I'm not sure why.
> 2. Finer grain locking
> 3. Channelized SSH 
> 
> Most of the other work that people have done is also very 
> useful, but I think we need to prioritize.
> 
> Sharon Chisholm
> Nortel
> Ottawa, Ontario
> Canada
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 20 Mar 2007 10:26:23 +0100 (CET)

> 3. Channelized SSH 

Is anything needed for this?  The channel mechanism is of course built
into SSH, and there's nothing in rfc4742 that talks about limiting
the number of channels to one.

I also suspect that most implementations will handle this by default.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 20 Mar 2007 13:20:24 +0100

I earlier had a simple draft on fine grain locking.
Balazs

Sharon Chisholm wrote:
> Hi
> 
> There seems to be lot of interest in building on the base Netconf to
> address various gaps that people have identified while implementing. If
> we were to do a BOF in Chicago and present a charter for a new working
> group to address some issues, what sort of problems should that charter
> solve?
> 
> 1. Standardized learning of what XML Schema and versions are supported
> on a system
> 	I get asked this question a *lot*. We have a solution in my
> organization but an IETF solution would be much  better.
> 2. Using XML Schema to define Netconf Content (draft available)
> 3. Monitoring Netconf protocol (draft available)
> 
> 1. Access control (draft available), although in practice this doesn't
> seem gating. I'm not sure why.
> 2. Finer grain locking
> 3. Channelized SSH 
> 
> Most of the other work that people have done is also very useful, but I
> think we need to prioritize.
> 
> Sharon Chisholm
> Nortel 
> Ottawa, Ontario
> Canada
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

Network Working Group                                        B. Lengyel
Internet-Draft                                          	   Ericsson
Expires: May 14, 2006                                 December 11, 2005

           Granular Locking for the NETCONF Configuration Protocol
               draft-lengyel-netconf-granular-locking-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 14, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The NETCONF protocol describes the lock and unlock operations 
   that (un)lock an entire configuration datastore. Often it is 
   needed to allow multiple management sessions to modify the 
   configuration of a managed element. In these cases it would be 
   needed to be able to lock only a part of a configuration 
   datastore. This draft proposes a capability based extension to 
   the NETCONF protocol to allow this.

   Please send comments to [email-masked].  To subscribe, use
   [email-masked].

Lengyel                     Expires May 14, 2006               [Page 1]

Internet-Draft         Netconf Granular Locking           December 2005

1.  Introduction

   The NETCONF protocol describes the lock and unlock operations 
   that (un)lock an entire configuration datastore. Often it is 
   needed to allow multiple management sessions to modify the 
   configuration of a managed element. In these cases it would be 
   needed to be able to lock only a part of a configuration 
   datastore. This draft proposes a capability based extension to 
   the NETCONF protocol to allow this.
   
   The managed information model behind NETCONF will not be 
   stable for a considerable time. Even so a mechanism for granular 
   locking can be defined based on the existing subtree filtering 
   and XPATH selection mechanisms in the protocl draft.
   
   Granular locking should be introduced as a capability into netconf.

2.  Granular Locking Capability

2.1.  Overview

   The :granular-locking capability indicates that the device supports
   the lock and unlock operations with a scope smaller then a complete 
   configuration datastore. The target can be specified using a 
   combination of a target datastore and a subtree filter or an 
   XPATH filter expression. A granular lock will succeed only if no 
   parts of the scope to be locked are locked by other management 
   users including users of NETCONF or any other management method. 
   The granular unlock operation has to specify the scope just the 
   same way as the granular lock operation. Granular unlock will only 
   succeed if the whole of the specified scope has been locked by the 
   user attempting to use the unlock operation. 

2.2.  Dependencies

   The :granular-locking capability's XPATH option is only relevant 
   if the :xpath capability is also supported.

2.3.  Capability Identifier

   The :granular-locking capability is identified by the following
   capability string:

      urn:ietf:params:netconf:capability:granular-locking:1.0

2.4.  New Operations

   None.

Lengyel                     Expires May 14, 2006               [Page 3]

Internet-Draft             Netconf Granular Locking       December 2005

2.5.  Modifications to Existing Operations

2.5.1.  <lock>

   The :granular-locking capability modifies the <lock> operation
   to accept a <filter> element beside a <target>.

2.5.2.  <unlock>

   The :granular-locking capability modifies the <unlock> operation
   to accept a <filter> element beside a <target>.

3.  Security Considerations

   No change compared to the <lock> and <unlock> operation in [NETCONF].

4.  IANA Considerations

	None

5.  Authors and Acknowledgements

   This document was written by:

      Balazs Lengyel, Ericsson

6.  References

7.1.  Normative References

   [NETCONF]  Enns, R., "NETCONF Configuration Protocol",
              ID draft-ietf-netconf-prot-09, October 2005.

Appendix A.  Change Log

A.1.  First version

   o  Initial version

Author's Address

   Balazs Lengyel (editor)
   Ericsson
   P.O. BOX 107
   1037 Budapest
   Hungary

   Email: [email-masked]