Subject: Re: <draft-ietf-disman-remops-mib-06.txt>

From: Alan Luchuk <[email-masked]>
Date: Wed, 11 Aug 1999 11:27:27 -0400 (EDT)

Hello all,

I've finally had a chance to read <draft-ietf-disman-remops-mib-06.txt>.
I believe I'm still within the two-week WG last call time window, so 
here are my comments.  I hadn't looked at the documents in several weeks, 
so I could read them with a (slightly) clearer head and see these issues.

Overall, the document looks pretty good.  Most of my comments are 
slight documentation changes.  The only issue that may be of any 
consequence are minimum size restrictions of 0 octets on the table 
indices that affect access control via VACM.

Hope these are of some value.

Page 7
------

Section 3.1.4, second paragraph, the last sentence reads:

"An implementation MUST start assigning pingProbeHistoryIndex 
values at 1 and wrap after exceeding the maximum possible value."

Does "maximum possible value" mean:

  a.  The value specified by the pingCtlMaxRows object; or
  b.  The maximum possible value storable by pingProbeHistoryIndex
      (specified on page 27 as 'ffffffff').

Could someone either refresh my memory or clarify this in the text?

A similar comment applies to the last sentence of the last paragraph
in section 3.2.4 on page 9.

Page 13
-------

The HostAddress textual convention is specified like this:

   HostAddress ::= TEXTUAL-CONVENTION
      STATUS  current
      DESCRIPTION
          "The textual convention for specifying a host
          address.  The type of address can be determined
          by examining the value of the preceding
          HostAddressType object:

             HostAddressType   OCTETs    ADDRESS TYPE
                none(0)         0        not specified
                dnsName(1)      1-255    DNS name
                ipv4(2)         4        ipv4
                ipv6(3)         16       ipv6"
      SYNTAX OCTET STRING (SIZE (0..255))

For a HostAddressType of ipv4, the HostAddress is restricted
to 4 octets in length.  This means that a user cannot specify
the IP host address in a human-friendly form, but instead
must specify it as an hexadecimal octet string.  For example,
the user cannot specify the IP host address like "192.147.142.150"
but instead must specify in a form like "C0 93 8E 96".

Was this intended?   

If this was intended, specifying the byte ordering required in 
the octet string would promote interoperability.  For example, 
should the byte ordering be:

    C0 93 8E 96,    96 8E 93 C0,    or    93 C0 96 8E

Something similar should be done for ipv6 addresses.

Personally, I would prefer that the agent take ipv4 and ipv6 
addresses specified in human-friendly (e.g., 192.147.142.150)
form and do the conversion.   This would require changing the
size restrictions specified in the description clause.

I can align with whatever the working group believes is the 
right thing to do.

Page 16
-------

The pingCtlOwnerIndex object is specified as:

   pingCtlOwnerIndex OBJECT-TYPE
      SYNTAX      SnmpAdminString (SIZE(0..32))
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
         "Description text deleted by Alan."
      ::= { pingCtlEntry 1 }

The minimum size for this object is 0 octets.   Was this intended?   
Will this minimum size of 0 octets affect the use of View-Based 
Access Control?   (As in, could security be compromised because 
someone specifies a pingCtlOwnerIndex of 0 octets in length?)

The pingCtlTestName (page 17),  traceRouteCtlOwnerIndex (page 35),
traceRouteCtlTestName (page 36), lookupCtlOwnerIndex (page 58),
and lookupCtlOperationName (page 59) are similarly defined with
size restrictions of (0..32) octets.

Would changing the minimum size to 1 would resolve any possible
security holes resulting from zero-length table indices?

Page 18
-------

Minor textual change in comment text in the pingCtlAdminStatus:

   pingCtlAdminStatus OBJECT-TYPE
      SYNTAX      INTEGER {
                            enabled(1), -- test should be started
                            disabled(2) -- test should be stop
                          }
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
         "Description text deleted by Alan."
       DEFVAL { disabled }
      ::= { pingCtlEntry 8 }

Change comment text:

from:     "-- test should be stop" to
to:       "-- test should be stopped"

A similar change should be made for traceRouteCtlAdminStatus 
(page 41).

Page 21
-------

The pingCtlSourceAddress MIB object has "SYNTAX HostAddress".

Presumably, the HostAddress format used here must be the same
HostAddress format used to specify the pingCtlTargetAddress.

Is my presumption correct?  Should a note about this be added
to the DESCRIPTION for the pingCtlSourceAddress?

Adding another MIB object to specify the HostAddressType for
pingCtlSourceAddress seems unnecessary, but is another possible
solution.  But I can't imagine why someone might want to specify
a pingCtlSourceAddress that is a different type (say, ipv4) from
pingCtlTargetAddress (say, ipv6).

A similar issue applies to the traceRouteCtlSourceAddress object
(page 39) and the traceRouteCtlTargetAddress object (Page 36).

Page 28
-------

The pingProbeHistoryResponse object has SYNTAX Integer32.  Was
this intended?   Or should it be Unsigned32 like the other MIB
objects that will only have positive values?

Page 47
-------

The second sentence in the DESCRIPTION text for the
traceRouteProbeHistoryProbeIndex object may belong in the
DESCRIPTION text for traceRouteProbeHistoryHopIndex.

   traceRouteProbeHistoryHopIndex OBJECT-TYPE
      SYNTAX      Unsigned32 (1..255)
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
         "Indicates which hop in a traceroute path that the probe's
         results are for."
      ::= { traceRouteProbeHistoryEntry 2 }

   traceRouteProbeHistoryProbeIndex OBJECT-TYPE
      SYNTAX      Unsigned32 (1..10)
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
         "Indicates the index of a probe for determining for a
         hop in a traceroute path.  The value of this object is
         initially determined by the value of traceRouteCtlInitialTtl."
      ::= { traceRouteProbeHistoryEntry 3 }

Page 48
-------

The traceRouteProbeHistoryResponse object has SYNTAX Integer32.  
Was this intended?   Or should it be Unsigned32 like the other 
MIB objects that will only have positive values?

Regards,
--Alan
 
 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 423 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 423 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.int.snmp.com/
 -----------------------------------------------------------------------------