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

From: Robert Moore <[email-masked]>
Date: Fri, 15 May 1998 09:28:43 -0400

Hi Derek,

I was going to post a note today detailing which of your comments
we hadn't addressed fully (and why), but you were too quick for me.
See my responses below.

Regards,
Bob

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

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.

@REM:  Since it looks like I will be issuing another draft, I have
no problem changing this object to tn3270eSrvrConfConnectivityChk.

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

@REM:  Some of us discussed this point here, and we reached the
opposite conclusion.  As long as an LU-LU session is up, it's
possible that somebody will be interested in management information
related to it.  So the tn3270eSnaMapEntry that ties this information
to the name by which the SLU is known in the SNA network should stay
around.  In your original comment you also raised the question of
whether an SSCP-supplied SLU name might be re-used for a different
SLU, leading to a collision in this table.  Nobody checked the code,
but the gut feel around here was that NCP (or the DLUR) wouldn't
allow an ACTLU that was trying to associate a previously known SLU
name with a new SLU.

  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.

@REM:  OK, I can add a sentence saying that this is implementation-
dependent.  Seems like we should try for as much commonality as we
can, though, so for implementations that can start wherever they're
told to, how about a SHOULD to specify a recommended starting place?
Where would you think this recommended starting place should be?

  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?

@REM:  We think we addressed this case, but in an indirect sort
of way.  I moved the Tn3270eAddrType TC from the MIB module into
the IANA module (in the process it acquired an "IANA" prefix),
so that new address types could be added later.  When we address
the proxy case in the future (recall that we said it was out of
scope for this iteration of the MIB), we can add some new
address types, say proxiedIpv4(3) and proxiedIpv6(4).  The
definitions for these new address types would say that they're
just like ipv4 and ipv6 addresses, except there's one more byte
to resolve the address collisions you're talking about.  Then
the existing table, with its existing indexing, will support
different entries for the two proxied clients.  To summarize,
we agree that this case can happen, and we've set up the MIB in
such a way that we'll be able to address it in the future.

Regards,
  Derek
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I'd like to get an updated draft out today if possible, and by
Monday at the latest.  To do this I need a recommended starting
point for the SNA trace data.  The question of when to delete
SnaMapTable entries is still an open one, and I'm not sure how
we're going to resolve it.  My preference would be to leave the
definition as it is in the new draft, and then discuss this issue
on the mailing list and/or at the TIE.

Regards,
Bob

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

---

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

Hi Bob,

> no problem changing this object to tn3270eSrvrConfConnectivityChk.

@DB2:
OK - thanks.

> around.

@DB2:
Yes, I appreciate the desire to keep it.

> In your original comment you also raised the question of

@DB2: Although it is pathological, it's easy to create that scenario.
Suppose I issue V INACT,TYPE=G, and the Host that takes over the PU
has different LU names.  Or suppose it's DLUS, the config of the PU is
changed (but the MN not recycled yet), then the DLUS VTAM falls over.
In each of these cases, the PU will see a DACTPU Giveback, then ACTPU.
(There may also be ways in which the first thing the PU would see is
ACTPU, but I'm unsure how to create that.)

In each case, there is no basis for either NCP or DLUR rejecting the
ACTLU.  As far as they are concerned, the new ACTPU has cleared all
SSCP-LU sessions.

But as I admit, it's pathological.  How about a compromise:
- a warning in the text to say that such sequences are possible, and
- the entry is allowed to stay in the table as long as it is
  unique

> Where would you think this recommended starting place should be?

@DB2:  OK... TH0.

> such a way that we'll be able to address it in the future.

@DB2:
Great!

Thanks,
  Derek