RE: comments on <draft-durham-nim-reqs-00.txt>

["Weiss, Walter" <WWeiss@lucentctc.com>]

Juergen,

Thanks for the comments. My vacation made me fall behind in a number of
duties so I apologize for the overdue response.  My comments follow inline.

regards,

-Walter

> Here are some comments on <draft-durham-nim-reqs-00.txt>. In general,
> I believe it is more important to build upwards that downwards. That
> is, I believe that for example we need to evolve the current SMI to
> make it more powerful, easier to use and the MIB definition easier to
> understand and implement. 
> 
While I may agree that SMI is a good modeling language, the question should
really be asked what requirements we have for a reasonable (general purpose)
information model. To debate the merits of specific languages prior to
concensus around the requirements is an excercise in futility.

> Creating a clean room technology unspecific data modeling language out
> of the blue is IMHO not too likely to help us solving any real-world
> problems. All the experience with similar ideas in the past did not
> really succeed to improve the world I am living in.
> 
The language is not the end game here. I can't speak for all of the authors,
but at least two of us believe the value lies in a set of extremely well
defined data structures that can be applied to existing/future management
protocols and paradigms. The chosen language is the means for expressing
these structures. We don't want to define a language. Ideally, we want to
use or extend an existing language that best satisfies the requirements
expressed in the document under discussion.

> - The abstract makes the following important statement:
> 
>     Irrespective of the 
>     number of technologies that are deployed to manage networking 
>     devices, the industry would benefit from a more consistent 
>     specification of data structures across these 
> technologies and the 
>     IETF would benefit from a reduction in the costs associated with 
>     defining these data structures. 
> 
>   Let us look at the IETF side. When does the cost reduction in the
>   IETF happen? To make NIM a success, the IETF first needs to invest
>   human resources in the development of NIM itself. The IETF then
>   needs to invest resources to develop mappings to derive technology
>   specific data models. The IETF also needs to educate people in the
>   various working groups so that they can define NIM modules (as they
>   do MIB modules now). Further, the IETF needs to gain experiences and
>   it must develop quality review rules in order to achieve consist and
>   high quality NIM modules. All this requires some non-trivial amount
>   of smart human resources and it will take some time to complete.
>   Once this is all in place, the IETF may indeed benefit from some
>   cost reduction. However, it is not clear for me when the break even
>   point will be reached. What do you estimate? 5 years from now? 10
>   years from now?
> 
If you consider the amount of effort being invested in defining management
structures for DiffServ. In the IETF people are working on a MIB, Policy
MIB, PIB, Policy Info Model, and Device Info Model. There is also interest
in doing LDAP (for DHCP) and CORBA structures (as per the BOF in Adelaide).
If we extrapolate that to all the other technolgoies currently under
consideration, I would venture to say that the break even point will be
reached within a year or two.

>   What bothers me a bit more is that the calculation above assumes
>   that the NIM will be successful and finally replace all the
>   technology specific data modeling work in the IETF. If, for some
>   reason, this assumption is not be true and NIM is not going to
>   replace everything, then the IETF has just added another modeling
>   language they need to take care of without any direct gains. In
>   other words: Work on NIM should IMHO only be started within the IETF
>   if there is a valid reasons to assume that NIM will succeed and that
>   the IETF can replace all the data modeling work being done today
>   within the IETF WGs with NIM modeling in the future.
> 
We would certainly not consider doing the work without the support of the
IETF in moving towards a single set of data structures that can be mapped to
various protocols and interfaces. The point here is not to add work. It is
the change a situation that is untenable moving forward: We are spending
more and more time trying to create and allign protocol-specific data
structures. In Adelaide, a full session of the DiffServ WG was spent trying
to align the conceptual model and the MIB. Think how big the problem becomes
when we throw all these other models into the mix.

>   Note also that all other prior attempts to define high-level
>   information models (e.g. GDMO) did not generally succeed. Further,
>   the areas where they are successful are usually bound and if you
>   look at the inheritance relationships, then things tend to be flat.
>   (Which can be seen as feature since it allows to decouple work
>   items. Too many interdependencies will lead to a nightmare if it
>   comes to advancement on the IETF standards track.)
> 
I can't speak to prior failures. It has only been in the past two years that
we have seen a proliferation of competing management technologies. I don't
know that the sense of urgency was then as it is today.

>   Even CIM did not really help me (as an end user) to better manage 
>   my PC. So what is really needed is a sound business case why
>   information modeling work really pays off, especially in a very
>   dynamic environment as the IETF.

I can't speak for the success of CIM, but the DMTF would almost certainly
challenge this assertion.

>   Without a sound business case
>   backed up by real data from other successful projects, I have
>   personally doubts that you can create such a nice clean room 
>   design tool in our more and more quick and dirty Internet.
> 
Again, you are focusing on the tool when you should be focusing on how we
can use data structures more consistently across various protocols.

> - The abstract contains the following statement:
>   
>     The 
>     purpose of an information model is to represent data in a manner 
>     that is independent of technology and implementation
> 
>   I think this is somewhat self contradictory. NIM itself will be a
>   technology with some features included and other features excluded.
>   Thus, NIM will itself be technology dependent. In fact, you can't
>   write something down in a purely technology independent way if you
>   want to be able to process it by computer programs.

The discussions around Methods would seem to confirm your point at least to
some extent. However, at the most fundamental level, computer programs have
had and will always continue to have data structures. Further, interfaces
will continue to be represented in terms of data structures. Therefore, if
we can agree on a set of data structures for interfaces, it is by definition
useful.
> 
> - The first paragraph in the introduction says:
> 
>     In the traditional IETF 
>     operations and management model, the working group developing the 
>     technology has also defined the data elements (usually in 
> the form 
>     of MIBs) necessary to monitor and manage the technology. 
> While this 
>     has been very successful, it has also led to a divergence of 
>     definitions and structures. In many cases, similar management 
>     elements that are to be applied to a specific technology 
> have been 
>     completely reinvented in different working groups because 
> of a lack 
>     of awareness. 
> 
>   I think the only option you have is to do the modeling work within
>   the working groups that develop a technology since these are the
>   technology experts. Are you proposing not to do the information
>   modeling in the working group which develops a technology?

No. We are suggesting that the working groups should define the model.
Further, the model they develope should be incorporated into the Network
Model (NIM) to minimize inconsistencies with previous models and maximize
reuse for future models.
 If not,
>   how does NIM prevent people from reinventing wheels in different
>   WGs? I think the only viable answer is to have process rules (such
>   as the IESG MIB review process) which helps to keep the number of
>   reinvented wheels within limits and a way to define more standard
>   constructs when you need them.

To my last comment, I would add that the NIM WG would provide the process
for normalizing various models.

>   This will be true for whatever
>   modeling language you use, whether that is SMI or NIM.
> 
NIM is not a language. NIM is a model (a set of data structures). Depending
on the requirements, NIM could be expressed in SMI (or a derivative) or XML
or UML, or something else.

>     In other cases, duplication has occurred because of a 
>     subtle variation in the definition of the element or because the 
>     relationship between the data element and other elements 
> is new or 
>     different. 
> 
>   Again, this is something we can't avoid. Technology evolves pretty
>   fast and these subtle variations and new or different relationships
>   are our everyday business. Can NIM help to solve this problem? I
>   guess not. (See also my comment below regarding the risks of over
>   specifications.)
> 
There are many reasons for variations. In some cases, as is the case with
many MIBs, there is no interest in reuse (there is little or no provision
for containment). In other cases, there is a lack of understanding of what
has been done previously. Frequently, variations occur because the authors
for one protocol's data structures are different from those developing data
structures for other protocols. Finally there are instances where new things
are being done which had not been considered before. In these cases,
non-optimal decisions must be made. I would agree that no modeling activity
can ever do anything about the last case. All architectures tend to entropy
over time. However, with a single model, we can certainly improve the other
cases.

>     Divergence of management definitions and structures has 
>     resulted in an environment where programming effort is 
> spent in the 
>     repetitive correlation, translation and data organization 
> associated 
>     with each data management technology, instead of in doing actual 
>     management. 
> 
>   Does NIM help? Will NIM be the kickoff where people really start
>   focusing on solving management tasks by inventing smart algorithms?
>   Or is it just the beginning of the next round of iteration where we
>   spend a significant amount of our time talking about a vision of an
>   integrated data driven management system which we will never be able
>   to build?
> 
I think it does help. As a product developer, I have to meet my customers
management needs. Some of my customers want to manage products with a
directory, so I LDAP enable my product. Other customers want to manage
products via HTTP, so I create a web server in my products. Still others
want to use COPS-PR, so I implement a PEP. And, of course, customers also
want SNMP, so I also implement an agent. I can't help but implement all
these interfaces because that is what the customer wants. However, each of
these protocols have different data structures with different operating
semantics. Therefore, I have to construct vertical interfaces into my device
for each of these technolgies. If they all used the same data structures,
the costs associated with supporting this set of protocols as well as future
protocols (AAA) is greatly reduced.

Nothing in the requirements doc nor my last comment suggests anything to do
with "smart algorithms." The goal here is to reduce standards development
time and product implementation costs.

>   To summarize this point: The first paragraph lists problems that I
>   take serious. However, it does not say if and how NIM can solve the
>   underlying questions. So either explain how NIM is an answer to the
>   questions or remove the whole paragraph. As it stands now, a not so
>   careful reader might be misleaded to believe that NIM is indeed the
>   solution to the underlying problems - which I think is not true.
> 
I believe my answers have sufficiently clarified this. If you believe some
of my text could usefully be in incorporated into the requirements doc, your
opinions would be appreciated.

> - The second paragraph talks about three major benefits, but only
>   lists two. What is the third one?
> 
There was a third but we removed it ;)  We will fix the text.

> - The fifth paragraph says:
> 
>     Just as MIB-I and MIB-II 
>     successfully standardized well-known constructs in the SNMP data 
>     model, this document will define the requirements for a 
> more broadly 
>     applicable information model.
> 
>   I do not understand this. In fact, we learned that MIB-II had to be
>   broken into smaller pieces in order to evolve the definitions over
>   time. So you can actually use MIB-II as an argument why a common
>   global model does not work in practice.
> 
You may be reading more into this then there is. There is no comparison of
MIB-I and MIB-II here, only an acknowledgement that they have been used to
construct an SNMP specific data model.

> - Motivation, 1st problem:
> 
>     1. Problem: With the exception of the Policy Framework's Core 
>     Information Model [PFCIM], no high-level network configuration 
>     information model exists in the IETF that is implementation-
>     independent. Implementation independence yields a model 
> that simply 
>     represents network constructs and data, relationships between 
>     constructs, and data constraints without regard to a 
> particular data 
>     model, protocol, or repository.  
>     
>   Why is this a problem? Perhaps it just shows that there was no need
>   so far to have high-level network configuration information 
> models? ;-)

I hope my earlier answers have clarified this. If not, please ask again and
I will  respond.
> 
> - Motivation, 2nd problem:
> 
>     2. Problem: The Distributed Management Task Force's (DMTF's) CIM 
>     (Common Information Model) [CIM] is not the optimal choice for a 
>     network information model. CIM provides no mechanism for defining 
>     class/model level constraints or for performing secure operations.
> 
>   Secure operations? This really sounds like protocol and technology
>   and I wonder how this can be a problem in a technology independent
>   information model...

You may be right. The question of access control to management information
in a technology independent way came up and we added it as a possible
extension to the model (as opposed to a requirement of the modeling
language).
>  
>     CIM also has dictated a naming scheme that cannot be 
> mapped into all 
>     implementations. 
> 
>   Will NIM solve that problem? Will NIM have a naming scheme that maps
>   easily into all implementation? (Perhaps CIM is just too technology
>   independent? ;-)
> 
One of the issues associated with naming delt with the concept of keys. CIM
has a very specific convention for key definition and key bindings that
provided for unique naming. However, this also led to many debates about
where and how keys should be specified. Given the amount of time devoted to
these issues in the DMTF, we felt that this issue was perhaps to complicated
and implementation dependent to be considered a constructive part of NIM.

If you reviewed the actual requirements, you would find that we chose
specifically not to solve this problem. There was some debate on the
question of whether keys and a hierarchy from a single root should be
included or not. But the current position is that these issues are too
implementation specific. It would appear that you agree with this position.

> - Motivation, 3rd problem:
> 
>     3. Problem: Current modeling representations are 
> insufficient due to 
>     a lack of available tools, lack of a textual 
> representation for ease 
>     of data exchange, or the expressiveness of the representations.
> 
>   Are you talking about CIM here or any modeling representations?
> 
>     In 
>     addition, for some or all of these representations, there is no 
>     constraint language, no suitable class naming conventions, no 
>     support for attribute level bindings, no ability to effectively 
>     create implementation-specific models, no ability to model 
>     associations, etc.  Unfortunately, some are also dependent on 
>     proprietary or high-level graphical tools. It will be up to the 
>     working group to determine what tool set would be most 
> appropriate 
>     in meeting the set of specific requirements listed below. 
> 
>   I think lack of available tools is really a poor reason. If a
>   modeling language is useful and well defined, then I expect that
>   people will write tools for it. A lack of tools either indicates
>   that (a) there is no real interest or (b) that the specifications
>   are simply too vague to implement something or (c) that people
>   prefer to keep the modeling technology itself proprietary rather
>   than open.
>
I would not necessarily focus on tools exclusively. This issue has 3
dimensions:
1. Scope or completeness of the modeling language. There are numerous
languages out there but most don't support the level of detail (vagueness)
or breadth of modeling semantics (hierarchies for example) to meet the
requirements.
2. Support for multiple protocols or paradigms. Many languages and their
tools are designed for a specific protocol/langauge or repository. While the
modeling language may or may not be applicable to other protocols or
repositories, the tools are lacking nontheless.
3. Availability of tools. In some cases the tools are insufficient. In other
cases there are not enough tools.

All of these dimensions are relavent. Further, the degree to which all these
dimensions are satisfied will determine the ultimate demand for the tools. I
would venture to say that a model validation tool that is applicable to both
LDAP and SNMP is more useful and have greater demand than one that is solely
applicable to SNMP.

> - Requirement 1:
> 
>   What are GUIDs? And why is this a real issue? I mean, even the MIB
>   folks managed to deal with this. I am not saying that the scheme
>   which was somewhat inherited from ASN.1 is perfect and without
>   flaws. But it is simple and works as far as I can tell without
>   a need to introduce new mechanisms such as GUIDs.
> 
The fact that it is a requirement does not mean it has not been done right
before. It only means that it must be addressed in the model. If you are
suggesting a particular approach for addressing this that's great.

> - Requirement 2:
> 
>   Not sure I understand this. Instance naming is very very important
>   and you can not simply say we try to avoid it wherever possible. I
>   argue that a NIM WG needs to work hard on this issue - otherwise the
>   whole thing fails. Without good and _automated_ translation into
>   technology-specific data models, the whole NIM idea becomes mostly
>   useless due to the costs and potential errors by manual
>   translations. I think that a good translation requires to have
>   instance naming schemes in place.
> 
The thinking here was that there are already established naming conventions
within various protocols. It is not clear that these conventions are
compatible or mappable. While consistent instance naming across protocols
has obvious benefits, I am not convinced that it is possible. Frankly the
issues unearthed in CIM related to keys are not something I would care to
repeat. Perhaps you have a solution in mind that you believe is
interoperable amounst implementations.

> - Requirement 3:
> 
>   I fully agree with this requirement.
> 
> - Requirement 4:
> 
>   Not sure you will ever reach the goal to make something like this
>   "completely unambiguous".
> 
>   Furthermore, I can only warn about over specifications. Constraints
>   can be used (with the best intentions) to make definitions so
>   inflexible that every little change in the underlying technology
>   will break the management interface. I think the MIB folks have had
>   some interesting experience with over specifications. It is
>   sometimes really more an art to make the right trade-off decision
>   here.
> 
I would suggest that you elaborate on this point somewhat. Which of the
items in 4 would you encourage and which would you avoid? Experience
justifying the removal of the item would be helpful. As a general comment my
concern with your perspective is that the MIB folks may have underspecified
at least in some cases because hierarchies were unavailable to them.

> - Requirement 5: 
>     
>   I agree that associations are important.
> 
> - Requirement 6:
> 
>   I think that the importance of inheritance is often over-estimated.
>   In Java, you have inheritance and interfaces, where a class can
>   implement a specific interface without being derived from a parent
>   class which defines this interface. I think that such a mechanism is
>   much more important than inheritance. Even the GDMO object
>   inheritance trees I have seen were pretty flat.
> 
It is interesting to note that the CIM inheritance tree is quite deep.
However, this is in part from having a single root (which we have at least
initially choosen not to require). I would say that I have found inheritance
very useful particularly in constructing abstractions of technologies that
could be derived to vendor or product specific subclasses. Further, I also
find inheritance useful in addressing well known implementation variations.
For example, a RED dropper and a Tail dropper can both derive from a dropper
and a WRED dropper can derive from a RED dropper.

> - Requirement 7:
> 
>   I am not sure I understand what you mean by "user rights" here. Why
>   should an information model have to deal with user rights?
> 
As I mentioned earlier, we have been toying with the notion of including
access control semantics into the model. This would be an extension to the
model. If this is not considered generally useful, this requirement will be
removed.

> - Requirement 8:
> 
>   Why is it important to support arrays of base types? If we 
> need arrays,
>   why restrict then to base types only?

This was a compromise by the authors. Some felt strongly about containment
which implies additional (structured) types while others felt that only base
types should be specified and that containment should be supported through
restrictive associations (aggregations in CIM). While containment was
allowed in as a requirement, arrays pushed the envelope. If folks feel
strongly on this, they should speak up.
> 
> - Requirement 9:
> 
>   I did not understand this.
> 
I think all this is saying is that collections of attributes does not
obsolve one from fully specifying the attributes. I am guessing here because
it was clear when someone explained it to me but the explaination has
escaped me know. In other words, this requirement needs to be more precisely
written.

> - Requirement 10:
> 
>   I do not really understand why the NIM should dictate how some
>   technology ships data around. I find it strange to require 
> in the NIM
>   that certain combinations of classes should be treated as a block.
> 
This was not a blocking issue. Rather it was suggested that groupings of
classes may facilitate the initialization or configuration of classes by
logical groupings. This is a feature that people could use to determine the
scope of a particular domain (DS, MPLS, DHCP, etc.) rather than a packaging
format.

> - Requirement 11:
> 
>   I agree that one needs methods. That is also the reason for NMRG
>   work on adding operations to SMIng. I personally think that one must
>   model constructors/deconstructors in order to be useful in practice.
> 
> - Requirement 12:
> 
>   Not sure if subscriptions belong to the information model. I think
>   the information model should only express the kinds of data.
> 
There was some debate on this one as well when the requirements were
written. I expect this requirement to leak onto the list as well.

> - Requirement 13:
> 
>   I would say it even stronger: It is necessary to develop automated
>   translations into data models that guarantee compliance to the
>   underlying information model.
> 
> - Requirement 14:
> 
>   Not sure how this will work in practice. My experience with agent
>   capabilities is that nobody in the commercial world is really
>   interested to clearly document what the limitations are.
> 
We could consider capabilities in terms of the set of things that can be
configured on this device. As end-to-end service definitions become more
important, it will also be more important for customers to configure
services consistently across various implementations. This does not
necessarily mean that all devices must support WFQ. Rather it means that
management systems will need to know which boxes support WFQ and which
support CBQ so that each box can be configured optimally.

> - Requirement 15:
> 
>   I do agree that we need compound data types. I do not really agree
>   with the example - but that is a minor point.
> 
> - Requirement 16:
> 
>   I am not sure I understand the requirement.
> 
By example, if I have an attribute called AS_Number, for which a change of
the value can only take effect when routing is brought down, I may have at
least two values of AS_Number in the system: Current and proposed. The model
must be capable of distinguishing the two. A simple approach might be to
define two attributes in the class. However, different products will make
different implementation decisions for when attribute updates take effect.
Further, some configuration management paradigms like LDAP rely on polling
to make changes to systems, so the state in the directory may not reflect
the state of the device until the device actually retreives the value and
notifies the directory that the new value is in effect. These various
scenarios suggest the need for a general mechanism in the model that
distinguishes the actual configuration from the desired configuration.

> - Requirement 17:
> 
>   Very important.
> 
> - Glossary
> 
>   I am not really convinced by some of the explanations:
> 
>   A data type is only a mechanism for identifying the binary
>   representation of atomic attributes?
> 
>   A NIM class is synonymous with an attribute??

I agree. Suggestions would be appreciated.

Thanks again for the thorough review.