Re: dumb questions/comments regarding smi-ng

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

I am really sorry for the long period that I did not respond to some
personal and mailinglist messages. I'd like to thank Fred for his
valuable comments on the objectives document. Here are my replies (the
whole message is quite long, however my bits are just a small
percentage; I just tried to keep the context, due to my response
delay)...



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

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

Jamie> My understanding reading the meeting minutes from the London WG
Jamie> meeting are that "ABNF Grammar" is to be replaced with
Jamie> something along the lines of rigorously defined syntax.  This
Jamie> would allow an XML schema to be put forth as a proposed SMIng
Jamie> language.

I agree to Jamie, as long as we consider 4.1.5 as it is, and it is
already changed in the working document. However, I think XML and XML
Schema would be in conflict with 4.1.3 (Human Readability).



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

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

PIB-ACCESS is an SPPI construct with simiar semantics to MAX-ACCESS.



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

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

Yes, SMIng is about to support 64 bit integers. The crux with nasty
things like ifSpeed vs. ifHighSpeed is that there is an SNMP (not SMI)
version that does not support 64 bit types, hence for the mapping from
the protocol neutral SMIng modules to protocol specific definitions it
has still to be considered whether you want to support SNMPv1 or not.

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

4.1.17 just talks about base types. Currently, from the conceptual
point of view, we regard Counter32 to be a subtype of Unsigned32 and
Counter64 to be a subtype of Usigned64.

I'll add a note to 4.1.17 that explains this to SNMP/SMIv1/2 folks. ;-)

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

This is also not a base type.

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

I agree that i18n is an issue, and 4.2.7 talks about it with respect
to SMIng constructs (not object values). However, note that

1. You are talking about MIBs, not the MIB defintion language.

2. The semantics and value ranges of existing standardized objects
   MUST NOT be changed. Hence, it is not allowed to change e.g.
   the definition of sysDescr to allow UTF-8. It is only possible
   to define additional objects that allow UTF-8 values.

However, I agree that SMIng should come with a set of well known
and well defined derived types, including UTF-8 strings. The I-D
draft-ietf-sming-modules-02.txt already supports the type
`Utf8String'.



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

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

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

I don't understand your interpretation, but I think it's what what 
4.1.19 is about.

4.1.19 says that the SMIng module author should have the possibilty to
express related objects in a way similar to unions in the C
programming language. In contrast to C unions, we want to have an
explicit deiscriminating object with such a union.



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

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

Yes, in SMIv2 Counter64 (and Counter32 and Gauge32) are
basetypes. However, this does not seem reasonable. The underlying
`intuitive' basetype seems to be an unsigned 64 bit integer. Counters
and gauges seem to be more specific derived types with special
semantics. Do you agree (from the intuitive and non-snmp view)?  This
is how we intend to construct the set of basetypes in SMIng.



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

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

Fred>     2.3.5.  Interface and Interface Metric Tables

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

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

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

Let me take another perspective: From the SNMP and COPS-PR point of
view, these problems have to be solved using tables. Since SMIng must
be mappable to SNMP and COPS-PR and since we already have a mechanism
to model tables, the question seems to be, whether we want a
simplyfing notation in SMIng. My feeling is that this would be a kind
of redundance that would cause more confusion than benefit.



Fred> A question for the assembled experts:
Fred> 
Fred> Many SNMP MIB Entries are in fact aggregate objects which are
Fred> accessed attribute by attribute due to the limitations of SNMP. For
Fred> example, while I might understand someone being interested in
Fred> separately accessing an interface's type, speed, name, counters,
Fred> and so on,
Fred> 
Fred> - an ARP entry is just that - the set of information that maps an
Fred>   L2 Address <-> an L3 Address
Fred> - an IP Route is just that - the information that tells me what
Fred>   happens to a packet sent to a given IP Prefix under a certain set
Fred>   of conditions
Fred> - an OSPF LSA is just that - the information, perhaps digitally
Fred>   signed, that says what a router is advertising regarding a given
Fred>   subject
Fred> - and so on
Fred> 
Fred> I alluded earlier to the fact that a vector entry might be
Fred> considered an aggregate object; I assert that aggregate objects
Fred> have significant value both in reducing the size of the data
Fred> elements exchanged and in organizing information.
Fred> 
Fred> For example, one can readily argue that an ASN.1 CHOICE is a
Fred> variety of aggregate object. It contains two bits of information:
Fred> the type of the value, and the value. When looking at an IP Prefix,
Fred> the authors of draft-ietf-ops-rfc2851-update-02.txt chose to
Fred> include the prefix length as well, and ask MIB designers to always
Fred> include all three in a certain order because they view the three
Fred> values as essential elements of the concept of an IP prefix. OK,
Fred> why not make it an aggregate object and make the implementation a
Fred> no-brainer?
Fred> 
Fred> Why are aggregate objects not on the list, either as accepted or
Fred> rejected for a reason?

Jamie> If I understand your comment correctly, it appears to me that
Jamie> what you are asking for is covered by requirements 4.1.28
Jamie> (Attribute Groups) and 4.1.29 (Containment).  I think that the
Jamie> confusion could possibly stem from different nomenclature.

Fred> if so, may I suggest a minor text edit?
Fred> 
Fred>          "..., also referred to as 'aggregate objects', ..."
Fred> 
Fred> I read those sections, and the concept of aggregate objects never
Fred> entered my mind while reading them.

As long as we don't use a certain term, we should not say that we do.
I have no strong opinion on which term would be better `aggregate objects'
or `attribute group', but I think we should not use both.



 -frank