The 43rd IETF Meeting in Orlando had 31 attendees. There were many new company reps. Including international attendees (Korea, Germany, Japan, France). The companies that were in the room included: Brocade, Sony, 3Com, NEC, Compuserve, Lucent, Ericsson, IBM, EMC, Boeing, Qlogic, Tellabs, Emulex, ADC, Fujitsu, Compaq, among others. The meeting addressed issues and comments raised by many on the reflector 1. NAA Issue : Compaq wanted to optionally include other NAA Types besides the IEEE 48-bit addresses. Their motivation was that their future SAN were likely to use other addressing schemes. Resolution: The group was generally opposed to this and the suggested resolution by the two IESG Area Directors present in the room was that, Compaq could generate another RFC as an extension to the present one. It was stated that this approach was commonly taken in the IETF process and would not result in delays to the movement of the existing draft. Second, since allowing other NAA Types was proposed as an option, this would not result in implementations that were supposedly compliant but could not interoperate because of the optional nature. However, the IETF would still approve the DRAFT standard if there were at least 2 interoperable implementations of the optional components of the spec. Action: It is now up to Compaq to write a separate draft and bring it to this group and drive it. For DRAFT STD. at least interoperable implementations are required. 2. MTU Issue: There was some disagreement on the MTU sizes in the 03.txt draft because it did not include optional IP headers. Resolution: Min MTU and Max MTU was specified by Gadzoox to include the IP Optional headers and agreed to by the group. The Max MTU for IP: 65,280 bytes. The Min MTU for IP: 92 bytes The Max MTU = Min MTU for ARP: 52 bytes Action: Include this in 04.txt 3. Inverse ARP Issue: Raj Bhagwat initiated this protocol as a way to solve the lack of broadcast support in some implementations. Resolution: The group was against making this is a mandatory requirement. The group agreed to include this as an optional parameter with the proper wording without causing a concern for interoperability problems Action: Include this in the 04.txt with appropriate wording 4. Multiple IP Addresses per MAC address for InARP Issue: This requirement was originated by Jeff Stai from Brocade as a Fibre Channel VI requirement. Resolution: The proposed solution of just one IP address representing a group of IP addresses was inconsistent with the way it works in Frame Relay according to Jeff Burgan/Tom Narten. Therefore it was suggested that some scheme be devised if this was really required, even if it meant a number of InARP Replies one for each IP association. The suggestion was to look into some Frame Relay solutions for a similar problem. Action: If this is really required include the new scheme in the 04.txt. 5. Modes of FARP and Interoperability Issue: Ezio from Brocade believes that the spec. as it is written today may end up having interoperability problems. FARP specifies two mechanisms. 1). Resolving 2) Resolving . Although, FARP is optional today, if a node receives a request to resolve the WW_PN to Port_ID then the Reply is mandatory. The real problem arises when an implementation only supports the second FARP mechanism and not the first. Resolution: The group felt that the second method should be entirely removed form the document. The group felt that the only way the second method could stay in the document if it was properly reworded. EMC's suggestion was to require all implementations to support the first method in a reply and to optionally allow support for the second method. So if a FARP request using the second method arrives first where there is no support, then a silent behavior is acceptable as it states today, but additionally the node ought to be able to retry using the first method. Note that still means that a FARP implementation is optional on Requests for either mechanism and optional for Reply using the second mechanism (silent behavior). Action: The suggestion was that 04.txt draft shall word-smith the document specifying this behavior. 6. Next Step: The 04.txt document will include the suggested changes. The goal is to send out the 04.txt document out before the end of the year. 7. MIB: It is anticipated that the MIB work will reassume during the March/April meeting.