NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Oct-97
Chair(s):
Ed Bailey <bart@vnet.raleigh.ibm.com>
Michael Boe <mboe@cisco.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Keith Moore <moore@cs.utk.edu>
Technical Advisor(s):
Robert Moskowitz <rgm3@chrysler.com>
Mailing Lists:
General Discussion:tn3270e@list.nih.gov
To Subscribe: listserv@list.nih.gov
In Body: sub tn3270e <first_name> <last_name
Archive: listserv@list.nih.gov
Description of Working Group:
Present specifications for access to 3270 and 5250 based applications over TCP/IP require improvement to become more commercially viable. Security, Service Location, Response Time, and Session Balancing are improvement examples.
The WG will drive to update and extend the standards specifications proposed in rfc1647 and rfc1205 so that they fully support 3270 and 5250 style access to host (S/390 and AS/400) applications respectively in today's environments.
Consideration will be given to work already in progress on protocols for accessing 3270 and 5250 based applications over TCP/IP.
Three protocol documents will be produced.
Deliverables
1. A revised version of rfc1647 (tn3270e) including clarifications of the protocol, and security considerations. The revised rfc1647 will be submitted to the IESG for advancement of the tn3270e protocol to draft standard status. Currently it is a proposed standard.
2. A new standards track document defining options for the tn3270e protocol. Such options are: IPDS printing, response time monitoring, error reporting, session balancing, service location, and security.
3. A new standards track document defining enhancements to the tn5250 protocol. This new protocol will be called tn5250e. This is not Display Station Passthrubut printing, LU assignment, service location, and security.
Goals and Milestones:
Apr 97 |
|
Discuss scope of initial tn5250ec enhancements at IETF session. |
Apr 97 |
|
Goal 2 tn3270e new options Propose a list of initial enhancements on listsrv for review. |
Apr 97 |
|
Goal 1 revised tn3270e (rfc1647) Conduct interoperability testing. |
Apr 97 |
|
Discuss scope of initial tn3270e enhancements at IETF session. |
Apr 97 |
|
Propose a list of initial TN5250e enhancements on listsrv for review. |
May 97 |
|
Goal 1 revised tn3270e (rfc1647) Publish Internet-Draft and issue Working Group Last Call. |
Jun 97 |
|
Goal 1 revised tn3270e (rfc1647) Incorporate any revisions and publish Internet-Draft. |
Jun 97 |
|
Goal 1 revised tn3270e (rfc1647) Submit to IESG for consideration for Proposed Standard. |
Aug 97 |
|
Goal 3 tn5250e Resolve issues with initial enhancements using the listsrv. |
Aug 97 |
|
Goal 2 tn3270e new options Resolve issues with initial enhancements using the listsrv. |
Sep 97 |
|
Goal 2 tn3270e new options Issue initial draft of new proposed rfc to listsrv for review. |
Sep 97 |
|
Goal 3 tn5250e Issue initial draft of new proposed rfc to listsrv for review. |
Nov 97 |
|
Goal 3 tn5250e Incorporate comments and publish proposed rfc for implementation. |
Nov 97 |
|
Goal 2 tn3270e new options Incorporate comments and publish proposed rfc for implementation. |
Apr 98 |
|
Goal 2 tn3270e new options Conduct initial interoperability testing. |
Apr 98 |
|
Goal 3 tn5250e Conduct initial interoperability testing. |
Jun 98 |
|
Goal 2 tn3270e new options Gather operational experience from implementers. |
Jun 98 |
|
Goal 3 tn5250e Gather operational experience from implementers. |
Aug 98 |
|
Goal 3 tn5250e Publish Internet-Draft and issue Working Group Last Call. |
Aug 98 |
|
Goal 2 tn3270e new options Publish Internet-Draft and issue Working Group Last Call. |
Oct 98 |
|
Goal 3 tn5250e Submit to IESG for consideration for Proposed Standard. |
Oct 98 |
|
Goal 2 tn3270e new options Submit to IESG for consideration for Proposed Standard. |
Oct 98 |
|
Goal 3 tn5250e Incorporate any revisions and publish Internet-Draft. |
Oct 98 |
|
Goal 2 tn3270e new options Incorporate any revisions and publish Internet-Draft. |
Internet-Drafts:
· TN3270 Enhancements
· Base Definitions of Managed Objects for TN3270E Using SMIv2
· Definitions of Managed Objects for TN3270E Response Time Collection Using SMIv2
Request For Comments:
RFC |
Status |
Title |
RFC1576 |
TN3270 Current Practices | |
RFC1646 |
TN3270 Extensions for LUname and Printer Selection | |
RFC1647 |
PS |
TN3270 Enhancements |
Minutes of the Telnet TN3270 Enhancements (TN3270) WG
Reported by Michael Boe <mboe@cisco.com>
I. Introduction/Old Business
· Ed: RFC1647 status: IESG needs statement of interoperability, then we can move it to Draft Standard status.
· LU6.2: IBM committed to provide LU6.2 Informational RFC...they will be posting this by the end of the week. Reckons that this will be "minimal" spec to allow LU6.2 flow.
II. MIBS (Configuration MIB [was "base" MIB])
· Bob: reviewed by Randy Presuhn. Comments were:
- several tables support remote configuration; a way of doing multiple-server updates (i.e., test-and-update object).
- the indexing problem: different order, we use enum/binary objects instead of full OIDs or transport-domains.
· Updated drafts out by beginning of January to be submitted to IESG by end of January.
· Changed anchor points of the MIB to snanauMIB {8,9}.
· Added tn370eSnaMapPrimaryLuNameobject.
· Added various TCP connection objects, including a ClientId. The nature of ClientId needs some words around.
· Input needed on ClientId enum types in the MIB.
· Need to make MIB IANA-registration compliant for the ClientID enum types.
· Changed Miscellaneous category to be in own class (ProxyClient). The ProxyClient narrative description also needs some words to properly describe.
III. MIB (Response-Time MIB)
· "Responses" or "timing-mark" (TN3270-compatible).
IV. BID/keyboard-restore issue (Roger Erickson):
· Explains both the BID and keyboard-restore problem
· Add FUNCTION: Contention Resolution (0x5)
· TN3270E header has a byte that is only used for printer error recovery so proposal is to use that byte for different purposes for screen sessions. call this SDI.
· The keyboard-restore problem never occurs on printers.
· On BID: use the RESPONSES mechanism to carry info.
V. Byte-doubling and Flush (Thomas Butts from OCS)
· Add a TN3270E FUNCTION to suppress byte-doubling.
· Add a new TN3270E FUNCTION to flush datastream at truncated.
· Issue over whether or not to use TELNET BREAK key.
VI. FMH and Sense Codes
· Support IPDS and fancy print jobs
· Transport SNA Sense codes between Client and Server.
· Open issue: OIA codes overlap with SNA sense codes. Do we need both?
VII. Security
· RFC1416 Authenticate parms could be used; or a SASL profile could be proposed. Chris Newman volunteers to address the SASL issue. Inline Negotiation appears to be the only way to go. Bob Moskovitz claims that IANA/IESG will not allow a standard to move forward that causes port-explosion. Others agree. Chris Newman references the URL schema problem (e.g., telnet, telnets, tn3270, tn3270s).
· The question was raised: why not use TLS authentication instead of encryption? After much discussion (some of which is broken out separately below), consensus was reached that TLS of itself does not provide all the authentication mechanisms that customers will want to use. Specifically:
- The WG should examine the possibility of defining a SASL profile for Telnet.
- Corporate security infrastructures are myriad in variety and infrastructure reform is slow. Examples given were Kerberos V4, Kerberos V5 (and NT 5.0), NT domain, RACF login/acct/password, etc. o Some of the authentication mechanisms are able to be used with TLS; others are not. Kerberos V5 is an example of authentication that can be built into TLS; straight RACF login/acct/password cannot be built into TLS.
- Some authentication mechanisms are inherently "weak." However, they are useful (RACF springs to mind). WG will angle to allow these weak authentication mechanisms to be used by ONLY allowing them to be used after strong encryption (128-bit) is already protecting the session.
· Ari Medvinsky from CyberSafe talked about the I-D that is being moved to proposed standard that allows KRB5 to be used as a TLS authentication mechanism. Proposed that KRB5 be one of the mandated Position with GSS-API and manageability, for the reasons given below:
- performance
- Microsoft support in NT5.0
· Various points were made apropos different authentication mechanisms: different mechanism require different infrastructures. For example, Kerberos requires a KDC.
· GSSAPI was brought up as a method of doing security instead of TLS. It was explained that the WG chose TLS because of widespread deployment and understanding of its close ancestor, SSL. Also, the WG needed deployable solutions that work with firewalls (printers were brought up as an example of things that need good proxy and firewall support).
VIII. Service Location
Three proposals were discussed. Some highlights of the operation, strengths and weaknesses of each approach were mentioned:
SRVLOC protocol:
Pros:
- improved interoperability among servers
Cons:
- lack of deployment experience;
- uses multicast (not well deployed right now, and could be problematic for extranet use);
- the SCOPE mechanism doesn't scale (and has recently been changed). The SCOPE mechanism needs to be re-examined.
Dynamic DNS: works by making server attributes into DNS names.
Pros:
- Well known and deployed distribution architecture;
- Improved interoperability among servers
Cons:
- May be a political hot potato. Abuse of the intent of DNS?
- Limit of 255 octets per name.
HTTP Redirection: works by querying an HTTP server to find out which server to go to.
Pros:
- Simple to understand and deploy "in the small."
Cons:
- Requires a whole new HTTP connection before the TN3270 connection can begin.
- Backend protocol among servers and HTTP servers would need definition.
IX. Various points made during service location discussion
· LDAP looks pretty similar (a superset?) in power to SRVLOC. Have we investigated using straight LDAP to do this?
· Are other groups working on similar HTTP redirection mechanism? [answer is: "not to our knowledge."]
X. TN5250 Standardization Progress
· First draft expected late January.
None Received