Subject: Re: Bit numbering I-D nit

From: "John Hufferd" <[email-masked]>
Date: Thu, 21 Mar 2002 08:04:16 -0800

Ralph,
I may have looked at this wrong, but though we have to change the way we
present (print) the bit numbering, the bits on the link are the same way it
was, or at least that is the way I read the RFC requirement.  What do you
think is the issue?

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

Ralph Weber <[email-masked]>@ece.cmu.edu on 03/20/2002 08:34:57
PM

Please respond to [email-masked]

Sent by:    [email-masked]

To:    IPS Reflector <[email-masked]>
cc:
Subject:    Bit numbering I-D nit

I am getting serious flack from the Fibre Channel
community over the bit numbering requirement
in http://www.ietf.org/ID-nits.html.

The problem is that Fibre Channel uses the
other bit numbering scheme and interoperability
woes seem certain unless something gets
documented in the IETF RFCs.

Everybody agrees that the body of the FC
Frame Encapsulation and FCIP drafts can
have the IETF bit numbering in the figures.

What they all want is an appendix, or some
such thing in the drafts/RFCs that translates
it all back to the Fibre Channel view of
reality.

Such a thing seems destined to make waves
in the IETF review process, and possibly
even be a target for the RFC Editor's ax.

Should I just jump of the top of the Hilton
now, or is there a way out of this mess?

Thanks.

Ralph...

---

From: Charles Monia <[email-masked]>
Date: Thu, 21 Mar 2002 11:02:52 -0800

Hi Folks:

In my opinion, the overriding consideration must be to achieve clarity. In
that regard, I think the following guidelines should apply to the fibre
channel related drafts:

1.  The specification should have one and only one convention for
representing bits in a structure.

2. When a fibre channel construct is referenced in the spec, including a
reference to specific bit positions, the conventions for representing the
structure and the corresponding textual reference to specific fields or bits
within it should correspond to the normative fibre channel spec in which the
structure is defined.

I would suggest an informative appendix showing the mapping between the
fibre channel convention and that shown in the 'nits' document cited by
Ralph.

thanks,
Charles

> -----Original Message-----
> From: Murali Rajagopal [mailto:[email-masked]]
> Sent: Thursday, March 21, 2002 9:56 AM
> To: Paul Koning; [email-masked]
> Cc: [email-masked]
> Subject: RE: Bit numbering I-D nit
> 
> 
> Paul/Ralph:
> 
> Clearly it appears that putting something an appendix is 
> reaching a high
> degree of consensus.
> One might also, via an example in the appendix alert the 
> reader to this
> mapping. I would find
> it hard that any RFC editor would argue with this informative example.
> 
> -Murali
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Paul Koning
> Sent: Thursday, March 21, 2002 8:04 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Bit numbering I-D nit
> 
> 
> >>>>> "Ralph" == Ralph Weber <[email-masked]> writes:
> 
>  Ralph> I am getting serious flack from the Fibre Channel community
>  Ralph> over the bit numbering requirement in
>  Ralph> http://www.ietf.org/ID-nits.html.
> 
> I can see why... I didn't realize that the requirement is for the
> confusing old IMB-360 style bit ordering rather than the "powers of
> two" bit ordering that's generally used.  Yuck.
> 
>  Ralph> The problem is that Fibre Channel uses the other bit numbering
>  Ralph> scheme and interoperability woes seem certain unless something
>  Ralph> gets documented in the IETF RFCs.
> 
>  Ralph> Everybody agrees that the body of the FC Frame Encapsulation
>  Ralph> and FCIP drafts can have the IETF bit numbering in the
>  Ralph> figures.
> 
>  Ralph> What they all want is an appendix, or some such thing in the
>  Ralph> drafts/RFCs that translates it all back to the Fibre Channel
>  Ralph> view of reality.
> 
>  Ralph> Such a thing seems destined to make waves in the IETF review
>  Ralph> process, and possibly even be a target for the RFC Editor's
>  Ralph> ax.
> 
> I would say an appendix that documents the mapping to other standards
> is the right thing.  If that gives the RFC editor and/or IESG
> heartburn, it's worth a battle.  Bit order is far too important an
> interop issue to be left undiscussed, and if bureaucratic rules stand
> in the way, those rules MUST change.
> 
> If those sound like strong words, so be it.  I've been burned far too
> many times by bit order confusion to take this sort of thing lightly.
> If there exist two conventions in the community, it's mandatory to
> document that explicitly and clearly state the mapping between the two
> notations, or things will never work.
> 
>    paul
> 
>

---

From: [email-masked]
Date: Fri, 22 Mar 2002 16:25:44 -0700

John,

The bits would be on the wire the same way we present the bit numbering.
Both specs use the same position in a word as the most significant, but they
name the bits differently. This can lead to human confusion and
interoperabillity problems. It is important to let the reader know that
there are two different naming schemes applied to the bits by the different
standards they are dealing with. We have had to handle a very similar
problem in mapping Ethernet payloads into a Sonet frame for the 10 Gig
Ethernet work. 

We should let the reader know about the bit labeling with a brief
description before the header diagrams. For instance, in the iSCSI draft, we
could add something like the following to the text of clause 9:

"Note that SCSI and IETF documents use different conventions for labeling
bits and bytes. SCSI documents label the bits of each byte from 0 to 7 with
7 being the most significant bit. SCSI documents label the bytes with byte 0
being the first byte. IETF documents label the bits of each word from 0 to
31 with 0 being the most significant bit. Therefore, SCSI would label the
first bit of the first word as bit 7 of byte 0 and IETF would label the same
bit as bit 0. This document labels bits following the IETF conventions. This
is a difference in labeling convention and does not represent a difference
in placement of bits or fields."

For the Fibre Channel related documents, the paragraph could be: 

"Note that Fibre Channel and IETF documents use different conventions for
labeling bits. Fibre channel documents label the bits of each word from 0 to
31 with 31 being the most significant bit. IETF documents label the bits of
each word from 0 to 31 with 0 being the most significant bit. Therefore,
Fibre Channel would label the most significant bit of a word as bit 31 and
IETF would label the same bit as bit 0. This document labels bits following
the IETF conventions. This is a difference in labeling convention and does
not represent a difference in placement of bits or fields."

An alternative place for this would be under Conventions used in this
document, but I think it is better to put the information in the section
with the headers. This could be in addition to an Annex if people feel an
Annex necessary.

Pat

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Thursday, March 21, 2002 8:04 AM
To: [email-masked]
Cc: IPS Reflector
Subject: Re: Bit numbering I-D nit

Ralph,

.
.
.
John L. Hufferd

Thanks.

Ralph...

---

From: Robert Snively <[email-masked]>
Date: Fri, 22 Mar 2002 16:31:15 -0800

Note that the IETF mapping we are looking at is not an
Ethernet or an IP mapping, but rather a TCP mapping.  The
mapping from TCP to IP to Ethernet is fortunately not
relevant to this discussion.

The FC frames we are looking at are actually two mappings,
one being the memory mapping of the bytes in the payload,
the other being the related mapping of the bytes in the
headers and trailers and payload onto the FC wire stream.

A simple table structure can express all those relationships,
making it nice and clear for people.  Because it is
a mandatory convention, it must reside in the introductory
text of the FC Encapsulation.  It should be either referenced
or replicated in all protocols that derive from that
encapsulation so that people don't make any inadvertent
and incorrect simplifications based on IETF-only or FC-only
knowledge.

Bob Snively                        e-mail:    [email-masked]
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, March 22, 2002 3:26 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 23 Mar 2002 02:36:55 +0200

Pat,

The "nits" document requires a certain numbering from the MSB to the LSB 
but not necesarily 0 to 31 (that is an example).
I did already the changes in the iSCSI document to fulfill this 
requirement. Now our "presentation" and SCSI are similar.
Obviously when sent on an Ethernet (but that is 1000 layers away :-)) bit 
7 gets out first and the same holds for the CRC calculation (somewhat 
arbitrary).

Julo

[email-masked]
Sent by: [email-masked]
23-03-02 01:25
Please respond to pat_thaler

        To:     John Hufferd/San Jose/IBM@IBMUS, [email-masked]
        cc:     [email-masked]
        Subject:        RE: Bit numbering I-D nit

John,

The bits would be on the wire the same way we present the bit numbering.
Both specs use the same position in a word as the most significant, but 
they
name the bits differently. This can lead to human confusion and
interoperabillity problems. It is important to let the reader know that
there are two different naming schemes applied to the bits by the 
different
standards they are dealing with. We have had to handle a very similar
problem in mapping Ethernet payloads into a Sonet frame for the 10 Gig
Ethernet work. 

We should let the reader know about the bit labeling with a brief
description before the header diagrams. For instance, in the iSCSI draft, 
we
could add something like the following to the text of clause 9:

"Note that SCSI and IETF documents use different conventions for labeling
bits and bytes. SCSI documents label the bits of each byte from 0 to 7 
with
7 being the most significant bit. SCSI documents label the bytes with byte 
0
being the first byte. IETF documents label the bits of each word from 0 to
31 with 0 being the most significant bit. Therefore, SCSI would label the
first bit of the first word as bit 7 of byte 0 and IETF would label the 
same
bit as bit 0. This document labels bits following the IETF conventions. 
This
is a difference in labeling convention and does not represent a difference
in placement of bits or fields."

"Note that Fibre Channel and IETF documents use different conventions for
labeling bits. Fibre channel documents label the bits of each word from 0 
to
31 with 31 being the most significant bit. IETF documents label the bits 
of
each word from 0 to 31 with 0 being the most significant bit. Therefore,
Fibre Channel would label the most significant bit of a word as bit 31 and
IETF would label the same bit as bit 0. This document labels bits 
following
the IETF conventions. This is a difference in labeling convention and does
not represent a difference in placement of bits or fields."

Pat

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Thursday, March 21, 2002 8:04 AM
To: [email-masked]
Cc: IPS Reflector
Subject: Re: Bit numbering I-D nit

Ralph,
I may have looked at this wrong, but though we have to change the way we
present (print) the bit numbering, the bits on the link are the same way 
it
was, or at least that is the way I read the RFC requirement.  What do you
think is the issue?

.
.
.
John L. Hufferd

Ralph Weber <[email-masked]>@ece.cmu.edu on 03/20/2002 
08:34:57
PM

Thanks.

Ralph...

---

From: [email-masked]
Date: Fri, 22 Mar 2002 18:00:25 -0700

Julian,
 
The nits document specifically says that bit zero is the most significant
bit in a word or field. SCSI labels the most significant bit of the byte as
7 so I don't see how we can comply with the nits document and be similar to
SCSI labeling. When you say you already did the changes, do you mean you
have already renumbered tables for the next draft or are you referring to
Draft 11?  Draft 11 shows bit 7 as the MSB of each byte which is consistant
with SCSI and not with the nit. 
 
Or do you mean that our next draft is similar to SCSI in that you number
bits within a byte rather than within a word though the bits are numbered in
opposite order? If so, I think it would be useful to the reader to point out
the difference. 
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, March 22, 2002 4:37 PM
To: [email-masked]
Cc: [email-masked]; John Hufferd; [email-masked]; [email-masked]
Subject: RE: Bit numbering I-D nit

Pat, 

The "nits" document requires a certain numbering from the MSB to the LSB but
not necesarily 0 to 31 (that is an example). 
I did already the changes in the iSCSI document to fulfill this requirement.
Now our "presentation" and SCSI are similar. 
Obviously when sent on an Ethernet (but that is 1000 layers away :-)) bit 7
gets out first and the same holds for the CRC calculation (somewhat
arbitrary). 

Julo 

	[email-masked] 

23-03-02 01:25 

John,

Pat

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Thursday, March 21, 2002 8:04 AM
To: [email-masked]
Cc: IPS Reflector
Subject: Re: Bit numbering I-D nit

Ralph,

.
.
.
John L. Hufferd

Thanks.

Ralph...

---

From: Robert Snively <[email-masked]>
Date: Fri, 22 Mar 2002 16:25:47 -0800

No.

I believe it must be in the text of the FC Encapsulation
document.  It is a necessary definition of the conventions
applied to the FC bit stream.

What is really required is a simple mapping table that may
be used by both FC folks and IP folks to map back and forth
between the conventions.  That way no one will be confused.

Bob

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 23 Mar 2002 16:23:05 +0200

Pat,

For draft 12 I renumbered the bits within bytes by not not the bytes 
within a word (the byte numbering is compliant with the nit draft
as far I understand it). 

Regards,
Julo

[email-masked]
23-03-02 03:00

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc:     [email-masked], John Hufferd/San Jose/IBM@IBMUS, [email-masked], 
[email-masked]
        Subject:        RE: Bit numbering I-D nit

Julian,
 
The nits document specifically says that bit zero is the most significant 
bit in a word or field. SCSI labels the most significant bit of the byte 
as 7 so I don't see how we can comply with the nits document and be 
similar to SCSI labeling. When you say you already did the changes, do you 
mean you have already renumbered tables for the next draft or are you 
referring to Draft 11?  Draft 11 shows bit 7 as the MSB of each byte which 
is consistant with SCSI and not with the nit. 
 
Or do you mean that our next draft is similar to SCSI in that you number 
bits within a byte rather than within a word though the bits are numbered 
in opposite order? If so, I think it would be useful to the reader to 
point out the difference. 
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, March 22, 2002 4:37 PM
To: [email-masked]
Cc: [email-masked]; John Hufferd; [email-masked]; [email-masked]
Subject: RE: Bit numbering I-D nit

Pat, 

Julo 

[email-masked] 

John,

Pat

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Thursday, March 21, 2002 8:04 AM
To: [email-masked]
Cc: IPS Reflector
Subject: Re: Bit numbering I-D nit

Ralph,

.
.
.
John L. Hufferd

Thanks.

Ralph...

---

From: [email-masked]
Date: Wed, 27 Mar 2002 18:03:12 -0500

Ok, here's the resolution, complete with AD approval, and I even
used the "normative" word for clarity ...

(1) Any normative diagram (i.e., one that the reader must understand
	in order to implement the protocol) MUST use the bit and byte
	order in the ID nits document.  A version using the T11 bit and
	byte order may be provided in addition to (but NOT instead of)
	the primary version with a note that it is provided for the
	convenience of those familiar with Fibre Channel.  A note to
	the RFC Editor SHOULD be inserted to instruct that the bit
	and byte order not be changed in this second version.

(2) It is acceptable to provide the sole version of a diagram in T11
	bit and byte order when that diagram is:
	- not normative, AND
	- located in an appendix of the draft
	In this situation, the draft needs to make it clear that the
	appendix containing such a diagram is not normative.  RFC 2625
	is an example, as it is clear from context that the appendices
	are not normative.  Any new draft needs to contain an explicit
	statement that the appendixes are not normative (i.e., do not
	impose requirements on the protocol).  A note to the RFC Editor
	similar to the previous case SHOULD be inserted.

The above items also apply to T10 and SCSI via the obvious word/acronym
substitutions.  I hope this is satisfactory.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------