
Date: Tue, 14 Aug 2001 13:10:40 +0200
Message-Id: <200108141110.NAA13830@henkell.ibr.cs.tu-bs.de>
From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
To: dperkins@dsperkins.com
CC: nmrg@ibr.cs.tu-bs.de
In-reply-to: <5.0.2.1.2.20010713150349.02f4d230@mail.scruznet.com> (dperkins@dsperkins.com)
Subject: Re: [nmrg] SMI types update
References:  <5.0.2.1.2.20010713150349.02f4d230@mail.scruznet.com>
Sender: owner-nmrg@ibr.cs.tu-bs.de
Precedence: bulk

>>>>> David T Perkins writes:

David> I submitted an individual proposal today for updating the data
David> types in the SMI. Here is the URL for it
David> http://www.snmpinfo.com/ftp/temp/draft-perkins-smi-addition-00.txt

David> I would appreciate some technical feedback.

Below are comments on <draft-perkins-smi-addition-00.txt>. We actually
discussed most of them in an informal meeting with Dave and Frank
during the IETF in London. I writing them down here so that others can
join in so that all issues raised are archived.

1. Typo in section 1 in the section talking about SMIv2:

   * INTEGER - a 32-bit signed numbers 

   (Note the plural 's' in numbers)

2. I propose to change the wording of the second sentence in the first
   paragraph in section 2 in order to not mix ASN.1 terms with C
   language terms.

   OLD:

   DiscUnion (discriminated union). The data type for a union without a 
   discriminator is not included, nor a sequence or an array (sequence 
   of). The types are: 

   NEW:

   DiscUnion (discriminated union). The data type for a union without a 
   discriminator is not included, nor a sequence (struct) or sequence 
   of (array). The types are: 

3. Section 2 does not say that there are no constants for floating
   point numbers. This is mentioned somewhere later on but I expected
   to have a statement here as well since the motivation of keeping
   the costs for MIB parsers low is probably the same.

4. I am personally not yet convinced that having no default values or
   constraints on floating point types is a good thing. If we do add
   floating point types, then we should do the complete thing.

5. I am wondering why you propose to support only Float and Double
   floating point numbers. I have researched the issue a bit more and
   here is what I found out:

   IEEE 754-1985 seems to specify:

   Single Precision          (32 bit)
   Double Precision	     (64 bit)
   Double-Extended Precision (>= 80 bit)

   The Quadruple Precision format (128) is not really defined in IEEE
   754-1985 although it is a de facto standard among several computer
   makers, even though many hardware FPUs seem to support just 80 bit
   floats. Note that Quadruple Precision is compatible with the IEEE
   Double-Extended Precision format.

   XDR (RFC 1832) defines the on-the-wire encoding of 32/64/128 bit
   floating point numbers. CDR (CORBA 2.4.2) defines on-the-wire
   encoding of 32/64/128 bit floating point numbers. Note that the
   CORBA IDL (CORBA 2.4.2) only provides float, double, long double
   types that match the IEEE 754 definitions (Single, Double,
   Double-Extended). The ANSI-C standard does not really define what
   the precision of a long double is. It is legal to map long doubles
   to just Double Precision IEEE floating point types.

   So it looks like protocol designers so far prefer to have 32/64/128
   bit floating point numbers on the wire, even though the various
   languages and implementations may not be capable to use full
   precision.

   Some Fortran compilers seem to support a quadrupel precision format
   (REAL*16) but it is unclear whether this is defined in one of the
   Fortran standards and whether implementations really use all 128
   bits.

   More background information can be found at
   <http://cch.loria.fr/documentation/IEEE754/>.

6. The current SMIng proposal defines:

   Float32
       [APPLICATION 12]
           IMPLICIT OCTET STRING (SIZE (4))

   Float64
       [APPLICATION 13]
           IMPLICIT OCTET STRING (SIZE (8))

   Float128
       [APPLICATION 14]
           IMPLICIT OCTET STRING (SIZE (16))

   This memo however defines:

   Float ::= 
       [APPLICATION 8] 
           IMPLICIT OCTET STRING(SIZE(4)) -- values are in IEEE format 
    
   Double ::= 
       [APPLICATION 9] 
           IMPLICIT OCTET STRING(SIZE(8)) -- values are in IEEE format 
    
   DiscUnion ::=  -- only unique base types are included in the choice 
       [APPLICATION 12] IMPLICIT SEQUENCE { 

   We need to resolve the conflicts.

7. There is a need to distinguish SMIv2 and SMIv2+ so that tools can
   do either pure conversion to SMIv2 or SMIv2+. Even though this
   proposal is labelled as an update, it still adds another version to
   the family of SMI languages.

8. I am not sure the discriminated union as defined is the right way
   to go. This memo ties the discriminator to the value so they can
   only be manipulated atomically. This leads to some interesting
   constructs when you need to store a discriminated union in DISMAN
   like MIBs and the proposed solution discussed in section 5 requires
   that the discriminator is limited to (1..2147483647), which I did
   not find natural when I first read the document.

   Another option would be to just define a Union base type and to
   have the discriminator as a separate object. This is what MIBs
   currently do with InetAddressType/InetAddress or TDomain/TAddress
   combinations. This approach also allows to share a discriminator
   between multiple unions (InetAddressType/InetAddress/InetAddress).
   It would than be a language issue to bind the union to a
   discriminator and it avoids problems with DISMAN-like MIBs.

/js