Re: FddiTime, and update to Path config table

Ahmet Tuncay <atuncay@synoptics.com> Tue, 28 July 1992 01:43 UTC

Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa16009; 27 Jul 92 21:43 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa16005; 27 Jul 92 21:43 EDT
Received: from CS.UTK.EDU by NRI.Reston.VA.US id aa00275; 27 Jul 92 21:43 EDT
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA12108; Mon, 27 Jul 92 21:07:11 -0400
Received: from mvis1.synoptics.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12104; Mon, 27 Jul 92 21:07:08 -0400
Received: from mvis2 (mvis2.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA28127; Mon, 27 Jul 92 18:07:03 PDT
Received: by mvis2 (4.1/2.0N) id AA11952; Mon, 27 Jul 92 18:07:07 PDT
Message-Id: <9207280107.AA11952@mvis2>
Date: Mon, 27 Jul 1992 18:07:07 -0700
From: Ahmet Tuncay <atuncay@synoptics.com>
To: anil@levers.enet.dec.com, ronkin@synnet.com
Subject: Re: FddiTime, and update to Path config table
Cc: fddi-mib@cs.utk.edu

Anil wrote:

    As a matter of curiosity: does your nms have specific knowledge of fddi/
    do you have an application rather than a vanilla nms with compiler.

    Please don't rigidly stick to "consistency" as a reason on this type
    of issue.  The ANSI folks made fddi work.  The job this forum is trying
    to get done is make it manageable, from the point of view of a network
    manager rather than that of an implementor. 

I would like to ask if you seriously think that FDDI can be managed using a
generic SNMP manager without specific knowledge of FDDI???  What do your 
users think about hundreds of useless objects scrolling down in their
screens??  Have you though about how an SNMP to SMT proxy should work??

    The former could
    care less about how times are internally represented.  Consistency
    is important to the extent that the protocol specified is adequately
    instrumented.  I would argue that a range of half what is required is
    more of a consistency problem.

This is largely true, however, you haven't made the case of why it should
be changed to something in-consistent with how things are actually 
instrumented to make the media protocol work :-).

    I was involved in a mib where time was represented in 1/256 seconds in the
    relevant IEEE standard!  We changed over to a more human-readable format.
    Mibs ought be reasonably usable without higher level applications or
    special features.

    Anyway, the vote is 3-1 against making this change so far and there
    are bigger and better issues yet to be resolved on this mib, so
    let's move on! :-)

Let's change the vote.

    Anil

Ahmet Tuncay
atuncay@synoptics.com