[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: netconf WG charter proposal



Allen,

Thank you for the clarification and I can see the point now.  This is a tough problem: the mapping between XML/config and MIB/notification data will be a challenge.  Also I guess the MIB/notification varBind contains instance information as well.  That means the XML/config data has to match exactly to the instance level. You brought up a very good point and that makes the SMI/schema mandatory (in the future or not, I will let the smart guys figure this one out).

How about the instance of the object? (Let's say ifIndex) Different box may index its table differently.  Is this a problem for the NMS?  Or does it always qualifies it with the box's identity (source id) and then match the instance value?  Trying to figure out how far the SMI/schema should go.

-faye

    

-----Original Message-----
From: Allen, Keith [mailto:kallen@tri.sbc.com] 
Sent: Monday, April 14, 2003 8:24 AM
To: xmlconf@ops.ietf.org
Subject: RE: netconf WG charter proposal

Faye, 

I did not mean to imply that I wanted the WG to translate all of the
standard SNMP traps to XML, or to standardize any XML notifications at this
time.  I am OK with the plans to just focus on protocol and leave the
tougher problem of standardized schema for later.  I would just like to see
the protocol produced by the WG include the capability to convey
notifications as well as configuration data.  XML is a data representation
language, and as such I don't think it is any better or worse suited to
notifications than it is to configuration.  The ID presented at the BOF
already has some provisions for notifications; I just hope to see that
fleshed out a little bit.  

I think you and I are using "mapping" in different ways.  I think the
mapping you are talking about refers to mapping SNMP trap definitions into
XML schema.  Some people on this group have mentioned an automated way of
doing this, but I have no knowledge about that.  The mapping I was referring
to was the need to map between different identifiers used on different
management interfaces.  Say we use the XML protocol to discover the
configuration of a router including how many interfaces it has, the
identities of those interfaces, etc.  Then later we get an SNMP trap for one
of those interfaces, but the identifier in the trap is somewhat different
than that used in the XML.  We would require some means to map between the
identifiers used on the XML interface and the identifiers used on the SNMP
interface.  Since the WG will probably focus on protocol issues and leave
naming for later, my concern is probably one for the future SMI/schema
WG(s).

My maintenance concerns center on the software costs of developing and
maintaining several different management interfaces/applications for each
model of equipment we deploy: XML for configuration, SNMP for some faults,
syslog for other faults, FTP for performance data collection, another FTP
interface for billing data, somebody mentioned troubleshooting and got a
quiver full of arrows shot at him, so we may need another interface for
that...


Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com
 

-----Original Message-----
From: Faye Ly [mailto:faye@pedestalnetworks.com] 
Sent: Sunday, April 13, 2003 5:16 PM
To: Allen, Keith; xmlconf@ops.ietf.org
Subject: RE: netconf WG charter proposal

Keith,

I can understand the admin head-ache to maintain multiple interfaces for
management channels.  Some of my personal opinions:

1. XML itself is not really a suited technology for monitoring and notifying
unless a well designed protocol is added to support both.  Mapping may not
be sufficient.
2. A lot of standards MIBs have been defined for SNMP.  Major efforts need
to be put in to convert them to XML.  This may actually kill the XML for NMS
due to the fact that the scope is too wide.
3. netconf or XML is very well suited for configuration data.  It has the
built in hierarchical data that is needed for configuration.  
4. If you are worrying about the maintenance cost for XML configuration
channel, well, maybe we can finally get rid of both telnet/tcp and
ftp/tcp(or tftp) and just use XML/[RPC]/BEEP/TCP?  SNMP stays the same with
or without XML, isn't it?

The netconf charter as it stands now should be a good set to start and
finish.  Being too ambitious may not be a good idea.

-faye



--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>

--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>