RE: FCIP -03 comments (part 2)

[Black_David@emc.com]

Three open issues, two of which are figure/diagram related.

> > -- Figures 4-6
> >
> > Should probably have an additional figure that shows
> > at least one FCIP Entity, FC_LEP, and FC_DE in a single
> > diagram.
> 
> I don't know how to use stick figures to communicate the
> concept that there can be multiple FCIP_LEPs in which there
> are multiple FCIP_DEs in the confined line widths of an
> Internet Draft.  I believe that any figure that fails to 
> communicate that point is a disservice to the reader.

In other words, too complex to do in ASCII graphics.
If that's the case, so be it.  I'll take another look at
this in a future version, but it is definitely not a
requirement for approval.

> > -- Section 6.6.1
> >
> > Please add a diagram of the whole header in addition to the
> > protocol-specific fields.
> 
> I will do this in rev 05 provided it it confirmed that the IETF
> practice is to replicate requirements in multiple RFCs so that
> a change in one RFC requires several others to be revised
> concurrently.

It's not necessary to show all the fields from the common
encapsulation header, but at least show their size and
reference the common encap draft/RFC for details, so that the
reader understands the overall structure.  This is common
practice in IETF RFCs (e.g., you'll find lots of discussion
of IP headers in the IPsec documents), and is similar to an
issue that turned up in an earlier version of the iSCSI draft
where it was difficult to determine field offset from the
start of the iSCSI PDU due to nested diagrams.

> There is an open issue among the FCIP Authors regarding the
> need for specificity about what constitutes a loss of
> synchronization.  This probably will result in additional 
> changes in rev 05 (since the Internet Drafts deadline looms 
> too close for resolution in 04).
> 
> Examples of conditions that may be declared to be indicators
> of loss of synchronization are:
> 
> a) failure of the comparison between length and -length
> b) two consecutive header errors in other fields
> 
> There is a reluctance to standardize on one minimum
> list of validation criteria because several equally
> valid lists have been proposed.  It is the determination
> of the FCIP Authors that choices of validation criteria
> have no effect on product interoperability and thus
> are not an absolute necessity in FCIP.

Clearly some sort of hurdle is needed here to make sure that
sufficient checks are made to avoid sending bad data to the
FC Entity.  There are clearly insufficient lists of validation
criteria (e.g., checking only that the timestamp is reasonable
is not enough), and hence I think some words are needed about
what makes a set of validation criteria a "valid list".

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------