NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Ed Bailey <bart@vnet.ibm.com>
D. Villanueva <dericv@wrq.com>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
R. Moskowitz <rgm3@chrysler.com>
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
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 Passthruput printing, LU assignment, service location, and security.Goals and Milestones:
Request For Comments:
|
RFC |
Status |
Title |
|
RFC1576 |
I |
TN3270 Current Practices |
|
RFC1646 |
I |
TN3270 Extensions for LUname and Printer Selection |
|
RFC1647 |
PS |
TN3270 Enhancements |
Minutes of the Telnet TN3270E Enhancements (tn3270e) Working Group
Reported by: Ed Bailey
I. Summary:The tn3270e Enhancements Working Group conducted two 1-hour sessions on Wednesday 4/9/97 at 3:45 p.m. and 5:00 p.m. with approximately 20 people in attendance. Deric Villanueva (co-chair) led the sessions while Ed Bailey (co-chair) took minutes. The agenda included announcing the formal establishment of the Working Group and IETF acceptance of the charter; announcement of the next tn3270e interoperability event scheduled for May 19, 1997; discussion of the disposition of lu6.2 over TCP/IP; detailed review of scope, objectives, milestones, and commitments; and detailed discussion of deliverables. There were no objections or changes raised. Refer to the following for details.
I. Detail (first hour session)
Many thanks go to Harald Alvestrand and Keith Moore (APP Area Directors) and Bob Moskowitz (ISG) for their guidance and assistance with the proposed charter and establishing the tn3270e Enhancements Working Group. We have a definite focus and set of objectives ahead of us. The charter was posted to the listsrv on March 12, 1997.
Michael Boe (Cisco) recapped the first tn3270e interoperability event last 10/97 with seven client/server vendors. The issues identified at the event are addressed in the next rfc 1647 draft that is to be posted for review in May. Cisco will again host the next interoperability event this Spring (May 19, 1997) to afford vendors another chance to verify their rfc 1647 implementations as the draft moves to Proposed Standard this summer. A posting of the event will be made on the listsrv in the next ten days for those who wish to attend.
The BOF held at the last IETF meeting in San Jose produced a candidate list of items to consider in the charter. One such item was lu6.2 over TCP/IP. This item will not be a part of this working group at this time. Lee Rafalow (IBM) presented an option to the Working Group that recommends an Informational RFC be produced as a first step. Additional work could be chartered following the Informational RFC based upon interest and need. The Working Group accepted the recommendation. The Informational RFC would identify appropriate subset of x-open MPTN document. Should the Informational RFC be submitted for a standard track, change control would have to be given to the IETF, the Working Group chairs will review the document and decide if it should be placed on a standard track.
The commitments made by the Working Group members for editing the new documents was re-confirmed.
III. Detail (second hour session)
The second Working Group session was focused on identifying the set of enhancements for tn3270e and tn5250 to be addressed by this work group. The following is a list of candidates suggested at the session. These items will be discussed on the listsrv and prioritized. tn3270e enhancements suggested are:
· Security
tn5250 enhancements suggested are items in rfc 1647 plus:
For rfc 1647, Bob suggested adding a statement on security risk Moskowitz (Chrysler).
Roger Fajman (NIH) noted that TN device type must be registered in the IANA.
Daniel McIntyre (Boeing) clarified the need for sequence numbers between the client and server.
It was mentioned that if you prefer a different wording in the draft on a topic, then providing alternative wording is appreciated.
Bob Moore (IBM) presented information on measuring response time used by previous methods in SNA/ms and NPM. Bob will look at the new RTFM RFC to see if there is some way to use it for response time measuring purposes.
Bob Moskowitz (Chrysler) highlighted the security options as follows:
Encryption is broken in kerberos, it is not a choice. SSL is moving to TLS - has problems with firewalls. SSH is new but addresses the issues most like TN. SASL lacks encryption and has no following as yet. IPSEC is long term but requires kernel changes. The priority is SSH, SSL, and IPSEC, respectively.
There was discussion on the next IETF meeting in Munich and if there will be any sessions. Also interim meetings was discussed as an option.