Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel
draft-ietf-imss-ip-over-fibre-channel-03

[Note]: 'Requesting expedited RFC-Editor processing for this document. T11 needs an RFC-number by Jan 20th so they can reference it in their document to be approved in the week after Jan 20th.' added by Amy Vezza

[Note]: 'Requesting expedited RFC-Editor processing for this document. T11 needs an RFC-number by Jan 20th so they can reference it in their document to be approved
in the week after Jan 20th.' added by Bert Wijnen

State Change Notice email list have been change to Black_David@emc.com; brian@innovationslab.net;cds@cisco.com;craig.carlson@qlogic.com; bob.nixon@emulex.com from Elizabeth.Rodriguez@DotHill.com; Black_David@emc.com; brian@innovationslab.net;cds@cisco.com;craig.carlson@qlogic.com; bob.nixon@emulex.com

IANA Last Call Comments:
Upon approval of this document the IANA will update the reference for Hardware type 18 - Fibre Channel found at the following registry:
http://www.iana.org/assignments/arp-parameters

Review from Internet Area expert posted to mailing list.
New revision expected

-----Original Message-----
From: imss-bounces@ietf.org [mailto:imss-bounces@ietf.org]On Behalf Of
Black_David@emc.com
Sent: Wednesday, October 12, 2005 21:18
To: imss@ietf.org
Subject: [imss] FW: INT Area Review:
draft-ietf-imss-ip-over-fibre-channel-01.txt


Internet Area Expert Review comments on the new IP over FC
draft are below.  Based on further conversation w/Brian, it's
ok not to update the references (Section 17 comment below) in
order to avoid getting caught in a REF (reference) hold at
the RFC Editor.  Many thanks to Brian for doing this review.

The authors should prepare a -02 version of this draft
to address these comments (and update the boilerplate while
they're at it).  They should make sure it passes the ID nits
checker at:

http://tools.ietf.org/tools/idnits/idnits.pyht

before submitting.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953            FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: Brian Haberman [mailto:brian@innovationslab.net]
Sent: Wednesday, October 12, 2005 9:18 AM
To: Margaret Wasserman
Cc: Black, David; Bert Wijnen
Subject: Re: INT Area Review: draft-ietf-imss-ip-over-fibre-channel-01.txt

Margaret & Bert,
      Here are my comments on this draft.  Overall, I think it looks pretty
good.

General Comments
--------------------------

      - The document needs to be consistent in its terminology on
        whether it is updating or obsoleting RFCs 2625 and 3831.
        The language in the Introduction seems to contradict the
          information in the document header.

Section 3
------------

      - I would like to see some rationale/explanation for the values
        1304 (in the fourth bullet) and 1024 (In the fifth bullet).  How
        are those values derived and how are they related?

Section 4.1
---------------

      - The last paragraph allows more than one frame to be included
        in an IP FC Sequence.  It states that only the first frame has an
        FC Network Header and LLC/SNAP Header.  I assume that
        means that all frames in the sequence must be the same protocol.
        It would be nice if that was stated explicitly and some reasoning
        given.

Section 4.3
--------------

      - Does routing traffic need to be mentioned in this list?
Specifically,
        how does routing traffic get handled?

      - Can the exceptions to the SHOULD be spelled out?

Section 4.8
--------------

      - With an MTU of 65280 octets is Jumbogram support needed?

Section 5.2
--------------

      - There is an implication that the FC U/L bit has the same semantics
        as the Ethernet U/L.  I believe that is true, but it would help if
it were
        mentioned.

      - I don't see the benefit of having both figures 9 & 10.

Section 5.3
---------------

      - I don't see the benefit of having both figures 12 & 13.

      - The last sentence contains an example interface ID of
        3463:462A:BCDE:F789.  I don't see where the x789
        portion comes from?  Is it just an example?  It may be
        clearer to replace those with 'xxx'.

Section 7
------------

      - The discussion of ARP opcodes should probably reference the
        [ARP] spec.

Section 9.3
--------------

      - (bullet 4) Should the responder cache info from the Request packet?

Section 17
-------------

      - The references to [AARCH], [ACONF], [DISC], and [ICMPv6] should
        probably be updated to the latest versions that are done or nearly
        done within the IPv6 WG.

Regards,
Brian