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

["David Harrington" <[e-mail]>]

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
[e-mail]
[e-mail]


> -----Original Message-----
> From: Sharon Chisholm [mailto:[e-mail]] 
> Sent: Monday, October 01, 2007 8:46 AM
> To: [e-mail]
> Subject: [NGO] Proposed Re-charting of NETCONF WG (was NEE)
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ngo
> 




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