SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    
    
    


Home

Last updated: Thu Mar 21 13:18:12 2002
9247 messages in chronological order