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

From: Randy Presuhn <[email-masked]>
Date: Wed, 11 Aug 1999 13:22:33 -0700 (PDT)

Hi -

Many thanks for the detailed comments!  As a technical contributor, I
have a couple of responses in-line below.

> Date: Wed, 11 Aug 1999 11:27:27 -0400 (EDT)
> From: Alan Luchuk <[email-masked]>
> To: [email-masked]
> Subject: Re:  <draft-ietf-disman-remops-mib-06.txt>
> Cc: [email-masked], [email-masked]
...
> 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.

I believe interpretation "b" is correct.  Do we need to clarify the text?

> 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?

I don't see anything in the TC definition that would require a
management system to use the hex form for either display or data
entry.  Am I mising something here?

> 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

Network byte order is the long-established practice.
The endpoint MIB is consistant with this, I don't think
we need to do anythin here.

> 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 strongly disagree.  Construction of user-interface-specific
data representations is far outside the scope of what agents
should be doing.

> 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?)

It's the security administrator's problem to ensure that the access
control policies for entries whose owner index get encoded as a single
0 subidentifier are formulated properly.  I don't see it introducing
any problems for VACM.

> 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?

I don't see what the security hole is, unless someone formulates policies
which wildcard the length subidentifier and try to work with substrings
of the owner index.  As detailed at the WG meeting in (Minneapolis?)
there are lots of nasty corner cases for formulating access control
policies in this way.  Since the "0" case is special anyway, the security
administrator would need to take care to formulate a distinct access
control policy for "0" (the length subidentifier NOT wildcarded).

I think there is no problem here.

> 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"

yup

> 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).

agreed that (at least) some clarification is in order here;
it may not be possible to represent both addresses in the same way.

> 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?

Unsigned32 seems right.

> 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 }

agree that something was misplaced here

> 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?
...

I think Unsigned32 is the right thing.

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com/
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's is probably coincidental.
 ------------------------------------------------------------------------