SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI padding should be 0



    Eddy,
    
    This discussion is purely based on semantics and the definition of the word.
    MUST indicates that it is REQUIRED.  Yes?  If it is REQUIRED that the
    padding be set to 0 and it is NOT then that implementation is in violation
    of the spec.  Yes?
    
    You are correct that the RFC does not say that you must check it but it does
    imply it (or at least that it is checkable), which is what I stated.  My
    concern is that Julian suggested that the spec say MUST be 0 and that he did
    NOT want people to check for 0.  To insure that it is not checked, the
    statement MUST remain "SHOULD be 0."  
    
    In the production environment, the checking of whether or not the padding
    has been set to zero may be bypassed for whatever reason, but in a testing
    environment (guess where I work. :) ), I am sure that if someone read the
    spec and implemented a test tool to verify that their implementation
    conforms to the spec they could generate a bug report if the padding was not
    0.
    
    I am just trying to make sure that the spec is as unambiguous as possible
    and I apologize if I am stepping on any toes.
    
    Michael Fischer
    
    -----Original Message-----
    From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
    Sent: Friday, July 27, 2001 9:32 AM
    To: 'Fischer, Michael'; julian_satran@il.ibm.com
    Subject: RE: iSCSI padding should be 0
    
    
    The RFC says:
      MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
      definition is an absolute requirement of the specification.
    
    How does that say that I MUST check to be sure it has been done? Is that
    requirement someplace else?
    
    
    Eddy
    
    -----Original Message-----
    From: Fischer, Michael [mailto:Michael_Fischer@adaptec.com]
    Sent: Friday, July 27, 2001 12:26 PM
    To: 'Julian_Satran/Haifa/IBM%IBMIL'; eddy_quicksall@ivivity.com
    Cc: ips
    Subject: RE: iSCSI padding should be 0
    
    
    
    Julian,
    
    I hate to butt in with this minor point, I think you guys are doing a great
    job in hammering out the specification and do not presume to know better.
    
    However, according to RFC2119 the word MUST indicates that it is a
    requirement of the specification and therefore implies that the receiver
    will need to check the value.  If it MUST be zero and is not, then that
    would indicate a protocol error.
    
    Michael Fischer
    
    -----Original Message-----
    From: Julian_Satran/Haifa/IBM%IBMIL [mailto:julian_satran@il.ibm.com]
    Sent: Friday, July 27, 2001 8:46 AM
    To: eddy_quicksall@ivivity.com
    Cc: ips
    Subject: Re: iSCSI padding should be 0
    
    
    
    Perhaps we should say MUST be sent as 0 and keep quiet about what the
    receiver should  do (check for 0 - we don't want that).
    
    Thanks,Julo
    
    "Eddy Quicksall" <eddy_quicksall@ivivity.com> on 27-07-2001 18:18:33
    
    Please respond to eddy_quicksall@ivivity.com
    
    To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    cc:
    Subject:  iSCSI padding should be 0
    
    
    
    
    Julian,
    
    Section 2.1 says the padding should be 0. I guess that is correct because
    one may not use CRC and therefore may not want to set them to 0. Wouldn't
    it
    be better if section 2.1 was more specific and mentioned when they must be
    0
    if there is a CRC. Also, I noticed at the UNH plug fest that at least one
    person thought "should" meant "must". Therefore, I don't think it should
    say
    "should" ... I think it should not mention the 0'ness unless there is a CRC
    present.
    
    Also,
    
            transmission.  Padding bytes, when presents in a segment covered by
    a
            CRC, have to be set to 0 and are included in the CRC.
    
    should say "when present in".
    
    Eddy_Quicksall@iVivity.com
    
    


Home

Last updated: Tue Sep 04 01:04:10 2001
6315 messages in chronological order