[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
XML for president
We are beginning to focus on XML because it appears to hold promise as a single language that can meet the requirements of a human-interactive NM interface, ala CLI, and a programmatic interface, ala SNMP, and a document-oriented interface, ala web pages.
See ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-iab-nm-workshop-01.txt "Overview of the 2002 IAB Network Management Workshop"
co-chair, IETF SNMPv3 WG
> -----Original Message-----
> From: firstname.lastname@example.org
> Sent: Wednesday, December 18, 2002 10:01 AM
> To: Andy Bierman
> Cc: email@example.com; firstname.lastname@example.org; email@example.com
> Subject: Re: FW: sming meeting minutes draft... Questions for the wg.
> >Further, attendance at the SMIng/EOS meetings in Atlanta was close to
> >I attribute this to lack of interest and my guess is that
> this is because
> of XML.
> Although I share you enthusiasm for XML as a technology for
> management, the
> reality is that I have not seen any RFP related to NGN
> networks in the last
> 3 years that mentions XML at all.
> Attendance and/or support from companies for standards work
> is directly
> related to the state of the economy. Justifying travel has been very
> difficult this year for everyone. Other standards bodies are
> having the
> same problem. As always, network management takes second
> place to call
> processing and budgets reflect that.
> >I agree, but I think vendors would update their products if
> the cost was
> >enough and the improvement in data transfer efficiency was
> high enough.
> I have not done this in a while but the last time that I checked,
> industrial grade XML tool sets where prohibitively expensive
> compared to
> SNMP ones. But, this is not the only driver here. Network
> operators like
> their HP OV NNM, Micromuse, etc. To change the existing
> toolsets is going
> to take some serious selling. Why should the operators spend
> a dine on
> XML? In this age of huge pipe over capacity, I do not think
> that data
> transfer efficiency would be a good selling point.
> Specially, considering
> that network management traffic is so minuscule as to be
> unimportant in
> traffic studies.
> Yes, it is possible to convert SMI to XML. So? What is the
> problem that is
> being solved? I hope that y'all are not doing this for the
> simple reason
> than because it can be done. Can anyone state the problem?
> Sidney Antommarchi
> VXi - Systems Engineering
> Andy Bierman
> <abierman@cisco. To:
> "Glenn Waters" <firstname.lastname@example.org>
> com> cc:
> Sent by: Subject: Re:
> FW: sming meeting minutes draft... Questions for the wg.
> 12/18/2002 12:15
> At 10:43 AM 12/17/2002 -0500, Glenn Waters wrote:
> >I meant to send this to the list...
> >-----Original Message-----
> >From: Waters, Glenn [CAR:IO47:EXCH]
> >Sent: Monday, December 16, 2002 23:30
> >To: 'Durham, David'
> >Subject: RE: sming meeting minutes draft... Questions for the wg.
> >Where to start.
> >XML is overshadowing all other network management
> discussions in the IETF.
> It is hard to do anything SNMP without XML being mentioned. Further,
> attendance at the SMIng/EOS meetings in Atlanta was close to
> pathetic. I
> attribute this to lack of interest and my guess is that this
> is because of
> I think there is very little official IETF activity related to XML.
> There is a lot of XML interest and activity by the vendors and their
> customers, especially compared to interest in SNMP.
> >SMIv3 provides much needed structure to the data; however, I fear the
> forklift upgrade necessary in order to get it deployed will be very
> detrimental to its success. I am not convinced SMIv3 could be deployed
> before XML has traction. I also don't think that using SMIv3
> with other
> protocols such as XML is useful -- there are too many other schema
> definition languages for XML already. Further, if there are
> that we need for the other XML schema languages we should
> pick one and work
> with that body.
> This is a valid criticism of SMIv3. It would impact
> everybody, especially
> the readers and writers of MIBs. Moving to XML would also be a major
> change for readers and writers. I don't know what you mean
> by a choice
> of XML schema languages. I think the choice has to be XML Schema from
> the W3C. The only other choice is DTDs, and they are not
> expressive enough
> to foster interoperability or allow for complex, reusable data types.
> >I think that the OOPS draft has the most potential although we should
> ensure the features that it offers are what we want to
> pursue. OOPS does
> not require a forklift upgrade. The features that it offers
> can operate on
> the existing SMI. The one issue with EOS is that an upgrade
> to the protocol
> stack is still required. Given the amount of time this is
> taking for SNMPv3
> I fear that industry uptake will be below an acceptable level.
> I agree, but I think vendors would update their products if
> the cost was
> enough and the improvement in data transfer efficiency was
> high enough.
> SNMP is mostly used for monitoring, and it is horribly inefficient at
> transferring data, especially for a binary encoding.
> >The bottom line is that interest in SMIng and EOS is low.
> Interest in XML
> is high. SNMP has no workers. XML has people jumping to help.
> I think that
> the IETF needs to reconcile where we want to go in the
> network management
> space. The reality is that XML is coming, it just may be that
> the IETF will
> not be defining it.
> I agree, but I hope the IETF will be clueful enough to pay attention
> to this trend. (BTW, I've noticed that the people that dismiss XML
> and all the tools work around it as just another fad are the least
> likely to actually have read the XML specs or checked out the tools.)
> >> -----Original Message-----
> >> From: Durham, David [<mailto:email@example.com
> >> Sent: Monday, December 16, 2002 16:53
> >> To: 'Wijnen, Bert (Bert)'; firstname.lastname@example.org
> >> Subject: RE: sming meeting minutes draft... Questions for the wg.
> >> Originally there was much excitement around the smi-ds
> proposal from the
> >> wg
> >> participants. Now that we are peeling back the onion a bit
> I think we
> >> seeing some of the complexities of this approach emerge, and we are
> >> experiencing some notable feature creep as well. So I
> wonder if the wg
> >> sentiment is cooling and why. Two fundamental questions
> that I would
> >> people to (quickly) respond:
> >> Are people still interested in perusing the hierarchical
> instance naming
> >> using oids as proposed in the smi-ds document?
> >> Are you interested in helping by being an editor on one or
> more of the
> >> documents listed below?
> >> If feature creep and gratuitous changes are the only
> issues, that is
> >> fixable. I want to understand if the fundamentals of the
> smi-ds proposal
> >> are
> >> still viable and have wg support.
> >> -Dave
> >> > -----Original Message-----
> >> > From: Wijnen, Bert (Bert) [<mailto:email@example.com
> >> > Sent: Monday, December 16, 2002 4:48 AM
> >> > To: Durham, David; firstname.lastname@example.org
> >> > Subject: RE: sming meeting minutes draft...
> >> >
> >> > I'd like to get a few more details on this (I think we got them
> >> > at the meeting):
> >> >
> >> > > Revisited Charter and Milestones. Updated charter was put on
> >> > > the mailing list. No issues raised on the list, no issues
> >> > > raised at the meeting either. According to the charter
> >> > > milestones we are a year behind. The original milestones
> >> > > assumed the nmrg documents which were complete, but the wg
> >> > > chose to investigate the smi-ds route. We will still need a
> >> > > few iterations on the smi-ds/v3 documents before they will be
> >> > > complete. The current proposed list of documents in
> priority order
> >> > >
> >> > > - 1. SMIv3 Language Definition: Andy Bierman
> >> > > - 2. Capabilities MIB: Andy Bierman: DONE
> >> > > - 3. SMIv3 Guidelines
> >> > > - 4. Transition from SMIv2
> >> > > - 5. SMIv3 MIB Modules (core types)
> >> > > - 6. INET Modules (textual conventions)
> >> > > - 7. RFC 2580 Conformance Updates
> >> > >
> >> > > We need volunteers for the documents or the wg will shut
> >> > > down, and the smi will not progress. Previous volunteers for
> >> > > the guidelines and transition documents are waiting for the
> >> > > language definition. In principle, people support the smi-ds
> >> > > work, but we will need people to sign up to get the work
> >> > > done. Likewise from the discussion at the wg meeting it seems
> >> > > that there is a lot of waffling on how we proceed item by
> >> > > item through the open issues listed below.
> >> > >
> >> > My understanding at the meeitng was that Andy
> un-volunteered for some
> >> > docs. And so I like to clearly understand who is
> currently volunteer
> >> > for what. I also like to see commitments as follows:
> >> >
> >> > - Volunteers to commit to deliver a reasonable revision of the
> >> > document they volunteer for
> >> > - From the WG to do serious review and to provide serious input
> >> > for the editors and the chair, so that we can get to consensus.
> >> >
> >> > The lack of WG participation and the lack of
> enthusiastic volunteers
> >> > for all documents does not bode well. And as David said, we're
> >> > already 1 year behind schedule.
> >> >
> >> > Thanks, Bert