Subject: Response to Derek's comments on the TN3270E Base MIB

From: Robert Moore <[email-masked]>
Date: Fri, 8 May 1998 14:59:25 -0400

Michael & Derek,

Same approach for Derek's comments on the TN3270E Base MIB,
identified as DB-Base-1 through DB-Base-29.

DB-Base-1:  See item DB-Base-10 / DB-Base 11 below.

DB-Base-2:  (This looks like a Cisco implementation discussion.)

DB-Base-3:  Good point.  The PLU name object in the
            tn3270eSnaMapTable must be filled in at BIND time,
            not at ACTLU time.  So at ACTLU time the PLU name
            object must be initialized with a zero-length octet
            string.

DB-Base-4:  What's always turned on for DLUR is VTAM's sending
            of the SLU names on the ACTLUs it sends down the
            CPSVRMGR pipe.  You raise a good point, though.
            I'll add a sentence stating that in order to
            have the information necessary to build this
            table in a TN3270E server that resides in a PU
            downstream from a DLUR, the customer must insure
            that the PU/LU Network Name Forwarding function
            has been turned on in the DLUR.

DB-Base-5:  Right, I need to remove the second "not".  Keeping
            the lock as advisory is in line with other current
            standard MIBs.

DB-Base-6:  I think that "lu" was just an imprecise way of
            saying "terminal".  Looking at the objects that use
            this TC, I don't see that we need an LU value that
            applies to both terminals and printers.  So how
            about this:

                     INTEGER {
                              other(0),
                              terminal(1),
                              printer(2)
                             }

DB-Base-7:  The upper bound of 256 bytes came from your
            colleague Barry Chan.  Do you have a specific
            larger value in mind?

DB-Base-8:  Could you work with Barry to come up with some
            proposed clarifying text?  Note that we'll be
            trying to come up with a new draft of the document
            by the middle of next week, so you'll need to do
            this quickly if you want us to include your text.

DB-Base-9:  I'll clarify the text to say that the only traffic
            relevant to this timeout is user traffic.  There's
            no problem with read-create access, since it's a
            superset of read-write.

DB-Base-10 / DB-Base-11:  You've identified a confusing area
            in the MIB.  To fix this, I'll rename these two
            objects, and add a third one that's currently
            missing:

               A. How often to scan connections to see which
                  ones need TM / NOP:

                   WAS:  tn3270eSrvrConfActivityInterval
                   NEW:  tn3270eSrvrConfTmNopInterval

               B. How long a connection must have had no
                  traffic to cause the server to send TM / NOP:

                   WAS:  tn3270eSrvrConfActivityTimeout
                   NEW:  tn3270eSrvrConfTmNopInactTime

               C. For TM, how long to wait for a reply before
                  terminating the connection:

                   WAS:  <not in the MIB>
                   NEW:  tn3270eSrvrConfTmTimeout

DB-Base-12:  It's not clear to me that all the older values
             here are negotiable.  (I looked at a few of the
             older RFCs, and it wasn't obvious to me what "code"
             to assign to some of the items.)  So I'm not sure
             what values would identity them under your proposal.

             If we could eliminate all dependencies on IANA, we
             should try really hard to make your suggestion work
             here.  Since we'd still have our other ranges for
             IANA to administer, though, I'm inclined to leave
             this TC the way it is now.

DB-Base-13:  read-create access is a superset of read-write, so
             there's no problem here.

DB-Base-14:  Which one are you saying is invalid -- terminate(1)?
             Can you say more about why you think it is invalid?

DB-Base-15:  See item DB-RT-1 in the note responding to your comments
             on the RT MIB.

DB-Base-16:  RFC 2271 defines SnmpAdminString as

                  OCTET STRING (SIZE (0..255))

DB-Base-17:  It's a statement about the table.  This text was added
             to insure that a management application wouldn't be
             faced with different entries at different levels of
             refinement in the same table.

DB-Base-18:  OK, I'll add text to this effect to the description.

DB-Base-19 / DB-Base-20:  Are you suggesting we have another
             three objects (max, inUse, spare) for resources
             that are shared between terminal LUs and printer
             LUs?  And picking up on DB-Base-6, I guess I need
             to change the "lu" language to "terminal" language
             in the first three existing objects.

DB-Base-21:  OK, we can re-cast the existing object as a count
             of rejects due to resource constraints, and add a
             new object that counts rejects due to TN3270E
             negotiation errors (and other TN3270E-level
             problems).

DB-Base-22:  (This looks like a Cisco implementation discussion.)

DB-Base-23:  Our servers can't do this now, but we see no reason
             for the MIB to rule it out.  What specific textual
             changes are you looking for here?  I don't see
             anything structural in the MIB that would preclude
             this possibility.

DB-Base-24:  (This looks like a Cisco implementation discussion.)

DB-Base-25:  Say more.  Are you concerned about the case of two
             clients with the same address, or the case of one
             client with two addresses?  Note that the "address"
             for a client includes port number as well as address
             type and address.

DB-Base-26 / DB-Base-27 / DB-Base-28:  How about this list of
             states, which simplifies things by eliminating the
             "establishing" states, and removes the dependency
             you were concerned about?

  tn3270eTcpConnSnaState  OBJECT-TYPE
      SYNTAX   INTEGER {
                    unknown(0),
                    noSluSession(1),
                    sscpLuSession(2),  -- but no LU-LU session
                    luLuSession(3),    -- but no SSCP-LU session
                    sscpLuSessionAndLuLuSession(4)
                       }

      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The current state of the SNA side of the end-to-end
          TN3270 connection.  The following states are defined:

          unknown(0)          - The true state is not known.
          noSluSession(1)     - The SLU has neither an SSCP-LU
                                nor an LU-LU session active.
          sscpLuSession(2)    - The SSCP-LU session for the SLU
                                is active, but the SLU is not
                                currently in session with a PLU.
          luLuSession(3)      - The SLU is currently in session
                                with a PLU, but the SSCP-LU
                                session for the LU is not active.
          sscpLuSessionAndLuLuSession(4) - The SLU currently has
                                an active session wiht a PLU,
                                and the SSCP-LU session for the
                                SLU is active."

      ::= { tn3270eTcpConnEntry 20 }

DB-Base-29:  Which reference does this comment apply to -- [17] or
             [18]?  (Neither of these is called out anywhere in the
             text of the document.)

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

---

From: "Derek W. Bolton" <[email-masked]>
Date: Mon, 11 May 1998 10:25:56 +1000 (EST)

Bob,

>             object must be initialized with a zero-length octet

OK, but there's also the issue of the SLU name in the Bind.  I believe
that this is not necessarily the same as the SLU name in the ACTLU
(e.g. SNI?).  Should we keep both!?  I propose that the server should
take the SLU name from the Bind if and only if there was no name in
the ACTLU.  Likewise, an ACTLU with a name should replace any
previously learnt name, be it from ACTLU or Bind.

What about ACTPU?  This gets tricky.  To be consistent with the DACTLU
behavior, the entry should be deleted.  The LU session can persist, so
the information could be useful, but there is a potential for
duplicate names since, in principle, the same LU name could now turn
up on a different LU.  So I vote that DACTLU, DACTPU and ACTPU should
all delete the entry.

>             applies to both terminals and printers.  So how

That forces implementations to have separate pools for
screens and printers.  If using DDDLU and a custom exit,
it may not be necessary to separate them in this way.
I'm not saying I see a need for such an implementation,
I just can't prove that it would be nonsensical.
It costs nothing to allow a fourth value for screen-or-printer.

>             colleague Barry Chan.  Do you have a specific

I'd like Barry's comment on this, but I suspect all he was
saying was that the CIP implementation would be satisfied with 256.

Anyway, thinking about it more, I think my real problem is only being
able to trace the start of a 'message'.  I can imagine situations
where it is interesting to trace, say, all the FF sequences, wherever
they occur.  In particular, I might want to trace the fact of having
sent EOR and how many bytes preceded it.  Or the whole of a
telnet-side message, even though it is forwarded piecemeal.

(Another problem is that the current proposal does not allow a
trace that says "here's 256 bytes of data, but the whole message
was 531 bytes.)

So I could live with only one byte for the length if there were a way
of specifying an offset from the start (i.e. from end of last EOR.
E.g. I could trace:

Offset 0, 16 bytes;
Offset 529, 2 bytes (being EOR).

The offset field would need to be two bytes.  I'd still prefer
a length of two bytes.

>             this quickly if you want us to include your text.

Because of implementations that might use an SNA API, I think
it is necessary to be flexible here.  The type field could
indicate various SNA header levels.  I propose:

                     X'01' outbound telnet PDU to the client
                     X'02' inbound telnet PDU from the client
                     X'03'-X'0F' reserved (might want to use
                           these for non-e, 5250 e.g.)
                     X'11' outbound SNA data from the host, TH0 on
                     X'12' inbound SNA data to the host, TH0 on
                     X'13' outbound SNA data from the host, RH0 on
                     X'14' inbound SNA data to the host, RH0 on
                     X'15' outbound SNA data from the host, RU0 on
                     X'16' inbound SNA data to the host, RU0 on

(Note, I swapped "to" and "from" in the host cases.  The base
proposal had outbound being to the Host?!)

Alternatively, could make use of the offset concept defined above and
always measure from TH0.  If not tracing TH data then the offset would
be as though there is only one segment and it's FID2, i.e. the offset
stated is 9 + offset from RU0.

>             no problem with read-create access, since it's a

OK.

>                    NEW:  tn3270eSrvrConfTmTimeout

Excellent.

>              this TC the way it is now.

OK.

> DB-Base-13:  read-create access is a superset of read-write, so

OK.

>              Can you say more about why you think it is invalid?

I'm saying that any server which dropped the telnet connection on
seeing Unbind Pass would not sell many copies.  If it were an
optional setting then no sane customer would choose it.

>                   OCTET STRING (SIZE (0..255))

OK.

>              refinement in the same table.

I don't see why that would be such a hardship.  If several servers
are managed by one agent then that is not very important to the
app.  The agent is merely a path to the server info.  The app
should have no difficulty handling the same mix of servers under
one agent that it has to handle across agents.  Please, at least
relax it to say only that the contributions from one server must be
at the same level.

>              LUs?

No, I think that's overkill.  I'd just like to see the usage defined.

>              And picking up on DB-Base-6, I guess I need

>              anything structural in the MIB that would preclude

Well, the definition of Tn3270ResourceType says:

  Tn3270ResourceType ::= TEXTUAL-CONVENTION
      STATUS      current
      DESCRIPTION
          "The type of resource defined by a resource pool.  ...

which rather implies only one value for the pool.  Mainly, I
want to see this clearly defined, so as to avoid multiple
interpretations later.  I think there are two workable approaches.
One would be to allow a mix within one pool, the other is to
specify the type not only as part of the pool characteristics
but as part of the pool index.  That way, an implementation
allowing a mix could represent one pool as multiple pools,
one of each type.

>              for a client includes port number as well as address

I was concerned about the statement:

           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."

Maybe I misunderstand what's meant by a proxy here.
If I'm reading it right, I could have two local subnets
10.1.1.*, each coming through a proxy which makes the
addresses unique as far as TCP is concerned.  Yet I could
have two remote clients with exactly the same TCP/IP address.

This could be resolved by adding an arbitrary one byte index
(I imagine one byte should be enough.)

>       ::= { tn3270eTcpConnEntry 20 }

Fine.

>              [18]?  (Neither of these is called out anywhere in the

OK - I meant [17], which clearly should not be referenced since
response time could not be part of the base MIB.

Regards,
  Derek