Subject: Review comments on tn3270e-mib-02

From: Barry Chan <[email-masked]>
Date: Tue, 30 Dec 1997 14:00:02 +1100 (EST)

Ken,

   Here are some review comments:

tn3270eSrvrStatsEntry:
   This is indexed by ConfIndex and StatsPort. It will be
more general to be indexed by ConfIndex and PortAddress + StatsPort.
This allows server with multiple IP addresses rather than restricted
server with single IP address and multiple ports.

Counter64 and Counter32:
   Does this mean server cannot support Counter64 doesn't  have to put
value on Counter64? If so, what value should it be? 0. If not, why use
both Counter32 and Counter64.

tn3270eClientGroupSubnetMask:
   How can the server know the subnet mask of the client? If this is
through configuration, then does it mean some sort of access list (lu
nailing)?

tn3270eSnaMapSscpSuppliedName:
   This name is used as an index for some fields. But the name may
be stripped by area-4 and may not pass to the server through ACTLU.
So it is necessary to use localName as an index.

lu mapping:
   The lu is known by VTAM using the sna name. In some cases the
lu is identified by puName and locaddr. In fact, the SnaNauMib (rfc1666)
is indexed by puIndex and locaddr. How is the mapping map to the
this mib?

   In general, I am concerned about little informations provided by
the MIB to indicate why the client is disconnected or refused to be
connected. At least there should be a field at Tn3270eTcpConnEntry.
eg.
   Tn3270eTcpLastDisconnectReason:
       unknown,
       hostSendsUnbind,
       hostDontAcceptConnection,
       outOfResource,
       clientProtocolError,
       invalidDeviceName,
       deviceInUse,
       inactivityTimeout,
       hostNotResponding,
       clientNotResponding,
       tcpClose,
       serverClose,
       sysreqLogoff,
       serverSpecificHexCode

tn3270eTcpConnState:
   This should provide more informations. At least this should
provide transient states like dis/establishingSscpLuSession and
dis/establishingLuSession.
   There is no state information about a client. e.g If client A
connects and disconnects to a lu. Client B then connects to this
lu. So when we display client A, how did we know client A is no
longer connected? Maybe all informations of client A is destroyed
after disconnect?

historical events:
   There are no historical events defined. This provides useful
informations to the administrator to diagnose the problem. These
events can be put at tn3270eTcpConnMiscInfo with unknown flag. It
will be much better to predefine events. eg.

           "unknown",
           "inactivity timer expired",
           "dynamic timer expired",
           "actlu req",
           "bind req",
           "clear req",
           "dactlu req",
           "warm actpu req",
           "sdt req",
           "unbind req",
           "notify resp",
           "Reply PSID neg rsp",
           "Reply PSID pos rsp",
           "Unbind rsp",
           "hierarchical reset",
           "Client connect req",
           "Client disconnect req",
           "Timing Mark received",
           "flow control timer expired",
           "Neg rsp to host",
           "Neg rsp from host",
           "Data contention",
           "no buffer to send sna data",
           "receive response while inbound",
           "client protocol error",
           "bad client sequence received",
           hex code

16 bytes to store the above events are very useful.

trace data:
   We found some trace data very userful to diagnose data. So instead of
unknown at tn3270eTcpConnMiscInfo, how about define a new type call traceData.
The trace data format can be
The first 2 octects to indicate the type and length. Type is defined by 2 bits
to indicate inbound/outbound telnet/sna data. The other 14 bits to indicate
the length. We found 14 bytes of data is quite sufficient. So each entry is
16 bytes data and 16 entries should be sufficient.

Barry

---

From: [email-masked]
Date: Tue, 27 Jan 98 09:18:17 EST

Barry,

>server with single IP address and multiple ports.

I remember that we added an address field to an PortEntry to enable
specification of port assignment on an address basis. I agree that
this needs to be carried into the StatsTable. I would prefer having
the address occur after the port. Both tables now have the same
indexes.

>both Counter32 and Counter64.

I've removed the Counter64 objects from the tn3270eBasicGroup
conformance statement and have put them into a separate
optional group. I think these objects should be optional. An
implementation that doesn't support them should return noSuchObject.
Returning a zero is misleading. Counter64 objects are recommended
when the Counter32 objects can wrap too frequently. The IF-MIB
(RFC 2233) requires that the 64 bit versions of its counters
be implemented when an interface can support rates around 20
million bits per second or greater. I think that at this rate
that a wrap could occur at just over 28 minutes.

Other MIBs, APPL-MIB for example, have defined Counter64 objects.
Personally, I'm not sure for us that they are really needed. For
now I will leave them in, make optional and attempt to add clarifying
text.

>through configuration, then does it mean some sort of access list (lu

This isn't the subnet of a client's addresses but the subnet for
a group of client addesses. A single client address would have
a subnet of 255.255.255.255 as explained in the DESCRIPTION clause
for tn3270eClientGroupSubnet. An entry in the tn3270eClientGroupTable
is used by the TN3270E-MIB to perform IP address to LU mapping
and by the TN3270E-RT-MIB to determine a set of clients for
performing response time collection.

>So it is necessary to use localName as an index.
.
>is indexed by puIndex and locaddr. How is the mapping map to the

Bob Moore has addressed these items in a prior posting.

>       hostDontAcceptConnection,

I've added tn3270eTcpConnStateLastDiscReason using the above
as its set of enumerations.

>dis/establishingLuSession.

OK. I've added these to tn3270eTcpSnaState.

>longer connected? Maybe all informations of client A is destroyed

I've added text to clarify this. Basically, entry removal
from the tn3270eTcpConnTable depends on two things. First,
the value of tn3270eSrvrConfSessionTermState (this indicates
what occurs when a SNA TN session terminates. Termination
of the TCP connection always causes the corresponding
tn3270eTcpConnEntry to be removed.

>16 bytes to store the above events are very useful.

OK, we will add an object for this in the next draft.

>16 bytes data and 16 entries should be sufficient.

Good idea. We added a new object tn3270eTcpConnTraceData to provide
for this function.

Bob and I are almost done with the new versions of the MIBs. We plan
to post them by the end of next week.

Regards, Ken