New iFCP draft

["ELLIOTT,STEPHEN (HP-Roseville,ex1)" <stephen_elliott@hp.com>]

With regards to the new iFCP draft

5.3        Trailing iFCP CRC

    This original Fibre Channel CRC shall not be encapsulated into the
    iFCP message.  Rather, iFCP MAY use a 32-bit field containing a CRC
    calculated over the data contained in the frame from the iFCP
    AUGMENTED DATA to the iFCP Payload (inclusive).  This includes the
    Fibre Channel header and payload.  The iFCP CRC follows the iFCP
    payload, and the CRC algorithm is the same used for the Frame Check
    Sequence (FCS) of IEEE 802.3 Ethernet frames.  A bit in the iFCP
    FLAGS field in the iFCP header indicates the presence or absence of
    this 32-bit trailing CRC. 

I would suggest "Rather, iFCP MUST use a 32-bit field containing a CRC ..."
unless ethernet provides an equivalent CRC elsewhere.  The reason is that I
believe gigabit ethernet uses the same physical layer as fibre channel.
This physical layer is specified for fibre channel to have a data bit loss
rate of 1 in 10^12 or less, and is not "perfect".  I think the CRC is
designed to throw out these imperfect frames instead of resulting in data
corruption.  Without the CRC, physical layer imperfections within
fibre-channel specificaiton may lead to data corruption.

Also, I am not intending to show preference for iSCSI or iFCP with this
email.  I just was skimming over the standard and thought this feedback
might be helpful.

Stephen Elliott