[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft-ietf-sming-reqs-03.txt
- To: email@example.com
- Subject: comments on draft-ietf-sming-reqs-03.txt
- From: Andy Bierman <firstname.lastname@example.org>
- Date: Fri, 03 Aug 2001 09:34:51 -0700
- Organization: Cisco Systems, Inc.
- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1
I have a couple comments on this draft and this process.
Next step: Evaluate Dev-Cost and Operational Impact
The list of requirements is fine -- based on the charter
this WG was given. Now it's time to evaluate each requirement
to estimate the technical difficulty and the potential benefit
and impact on the operational community. Some are easy, some are
not so easy, and some are controversial, but it seems unlikely
that we can achieve all of them within the schedule outlined in the
Ignoring the Installed Base: I strongly agree with Jeff and Jon
about the need the leverage the knowledge of the considerable number
of people who understand and use data definition specs written in SMIv2.
Most of these people are not reading this mailing list, not
reading the sming I-Ds, and have no technical expertise or interest
whatsoever in COPS-PR or SPPI. Some requirements are going to
be very expensive to achieve (in terms of complexity), such as
4.1.14 Protocol Independence, 4.1.15 Protocol Mapping,
4.1.43 Align Instance Naming, 4.1.45 Assign OIDs in Protocol Mappings.
They reflect the charter's goal of merging SMIv2 and SPPI, but the
operational community isn't asking us to merge SMIv2 and SPPI.
I'm concerned some of the constructs in sming will be too complex
for anybody to use, trying to satisfy 4.1.43 and 4.1.45.
There are many good things from SPPI that should be merged,
such as UNIQUENESS, EXTENDS, and 64-bit data types, but let's
not re-invent instance naming or require sming authors to create
and maintain distributed, yet tightly coupled constructs.
There's just no cost justification for massive changes like that.