RE: revew of linowski requirements-00

[<mikko.lahdensivu@nsn.com>]

Hi,

>-----Original Message-----
>From: owner-netconf@ops.ietf.org 
>[mailto:owner-netconf@ops.ietf.org] On Behalf Of ext David Harrington
>Sent: 04.03.2008 20:57
>To: netconf@ops.ietf.org
>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

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