Subject: Re: MIB & Associated pairs

From: "Greg Rickard" <[email-masked]>
Date: Fri, 26 Jun 1998 16:35:37 -0500

On 6/25/98, at 3:29 PM, Michael Boe wrote:

>Not to rain on anybody's future server designs :-), but a-priori knowledge by
>the server of the association is not necessary.  Consider the possible server
>design where the TN Server has a side-channel to the host whereby the
>association is done when the printer is requested: the TN Server queries the MF
>as to what what the association is, and then picks the device. The only
>a-priori knowledge the server must have here is that a certain group of LUs
>must be eligible for association.  This is can be considered "late-binding."
>Indeed, it might be very late-binding at the MF itself:  the association might
>not be made until after the security/authorization checks have been passed and
>appropriate information retrieved from the MF or MF-application authorization
>database.
>
>Not quite so late a binding, but still so late as to be unusable by "static
>configuration" scanners is where the association is known only from the time
>the first screen in the associated group is allocated to the time where the the
>last screen in the group is deallocated by a particular TN3270E client.
>
>That's a "host-hugger" server example.  It's pretty easy to imagine
>branch-office servers using network-directory-access methods such as
>NT/lan-manager/NetWare/NIS+ to do the same thing. MS SNA Server, for instance,
>already does this.

I don't find that SNA Server 4.0 does.  It does, however, allow static association.  It would be easy to extrapolate these methods to where there is no need for static device configuration at all.
Would these methods work in reverse?  We discussed at the 11/97 TIE allowing the ASSOCIATE before the CONNECT....

>But that's not to say that such a table shouldn't exist in the MIB as an
>optional table indicating some a-priori configuration for those servers that
>use such. Nor is it arguing against adding row-elements to connections that
>"point" to the associated printer connections during the lifetime of the
>associated printer connection.
>
>Comments from the wider community, please.

Yes, please.

>>
>> Abbreviated from a 2355 example:
>>
>>    Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 CONNECT
>>                    termxyz IAC SE
>>    Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
>>                    termxyz IAC SE
>>
>>    Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1
>>                    ASSOCIATE termxyz IAC SE
>>    Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
>>                    termxyz's-prt IAC SE
>>
>> The only way the server knows to fill the "ASSOCIATE termxyz" request with
>> device "termxyz's-prt" is an association between "termxyz" and
>"termsxyz's-prt" established before the connect.  "There should be a unique,
>one-to-one mapping between a terminal and its associated printer."  I don't
>think anyone proposes that the "'s-prt" extension on the device-name is the
>magic that associates these two devices.
>>
>> Likewise for the generic/specific indicator.  The server must know if a
>> device is eligible for a generic attach request:
>>
>>    If a TN3270E server wishes to support traditional tn3270 clients, it
>>    must maintain a set of terminal device-names that can be used to
>>    satisfy requests from such clients for terminal sessions.  This same
>>    pool could be used to satisfy generic requests for terminal sessions
>>    from TN3270E clients.
>>
>> Once again, I don't think that the format or keywords contained in the
>> device-name or pool name of the device is strong indication that any given
>device is generic or specific.
>
>Yes, that's true. It's certainly an area that was skipped over. But why is
>that?  Either nobody cared, or it was (silently) put in the too-hard basket. I
>think probably the latter. Why? Again, authorization issues make it difficult
>to see how such an indicator could be useful.  An LU might be eligible to fill
>a "generic" request from a client, but the pool of clients allowed such a
>privilege might be very restricted. So what would such a "generic-eligibility"
>indicator mean?

It means a "nameless" pool and not having to configure resource names at each client.  Authorization can be handled in some way independent of resource-name, such as IP address restriction.  Resource-name can't really be considered "strong" authorization, anyway.  A client that assumes reasonable defaults and uses SLP to find its server would require no configuration to connect a terminal session.

>I don't think that's quite good enough, but perhaps there's a
>set of descriptors that can (a) meaningfully describe how an LU can be
>allocated, (b) isn't overlapping in definition, and (c) is known prior to
>client connect time.
>
>Here's a stab at it:  two independent sets of descriptors indicate the methods
>by which an LU may be allocated. The first set is a single bit:
>
>Allocation Authorization Type:
>   [auth-further]:     LU may only be allocated by clients authorized beyond
>the authorization normally required.  If this bit is set to zero, then the LU
>can be allocated by any client authorized to request any device of this LUs
>allocation-type (see below).
>
>Allocation Type:
>   [generic-eligible]  LU may be allocated by the server to fulfill a generic
>LU request.
>
>   [specific]          LU may only be allocated via a REQUEST DEVICE-NAME or
>ASSOCIATE subnegotiation by the client.
>
>   [associate]         LU may only be allocated via an ASSOCIATE subnegotiation
>by the client.
>
>
>Is this simple enough? Does it completely (and usefully!) describe how an LU
>can be allocated?  And is do servers know this information well before a client
>has actually attempted to connect to the LU in question?
>
>[...snip]
>
>/msb

Why the [auth-further]?  All clients are subject to whatever authorization mechanisms are in place at the server.  The "generic" flag just allows 2355's resource-name mechanism to be optional for that device.
I see the need for the [associate] type in a "dynamic association" environment; it would return meaning to the CONN-PARTNER rejection reason.

>>
>> Greg Rickard
>>
>>
>> *********** REPLY PARTITION ***********
>>
>> On 6/25/98, at 10:58 AM, Michael Boe wrote:
>>
>> >I've not had time to look at any of the "hard" mail yet; have been out of
>> >town. I'll look soon. In the meantime, can you make a case for why
>> >distinguishing generic & specific devices in the MIB is useful?  Ditto for
>> >terminal-printer pairs.  In making this case, understand that the server
>> >need not store or be cognizant of such associations before client
>> >connect-time.
>> >/msb
>> >
>> >On 25-Jun-98 at 13:34, Greg Rickard ([email-masked]) wrote:
>> >> The TN3270E-MIB does not allow associated terminal-printer pairs or
>> >> differentiate between generic and specific devices.  Both concepts are
>> >discussed in section 7.1.1 of RFC 2355.
>> >>
>> >> We brought these deficiencies to the attention of the group on Monday,
>> >> 22 June, but have not gotten any response.  While I understand the
>> >> reluctance to
>> >modify the draft during its final call, ignoring these shortcomings will
>> >not make them go away.
>> >>
>> >> We came across these problems implementing the MIB on our server, which
>> >> has always supported associated printing.  If not addressed, they will
>> >> prevent
>> >the MIB from being fully capable of managing a TN3270E server.
>> >>
>> >> Greg Rickard
>> >> Director of Product Development
>> >> Data Interface Systems Corporation
>> >> (512) 335-8200
>> >
>> >
>

Greg Rickard
Director of Product Development
Data Interface Systems Corporation
(512) 335-8200

---

From: Michael Boe <[email-masked]>
Date: Fri, 26 Jun 1998 19:58:50 -0700 (PDT)

> >that?  Either nobody cared, or it was (silently) put in the too-hard
> >basket. I think probably the latter. Why? Again, authorization issues
> >make it difficult to see how such an indicator could be useful.  An LU
> >might be eligible to fill a "generic" request from a client, but the pool
> >of clients allowed such a privilege might be very restricted. So what would
> >such a "generic-eligibility" indicator mean?
>
> It means a "nameless" pool and not having to configure resource names at
> each client.  Authorization can be handled in some way independent of
> resource-name, such as IP address restriction.  Resource-name can't really be

> considered "strong" authorization, anyway.  A client that assumes reasonable
> defaults and uses SLP to find its server would require no configuration to
> connect a terminal session.
>
> >Here's a stab at it:  two independent sets of descriptors indicate the
> >methods by which an LU may be allocated. The first set is a single bit:
> >
> >the authorization normally required.  If this bit is set to zero, then the
> >LU can be allocated by any client authorized to request any device of
> >this LUs allocation-type (see below).
> >
> >Allocation Type:
> >Is this simple enough? Does it completely (and usefully!) describe how an
> >LU can be allocated?  And is do servers know this information well before
> >a client has actually attempted to connect to the LU in question?
> >
> >[...snip]
> >
> >/msb
>
> Why the [auth-further]?  All clients are subject to whatever authorization
> mechanisms are in place at the server.  The "generic" flag just allows 2355's

> resource-name mechanism to be optional for that device. I see the need for
> the [associate] type in a "dynamic association" environment; it would return
> meaning to the CONN-PARTNER rejection reason.

Are you thinking of this as a writable flag? Or just read-only?

If read-only, then I have trouble seeing how [auth-further] wouldn't be useful
(or alternately, how the other flags are much use without [auth-further]).
Suppose that only a single user "Fred" is authorized for a particular LU. In
that case, having "generic-eligible" doesn't really mean much since only Fred
can use it (generically or in any other way).  An SNMP NMS program, counting
how many "generic" LUs are available for use at different times of the day,
would count this LU even though only Fred can really use it.

And I have about these bits being writable quantities.  In the case of Cisco's
TN3270 Server, the "generic" nature of an LU is determined at PU activation
time: LUs statically defined by the SWMN are consider ineligible for generic
consumption; all others are (unless the PU was not DDDLU capable, in which case
none are).  This is complicated/modified by other authorization features:
IP-address nailing may make it possible for certain clients request an LU
"generically," but nobody else can even access the LU (and can make
statically-defined LUs eligible for those nailed client-IP-addresses). The list
goes on, with the actual "generic-eligibility" being determined by a confluence
of factors that are server-side only and way beyond the scope of SNMP. I'm
pretty sure that the other vendors have similarly complex methods of
determining the allocation of LUs.  Comments, anyone?

/msb