FCEncap: review comments

["Mallikarjun C." <cbm@rose.hp.com>]

Some comments on rev6, excuse me if some/all these were earlier
discussed by the design team.

- Section 3.1, page 4.  For the Protocol# values for FCIP and iFCP, the Annex B
   should instead be referred.

- Section 3.1, pages 4 & 5.  I notice that all the ones complement fields (-Protocol#, 
   -Version etc) are described as "contains the ones complement" as opposed to "SHALL 
   contain ones complement", whereas the corresponding non-1's complement fields 
   have the SHALL wording.  Any reasons for this distinction?
  
- Section 3.1, page 5, CRCV bit description.
        "Some protocols may always check the CRC without regard for the state of this bit."
   I am troubled by the literal implication of this sentence.  Why would that be so?
   Would the encapsulating protocol not mandate CRCV to be set to valid
   always instead?  It seems like the purpose of defining a common encapsulation 
   format and associated semantics is watered down for no stated reason....

- Section 3.2.1, page 7.  S/b "step wise" w/ "stepwise".

- Section 4, page 7. 
       "The protocol SHALL specify whether or not implementation support is
         required."
   A general comment on usage of the term "protocol" here and in other areas - 
   I would recommend using "encapsulating protocol" instead to make it easier
   (or perhaps use "Protocol" may be...) for the reader to follow the usage.

- Section 4, page 8.  Since there is no mention of a notification frame to announce
   an entity's transition into/out of the Synchronized state, I assume it's possible and
   even anticipated that there may be times when one of the two entities may be
   in Unsynchronized state even while the operational encapsulating protocol requires 
   Synchronized operation.  The expectation is that the state rules (and encapsulating
   protocol-specified rules) should cause this type of start-up/transient sceanario to 
   be correctly sorted out.  Is that right?

- I think it might be useful to add a statement in this section along the lines of - 
   If the encapsulating protocol mandates Synchronized operation, the entity MUST
   NOT accept TCP connections on the well-known port(s) unless the entity is in the 
   Synchronized state. 

- Section 4, page 9, Synchronized state rules.  I think this should also address what
   is to be done in case there's a case of "bad synchronization" when Time Stamp
   words are valid.  For ex., when the received value is smaller than the received 
   entity's timebase, I assume it would result in arriving at a huge transit time.  While the 
   huge transit time may cause the frame to be discarded, it isn't clear to me what
   may cause the TCP connection drop and a re-synch.

- Section 4, page9, Synchronized state rules.  
   "If both Time Stamp words have a value of zero, the receiving
     entity SHALL process the de-encapsulated frame without
     computing the transit time. The disposition of the frame and
     any other actions by the recipient SHALL be defined by the
     protocol specification."
   
   I am rather perplexed by the usage of the words here.  While saying
   that the frame shall be "processed", this also seems to leave it up to
   the encapsulating protocol to define if it needs to be processed (as
   reaffirmed by rule (e) in Annex A).  One change that makes it clear to me is:  
    S/b "SHALL process the de-encapsulated frame" 
      w/ "SHALL de-encapsulate the frame".

- It may be useful to add informative references to FCIP and iFCP.

- Section 9, page 13.  S/b "no long working" w/ "no longer working".

- Annex B, page 15.  It isn't clear to me from this sentence if the 
   Protocol# values (1 & 2) are temporarily assigned by this draft for 
   now. 
   
    "Standards action on this RFC should be accompanied by IANA
     assignment of the following two Protocol# values:"


--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com