This would not logically include ignoring the rule about everything put to the wire must be "BIG ENDIAN"? Obviously everyone knows to ignore this ruleset when dealing with CRC32C; however, if you are a "BIG ENDIAN" box you must conform to make your CRC32C put on the wire in "LITTLE ENDIAN". Of course this is me being picky about following the rules. Cheers, Andre Hedrick LAD Storage Consulting Group On Fri, 14 Feb 2003, Loa Andersson wrote: > > Ran, > > would agree to this, and put even stronger > > "... Internet RFCs the normal Inernet terminology SHOULD be used, unless > there > are very stong and explicitly stated reasons not to ..." > > it should als be that the I* have a guiding role in this > > /Loa > > > RJ Atkinson wrote: > > > > > On Wednesday, Feb 12, 2003, at 13:24 America/Montreal, Mallikarjun C. > > wrote: > > > >>> All the Internet documentation with which I am familiar, as well as the > >> > >> > >> I think we have a case of overlapping vocabulary from two different > >> domains. > >> > >> Per SCSI Architecture Model (SAM-2, SAM-3), iSCSI is very clearly > >> a "SCSI transport protocol" (as opposed to a SCSI application layer > >> protocol). > >> Parallel SCSI, Fibre Channel etc. are all "SCSI transports" per SCSI > >> conventions. > >> That is all the critiqued abstract is trying to describe. > > > > > > In the context of an *Internet* RFC, it seems sensible to use the normal > > Internet terminology -- unless one very very clearly indicates that a > > term is being used in some different semantic. One might postulate that > > the document's editors and RFC-Editor could work out a mutually agreeable > > editorial change here to add clarity. > > > > Ran > > > > > > > > >