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

From: "Carl W. Kalbfleisch" <[email-masked]>
Date: Wed, 03 Feb 1999 16:33:38 -0600

Bob Stewart wrote:
> 
> 
> >   lookupAddress OBJECT-TYPE
> >      SYNTAX      HostAddress
> >      MAX-ACCESS  read-create
> >      STATUS      current
> >      DESCRIPTION
> >          "Specifies the address used for a getHostByAddr Lookup
> >          operation at a remote host."
> >      ::= { lookupEntry 5 }
> >
> >   lookupDnsName OBJECT-TYPE
> >      SYNTAX      DnsName
> >      MAX-ACCESS  read-create
> >      STATUS      current
> >      DESCRIPTION
> >          "Specifies the address used for a getHostByName Lookup
> >          operation at a remote host."
> >      ::= { lookupEntry 6 }
> 
> This would work nicely with one read-create input object and two output
> objects.  The input parameter of type DisplayString (or similar) is either
> a domain name or an IP address.  It's easy to parse that string and know
> which you have.
> 

I like Bob's proposed approach

One question, what value should these objects return in the event that
the DNS lookup fails?

Carl

--
Carl W. Kalbfleisch
Manager NMS Development
Verio Inc., http://www.verio.net

---

From: [email-masked]
Date: Thu, 4 Feb 1999 09:07:24 -0500

Carl,

>I like Bob's proposed approach

I had them combined before. There was something like:

  RemopsHostAddressType ::= TEXTUAL-CONVENTION
     STATUS  current
     DESCRIPTION
         "The textual convention for defining the type of
         the target host's (destination) address."
     SYNTAX  INTEGER {
            none(1),
            dnsName(2), -- Utf8string encoded DNS name
            ipv4(3),    -- ipv4 address
            ipv6(4)     -- ipv6 address
           }

to indicate what was being returned. A type indicator would have to proceed

the object that contained either of the two: ipv4/ipv6 address or dns name.

>One question, what value should these objects return in the event that

This object or objects would return 0 length octet string.

Ken

---

From: [email-masked]
Date: Wed, 10 Feb 1999 18:55:43 -0500

Mike,

Thanks for the suggestion and pointer to:

>--
>-- Enumerated integer version of previous registrations.
>--
>-- This TC can be used to represent transport domains in situations
>-- where a syntax of TDomain is unwieldy (for example, when
>-- used as an index).
>--
>-- Currently the enumerated values of this object are identical to the
>-- last sub-identifier of the OID registered for the same domain.
>--

>IanaAddrDomainType ::= TEXTUAL-CONVENTION
>    DISPLAY-HINT "1d"
>    STATUS       current
>    DESCRIPTION
>            "A value that represents a transport domain."
>    SYNTAX      INTEGER {
>                        other(0),
>                        ianaAddrIPv4Domain(1),
>                        ianaAddrIPv6Domain(2),
>                        ianaAddrUDPIPv4Domain(3),
>                        ianaAddrUDPIPv6Domain(4),
>                        ianaAddrTCPIPv4Domain(5),
>                        ianaAddrTCPIPv6Domain(6),
>                        ianaAddrUNIXDomain(7),
>                        ianaAddrCLNSDomain(8),
>                        ianaAddrCONSDomain(9),
>                        ianaAddrDDPDomain(10),
>                        ianaAddrIPXDomain(11)
>                        }

Ken

---

From: [email-masked]
Date: Wed, 17 Feb 1999 14:02:06 -0500 (EST)

>o Add the following objects to an pingEntry:
>    - pingMinRtt (Unsigned32)
>    - pingMaxRtt (Unsigned32)
>    - pingAverageRtt (Unsigned32)
>    - pingProbeResponses (Counter32)
>    - pingSentProbes (Counter32)
>    - pingRttSumOfSquares (Unsigned32)
>   ProbeResponses, MinRtt, MaxRtt, and RttSumOfSquares are
>   incremented when a "good"  response is received to a probe.
>   Keeping a sum of the RTTs squared allows calculation of a
>   standard deviation.
>o Add pingFrequency (Integer32). Basically, elapsed time to wait before
>   restarting a ping operation in seconds, not milliseconds.
>o Add an object, pingResultsControl, that could be used to determine
>  if entries in the pingResultsTable where added.

I believe these are useful additions to the pingTable and support their
inclusion.  I also believe similar objects in the traceRouteTable would
be useful additions.  Calculation of the computed values is trivial for 
the agent, but obviously requires a management station to retrieve alot 
of data to calculate.  So I believe moving the calculation of these values 
to the agent is a wise choice.

In draft-ietf-disman-remops-mib-03.txt, the pingRowStatus object is
overloaded to both manage the row creation and be a "ping now" trigger.
If a pingFrequency object is added to support the "pro-active" network
availability test mode, then would it make sense to de-couple the two
functions of the pingRowStatus object and add a "trigger now" object
to the row?  Or am I mis-understanding the function of the pingFrequency
object?

>Questions:
>
>4.Do we need to add DateAndTime objects:
>   - Time stamp in an pingResultsEntry when a probe result was added to
>      the results table
>   - Time stamp in an pingEntry when the last "good" probe response was
>      received

If DateAndTime objects are added, I believe implementation of them should 
be optional.  I can envision these MIBs being implemented on embedded 
systems that do not have real-time clocks.

>>In this case I believe the technical guidance of the straw poll went the
>>wrong direction and it's perfectly reasonable for our
>>application-instrumenting MIBs to support DNS lookups intrinsically, or at
>>least to be allowed to do so.
>
>>I've implemented MIBs that way.  If you have DNS services it's neither
>>expensive nor complicated and it makes life considerably easier for users
>>of the MIB.
>
>I would prefer to put it back in. I would like to hear what some other
>folks think first.

I support allowing the host address objects to also allow host names, for
the reasons described in the previous paragraphs.

Regards,
--Alan

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 17 Feb 1999 16:16:17 -0800 (PST)

Hi - 

> Date: Wed, 17 Feb 1999 16:36:32 -0500
> To: [email-masked]
> From: Bob Stewart <[email-masked]>
> Subject: Re: <draft-ietf-disman-remops-mib-03.txt> comments
> 
> At 03:03 PM 2/17/99 -0500, [email-masked] wrote:
> >Would 
> >it make sense to have a storageType object in the pingTable that would 
> >save the configuration across reIPLs?
> 
> StorageType is a kluge and is not sufficient.  It doesn't apply to scalars
> and having to put it on every row of every read-write or read-create table
> is intrusive.  We've fallen into a bad habit of throwing it at the problem.
> 
> Whether or not the entries remain across reboots should be left entirely up
> to the implementation and not specified via a row-by-row object.

Leaving it entirely up to the implementation will not improve matters.

> Perhaps it would be best to separate the configuration objects into a
> separate table from the control and result objects.  Then you could say
> retention of the configuration table is up to the implementation and
> retention of results is not expected but allowed.
...

Separating the configuration/control objects from the result objects
is probably a good idea anyway.   A StorageType  for the configuration
entries is probably a reasonable thing.

Dealing with the retention of results is a different matter.
A "resultRetentionDesired" element in the  configuration/control
entry might be one possible solution.

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