Subject: Review comments on tn3270e-mib-02

From: Michael Boe <[email-masked]>
Date: Mon, 22 Dec 1997 22:11:57 -0800 (PST)

Ken,

You had asked me to provide some words around ProxyClient, etc. Included
somewhere in this note are some words. Also included in this note are some more
review comments on the MIB document.

General:
--------

--Security: do we put security-related variables in this MIB?  Or does this MIB
really relate to RFC1647?  If so, should we take out all the FarEnd client
stuff?

--ProxyClients and FarEndClients:  This is somewhat related to the Security
question.  If this MIB really reflects RFC1647, then maybe none of this stuff
belongs in the MIB (we can do a follow-on extension MIB).

If the answer is that ProxyClients should be part of this MIB, then I feel that
the current variables are bass-ackwards, so to speak.  That is, I think that
the MIB has no choice but to list all nearEndClients as Clients, whether they
be Proxy Clients or regular clients.  This is because there's no foolproof way
of saying whether a TN3270(E) client is nearEnd or farEnd. So I think there's
little choice but to list all nearEnd clients as TN3270E clients, and talk
about farEnd clients as being optional, additional things.

Specific:
---------

Section 3.1.1:  In the first paragraph, there's the expression "on the same
host."  This should read "serviced by the same SNMP agent."  The "on the same
host," or variations on it, occurs several other places in the document.

MIB:
------------

Tn3270Functions:  Is there anyway we can just reserve a block of bits and say
that these bits (offset by some value) indicate TN3270E Function bits?  That
way, the MIB can track additions to the function-bit support without too much
trouble.  Also, coding will be made a bit easier.

tn3270eSrvrPort:  syntax....unsigned32?  unsigned16?

tn3270eSrvrPortAddrType:  client address should be server address.
tn3270eSrvrPortAddress:   client address should be server address.

tn3270eSrvrSpareLus:  useable-->usable.

tn3270eSrvrStatsMaxPtrs:  I'm concerned about this one.  The TNServer may not
know what the maximum number of Printer Resources might be, other than it must
be less than the total number of LUs. Also, I'm not sure I can think of a use
for this variable (but I admit to not trying all that hard :-).  Can somebody
give one or two good examples of how this would be used?

tn3270eSrvStatsConnectsIn:  Need to clarify whether these connects are
transport-layer connects, or what.

tn3270eSrvrStatsConnRejects: Note that it's possible to REJECT and ASSOCIATE
attempt w/o rejecting the connection at a TCP level.  This needs clarification
as to exactly what is being rejected.

Can you that connectsIn - rejects - disconnects == active?  If so, it should be
mentioned here.

tn3270eSrvrStatsOctetsIn/Out:  At what level are these octets being counted? I
would suggest that the number of octets be the number of bytes of TN3270
payload.  Or you can make it at the TCP level. [Remember that this count is
complicated by two things:  the 0xff byte-stuffing, and the possible existence
of a security layer between TCP and Telnet...so we need to be very precise
about what's being measured here.]

tn3270eResPoolTable:  I would either take out the reference to RFC1647, or wait
till it's successor becomes a DRAFT standard.

tn3270eSnaMapTable:  TN3270e should be TN3270E.

tn3270eTcpConnRemPort:  as noted at the top of this note in the "General"
section, I don't think we've got any choice but to have the nearEnd client's
address here, not the farEnd client's address.

tn3270eTcpConnLastActivity:  associated, not associating.

tn3270eTcpConnBytesIn/Out:  same clarification needs as for the
SrvrPortOctetsIn. What layer are we measuring the bytes at?

tn3270eTcpConnDeviceType:  the explanation is wrong.  The TN3270E DEVICE-TYPE
(or TN3270 TERMINAL-TYPE) should not be confused with LOGMODE.  It will map to
a LOGMODE somehow, but that's not important to the discussion on this variable.

tn3270eTcpConnFunctions:  negioted should be negotiated.

tn3270eTcpConnClientIdFormat:  Description should read: "Identification of
client by the TN3270 server to authorize what resources can be used by the
client."

The enumerations are as follows:
    * x509dn -- X.509 Distinguished Name
    * userid -- userid/password based authentication.  The actual ID probably
also includes the method used to verify identity (racf,tacacs+,radius,etc).
    * none   -- no identity was used/given in determining authorization
    * ipaddr -- the IP address of the client was basis for authorization.
    * dnsname-- the DNS name of the client was basis for authorization.

As you can see, I'm pretty fuzzy on all these. My personal opinion is that we
should not included this stuff until the security portion of the specs starts
taking shape.

tn3270eTcpConnMiscInfoFormat:  This needs clean up wrt nearEnd/farEnd client
stuff.

Hope this is some use,
/msb