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 <WW_PN, Port_ID>  2)
Resolving <IP Address, Port_ID>. 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.