Internet Area Directors: o Stev Knowles: stev@ftp.com o Claudio Topolcic: topolcic@bbn.com Area Summary reported by Stev Knowles/FTP Software and Claudio Topolcic/BBN The following BOFs and working groups met during the December IETF meeting in San Jose, California: o Multiprotocol Transport BOF (MPTRANS) o Dynamic Host Configuration Working Group (DHC) o DNS IXFR, Notification, and Dynamic Update Working Group (DNSIND) o Internet Stream Protocol V2 Working Group (ST2) o IP Over Asynchronous Transfer Mode Working Group (IPATM) o Point-to-Point Protocol Extensions Working Group (PPPEXT) o Service Location Protocol Working Group (SVRLOC) Multiprotocol Transport BOF (MPTRANS) Diane Pozefsky presented the principles of MPTN as embodied in the ANYNET family of IBM products. She explained the philosophy behind MPTN, not to use encapsulation, but to use protocol transformation at the proper level in the various stacks. She presented the challenges of MPTN: function compensation, address mapping, transport gateway, and network management. Diane presented the experiences of implementing MPTN in the cases of SNA over TCP, Sockets over SNA, Netbios over SNA, Sockets over Netbios. A key question came up, of the usefulness of MPTN to the IETF, or why was this BOF scheduled? The main answer given was that this is an opportunity for IBM to cooperate with the IETF on technology of common interest. The discussion continued and the subject of writing several Informational RFCs was brought up. This will be looked at by Sig Handelman and Diane. Also, the intersection of MPTN and SNA could solve TN3270E problems, and create a general solution for 3270, and other SNA sessions (i.e LU6.2). Finally, the idea of using MPTN as model for the IPv4 to IPv6 transition was proposed. Dynamic Host Configuration Working Group (DHC) The DHC Working Group met twice. The latest round of changes between RFC 1541 and the November Internet-Draft were discussed. They are based on the results of the Toronto bakeoff; there were changes, none significant. The issue of a new DHCP message, ``DHCPINFORM,'' was discussed as a way for DHCP clients to get local configuration information without requesting a network address. After a discussion of a server-to-server protocol, it was suggested (and, in fact, several vendors have already done this) that DHCP servers could use existing distributed database technology such as NIS or Oracle, rather than reinventing the wheel. The working group discussed the relationship between IPv6 addrconf and DHCP. By consensus, the existing semantics in DHCP can support the IPv6 address configuration model, with the possible addition of a new message, DHCPREACQUIRE, which is intended as a hint to clients that they should reacquire IP addresses. The group also discussed DHCP and dynamic DNS updates; this group will define the set of DNS updates it expects to require and pass that list to the DNS Working Group. Along with dynamic DNS update, this working group discussed authentication and security; the DHC Working Group will define its authentication and security requirements. Finally, the group discussed the server-to-server protocol, and came to the conclusion that, although some sites may choose to use external distributed databases in support of multiple DHCP servers, other sites will still want to use a DHCP-specific server-to-server protocol. The working group will expand on a conceptual proposal presented on Wednesday. DNS IXFR, Notification, and Dynamic Update Working Group (DNSIND) Thomas Brisco's Load Balancing draft is moving toward becoming an Informational RFC. There were no objections to this. The code for it may or may not be in the next BIND, but will at least be in the contrib directory. Masataka Ohta presented the Internet-Draft draft-ietf-dnsind-ixfr-00.txt. It is very different from the previous proposal in that the server maintains no state about the client. There was general agreement on the approach, but more work is needed on the draft. Security issues need review. He will have a new Internet-Draft soon with the plan for an RFC in Danvers. Susan Thomson presented the status of the Dynamic Update work. Broadening the scope of the work has raised questions about requirements that need to be supported and consequent new design issues. Requirements and issues were enumerated and explored. They are included in the DNSIND minutes. The DynUpd crew felt they had sufficient guidance to produce a new draft. They expect more input from the mailing list. There will be an interim meeting of the DNSIND Working Group in late January or early February, specifically to progress toward a new DynUpd draft. This is likely to be 8 February, just before the IPng interim, in the Bay Area. The plan is to produce an new Internet-Draft in time for a cycle at Danvers. Mark Lottor discussed problems in the COM domain. The COM domain is annoying in terms of size, trademark issues, etc. Write to mkl@nw.com if you are interested in the subject. Paul Vixie described the status of the Notify drafting work. He will publish a new draft in the next weeks, with the intent of an RFC by Danvers. It was the general consensus that the current nibble IPv6 address to name translation was the safest. Internet Stream Protocol V2 Working Group (ST2) The ST2 Working Group met twice. The majority of the time was spent on a detailed walk through of the current Internet-Draft. Some minor technical issues were reviewed and resolved. The group as a whole believes that all issues are resolved and the Internet-Draft should be completed by mid-January. Once the Internet-Draft is published as an RFC, the only work remaining for the working group will be publishing state machines for the protocol. The state machines will be published separately from the protocol specification. The state machines are scheduled to be issued as an Internet-Draft in RFC quality form prior to the Danvers meeting. The main activity in Danvers will be the review and acceptance of the state machines. The key actions resulting from the working group are to complete the Internet-Draft by mid-January and to issue the next version of state machines in January. Some minor issues are mentioned in the detailed minutes. IP Over Asynchronous Transfer Mode Working Group (IPATM) o Drew Perkins gave a report on the ATM Forum. He will send an e-mail report to the mailing list for the Kyoto meeting. o There are now about ten implementations of RFC 1577 in progress and it is possible that Digital has even passed the first interoperability test with two other vendors. o Dario Ercole gave a presentation on interpersonal multimedia communications over ATM. This was shown at Interop '94. o Grenville Armitage led a review of the IP Multicast draft. Its goals are to work within RFC 1577 context and utilize UNI 3.1 multicast services. o Discussion of the framework document was led by David Shur. The general consensus is that the group needs to close on this real soon. o Mark presented the suggested FY95 work plan. Point-to-Point Protocol Extensions Working Group (PPPEXT) The status of the issues with Motorola regarding the Compression Control Protocol are as follows. Motorola has advised Steve Coya, Executive Director of the IETF, that they plan to offer licenses on fair terms. Letters describing those terms have not yet been received by either Steve or Fred. Fred, in the absence of its author (Steve Senum), presented the updated draft of the PPP Banyan Vines Control Protocol (BVCP) (draft-ietf-pppext-vines-01.txt) and the updated draft of the PPP XNS IDP Control Protocol (XNSCP) (draft-ietf-pppext-xnscp-00.txt). The former formalizes the use of the control and data protocols specified by Assigned Numbers, and three options relating to routing protocol messages and fragmentation. The latter formalizes the use of the control and data protocols specified by Assigned Numbers, and proposes no options. The working group approved the advancement of both to Proposed Standard. Gerry Meyer presented the PPP Encryption Control Protocol (ECP). This is draft-ietf-pppext-encryption-00.txt. This protocol is modeled on the CCP, including the use of separate informational documents describing separate encryption procedures. Jeff Weiss suggested adding an encryption reset and acknowledge, for use by non-self-synchronizing encryption procedures. Jeff feels he can eliminate another potential patent problem. The Synchronous Data Compression Consortium made a presentation to the Working Group at the last IETF meeting, describing its use of PPP between DSUs. It has now largely completed its design and is about to ask TR 30.1 to recommend the use of the procedure. They produced three Internet-Drafts. Several questions were raised concerning technical aspects. The people concerned about them will contact the author and discuss them on the dsu-compress[-request]@paradyne.com list. These will be published as Informational RFCs when complete, due to their status in ANSI. In the currently widely held security model, exchange of passwords in the clear does not appear wise. Thus, PAP is no longer a recommended procedure. CHAP, however, is still believed to be acceptable for a certain class of problems. Bill will create a new Authentication Internet-Draft which does not have PAP in it. The IESG can declare RFC 1334 ``Historical,'' making PAP a historical procedure, and the new CHAP-only draft will become a Draft Standard when a consensus on the list supports that. The Kerberos and one-time passwords effort (Carrels, Blunk, and Parker) has not produced a requirements document. Two companies, however, have deployed incompatible authentication procedures of that type. Brad Parker will update the draft-ietf-pppext-gap-00.txt draft according to deployment experience, and we will publish that, probably as a Proposed Standard. Fred will contact Larry Blunk to determine whether the combined effort is still likely to occur. Service Location Protocol Working Group (SVRLOC) The Service Location Working Group met to discuss changes to the current draft (including reorganization of the protocol header, field size changes, query example and multiple addresses in the service instance), SCOPE, IPv6 and implementation experience. The changes in the current draft were described in detail. The current SCOPE mechanism was discussed and explained in detail including the relationship between foreign scope and DNS. The differences in the Internet-Draft for IPv4 and IPv6 were discussed. The main differences are in the service instance address formats. The implementation status was reviewed. Only one group is currently working on an implementation of the protocol. Implementation experience has shown that this protocol can be easily implemented on modern PC operating systems.