Subject: I-D ACTION:draft-ietf-tn3270e-tn3270-mib-07.txt

From: [email-masked]
Date: Thu, 14 May 1998 10:18:10 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telnet TN3270 Enhancements Working Group
of the IETF.

        Title           : Base Definitions of Managed Objects for
                          TN3270E Using SMIv2
        Author(s)       : R. Moore, K. White
        Filename        : draft-ietf-tn3270e-tn3270-mib-07.txt
        Pages           : 54
        Date            : 13-May-98

This memo defines a Management Information Base (MIB) for configuring
and managing TN3270E servers.  TN3270E, defined by RFC 1647 [15], refers
to the enhancements made to the Telnet 3270 (TN3270) terminal emulation
practices.  Refer to RFC 1041 [14], RFC 854 [12], and RFC 860 [13] for a
sample of what is meant by TN3270 practices.

The MIB defined by this memo provides generic support for both host and
gateway TN3270E server implementations.  A TN3270E server connects a
Telnet client performing 3270 emulation to a target SNA host over both a
client-side network (client to TN3270E server) and an SNA Network
(TN3270E server to target SNA host).  The client-side network is
typically TCP/IP, but it need not be.

A host TN3270E server refers to an implementation where the TN3270E
server is collocated with the Systems Network Architecture (SNA) System
Services Control Point (SSCP) for the dependent Secondary Logical Units
(SLUs) that the server makes available to its clients for connecting
into a SNA network.  A gateway TN3270E server resides on an SNA node
other than an SSCP, either an SNA type 2.0 node, a
boundary-function-attached type 2.1 node, or an APPN node acting in the
role of a Dependent LU Requester (DLUR).  Host and gateway TN3270E
server implementations typically differ greatly as to their internal
implementation and system definition (SYSDEF) methods.

It is the intent that the MIB defined herein be extended by subsequent
memos.  For example, one such extension enables collection of TN3270E
response time data.  The specification of this MIB uses the Structure of
Management Information (SMI) for Version 2 of the Simple Network
Management Protocol (refer to RFC1902 [3]).

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-tn3270e-tn3270-mib-07.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tn3270e-tn3270-mib-07.txt

Internet-Drafts directories are located at:

        Africa: ftp.is.co.za

        Europe: ftp.nordu.net
                ftp.nis.garr.it

        Pacific Rim: munnari.oz.au

        US East Coast: ftp.ietf.org

        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:      [email-masked].  In the body type:
        "FILE /internet-drafts/draft-ietf-tn3270e-tn3270-mib-07.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Derek W. Bolton" <[email-masked]>
Date: Fri, 15 May 1998 11:35:15 +1000 (EST)

Hi Bob,

Nearly there :-), but still some issues :-(.

3.1.1  tn3270eSrvrConfTable

  :

The four objects:

o   tn3270eSrvrConfActivityCheck
o   tn3270eSrvrConfTmNopInterval
o   tn3270eSrvrConfTmNopInactTime
o   tn3270eSrvrConfTmTimeout

@DB: Rats!  I didn't notice that you still have "ActivityCheck"
as the name there.  Surely it's a connectivity check?
But don't bother issuing another draft if there's nothing more
serious than this.

3.3.1  tn3270eSnaMapTable

The tn3270eSnaMapTable is a read-only table that maps a secondary LU's
SNA network name to the name by which it is known locally at the
TN3270E server.  For correlation with data from the SNA network, the
name of the associated primary LU also appears in a
tn3270eSnaMapEntry.  An entry in this table is created when the
Activate LU (ACTLU) request carrying the SNA network name of the SLU
is received from the SSCP.  The entry is deleted when the SLU is
deactivated.

@DB: This doesn't address the issue I raised re ACTPU.  I believe the
entry should be deleted whenever the SSCP-LU session is terminated,
either explicitly or implicitly.  The latter includes DACTPU, ACTPU
and link loss.  Of these, ACTPU and DACTPU Giveback do not deactivate
the SLU completely - an existing LU-LU session can continue (if
ANS=CONT).

  Tn3270eTraceData ::= TEXTUAL-CONVENTION

  :

                     X'01' telnet PDU from the server to the client
                     X'02' telnet PDU from the client to the server
                     X'03' SNA data from the server to the SNA host
                     X'04' SNA data from the SNA host to the server

            data   = initial part of a PDU.

@DB: Hmm.. no progress here.  At the very least, let's say that what
constitutes the start of a SNA PDU is implementation dependent.

  tn3270eTcpConnRemAddress OBJECT-TYPE

  :

           If a TN3270(E) client is connected to its
           server via a proxy client the address represented by
           the value of this object shall be the remote client's
           address, not the proxy client's address."

  tn3270eTcpConnRemPort OBJECT-TYPE

@DB:  I don't understand what's happening here.  I have seen no
refutation of my claim that the remote client's IP+TCP address
might not be unique.  Is it not possible that there are two
subnets 10.1.1.*, that there is a client at 10.1.1.1:99 on each,
and that these subnets each reach the server via proxies that
provide unique IP+TCP addresses to represent them on the TCP
sessions?

Regards,
  Derek