Subject: RE: iSCSI: CRC description

From: [email-masked]
Date: Wed, 12 Jun 2002 12:24:47 -0600

Julian,
 
The changes to the text on CRC are a step down rather than up in clarity.
 
In particular: 

 " - In the bit stream mentioned above the CRC bits are appended   to the message bits with x^31 first followed by x^30 etc. In   the examples provided in Appendix B.4 - CRC Examples, the   value is outlined as a word sent or received and therefore   the CRC bits are mapped into the CRC word according to Section   1.3.4 Bit Rule - i.e., the x^31 coefficient in bit 7 of   the first byte of the digest continuing to through the byte the x^24 coefficient in bit 0 of the first byte, continuing with the x^23 coefficient in bit 7 of second byte through x^0 in bit 7 of the last byte.  

This statement will be very confusing to readers. The there is no abstract bit stream in which the CRC bits follow each other. Trying to specify the CRC with respect a bit stream will just lead to confusion. The old text with the changes I had suggested would provide more clarity.

Also, there is no MUST on the CRC computation method. Using a compatible computation method is necessary to produce interoperability so there should be a MUST. I suggest the following  which should allow for compatible variations in implementation:

Replace, "The CRC should be calculated as follows:" with "The CRC MUST be calculated using a method that produces the same result as the following process:"

Regards,
Pat

---

From: [email-masked]
Date: Wed, 12 Jun 2002 13:59:15 -0600

Julian,
 
I agree it is frustrating but I suggested text that would have been clear. This doesn't have to go on and on but the text has to be clear. The recent changes split the information on how to use the CRC between a paragraph near the front (which only applies to the CRC calculation) and 11.1 on page 209. 
 
Vince's comment on emphasis was about the magic number order and I don't have any problem with that text.
 
I am just asking you to use similar text in describing how the CRC is appended as that you already use to describe the formation of the polynomial M(x): "- The n bits of the bit-stream are considered coefficients of a polynomial M(x) of order n-1, with bit 7 of byte 0 being x^(n-1)." The text that is confusing says that the CRC is appended with x^31 term followed by x^30 term isn't useful as the bits only are that way in some hypothetical data stream and are in the packet in the opposite order (within each byte).
 
As I pointed out in a separate message, the text that was added on bit order is inaccurate because it only applies to CRC and does not apply to the other cases where bits have positional significance (e.g. numbers, polynomial significance for authentication and encryption).
 
Pat

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 11:41 AM
To: [email-masked]
Subject: RE: iSCSI: CRC description
Importance: High

The thing about this text that is going on and on is very frustrating. 
First Vince insisted on emphasis. 
Now you find it confusing. 

I gave it as a quiz to a undergraduate class and no one made a mistake. 

How much effort do you think I will spend on it? And who are the people that are confused? 

Julo 

	[email-masked] 

06/12/2002 09:24 PM 
Please respond to pat_thaler 

        To:        Julian Satran/Haifa/IBM@IBMIL 
        cc:        [email-masked], [email-masked] 
        Subject:        RE: iSCSI: CRC description 

Julian, 

In particular: 

 " - In the bit stream mentioned above the CRC bits are appended   to the message bits with x^31 first followed by x^30 etc. In   the examples provided in Appendix B.4 - CRC Examples, the   value is outlined as a word sent or received and therefore   the CRC bits are mapped into the CRC word according to Section   1.3.4 Bit Rule - i.e., the x^31 coefficient in bit 7 of   the first byte of the digest continuing to through the byte the x^24 coefficient in bit 0 of the first ! byte, continuing with the x^23 coefficient in bit 7 of second byte through x^0 in bit 7 of the last byte.   

Regards,
Pat