revew of linowski requirements-00

["David Harrington" <ietfdbh@comcast.net>]

Hi,

I have reviewed this document, and have some comments. 

My main impression is that this is not a list of requirements, but a
wish list of nice to have features. We have already seen many of these
items raised during the SMING WG, but many add complexity without
providing significant benefit to over-the-wire management information
sharing, especially to operators who are not data modeling theorists. 

A number of these requirements are suggested application-development
solutions that might benefit manager application developers, but they
can use object oriented languages such as C++ and Java with various
application-support libraries, such as GUI libraries, and
application-appropriate database designs to get what they need in the
application. But that does not make them features that are REQUIRED
for over-the-wire protocols to utilize to share data in an
interoperable manner amongst multiple manager applications and managed
entities. 

I used to work on an industry-leading NMS application, and we used
C++, and object-oriented database modeling with support for
inheritance, and SQL queries and fancy GUIs, and these were important
to making the application user-friendly, but those features certainly
do not belong in an on-the-wire protocol suite for gathering
vendor-neutral standardized data from managed entities, especially
when some of those entities might be tremendously resource
constrained.

Data modeling for programming applications and data modeling for
standardized over-the-wire data gathering have distinctly different
sets of requirements.

--

Here are my detailed comments:

section 3. 
"data model" definition requires some rewording to make it good
English.

4.2.2. 
English and ASCII are required for purposes of IETF "interoperability"
during standardization; English and ASCII have been established as the
standards for sharing proposals within the IETF, to make those
proposals reviewable by IETF members. It is generally not acceptable
to propose IETF standards in other languages or language-specific
characters (except when standardizing what character set a value might
contain). It might be acceptable for proprietary data models, but not
IETF standard data models.

4.2.2. 
There is a Note that expresses an opinion, but that opinion is not
necessarily accepted as consensus. I'm not sure I agree it belongs
here without at least mentioning the opposing view.

4.2.3. 
I would reword "All kinds of characters, including language specific
characters must be supported." 

First, "all kinds" encompasses much more than we need to encompass. If
the local Star Trek fan club develops a new, non-standard, version of
Klingon, must that be supported?

Second, there are some fields which make protocol sense to express in
local languages, but there are other fields that probably should not
be. That's why SNMP has DisplayStrings and SnmpAdminStrings - to limit
the range of characters used in specific fields such as index clauses.
Lexicographical ordering is already hard enough without having to deal
with lexicographical ordering across different, possibly non-standard,
languages. It is not good practice to require that an agent in a
resource-constrained device must support a wide range of character
sets unnecessarily. 

I don't feel that it is a requirement to be able to support data entry
field captions within a data model; the approrpiate data enrty field
captions will depende greatly on the application and the users of that
application. I would not want to have to specify as part of a standard
the appropriate data entry field captions for every known language for
every object in the data model. 

4.3.1 
Why is it a requirement that the release identifier support the dot
character? Is this presupposing a specific format that has not been
agreed to?

I don't understand the sentence "Typing versions to individual model
elements in one release agnostic (compound-) model wouldn't be
practical." It might be better to reword this.

"as a release specific views" - plurality needs to be consistent.

4.3.2
I agree manager applications need to be able to handle different
revisions of the same data model simultaneously to represent different
managed implementations. I do not agree this is a requirement of the
data model for use with an over-the-wire protocol; this is a local
database requirement for the manager application.

It is, however, important to be able to distinguish instances of MIB
modules on a managed entity, as is provided by the community or
context concepts of SNMP, since this is important for over-the-wire
interoperability. It would be useful to be able to query a managed
entity to determine which MIB revision (or compliance level) is
supported.

One issue with this requirement is that we are dealing with standards,
and the definitions (semantics) for elements typically should not
change across revisions, with few clearly defined exceptions to this
rule such as those identified in SMIv2. If the semantics change, the
element identifier should be changed as well. So I question whether a
named item needs to be scoped by its revision; the name and semantics
of a managed object should be consistent across revisions.

4.4
In my experience, operators usually do not think in object-oriented
terms. Programmers often do. Defining models in object-oriented terms
makes it harder-to-use for operators. Features like concrete and
abstract classes and inheritance are focused on the wrong audience for
network management.

There are some serious issues with moving toward an object-oriented
approach. 

Searching for matching data inside nested objects becomes harder, in
much the same way that multiple nested levels of menus in a GUI can
make it harder for a user to find the option they are looking for. 

Hierarchical structures of inheritance can make it more difficult to
merge different data models, in much the same way that Borland's C++
libraries and Microsoft's C++ libraries were difficult to use
together; they were built on different roots and compounded their
differences by inheriting a whole philosphy of hierarchical design. As
a standards organization based on running code, we need the ability to
merge data models from different vendors. If we go too far toward
hierarchical nesting of data models, we reduce the ability to merge
them into a standard.

[I skipped over much of this document for lack of time ...]

While some of these requiremnets might be useful features in a
general-purpose DML, this document seems focused on a different
problem space than data modeling for use with the Netconf protocol, or
any over-the-wire network management protocol.

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharrington@huawei.com



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