IPNG Directorate Teleconference March 21, 1994 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES --------- Scott Bradner / Harvard Allison Mankin / NRL J Allard / Microsoft Jim Bound / DEC Dave Clark / MIT Eric Fleischman / Boeing Frank Kastenholz / FTP Greg Minshall / Novell Paul Mockapetris / ISI Rob Ullmann / Lotus Lixia Zhang / Xerox PARC Regrets ------- Steve Bellovin / AT&T Ross Callon / Wellfleet Brian Carpenter / CERN Jon Crowcroft / UCL John Curran / NEARnet Steve Deering / Xerox PARC Dino Farinacci / Cisco Paul Francis / NTT Daniel Karrenberg / RIPE Mark Knopper / Ameritech Craig Partridge / BBN 1. Scott and Allison will attempt to organize a dinner for the IPNG Directorate members on Thursday, following the IESG Plenary, during the Seattle IETF meeting. 2. The list of IPNG presentations that are to take place Monday morning in Seattle were reviewed. The breakdown is as follows: a. Allison and Scott - IPNG status b. Dave Clark - status of the External Review Panel c. Frank Solensky - Report from the ALE WG d. Jon Crowcroft and/or Frank Kastenholz - Report on the IPNG Requirements document 3. Coya to prepare an IPNG track for Seattle and send to Scott and Allison. Coya to send message to the IPNG list soliciting the formal set of documents from each of the groups. 4. The text of the disclaimer written by Allison and Scott, which is to be included in IPNG documents, was read to the directorate. No requests for changes were made. 5. Allison conducted a full review of the Criteria section of the requirements document. Request changes include: a. In the section on scale, the phrase "up to" should be replaced with "at least" A notation that "another 3 orders of magnitude might be needed" will be added. b. All references to the big-internet list should include the list address. c. In the discussion on scale, change "whole purpose" to "initial motivating purpose" d. Replace "very very very" by "extremely" It was mentioned " the diameter of Internet will grow very very very large.." and that to scale might require a hierarchy in network topology, and for a global system, there is a requirement for guidance in topological engineering. e. The character string to use is IPng, not IP:NG. f. The requirement that multiple IPNG protocols co-exist needs to be reworded as there will only be one (1) IPNG protocol. Will be reworded to require that multiple versions of IPNG need to co-exist on the network. g. On the section on Media, expand "VJ-like" to "Van Jacobson-like" h. It was requested that the requirements include "the ability to send an IP datagram as large as allowed by the inter-network layer (assuming, of course, that the recipient is able to accept a datagram that large). The topic of fragmentation was raised, but discussion was deferred. i. In the section on Configuration, Admin, and OPS, it should be added that "nothing in the proposal should inhibit a future requirement for auto registration." j. It was suggested that the IAB report from the Security W/S might provide text for the security section of the requirements document. Coya to send to the IPNG list, Kastenholz to review. k. In the section on unique naming, use the phrase "multicast addresses" l. In the section on extensibility, reiterate the need to run multiple versions on IPNG over the same wire. m. In the section on non-goals, it was suggested that the section on IPv4 and IPng Communication be removed as it was not needed in the requirements document. It was suggested that the discussion on fragmentation should mention the experience with IPv4 fragmentation (i.e. negative impact on network performance). n. Might be able to incorporate some ideas, concepts and text from the IAB report or the recently published RFC on Firewall in the section on Firewalls in the requirements document. o. There is a need to clarify what is meant by "accounting" in the section on non-goals. Kastenholz will reword. p. In the section on robust service, it was stated that host performance should not decrease (below the level of IPv4), and that the protocol should not, due to its complexity or other features, increase the liklihood of poor implementation on host platforms, especially with respect to performance.