[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Perspective: XML's ticking time bomb
Replies inline. Sorry that this took a day, but I was in meetings from 8am
onwards.
Andrea
-----Original Message-----
From: owner-xmlconf@ops.ietf.org [mailto:owner-xmlconf@ops.ietf.org]On
Behalf Of Faye Ly
Sent: Sunday, January 05, 2003 6:36 PM
To: Andrea Westerinen; Wijnen, Bert (Bert); Xmlconf (E-mail)
Subject: RE: Perspective: XML's ticking time bomb
Andrea,
Thank you for the information. I went to dmtf.org and checked out the
CIM specification. I am specifically looking for the following
information:
How do I provision a DSL subscriber?
<arw> The DSL model has some basic elements defined by Cisco, but is still
work in progress in the Networks WG. In terms of the model hierarchy, the
DSL endpoints are subclasses of CIM_ProtocolEndpoint in the Network Model.
A subscriber is an instance of an OrganizationalEntity in the User Model
today. But there is work going on in this space also, that decouples
identity from organizational white pages info. So, in the next release
(V2.8 - 2Q2003), there will be a CIM_EstablishedIdentity (or some similar
name) - where the DSL subscriber would be an instance of EstablishedIdentity
(where the subscriber ID establishes the identity). As regards the DSL
subscriber's "settings" that are provisioned, these are subclasses of the
CIM_Setting class.
How do I diagnose a subscriber circuit problem identified by a
subscriber id?
<arw> I am assuming that you are working this from the subscriber side -
where the subscriber indicates that they have a problem and you want to find
and debug the associated circuit. An association ties
CIM_EstablishedIdentity with the CIM_Roles enabled by the identity - and so
the "subscriber for a circuit" can be found. A circuit is an instance of a
CIM_Pipe, also in the Network Model. If you are looking at the problem
because your network notified you of an issue, you can do this via
CIM_AlertIndications. These are notifications carrying priority,
information on the element that is being reported against, and other data.
So, if there were circuit problems, these could be alerted/indicated and the
model traversed in the other direction to find the impacted subscriber.
No such luck! Or maybe I was simply lost in the object model itself.
Is this because this is work in progress? Can you please give me a few
more pointers?
-faye
-----Original Message-----
From: Andrea Westerinen [mailto:andreaw@cisco.com]
Sent: Sunday, January 05, 2003 1:30 PM
To: Faye Ly; Wijnen, Bert (Bert); Xmlconf (E-mail)
Subject: RE: Perspective: XML's ticking time bomb
This is exactly what the DMTF is trying to do with CIM - create an OO
model for managing end to end (provisioning, monitoring, faults, ...).
The model is tied together across management domains, vendors, and
products. Whether the model is encoded in XML or something else is
secondary. The fact that concepts like systems, services, interfaces
(protocol endpoints), etc. can be modeled and generically understood
(have inherited properties and
behaviors) is much more valuable than the encoding. After all, "XML is
just a syntax in search of a semantic."
However, if you are looking for XML, then there is an XML DTD for CIM -
and also work-in-progress regarding a CIM XML-Schema, and discussions of
CIM-WSDL.
Andrea
-----Original Message-----
From: owner-xmlconf@ops.ietf.org [mailto:owner-xmlconf@ops.ietf.org]On
Behalf Of Faye Ly
Sent: Sunday, January 05, 2003 8:51 AM
To: Wijnen, Bert (Bert); Xmlconf (E-mail)
Subject: RE: Perspective: XML's ticking time bomb
Bert,
That is a very good article. I admit I went back to this mailing list's
archive and got lost in the multiple mail threads. So what is the
conclusion on moving forward for this group?
I think I tend to agree that XML is a superior language over MIB but the
fact that we are missing 'management object' on many things such as -
Service provisioning/ subscriber provisioning
fault isolation that is transparent to the underlying transport method
...
Sort of similar to the effort of snmpconf (for provisioning only) that
is currently missing. I actually think it is in-relevant if we do it
using XML or the good old MIB. The important thing is to come up with
consensus on the management model. If XML can help with the majority of
the people to better understand and thus expedite the process, then
let's go with XML. I think this is actually the time to organize the
effort around coming up with standards for:
1. provisioning
2. fault isolation
3. performance monitoring
4. othrs such as file management, upgrade and etc ...
And let each group come up with the management model first, XML and/or
MIB later?
What do you think?
-faye
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, January 05, 2003 3:51 AM
To: Xmlconf (E-mail)
Subject: Perspective: XML's ticking time bomb
Here is another one to take into account:
Perspective: XML's ticking time bomb
http://news.com.com/2010-1071-961117.html
It is a few months old... not sure how I all of a sudden
ran into it. Oh well...
Bert
--
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/>
--
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/>