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

From: [email-masked]
Date: Sat, 28 Aug 1999 04:48:11 -0700

Hi Alan,

Here are my comments to your original note that I hope I have factored in the
comments/discussion from related follow-on notes:

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

All comments are welcomed.

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

Randy's comment was:

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

I agree with Randy and have added this clarification to the text.

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

Updated as per last comment.

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

Randy's last comment was:

"Since the concerns about the HostAddress are hardly
unique to the <draft-ietf-disman-remops-mib-06.txt>
document, and since these same comments would apply
to <draft-ops-endpoint-mib-00.txt>, I suggest that the
discussion of this particular issue be moved from the
disman list to the [email-masked] list.  (Subscribe
using [email-masked])

I'd like to close this issue, and would prefer to not wait
for <draft-ops-endpoint-mib-00.txt>   Objections?"

No. There is no easy solution for providing a user friendly
interface. In any case, user interfaces are out side the
scope of the MIB. It is fairly easy to write something like
a shell script to take whatever format is easier for a user to
convert it to what needs to be pass to down to something like a
snmp command.

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

I agree with Randy's response for this and believe no change is
required:

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

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

Done.

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

I agree that some clarification is needed here. What I have added
is:

   The address type (HostAddressType) that relates to
   this object is specified by the corresponding value
   of pingCtlTargetAddressType.

Is this sufficient? I have also updated the traceroute related
object as well.

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

I have no problem with changing this object to Unsigned32 and
have done so.

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

Agreed, they are now:

 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.  The value of this object is initially
       determined by the value of traceRouteCtlInitialTtl."
    ::= { traceRouteProbeHistoryEntry 2 }

 traceRouteProbeHistoryProbeIndex OBJECT-TYPE
    SYNTAX      Unsigned32 (1..10)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
       "Indicates the index of a probe for a particular
       hop in a traceroute path.  The number of probes per
       hop is determined by the value of the corresponding
       traceRouteCtlProbesPerHop object."
    ::= { 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?

Changed to Unsigned32.

I have prepared a new draft that I will submit when Randy
says the review period has ended.

Regards, Ken