Subject: [NGO] Proposed Re-charting of NETCONF WG (was NEE)

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 1 Oct 2007 08:45:45 -0400

Hi

We agreed in an offline call that even though we are likely looking to
re-charter the existing NETCONF working group to take care of the work
initially proposed in the NEE BOF, that we would use the NGO mailing
list to for initial discussion so as not to clutter up the netconf
mailing list while they are trying to finish up the notification work.

Below is the current re-charter proposal. There are a couple of items
currently included in the future work items that I know there is some
support for. It would be good for people to re-iterate their support for
those items to get a good sense of whether they should be pulled
forward.

Thanks,

Sharon

---------------

A second phase of incremental development of NETCONF will include the
following items: 

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

(The initial draft will be based on
draft-lengyel-ngo-partial-lock-00.txt barring additional
contributions from the community.)

2. 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. NETCONF does not provide this capability.
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.

(The initial draft will be based on
draft-chisholm-netconf-monitoring-00.txt barring additional
contributions from the community.)

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

(The initial draft will be based on
draft-scott-netconf-schema-query-00.txt barring additional contributions
from the community.)

The following are currently not considered in scope for re-chartering at
this time, but may be candidates for work when there is community
consensus to take them on.

   o  NETCONF over TLS
   o  Access Control requirements
   o  General improvements to the base protocol
   o  Netconf access to SMI-based MIB data
   o  The Bill Fenner problem:  Address real or perceived issue that
"giving SSH for netconf gives full SSH access to the box" 

Goals and Milestones

(October should be read "When the WG is re-charted")

December 2007    -00 draft for Netconf Monitoring
December 2007    -00 draft for Schema Advertisement
December 2007    -00 draft for Fine Grain Locking
May 2008        WG Last Call on three documents
August 2008     - WG Last Call on Netconf Monitoring after IETF72 
August 2008     - WG Last Call on Schema Advertisement after IETF72 
August 2008     - WG Last Call on Fine Grain Locking after IETF72 
October 2008    Send three documents to the IESG

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 01 Oct 2007 06:38:36 -0700

> those items to get a good sense of whether they should be pulled

1) I do not believe all this work will be done by October 2008,
    but IETF charter milestones are mostly meaningless, so this
    is not important.

2) None of this work will actually move the IETF one step closer
    to fulfilling the original NETCONF charter.  They are nice features,
    but just like Notifications, not directly relevant to the pursuit
    of standard data models for network configuration.

3) The NETCONF WG began work over five years ago.
    At what point is the IETF going to actually work on standard
    data models for configuration, instead of standardizing a wrapper
    around proprietary CLI?  At what point is there actually going
    to be a standard data model suitable for use with <edit-config>?

> Sharon

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 1 Oct 2007 10:40:41 -0400

Hi

I think the datamodel work should start now but not in this working
group.

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, October 01, 2007 9:39 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [NGO] Proposed Re-charting of NETCONF WG (was NEE)

> support for. It would be good for people to re-iterate their support 
> for those items to get a good sense of whether they should be pulled 
> forward.

Andy

> draft-lengyel-ngo-partial-lock-00.txt barring additional contributions

> groups to include management of their protocols within the scope of 
> the solution they are providing. NETCONF does not provide this
capability.
> mechanisms allowing NETCONF itself to be used to monitor some aspects 
> of NETCONF operation.
> 

> which XML Schema are supported on the device. The NETCONF working 
> group will produce a standards-track RFC with mechanisms making this 
> discovery possible.
> 
> draft-scott-netconf-schema-query-00.txt barring additional 
> The following are currently not considered in scope for re-chartering 
> at this time, but may be candidates for work when there is community

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 01 Oct 2007 18:06:51 +0200

Hello Sharon,
I agree with the charter, but strongly support merging items 2 and 3.
Balazs
PS. Andy is right the data modeling must also start.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 3 Oct 2007 10:19:16 -0400

Hi,

I want to go on record as strongly opposing some of this proposed
work. 

The 2002 IAB workshop on network management did not call for a new
notification mechanism, nor a new monitoring mechanism, nor a new
schema discovery mechanism. All of these are reinventing solutions
rather than utilizing existing IETF standards.

Notifications were already addressed by SNMP and by syslog, yet this
WG decied they needed to reinvent notifications. SNMP is widely used
for monitoring networks, and designing a new protocol just to monitor
netconf does not make a lot of sense. 

It has been claimed that using SNMP to monitor Netconf is an unnatural
union. Is it also an unnatural union to use SNMP to monitor other
protocols, such as MPLS and Ethernet and Bridging and TCP and UDP and
IP? Should each of these protocols develop their own protocol-specific
extension for purposes of monitoring that protocol?

Where is the interoperability of defining a netconf extension to do
netconf-only monitoring? There is a multi-billion dollar industry of
applications using SNMP to monitor IP-based networks. The existing
monitoring infrastructure will not be able to monitor the netconf
protocol, if netconf monitoring requires a netconf-specific extension
to netconf. We should use SNMP to monitor the protocol, just like we
use SNMP to monitor other IETF protocols.

Is the intention to "get the foot in the door" so netconf can become
like SNMP - "let's do everything with our one protocol"? The
experience we have from the existing management framework is that a
one-protocol approach to management does not work adequately; we need
different protocols optimized for different purposes. Let's stop
trying to make Netconf do everything. Netconf should stay focused on
**configuration** - not notifications, not monitoring, not schema
discovery. We do not need to reinvent SNMP for purposes of
configuration.

We need the ability to allow multiple operators to simultaneously
configure different functionality within a device. We need the ability
to control which operators can configure which functionality within a
device. That, and a Data modeling language that meets the needs of
configuration, is what we should be focused on delivering.

David Harrington
[email-masked]
[email-masked]

> From: Sharon Chisholm [mailto:[email-masked]] 
> Sent: Monday, October 01, 2007 8:46 AM
> To: [email-masked]
> Subject: [NGO] Proposed Re-charting of NETCONF WG (was NEE)
> 
> Hi
>

---

From: Steve Berl <[email-masked]>
Date: Wed, 03 Oct 2007 08:58:36 -0700

My original requirement, long ago, was that netconf provide a way to get
asynchronous, "detailed" configuration change notifications to a management
application. This is to support applications that are attempting to keep a
"synchronized" copy of the current configuration in their own memory. The
notifications should be self contained by which I mean they need to contain
a description of what actually changed in the configuration, and not require
the management agent to go back and query the agent for more information.
The changes should be represented in a way that makes sense in terms of the
same data model used for the rest of the netconf operations.

Doing this with syslog and snmp has been problematic, mostly because of the
size of the messages. We need a way to do this.

This is not a requirement for a full blown, general purpose notification
protocol. We just need a solution for the problem described above.

-steve

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 Oct 2007 17:52:39 -0700

> size of the messages. We need a way to do this.

Write a draft proposing a solution, i.e., content
for the notification mechanism we just defined.
Do you want to capture the <edit-config> or <commit>
request that caused the change?  Do you want
this notification for every config, or just <running> config?

> protocol. We just need a solution for the problem described above.

Somebody else (from your company) said they needed a device-changed
notification as well to support hot-swap configuration.
Some vendors do want a generalized notification
delivery mechanism within NETCONF, with replay buffer, and filtering.

There is clearly WG consensus to finish this document,
after spending so much time reviewing and refining 11 versions of it.
There are multiple independent implementations in progress as well.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 04 Oct 2007 00:33:49 -0400

>after spending so much time reviewing and refining 11 versions of it.

At the Prague IETF, the "feel of the room" votes were low single
digits.  Is anyone really screaming for netconf-based notifications?
Did we define a generic facility when the requirements are for a
much smaller content set?

>There are multiple independent implementations in progress as well.

With no standard for how to carry syslog or SNMP (or config-related)
notifications over this new notification stuff, these implementations
are left to define their own content.  In the config world (where
all content is non-standard) this is bad, but in the notification
world (where all content is standard) it is much, much worse.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 Oct 2007 00:00:13 -0700

> much smaller content set?

There have been several vendors (mid-single digits) all along
who have supported the draft and have committed to implementing it.
This is more than enough to go to Proposed Standard in the IETF.

> world (where all content is standard) it is much, much worse.

IMO, it is not much worse.
We have been told there are barely one field's worth of compatibility
in a syslog message at the last IETF.

Except for the coldStart and a few other SNMP
notifications, there is mostly proprietary notification content,
just like with configuration.

Andy

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 4 Oct 2007 09:09:50 -0700

Hi,

I strongly agree with all the points that David makes
below.  Netconf as the "universal management solution"
of the future is a complete non-starter.  Netconf even
for *configuration* outside the router/switch industry
is a complete non-starter - it competes (unsuccessfully,
IMHO) with the rich open standard DMTF CIM model and
usage profiles, which are the stated standard data model
for both DMTF WS-Mgmt and OASIS WSDM in the future.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: David Harrington [mailto:[email-masked]]
Sent: Wednesday, October 03, 2007 9:19 AM
To: 'Sharon Chisholm'; [email-masked]
Subject: RE: [NGO] Proposed Re-charting of NETCONF WG (was NEE)

Hi,

David Harrington
[email-masked]
[email-masked]

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.14.0/1049 - Release Date: 10/4/2007 8:59 AM

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 Oct 2007 09:37:09 -0700

> for both DMTF WS-Mgmt and OASIS WSDM in the future.

I do not agree with either of you.
There are varying opinions on the role of SNMP wrt/NETCONF,
all the way from 'none' to 'MUST be used instead of NETCONF'.

I do not know of significant deployment of any standard configuration
mechanisms.  There are dozens of proprietary config file formats.
The situation is quite a mess actually.  In the router world, CLI is King
for configuration.  If you believe me, ask Randy Bush. (Remember the
"It's the CLI, Stupid" T-shirt?)

There is no way any one 'camp' will *ever* convince all the other 'camps'
that they should go away and use the one and only Great Solution instead.
IMO, NETCONF is in the 'Programmatic CLI phase'.  The next phase
should focus on how to transition from 100% proprietary config to an
ever-increasing percentage of standard config.  NETCONF isn't trying
to be a desktop application config file replacement.  The charter
is *network* configuration.

Regarding the specific work being proposed here:
  * The schema advertisement is simple and useful.
    It is needed to assist config applications
    identify the data models supported by each agent.
    The <hello> message could be extended, but the WG seems
    to favor a separate mechanism to keep the <hello> message size small.
  * The monitoring schema is not that important, but easy to implement.
    The overhead of adding an SNMP agent just for this is a non-starter,
    so the MIB version should be optional for those devices that already
    have SNMP agents.
  * Partial locking is NETCONF-specific, and important for optimizing
    config database performance in large devices

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 04 Oct 2007 15:13:41 -0400

>who have supported the draft and have committed to implementing it.

Sure, if it goes to standard, vendors will implement it.  My question
is: will anyone care?  No one seems to.  IMHO we've lost a lot of
momentum and operator support churning on a problem for which there
are already reasonable solutions.

>in a syslog message at the last IETF.

The strength of syslog is the vast amount of code that is
instrumented with syslog() calls.  The content is the message
payload, which is completely non-standard.

>In the router world, CLI is King
>...
>ever-increasing percentage of standard config.

So how do the following topics help us in that next phase:

- Notifications (the WG's output for the past year)
- Fine-grain locking
- Netconf monitoring
- Schema advertisement

These don't seem like the building blocks for the next phase, and
I don't think we can keep anyone interested if we decide to burn a
couple years working on them.

Agree with your phases:
(0) CLI is King
(1) Proprietary APIs
(2) Standard APIs
(3) Proprietary Content
(4) Standard Content

NETCONF brings us to (2).  I don't see any of the above items used
in these phases.

FWIW, IMHO I think phase 3.5 will end up being the key:  a phase in
which standard content is translated into device-specific content
and vice versa.  To get value out of your proto-standard models,
you need a way to leverage them on boxes that don't implement your
model.  Defining that translation layer is the key building block.

Important, hard, and interesting.  Why aren't we working on that?  ;^)

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 Oct 2007 13:00:55 -0700

> are already reasonable solutions.

Yes.  People have been reviewing every version.
I agree we have lost momentum, but a week before the
final version is published is a bit late to worry too
much about that.

> payload, which is completely non-standard.

That is my point.  No standard content.
The 'Yet Another' argument against NETCONF notifications
is valid, unless and until there is some standard content
such as a 'config-changed' notification.  The ability
to send notifications with the same data models as used
within the NETCONF databases will also be very useful in the future.

> - Notifications (the WG's output for the past year)

It doesn't.  (see my email rant that started this off ;-)

I actually implemented schema advertisement in a few hours,
under /netconf/schemaList, using <get>.  It is not redundant,
because the module info I send in the <hello> message does not
contain the 'schemaLocation' field or the 'version' field.

This does help automate tools quite a bit, rather than the
traditional approach of hard-wiring an off-line file,
based on some data point (sysObjectID).

> NETCONF brings us to (2).  I don't see any of the above items used

You are leaving Security Considerations out of the picture entirely.
I proposed work on an access control model for NETCONF,
but I was told (repeatedly) that the NEE charter items above are
more important right now than security.

> Important, hard, and interesting.  Why aren't we working on that?  ;^)

Some of us are, but not in the IETF.
This tends to be tool-specific, which usually
puts it out of scope in the IETF.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 4 Oct 2007 16:49:23 -0400

<Phil>
With no standard for how to carry syslog or SNMP (or config-related)
notifications over this new notification stuff, these implementations
are left to define their own content.  
</Phil>

I have little or no requirement to transport SNMP or syslog information
over NETCONF. The requirement I have is to transport event information.
It's a strong one, but luckily this work is almost done with the
protocol work for this so we can move ahead and start standardizing on
the content of notifications and other things. I believe this is a
separate working group though.

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 5 Oct 2007 07:11:44 -0400

Hi

I think the configuration focus or general protocol question is a bit of
a red herring. Either way we need
	- Standard data model
	- Schema discovery
	- The ability to monitor netconf
	- Access control
	- Finer-grain locking
	- and all the work chartered to date.

Sharon 

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Friday, October 05, 2007 6:26 AM
To: David Harrington
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: [NGO] Proposed Re-charting of NETCONF WG (was NEE)

I strongly agree with the section I have quoted from David Harrington's
mail, below:

On Oct 3, 2007, at 10:19 AM, David Harrington wrote:

> Let's stop

> configuration, is what we should be focused on delivering.

I don't really care whether a Netconf data model and Netconf access
control are developed in a WG called "netconf", but I think that is
where we should be focusing our efforts.

Margaret

---

From: Andy Bierman <[email-masked]>
Date: Sat, 06 Oct 2007 08:16:00 -0700

> rather than utilizing existing IETF standards.

The IAB workshop held over 6 years ago contained a lot
of recommendations, but not every topic in the industry
was discussed.

> netconf does not make a lot of sense. 

I want to comment on this bit, because Notifications are almost
done in the protocol, and not part of the proposed new work.

I want to go on record strongly opposing the coupling of SNMP
and NETCONF work within the IETF.  NETCONF is a new, perhaps
even someday a next-generation network management protocol, and it
should be allowed to develop protocol mechanisms that are
agreed upon, and chartered, just like any other protocol WG.

The management operations available in NETCONF aren't just
different than SNMP, they are better.  The integrated notification
replay and filtering is way simpler and better than
SNMP notification delivery, and can support complete event
reports within a single notification, since there are no
message size restrictions.

Standard content must be developed in addition to protocol features.
There seems to be wide agreement on that point.  By simply examining
the syntax structure of the RPC method parameters developed by
the NETCONF WG, it is clear that people want to take advantage
of the advanced data modeling capabilities of XML, and the advanced
API modeling capabilities of the protocol itself.

Andy

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 5 Oct 2007 06:25:32 -0400

I strongly agree with the section I have quoted from David  
Harrington's mail, below:

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 5 Oct 2007 06:25:32 -0400

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 5 Oct 2007 07:57:34 -0400

I agree that schema discovery and finer grained locking are things  
that we have to do in order to have a useful standard data model and  
an acceptable access control mechanism.

I'm not sure about "the ability to monitor netconf" as it is  
described in the charter, but I don't have any strong objection to  
the idea that part of our standard data model would cover the netconf  
protocol itself.

My concern with the charter is it just includes thoaw little things  
(schema discovery, monitoring, finer-grained locking) and not the  
bigger pieces that we really need to start working on (standard data  
model, access control).  I'm not wild about the idea of chartering  
these small things in netconf and hoping for another group to  
undertake the larger, more important things.

In fact, I am not even sure how we can fully understand what we need  
from schema discovery or finer-grained locking without understanding  
what we plan to do for a standard data model or access control.

Margaret

On Oct 5, 2007, at 7:11 AM, Sharon Chisholm wrote:

> Harrington's
> control are developed in a WG caO [192.168.2.8])
	by thingmagic.com (CommuniGate Pro SMTP 5.0.13)
	with ESMTPSA id 2323638; Fri, 05 Oct 2007 07:57:36 -0400
From: Margaret Wasserman <[email-masked]>
Subject: Re: [NGO] Proposed Re-charting of NETCONF WG (was NEE)
Date: Fri, 5 Oct 2007 07:57:34 -0400
To: Sharon Chisholm <[email-masked]>
Cc: [email-masked]

I agree that schema discovery and finer grained locking are things  
that we have to do in order to have a useful standard data model and  
an acceptable access control mechanism.

I'm not sure about "the ability to monitor netconf" as it is  
described in the charter, but I don't have any strong objection to  
the idea that part of our standard data model would cover the netconf  
protocol itself.

My concern with the charter is it just includes thoaw little things  
(schema discovery, monitoring, finer-grained locking) and not the  
bigger pieces that we really need to start working on (standard data  
model, access control).  I'm not wild about the idea of chartering  
these small things in netconf and hoping for another group to  
undertake the larger, more important things.

In fact, I am not even sure how we can fully understand what we need  
from schema discovery or finer-grained locking without understanding  
what we plan to do for a standard data model or access control.

Margaret

On Oct 5, 2007, at 7:11 AM, Sharon Chisholm wrote:

> Harrington's

lled "netconf", but I think that is

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Oct 2007 16:31:39 +0200

While adding my agreement to Ira's and other in support of the
multi-protocol vision drafted by David and about the fact that NETCONF
was not started and designed as the new universal management solution, I
would disagree that Netconf is a non-starter out of the router/switch
industry. There is nothing in the design of NETCONF that limits it to
configuration of switches and routers and there are other IP
applications and devices running where WSDM and WS-Mgmt would not work
over the network better than NETCONF or would not work at all. 

Dan

(speaking as contributor) 

> From: McDonald, Ira [mailto:[email-masked]] 
> Sent: Thursday, October 04, 2007 6:10 PM
> To: David Harrington; Sharon Chisholm; [email-masked]
> I strongly agree with all the points that David makes below.  
> Netconf as the "universal management solution"
> of the future is a complete non-starter.  Netconf even for 
> *configuration* outside the router/switch industry is a 
> complete non-starter - it competes (unsuccessfully,
> IMHO) with the rich open standard DMTF CIM model and usage 
> profiles, which are the stated standard data model for both 
> DMTF WS-Mgmt and OASIS WSDM in the future.
> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect) Chair - Linux 
> Foundation Open Printing WG Blue Roof Music / High North Inc 
> I want to go on record as strongly opposing some of this 
> proposed work. 
> 
> The 2002 IAB workshop on network management did not call for 
> a new notification mechanism, nor a new monitoring mechanism, 
> nor a new schema discovery mechanism. All of these are 
> reinventing solutions rather than utilizing existing IETF standards.
> 
> Notifications were already addressed by SNMP and by syslog, 
> yet this WG decied they needed to reinvent notifications. 
> SNMP is widely used for monitoring networks, and designing a 
> new protocol just to monitor netconf does not make a lot of sense. 
> 
> It has been claimed that using SNMP to monitor Netconf is an 
> unnatural union. Is it also an unnatural union to use SNMP to 
> monitor other protocols, such as MPLS and Ethernet and 
> Bridging and TCP and UDP and IP? Should each of these 
> protocols develop their own protocol-specific extension for 
> purposes of monitoring that protocol?
> 
> Where is the interoperability of defining a netconf extension 
> to do netconf-only monitoring? There is a multi-billion 
> dollar industry of applications using SNMP to monitor 
> IP-based networks. The existing monitoring infrastructure 
> will not be able to monitor the netconf protocol, if netconf 
> monitoring requires a netconf-specific extension to netconf. 
> We should use SNMP to monitor the protocol, just like we use 
> SNMP to monitor other IETF protocols.
> 
> Is the intention to "get the foot in the door" so netconf can 
> become like SNMP - "let's do everything with our one 
> protocol"? The experience we have from the existing 
> management framework is that a one-protocol approach to 
> management does not work adequately; we need different 
> protocols optimized for different purposes. Let's stop trying 
> to make Netconf do everything. Netconf should stay focused on
> **configuration** - not notifications, not monitoring, not 
> schema discovery. We do not need to reinvent SNMP for 
> purposes of configuration.
> 
> We need the ability to allow multiple operators to 
> simultaneously configure different functionality within a 
> device. We need the ability to control which operators can 
> configure which functionality within a device. That, and a 
> Data modeling language that meets the needs of configuration, 
> is what we should be focused on delivering.
> 
> David Harrington
> [email-masked]
> [email-masked]
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Oct 2007 16:43:38 +0200

I am (as a contributor) in agreement with much of what David says. I
would differ on just one issue. I see many protocols in the IETF (SIP
for example) adding reporting and notification capabilities and the line
of reasoning is that in real life applications devices should not be
mandated to support another protocol just to allow for monitoring (kind
of an 'in-band' philosophy from their point of view). I do not believe
that one camp will convince the other or one line will prevail, not on
short term anyway. This is why I consider defining a multi-protocol
framework for management an important task for our area, so that
different protocols should have a common set of understood requirements
about how performance is monitored and how notifications are carried.
Back to NETCONF this means in my opinion that although at a lower
priority such work items should not be excluded from a future charter if
people believe that they are useful and relative low effort additions. A
NETCONF monitoring scheme could be developped in parallel with a NETCONF
MIB for example, couldn't it? 

Dan

> Sent: Wednesday, October 03, 2007 4:19 PM

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Oct 2007 16:53:37 +0200

Margaret,

My assumption is that a standard data model work will be chartered in a
separate Working Group in one IETF cycle or two. There are at least a
couple of proposals that are being prepared and discussed, and a BOF
request was submitted for Vancouver. 

Dan

> Sent: Friday, October 05, 2007 1:58 PM
> To: Sharon Chisholm
> Cc: [email-masked]
> I agree that schema discovery and finer grained locking are 
> things that we have to do in order to have a useful standard 
> data model and an acceptable access control mechanism.
> 
> described in the charter, but I don't have any strong 
> objection to the idea that part of our standard data model 
> would cover the netconf protocol itself.
> 
> My concern with the charter is it just includes thoaw little 
> things (schema discovery, monitoring, finer-grained locking) 
> and not the bigger pieces that we really need to start 
> working on (standard data model, access control).  I'm not 
> wild about the idea of chartering these small things in 
> netconf and hoping for another group to undertake the larger, 
> more important things.
> 
> In fact, I am not even sure how we can fully understand what 
> we need from schema discovery or finer-grained locking 
> without understanding what we plan to do for a standard data 
> model or access control.
> 
> Margaret
> 
> > I think the configuration focus or general protocol 
> question is a bit 
> > of a red herring. Either way we need
> > 	- Standard data model
> > 	- Schema discovery

---

From: Andy Bierman <[email-masked]>
Date: Sun, 07 Oct 2007 08:31:00 -0700

Margaret Wasserman wrote:
> 
> I agree that schema discovery and finer grained locking are things that 
> we have to do in order to have a useful standard data model and an 
> acceptable access control mechanism.
> 
> I'm not sure about "the ability to monitor netconf" as it is described 
> in the charter, but I don't have any strong objection to the idea that 
> part of our standard data model would cover the netconf protocol itself.
> 
> (schema discovery, monitoring, finer-grained locking) and not the bigger 
> pieces that we really need to start working on (standard data model, 
> access control).  I'm not wild about the idea of chartering these small 
> things in netconf and hoping for another group to undertake the larger, 
> more important things.
> 

I guess I agree with your comments.
The NETCONF monitoring is kind of a Red Herring.
It isn't actually needed, in any encoding or protocol.
The counters and state info are of minor interest to implementors.
Proprietary debugging info exists, and creating a standard
data model for debugging should be a really low priority.

Each time a new data model is created, the WG can continue
to ignore access control and data model consistency, claiming
that "we aren't working on that yet".  Yet, all along,
the WG will be making data model consistency decisions (or not),
and impacting access control (knowingly or not).

There have been cases in the IETF where the IESG actually stepped
in and applied adult supervision, and forced WGs to prioritize
security over other features.  Perhaps the IESG will do its job here.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Oct 2007 11:03:24 +0200

Sharon,

I would suggest that you try to draw the line and issue a new version of
the re-charter proposal which I would like to discuss in the IESG
telechat on 10/18. If it passes the IESG it will be sent for review to
the whole IETF. We can expect more comments and need to do more changes
following these discussions. 

My opinion is that we need to focus on the protocol extensions working
on the assumptions that a data modeling language effort will start
happening in parallel if the YANG BOF will be successful. Data models
definition and examples as needed should be in the meantime included in
the I-Ds same as we have done until now. 

I prefer to minimize the number of work items. Personally I am not
convinced that NETCONF monitoring is a high priority item, but take this
as a contributor opinion. On the other hand I think that NETCONF over
TLS has gathered enough support and is in line with the current work.  

Also, please include the notifications related text and milestones that
need to be completed in the re-chartering proposal, so that we can start
to operate with one charter at a time. 

The sooner you can send this proposal the better, to be able to catch
the 10/18 slot in the IESG. 

Thanks and Regards,

Dan

> Sent: Monday, October 01, 2007 2:46 PM
> To: [email-masked]
> We agreed in an offline call that even though we are likely 
> looking to re-charter the existing NETCONF working group to 
> take care of the work initially proposed in the NEE BOF, that 
> we would use the NGO mailing list to for initial discussion 
> so as not to clutter up the netconf mailing list while they 
> are trying to finish up the notification work.
> 
> Below is the current re-charter proposal. There are a couple 
> of items currently included in the future work items that I 
> know there is some support for. It would be good for people 
> to re-iterate their support for those items to get a good 
> sense of whether they should be pulled forward.
> 
> Thanks,
> 
> Sharon
> 
> 
> ---------------
> 
> A second phase of incremental development of NETCONF will 
> include the following items: 
> 
> 1. 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.
> 
> 2. 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. NETCONF 
> does not provide this capability.
> 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.
> 
> 3. 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.
> 
> The following are currently not considered in scope for 
> re-chartering at this time, but may be candidates for work 
> when there is community consensus to take them on.
> 
>    o  NETCONF over TLS
>    o  The Bill Fenner problem:  Address real or perceived 
> issue that "giving SSH for netconf gives full SSH access to the box" 
> 
> 
> Goals and Milestones
>

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 10 Oct 2007 12:46:14 +0200

Hello Phil,
Ericsson is screaming for notifications. I want to be able to get a notification when long 
running configuration operations (e.g. backup) complete (or fail) without using SNMP.
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 10 Oct 2007 13:27:18 +0200

I know about the following companies that have significant non-router business who are 
currently in the process of implementing Netconf:

Ericsson, Nortel, Tailf, Tellabs, Sonus, Fujitsu, Qualcomm

So saying that Netconf is a complete non-starter seems a bit of the mark.

Balazs

---

From: Phil Shafer <[email-masked]>
Date: Wed, 10 Oct 2007 08:58:34 -0400

>running configuration operations (e.g. backup) complete (or fail) without using SNMP.

But how will you encode this notification?  What content will you
carry inside your <notification>?  While I think configuration is
currently completely proprietary, notifications aren't.  While no
one is using snmp for config, everyone is using it for notifications.

So my question is: since I have these two strong sources of
notifications (snmp and syslog), how do I encode them over netconf?
It's not rocket surgery, but it needs to be written down and
standardized.  This would have made a good usage scenario test case
before moving to last call.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 10 Oct 2007 09:03:36 -0400

>So saying that Netconf is a complete non-starter seems a bit of the mark.

But the key is that we're not developing a solution for those
markets.  We're developing a solution for router configuration.
Others might find it useful for their scenarios, but we are trying
to limit our audience so as to avoid the all-things-to-all-people
boiling-the-ocean grand-unified-theory issues that have sunk past
efforts.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Oct 2007 06:39:41 -0700

> one is using snmp for config, everyone is using it for notifications.

This document is not intended to define notification content.
This is the protocol specification for processing notifications,
just as RFC 4741 is for other protocol operations.

There are far more vendor-specific SNMP notifications
defined than standard notifications.  After 20 years,
there are probably a dozen widely supported SNMP notifications.

The WG debate whether this work should be done at all
has long passed.  Standard notifications will be defined
along with standard data, same as with MIB development.
There is interest in standardizing some notification content
already.

The notification feature is capability-driven (i.e., optional),
and vendors can choose to support SNMP, NETCONF, or both.

There is no question that it is easier for an application
developer to deal with a NETCONF feature and its async messages,
all within one protocol, rather than utilize and
integrate multiple protocol toolkits and data model languages.

> before moving to last call.

We did not have any standard config data when we went
to WGLC on RFC 4741 several years ago.  We still don't
have any standard config data.

I suppose people should write code, write drafts, and propose
the standard NETCONF notification encoding of these other
notification sources, plus the 'config-change' notification that
has been discussed.

There are several companies already implementing this draft,
before it is even done.  There is a need for event-driven
configuration applications (e.g., failure recovery, module-plugin).

I believe all these individuals who claim their company needs
this notification delivery mechanism to support the various
things they are doing with their NETCONF applications.

Andy

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Wed, 10 Oct 2007 15:43:50 +0200

Mmm.... I don't think I can agree that our NetConf protocol was/is
intended for just "router". Making sure it can be used for router
configuration was/is important. But I do not recall we ever wanted
ourselves to be limited to that.

Bert Wijnen  

> From: Phil Shafer [mailto:[email-masked]] 
> Sent: Wednesday, October 10, 2007 3:04 PM
> To: Balazs Lengyel
> Cc: [email-masked]
> Others might find it useful for their scenarios, but we are 
> trying to limit our audience so as to avoid the 
> all-things-to-all-people boiling-the-ocean 
> grand-unified-theory issues that have sunk past efforts.
> 
> Thanks,
>  Phil
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Oct 2007 06:47:50 -0700

> boiling-the-ocean grand-unified-theory issues that have sunk past

Amen. (To steal your phrase ;-)
I would change 'router' to 'network device',
but there is no doubt that router/switch configuration is a
complicated problem.  (It's like standardizing a TV remote control
with 10,000 buttons ;-)

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 10 Oct 2007 12:08:04 -0400

>ourselves to be limited to that.

My bad.  s/routers/networking equipment/

Thanks,
 Phil

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Oct 2007 18:10:05 +0200

Phil,

I am not sure what is this statement based upon. Certainly, we're
developing a solution for router configuration, but not only for
routers. There is nothing in the NETCONF charter that speaks about this
protocol being for configuration of routers only, on the contrary, I
think that we want it to be adopted for configuration purposes by a
broad range of applications running over IP, and there are other types
of IP devices and applications that are looking for NETCONF as a
solution. Focus is necessary, I agree, but not in limiting the design to
a specific class of devices. 

Dan

---

From: Phil Shafer <[email-masked]>
Date: Wed, 10 Oct 2007 12:11:16 -0400

>there are probably a dozen widely supported SNMP notifications.

A dozen?  That's just sad.

My point was that wrapping a standard (SNMP notifications) in a
non-standard mapping to send it over a standard NETCONF connection
was worse that wrapping a non-standard configuration in a standard
RPC mechanism over a standard NETCONF connection.

But if your take is that no one uses standard snmp notifications,
I can't prove you wrong.

Thanks,
 Phil

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Oct 2007 18:12:13 +0200

> The WG debate whether this work should be done at all has 
> long passed.  

I agree.

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Oct 2007 18:13:55 +0200

> Sent: Wednesday, October 10, 2007 6:08 PM
> To: WIJNEN, Bert (Bert)
> Cc: [email-masked]

I can live with this. 

Dan

PS - Is an application server a network device? :-)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Oct 2007 18:31:44 +0200

> RPC mechanism over a standard NETCONF connection.

Once there is a NETCONF data modeling language, I am pretty sure there
will be an algorithmic mapping of SNMP notifications to it and so you
can ship your SNMP notifications in a standard way over a standard
NETCONF connection.
 
> But if your take is that no one uses standard snmp notifications,

Andy did not say nobody uses them. He said that only a few of them
seem to be popular - which is a very different statement. If I look at
the SNMP traces we have collected, then the portion of proprietary
notifications is significant but since notifications are bound to
events, it also matters how frequently events occur. (Simply counting
notifications leads to a false impression; we have seen devices
continuously reporting fan failures and obviously nobody caring about
the failing fan...)

/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: Andy Bierman <[email-masked]>
Date: Wed, 10 Oct 2007 10:13:30 -0700

> RPC mechanism over a standard NETCONF connection.

I am much more interested in new event definitions that
support NETCONF directly:

   - config-change
   - delayed-rpc-response

> But if your take is that no one uses standard snmp notifications,

Some SNMP notifications like coldStart or ifUp/ifDown are supported
almost everywhere. My experience was that engineers were more
inclined to define proprietary notifications, rather than tack
on proprietary data to standard notifications.

Andy