RE: Bit numbering I-D nit

[Charles Monia <cmonia@NishanSystems.com>]

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:muralir@cox.net]
> Sent: Thursday, March 21, 2002 9:56 AM
> To: Paul Koning; roweber@acm.org
> Cc: ips@ece.cmu.edu
> 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: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Paul Koning
> Sent: Thursday, March 21, 2002 8:04 AM
> To: roweber@acm.org
> Cc: ips@ece.cmu.edu
> Subject: Re: Bit numbering I-D nit
> 
> 
> >>>>> "Ralph" == Ralph Weber <ralphoweber@compuserve.com> 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
> 
>