INTERNET AREA Directors: o Sue Thomson, Bellcore o Frank Kastenholz, FTP Software, Inc. Area Summary reported by Sue Thomson, Bellcore, and Frank Kastenholz, FTP Software, Inc. MSGWAY The Working Group reviewed the current status of the MessageWay End-to-End (EEP) and Router-to-Router (RRP) protocols. During the EEP discussion, endian-ness was discussed in more detail. The result was adding an additional bit to the endian-ness specification to cover more possibilities. Other issues relating to scaling, particularly with respect to how to address large numbers of processors in SANs, were brought up. It was felt that the scaling discussion should be continued on the Working Group's mailing list. API issues, including the MPI, were discussed. While the IETF traditionally does not specify APIs, it was felt that specifying one in an informational RFC or appendix would be useful. DNSIND The status of the three documents specifying incremental zone transfer, notification and dynamic updates are as follows: o IXFR draft is ready for submission to Proposed Standard status except the author has been asked to consider one optimization; o NOTIFY draft has removed auto-discovery of "stealth" servers; a default mechanism for finding such servers has been proposed; and, o DYNUPD has removed dependence on SIG RRs and the ability to update them for guaranteeing ordering. Some suggestions were made during the Working Group meeting to clarify the document. There will be an issue of multiple implementations, as BIND is the only generally available server. There could be multiple implementations of the features, but this is not assured. IPATM The Working Group discussed several Internet-Drafts and other topics, some jointly with the ROLC Working Group. The subjects discussed included multicast address resolution draft (MARS), the update to classic IP over ATM (classic2), IPv6 over ATM, RSVP over ATM, transition issues between classic2, and NHRP and auto configuration. The packet formats for ROLC's NHRP and IPATM's MARS have been harmonized. Based on ROLC's consensus, all NHRP references in the RFC1577 "classic2" update internet-draft have been removed. It was felt this simplified things. ROLC and IPATM will liaison to the ATM Forum. The liaison will include two sections, one suggesting leveraging the LANE configuration server for IETF uses, the second asking for LAN Emulation Configuration Server redundancy. MIB work is in progress and will be based on the RFC1577 "classic2" update. Classic2 will be delayed until IPATM resolves ATMARP server synchronization approaches, issues, and suggested evolution to authenticated registration. It is noted that this work might be usable by ROLC. This was the first meeting that included IPv6 over ATM discussions. The two presentations made on this topic did not receive sufficient time but did begin to acquaint the Working Group with the IPv6 topic area. A presentation was made on RSVP over IP over ATM and an informational discussion item. Greater attention will be given to this topic via a proposed joint IPATM, Integrated-Services, and RSVP session at the next IETF meeting. In addition to the working group meetings, the Routing and Internet Area Directors and the ROLC and IPATM chairs met to discuss the relationship between NHRP and ATMARP. The result is: o Servers will do either just ATMARP or both ATMARP and NHRP. Since the basic ATMARP technology is a subset of NHRP, we believe that this will place minimal burden on server implementations (this decision may be revisited). o Nodes need only support ATMARP or NHRP. They are not required to support both. o A common technology for security and server-synchronization is desired so every effort will be made to develop one on which both ATMARP and NHRP can converge. Service Location The Working Group made a commitment to have an Internet-Draft available for Last Call by the end of the year. This document will contain clarification and descriptions of the following items that were discussed in the Working Group meeting: o Naming authority; o scope semantics; o a beefed up security section detailing some of the holes; and, o clarification of Address Family and use within the URL semantics. The Group will also draft a template document for the specification of service location schemes. This template should be used as a mechanism to make the authoring of scheme descriptions better defined. The Working Group started on the definition of several schemes, namely the "mailbox" and "mail_relay," in order to evaluate the effort for this task. The Working Group concluded that it is important for relevant experts who are needed for definition of schemes. In addition, a long-term scheme is needed for reviewing and approving proposed schemes. DHC The DHC Working Group discussed both DHCPv4 and DHCPv6. In the DHCPv6 discussion, Jim Bound discussed a list of about 20 issues which were compiled jointly with the Working Group. The issues are described in the minutes; some were resolved in the Working Group meeting and most were deferred to the dhcp-v6@bucknell.edu mailing list. The DHCPv4 discussion covered DHCP and dynamic DNS updates, a status report (and other miscellanea), graceful renumbering, and security/authentication. Yakov Rekhter's dynamic DNS update model was well-received. The model assigns an owner to an RR; it is the owner that completes updates. DHCP must provide support for negotiating whether the server or the client is to do the update. Ralph Droms talked about the state of the spec and options docs (the spec has been submitted to the IESG for consideration as a Draft Standard and the options document is due to be), and asked if the BOOTP clarifications and interoperability docs should also be moved along the standards track (they will be). The Working Group heard about a proposal for a new option to accommodate fully-qualified domain names in options, and the Working Group will review Charlie Perkins' mobile IP options I-D. Lowell Gilbert presented a mechanism for graceful renumbering that uses address deprecation and invalidation to support transition between addresses; he will write the proposal up in an I-D. Finally, Ralph Droms talked about mutual authentication of DHCP clients and servers. He will write up some alternatives discussed in the Working Group (along with another proposal developed by Christian Huitema and Jeff Schiller in a terminal room BOF) and put them on the mailing list. ST2 The Working Group spent most of the time discussing the document on finite state machines. This specification still requires substantial editing for clarity and some minor technical corrections. The Group reviewed its status, and concluded that the Group will close before the next IETF following the completion of the finite state machines draft which is planned to be completed in February 1996. Brief reports were given on an ST2+ implementation at George Mason University and work on ST2 over ATM at NTT. PPP The Area Director updated the Working Group on the status of the CCP and ECP documents and the Variance request for advancing these two protocols to Proposed Standard Status. The Working Group discussed some updates to be made to the IPCP draft with respect to some ambiguities in IP Address Negotiation. CHAP and LQM were also discussed. The Group is seeking interoperable implementations of these two protocols prior to requesting draft standard status. A presentation on Bay Networks Compression Protocol (WCP) was made. WCP is a lightweight reliable compression protocol. The issue at hand was the perceived heaviness of LAPB. A lunch meeting was held to clear up the issues surrounding PPP/FR and Dataencaps. This meeting was attended by Keith Sklower, Keith Mader, Bill Simpson, Joel Halpern, Andy Malis, Fred Baker, and Frank Kastenholz. It was decided that PPP/FR should advance with all due haste to Proposed Standard, and that Joel and Keith Mader would discuss the possible need for Data Encapsulation, and would be free to publish it as an Experimental RFC if they so choose. Clarifying updates to the Multilink proposal was discussed. Final details were directed to the mailing list. There was a general consensus that proposals made to incorporate features from Ascend MP+ should not hold up revision and republishing of Multilink Specification. These features will become additional protocols. Many issues surrounding EAP Authentication were discussed.