RE: no NETCONF WG meeting planned for Paris

["Faye Ly" <fayely@juniper.net>]

Andy,

Very well said!  I wonder if anybody has considered the following
requirements for the need of notification besides SNMP and SYSLOG:
(Sharon, if this duplicates your requirements I apologize.)

1. Customer may or may not want to punch so many holes in their firewall
for management purpose.  SNMP, SYSLOG and NETCONF all have different
ports.  Having a single TLS port helps eliminate the administration
cost.
2. SNMP is not secure despite of v3.  I think we have gone through this
many times and not many customers seem to be deploying v3?  Why, I am
not an expert.  I think NETCONF is very well designed with the security
and notification channel is a natural next step.  Again this saves admin
cost that once you setup one secured management port you do both config
and notification using the same port.  
3. The scalability of SNMP traps is great for network devices but there
has been some new requirement like the security device.  The later sends
a lot more logs than regular network device.  Soaking no longer works as
each log needs to be sent to the server to be examined.  But I do agree
with you that this might be a special case and we should not change the
overall model just because some corner case.  This largely depends on
the member of this mailing list.  Is this a high requirement for other
network device as well?

Best,

-faye

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Friday, May 27, 2005 6:23 AM
To: dbharrington@comcast.net
Cc: 'Sharon Chisholm'; 'netconf'
Subject: Re: no NETCONF WG meeting planned for Paris

David B Harrington wrote:

>Hi Andy 
>
>  
>
>>There are some pretty powerful features within a
>>decent transaction model to act on that bucket of XML content.
>>I know some of us on the design team we're really just
>>trying to eliminate screen-scraping the CLI with 1.0.
>>Even if NETCONF is just used as a programmatic interface
>>to the CLI at first, this is better than screen-scraping.
>>    
>>
>
>And I strongly support that vision. Screen-scraping needs to go. 
>
>But we also need to move past the constraint that any operator must be
>able to lock the whole configuration to modify it, and a large number
>of other issues that you have collected during the development of
>netconf 1.0. Just changing from screen-scraping to XML isn't enough to
>meet operators' needs, even if it is a big step in the right
>direction.
>  
>

I disagree.
The 2 main deferred features -- partial locking and notifications --
are both simply speed optimizations, which impact a relatively small
number of use cases.   We don't have any serialization in SNMP or
CLI at all!  Concurrent writes can clobber config now, but this
doesn't seem to be a big problem.  I'm not convinced the lack
of locked concurrent writes in NETCONF is a problem yet.

Notifications essentially provide a speed improvement over polling
techniques.  Currently, many CLI applications use SNMP notifications
and SYSLOG for this purpose.  The convenience of receiving async
messages within a NETCONF session is probably balanced out by
the increased localized cost of the NETCONF implementation, and
most likely does not represent a significant percentage of either
the implementation or deployment complexity.

IMO, the lack of these deferred features has no significant impact
on the usefulness of NETCONF 1.0.

As for NETMOD -- I don't see much hope of a WG agreeing on the
one true NETCONF data modeling language.  I agree that would
be the ideal from a standards-POV, but not realistic or even
close to operationally optimal.  E.g., A scheme tuned for SNMP
integration isn't going to work well for CLI-oriented configuration.

Andy




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