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 BOF and working groups met during the April IETF meeting in Danvers, Massachusetts: o MessageWay BOF (MSGWAY) 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 IPv6 MIB Working Group (IPV6MIB) o Point-to-Point Protocol Extensions Working Group (PPPEXT) MessageWay BOF (MSGWAY) This BOF session introduced the need for processors in separate, possibly non-homogeneous MPPs (Massively Parallel Processing systems) to communicate with each other. It was felt that IP provides more scalability and generality than necessary, and does not provide the high performance that this application requires. The MsgWay approach is to define a Level-3 protocol that is similar in its philosophy to IP, but has implementation details geared toward high-performance, possibly at some cost of generality and wide area scalability. Danny Cohen, the BOF chair, presented the proposed architecture. The following topics were discussed: o Why should MsgWay be an IETF activity? It is proposed to conduct the MsgWay activity as an IETF working group because of the firm belief that interoperability should be handled at Level 3 (not just at Levels 1 and 2), and because of the recognition that MPP networks are computer communication networks with much in common with the networks that the IETF community is dealing with. o Technical discussion and clarifications. Including similarity to IP, transport level reliability, source routing, MTU, interconnection of separate MsgWay islands. The purpose of the BOF was to evaluate appropriateness of the proposed work to the IETF and to determine community interest in creating a working group. Danny reported that in addition to those who participated in this BOF, there are about 20 other people from academia, government, and industry who expressed interest in participating in defining MsgWay, most of them had participated in two earlier meetings discussing MsgWay. Danny will work with Frank Kastenholz, an incoming Internet Area co-Director, on a draft charter for the working group, and will post it on the MsgWay mailing list. The MsgWay Working Group is expected to conduct its work over e-mail, to meet at IETF meetings, and to possibly have additional meetings between IETF meetings. It is expected to have a rough draft of the minimal MsgWay protocol by the next IETF meeting, in mid-July. Dynamic Host Configuration Working Group (DHC) Topics that were discussed included the following: o DHC in the Mobile IP environment. o DHCPREVALIDATE, which will be deleted; and DHCPINFORM, which was thought to be a good idea. o DHCPv6 for IPv6. Further discussion was deferred to the mailing list. o Reliable operation of replicated DHCP servers. A new mailing list will be created. o Client and server authentication. A three-way private key exchange was favored. Further discussion will take place on the host-conf mailing list. o ``Freely available'' DHCP implementations. There is one from WIDE, and there may be another soon. DNS IXFR, Notification, and Dynamic Update Working Group (DNSIND) Although it was hoped that this would be the last meeting of this group, it is now planned that the last meeting will be at the next IETF, particularly since this group may need to take on more DNS issues (with a corresponding update of the charter). Other topics that were discussed included: o IXFR operation and formats. Formats will be worked on, and delay going to RFC until implementation. o Proposal to split prefixes from host identifiers in Internet address records. o DNS Notify. o IPv6 address-to-name mapping. o Dynamic update. Many issues were discussed. Internet Stream Protocol V2 Working Group (ST2) Since the Protocol Specifications have been submitted as an RFC, the primary objective of the meeting was to review and discuss the draft of the State Machine document as well as to determine the future direction of the group. The group had already agreed to submit the ST protocol specification for publications as, per the charter, an Experimental RFC. Publication is awaiting IESG action. The State Machine draft is in progress with a targeted completion of June. If the State Machine draft is indeed completed in this time frame, the working group may not meet in Stockholm. The group discussed the State Machine draft, specifically: o When can data be transmitted? o The `E' bit in REFUSE messages must be added to all state diagrams. o Diagrams will be updated to show Local Resource Management interfaces on processing these messages. o Time out handling will be added in the next draft. o State machines for failure processing needs to be added. o A mechanism is needed to add API interfaces to state machines. o The handling of JOIN/JOIN REFUSE and upstream-oriented messages must be revisited. o The interfaces between origin and target sides of the router state machines must be specified in more detail. IP Over Asynchronous Transfer Mode Working Group (IPATM) The Routing Over Large Clouds (ROLC) and IPATM Working Groups met in a joint session on 3 April. The following three major topics were discussed: o IP architecture extensions for ATM. Yakov Rekhter presented draft-rekhter-ip-atm-architecture-00.txt, which discusses IP architecture extensions for ATM. The working group concluded that the current ROLC work meets some of Yakov's needs, and the future work in the IPATM Working Group should address the issues, in coordination with INTSERV and RSVP. o RFC 1577 client behavioral changes and NHRP and ATMARP interactions. Including single server issues with regard to fault tolerance and support for alternative services. o ATM Forum announcement. Relaxed document distribution policy to allow easier access to ATM Forum documents. There will be a BOF at the next IETF to discuss how to foster better interactions between the IETF and the ATM Forum. IPv6 MIB Working Group (IPV6MIB) This is a newly created working group. This group had met as a BOF at the San Jose IETF meeting, and this represented its first meeting as a working group. The working group's charter falls into three broad categories: o Identify changes, if any, to existing standards track SNMPv2 document. o Potential changes to existing MIBs. o New and additional MIBs that are specific to the IP: Next Generation Protocol. The IPv6 MIB Working Group is initially chartered to identify specific areas of work and their corresponding work items, within each of the abovementioned categories. The following topics were discussed: o Working group charter. There was general agreement on the scope of work. Since most of the working groups with which IPv6 MIB was planning to coordinate are planning to shut down, the incoming Area Directors for the Internet and Network Management Areas and the IPV6MIB Working Group Chair agreed to (re)explore appropriate Areas where IPv6-related management oriented work may be conducted. o General overview of the required effort. Including, SNMP impact, SNMPv2 status, technical direction, changes to existing MIBs, new MIBs, and current work. o Changes not required. No changes were proposed to SNMPv2 SMI. No additional SNMP Protocol support (`extensions') are needed to manage IPv6 via IPv4 Managers. No changes would be required to the standards-track SNMPv2 documents. o Textual Conventions, Transport Mappings, and organization of existing MIBs. No definitive result or outcome. Follow-on discussions will continue on the mailing list. Point-to-Point Protocol Extensions Working Group (PPPEXT) The following topics were discussed: o Encryption Control Protocol (draft-ietf-pppext-encryption-03.txt) was returned by the IESG. Keith Sklower will write a draft addressing some issues. o ECP/CCP patent status. Steve Coya reported on the communication with Motorola. o Multilink Procedures RFC 1717. Fine tuning. o Extensible Authentication Protocol. Some clarifications and some decisions. o Public Key Authentication Proposal. This draft is either poorly worded or fundamentally incorrect; in either case, it requires a great deal of work. o IP Control Protocol. A number of agreements and clarifications were made with the purpose of allowing IPCP from Proposed Standard status to Draft Standard.