Re: iSCSI: 12-97 Bit Rule

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Thu, 13 Jun 2002, Luben Tuikov wrote:

> Bill Studenmund wrote:
> >
> >
> > Yes, actually, I do. 1) An independent reader of the document agreed with
> > the author as to the meaning of the bit ordering. This fact is important
> > as authors (as I have found with most of the technical documents I have
> > written) have an intimate association with the document, and as such may
> > not see things as an independent reader would. 2) I wasn't repeating
> > Julian, I was expressing my opinion. The fact we agree indicates that
> > we agree. :-)
>
> So, this is all contrary to the fact that you mentioned
> that it is indeed confusing in a previous letter on this thread.

No, it's not contrary to that statement.

The IETF does something, as part of its standards, that I find counter-
intuitive, and at first glance is confusing. It numbers bits in bytes in a
manner I would not choose.

However, the IETF uses this bit numbering scheme in ALL of its documents.
It is consistent in its bit numbering. Thus if I read an IETF document, I
prepare my mind for IETF bit numbering.

Note that the IETF is not the only group to use this bit numbering. As I
understand it the Mainframe folks use this bit numbering. Also, the
documentation I have on PowerPC chips all uses this bit numbering, so it's
not something the IETF made up.

> As I said: we'll just wait to see for the comments
> from the industruy and the implementers. Especially
> the Linux community, which has defied all
> ``consensus'', ``ideology'', and what-not,
> and has chosen for the ``makes sense'' attitude.
> (Badly quoted from Linus.)

Well, two thoughts come to mind:

1) For me, no explanation of how to perform this CRC calculation will make
sense if it dives into the space of abstract bit streams and such. My mind
works much better with code snippets.

2) I expect the Linux community will start by looking at the
implementations out there. The UNH implementation has CRC32C code in it.
That code, AFAICT, is correct.

> > > Anyway, if you had paid attention you'd have noticed
> > > that the algorithm I sent DOESN'T DEPEND on the
> > > bit numbering (7:0 or 0:7) of the draft. _This_
> > > was the more important subject (and my point)...
> >
> > Then why distract everyone by talking about bit sequence?
>
> So that it doesn't matter if YOU count bits 0 to 7 or 7 to 0
> in a byte. So that anyone can implement it anyway.

I'm sorry, that came out wrong. If your main point was that your proposed
text is independent of bit numbering, then the way you were discussing
Julian's use of the bit numbering which is consistent with the rest of the
document didn't help. At least not for me.

Take care,

Bill