dumb questions/comments regarding smi-ng

[Fred Baker <fred@cisco.com>]

Bert asked me to look at draft-ietf-sming-reqs-04.txt; I have a few 
questions and comments.

>4.1.5 ABNF Grammar
>
>    Type: new
>
>    From: NMRG
>
>    Description: A complete ABNF specification of the grammar has to be
>       supplied.
>
>    Motivation: A complete specification of the language grammar in ABNF
>       encourages the use of compiler toolkits to construct solid
>       parsers.

dumb question of the month; while I understand that XML seems to be the 
latest in a long string of 
solutions-to-the-world's-problems-looking-for-problems-to-solve, I 
personally would not be bothered by finding SMIng to be an adaptation of 
XML. Is there a specific reason that an XML DTD or Schema is excluded here, 
other than that lex and yacc look for something similar to ABNF?

>4.1.6 Accessibility
>
>    Type: align
>
>    From: SMI, SPPI
>
>    Description: Attribute definitions must indicate whether attributes
>       can be read, written, created, deleted, and whether they are
>       accessible for notifications, or are not accessible.  Align PIB-
>       ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS.

is that MIN-ACCESS and MAX-ACCESS? I don't know what PIB-ACCESS is...

>4.1.17 Base Data Types
>
>    Type: basic
>
>    From: SMI, SPPI
>
>    Description: SMIng must support the base data types Integer32,
>       Unsigned32, Integer64, Unsigned64, Enumeration, Bits, OctetString,
>       and OID.
>
>    Motivation: Most are already common.  Unsigned64 and Integer64 are in
>       SPPI, must fix in SMI.

Does this mean that the SMI will finally support 64 bit integers? I believe 
that this will greatly simplify interface and interface-dependent MIBs, 
which now are required to maintain separate Counter32 and Counter64 objects 
depending on the speed of the interface being described. Having to 
differentiate between, for example, ifSpeed and ifHighSpeed rather than 
simply reading one object is a bit painful.

By the way, support for Counter64 and Gauge64 should be listed here, and 
for backward compatibility, Counter32 and Gauge32.

I'm a little surprised that DisplayString is *not* listed; it was added 
fairly early on to manage a surprising number of implementation 
incompatibilities in the use of OCTET STRING.

With respect to the problems mentioned in 
http://www.ietf.org/rfc/rfc2825.txt, one of the issues that the 
internationalized domain name problem struggles with is that, while SNMP 
theoretically supports UTF-8, none of the implementations actually do. One 
of the attributes SMIng's DisplayString should presume is that 
DisplayStrings are encoded in UTF-8, not ASCII. For example, a machine name 
should presumably be anything that can be encoded in DNS, which will in 
turn be UTF-8 compliant.


>4.1.19 Discriminated Unions
>
>    Type: new
>
>    From: WG
>
>    Description: SMIng must support discriminated unions.
>
>    Motivation: Allows to group related attributes together, such as
>       InetAddressType (discriminator) and InetAddress, InetAddressIPv4,
>       InetAddressIPv6 (union).  The lack of discriminated unions has
>       also lead to relatively complex sparse table work-around in some
>       DISMAN mid-level manager MIBs.
>
>    Notes: Discriminated unions have the property that the union
>       attribute type is constrained by the value of the discriminator
>       attribute.

Again, I'm not sure what this means. If it means that the same MIB might 
specify an IPv4 or an IPv6 address, and a type implicit in the format of 
the address (as is done in an ASN.1 CHOICE) discriminates among them, I'm 
thrilled.

The NetworkAddress was originally such a CHOICE, and was discarded in favor 
of IpAddress because adding a new sub-type to the choice could potentially 
lead to operational faults (as a result of storing a 16 byte address in a 
four byte container, for example), or as a result of some implementations 
having been updated to support the new sub-type while others are not. This 
issue should be expressly handled in some way, and it should be made clear 
that robustness of implementation is the responsibility of the 
implementation, not the language.

>4.1.24 Extended Data Types
>
>    Type: align
>
>    From: SMI, SPPI
>
>    Description: SMIng must support a mechanism to derive new types,
>       which provide additional semantics (e.g., Counters, Gauges,
>       Strings, etc.), from base types.  It may be desirable to also
>       allow the derivation of new types from derived types.  New types
>       must be as restrictive or more restrictive than the types that
>       they are specializing.
>
>    Motivation: SMI uses application types and textual conventions.  SPPI
>       uses derived types.

I mentioned Counter64 as an example of a base type earlier in this note. 
It's not obvious to me why it is not considered such here. In SNMP SMIv2, 
Counter64 is the only example of a 64 bit integer permitted, and it is 
specified as a base type. What am I missing?

>4.2.3 Float Data Types
>
>    Type: new
>
>    From: WG, NMRG
>
>    Description: SMIng should support the base data types Float32,
>       Float64, Float128.
>
>    Motivation: Missing base types can hurt later on, because they cannot
>       be added without changing the language, even as an SMIng
>       extension.  Lesson learnt from the SMIv1/v2 debate about
>       Counter64/Integer64/...
>
>    Notes: There is no mention as to whether or not the underlying
>       protocols will have to natively support float data types.  This is
>       left to the mapping.  However, it seems imperative that the float
>       data type needs to be added to the set of intrinsic types in the
>       SMIng language at the creation of the language as it will be
>       impossible to add them later without changing the language.

in doing the MIBs to support
         rfc2210.txt rfc2211.txt rfc2212.txt rfc2215.txt rfc2210.txt
         rfc2211.txt rfc2212.txt rfc2215.txt rfc2210.txt rfc2211.txt
         rfc2212.txt rfc2215.txt rfc2997.txt rfc3006.txt

I was faced with an interesting choice. The use of IEEE Floating point 
numbers in these specifications was justified by the fact that service 
rates from a few kilobits to multiple gigabits was necessary. The fact that 
I didn't have Integer64 *and* I didn't have real numbers meant that I had 
to make a creative trade-off. As a result, RFCs 2213 and 2214 specify an 
integer for the bytes-per-second, hoping that this will work long enough 
for the MIB to be useful.

Integer64 support would be adequate here, but since the underlying data 
type is a floating point number, I personally would prefer to directly 
report and set floating point numbers.

In other words, this is not a future requirement.


>4.2.6 Arrays
>
>    Type: new
>
>    From: WG
>
>    Description: SMIng should allow the definition of a SEQUENCE OF
>       attributes or attribute groups (Section 4.1.28).
>
>    Motivation: The desire for the ability to have variable-length,
>       multi-valued objects.
>
>    Notes: Some issues with arrays are still unclear.  As long as there
>       are no concepts to solve the problems with access semantics (how
>       to achieve atomic access to arbitrary-sized arrays) and their
>       mappings to SNMP and COPS-PR protocol operations, arrays cannot be
>       more than a nice to have objective.

it is not obvious to me why these need to have atomic access, apart from 
being considered aggregate objects. Right now a number of MIBs have rather 
unwieldy tables in them which, by adding an index, create such objects. 
Examples include the relationship between the OSPF Interface Table and the 
OSPF Interface Metric Table, concerning which RFC 1850 says:

2.3.5.  Interface and Interface Metric Tables

    The Interface Table and the Interface Metric Table together describe
    the various IP interfaces to OSPF.  The metrics are placed in
    separate tables in order to simplify dealing with multiple types of
    service, and to provide flexibility in the event that the IP TOS
    definition is changed in the future.  A Default Value specification
    is supplied for the TOS 0 (default) metric.

or the IP Forwarding MIB's metrics, of which there are five objects because 
Cisco IGRP has a five-number metric, where a five-valued vector would have 
been better.

IMHO, the examples of places where vector-valued objects would be useful 
makes the concern about handling vectors of arbitrary size a little trite. 
I don't see that folks want to put an infinite number of next hops into a 
route, but they would like to be able to specify more than one, and right 
now are forced to do so using the index of the Entry by the limitations of 
SNMP. I don't see that people want to put in an infinite number of 
separately-considered routing metrics, but I have current customers that 
are asking me to supply more than one. Is the problem here that folks don't 
want to do this, and so are using the difficult ultimate general case to 
argue against supplying the valuable and needful 80% solution?

>4.2.8 Separate Data Modelling from Management Protocol Mapping
>
>    Type: new
>
>    From: NMRG
>
>    Description: It should be possible to separate the domain specific
>       data modelling work from the network management protocol specific
>       work.
>
>    Motivation: Today, working groups designing new protocols are forced
>       to care about the design of SNMP MIBs and maybe COPR-PR PIBs to
>       manage the new protocol.  This means that experts in a specific
>       domain are faced with details of at least one foreign (network
>       management) technology.  This leads to hard work and long revision
>       processes.  It would be a win to separate the task of pure data
>       modelling which can be done by the domain experts easily from the
>       network management protocol specific mappings.  The mapping to
>       SNMP and/or COPS-PR can be done (a) later separately and (b) by
>       network management experts.  This required NM expertise no longer
>       hinders the progress of the domain specific working groups.

While I understand that SNMP isn't something that every working group wants 
to deal with, data modeling isn't a universal language either, and I 
personally (who do a lot of protocol work and have been accused of knowing 
something about SNMP MIBs) find data modeling to generally be sufficiently 
abstract as to not tell me much about how to write a MIB.

--------------------------------------------------------------------------

A question for the assembled experts:

Many SNMP MIB Entries are in fact aggregate objects which are accessed 
attribute by attribute due to the limitations of SNMP. For example, while I 
might understand someone being interested in separately accessing an 
interface's type, speed, name, counters, and so on,

  - an ARP entry is just that - the set of information that maps an
    L2 Address <-> an L3 Address
  - an IP Route is just that - the information that tells me what happens
    to a packet sent to a given IP Prefix under a certain set of conditions
  - an OSPF LSA is just that - the information, perhaps digitally signed,
    that says what a router is advertising regarding a given subject
  - and so on

I alluded earlier to the fact that a vector entry might be considered an 
aggregate object; I assert that aggregate objects have significant value 
both in reducing the size of the data elements exchanged and in organizing 
information.

For example, one can readily argue that an ASN.1 CHOICE is a variety of 
aggregate object. It contains two bits of information: the type of the 
value, and the value. When looking at an IP Prefix, the authors of 
draft-ietf-ops-rfc2851-update-02.txt chose to include the prefix length as 
well, and ask MIB designers to always include all three in a certain order 
because they view the three values as essential elements of the concept of 
an IP prefix. OK, why not make it an aggregate object and make the 
implementation a no-brainer?

Why are aggregate objects not on the list, either as accepted or rejected 
for a reason?