clarifications of SNMPv2 related RFCs.

Bert Wijnen <wijnen@vnet.ibm.com> Thu, 30 January 1997 18:49 UTC

Received: from cnri by ietf.org id aa15711; 30 Jan 97 13:49 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa17385; 30 Jan 97 13:49 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19592 for snmpv2-outgoing; Thu, 30 Jan 1997 13:38:33 -0500 (EST)
Message-Id: <199701301844.NAA22442@relay.hq.tis.com>
Date: Thu, 30 Jan 1997 19:42:44 -0000
From: Bert Wijnen <wijnen@vnet.ibm.com>
To: snmpv2@tis.com
Subject: clarifications of SNMPv2 related RFCs.
Sender: owner-snmpv2@ex.tis.com
Precedence: bulk

I figured that maybe we should have some discussion on an issue I
recently reported to Dave Perkins (who is working with some others
on a clarifications document).

Mayeb other people have comments and suggestions on this.

Dave Perkins reacted to a discussion on OwnerString in the if-mib and
disman WG mailing lists about issues w.r.t. it being allowed to do
new TC as a efinement of an existing TC .

I then thought abot the following strange thing that I do not yet
grasp.

In RFC1903 I see the TCs for TDomain and TAddress

In RFC1906 I see snmpUDPDomain and snmpUDPAddress and others.

So if I have a MIB I would like to be able to define 2 columns
in a table, one of type TDomain and one of TAddress, like:

   myTdomain  OBJECT-TYPE
       SYNTAX   TDomain
       ..etc..

   myTaddress OBJECT-TYPE
       SYNTAX   TAddress
       ..etc..

If an instance of myTdomain takes for instance the value of
snmpUDPDomain, then the same instance of myTaddress takes the
value of an octet string formatted according to the snmpUDPAddress.
Sofar So good. But the question then is.... what is the use of
snmpUDPAddress TC?? Should it not be based on TAddress with a
refinement? And even then.... how do you handle that programmatic?

Bert