Subject: Re: [NGO] revew of linowski requirements-00

From: <[email-masked]>
Date: Fri, 7 Mar 2008 06:07:52 +0200

Hi,

[resending to NGO mailing list]

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of ext David Harrington
>Sent: 04.03.2008 20:57
>To: [email-masked]
>Subject: revew of linowski requirements-00
>
>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.

You are obviously free to have different opinion about the requirements,
but that doesn't make a set of requirements any less a set of
requirements :-)

The benefit of object to the operators comes from tools that are not
based on hard-coded models, but can adjust themselves to various data
models, whether standard or implementation specific models.

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

With a huge amount of models, standard and implementation specific
extensions, it requires an enormous effort to implement such mapping
classes on top of the models, and the mapping between the models is
error-prone. Also, this causes delays in taking the new models into use
because of need to implement these mapping classes after model has been
designed.

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

The model inheritance does not imply extra resource requirements for the
agent implementation. If you have classes A and B inheriting common base
class C, the configuration data on the wire would be exactly same as if
A and B would be defined independent of each other but sharing the same
attributes. The difference is that a client capable of operating on
instances of C knows that it can do the same with instances of A and B.

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

Partly different, but object oriented concepts are applicable to both,
and help to cope with growing complexity of models.

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

Netconf DML should be usable for standard and proprietary data models.
Configuration management interoperability should not be available only
within the limited set of standardized configuration 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.

So do you share that opposing view? If yes, could you be more specific
as to what is your view on the documentation of models?

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

Perhaps Unicode would be enough :-)

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

This is not required. In any case, IETF models obviously would only have
English presentations, and it is up to the agent implementation whether
it supports proprietary models (which might use other languages).

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

The requirement here is that it is possible to give the presentation
name to model elements, not that every model element would need to have
a separate presentation name. Further on, this would not require you to
provide name in every language.

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

No, this proposes a set of characters that at least should be supported
for release identifier. Version numbers typically use dots, so I think
dot is quite justified. But the DML could support some other characters
as well.

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

You could have several pluggable units within a network element, each
having its own release. They do not necessarily share their data models.
And those pluggable units can have their own pluggable sub-units.

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

Just because multiple units within the agent have different releases of
same model, there should be no need for a separate Netconf request. They
should all be part of the complete model of the agent.

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

This might be the case with IETF models, but the DML should be usable
for all models for Netconf, not just IETF standard models.

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

This is not required by object oriented approach. If you don't prefer to
use in your client GUI object oriented approach, you can treat classes
as simple structures, expanding all inherited attributes and
relationships from the base classes to the derived class. This wouldn't
affect the configuration data on the wire.

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

In merging you probably wouldn't directly inherit from these vendor
models (any more than you would directly import from vendor specific
SNMP MIBs). And if you just reuse attributes from different vendor
models via copying, the object-oriented approach does not prevent you
from doing so.

Regards,

Mikko
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo