SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    IPS Yokohoma draft minutes



    Please send any comments by Friday Noon.
    
    Thanks,
    
    Elizabeth Rodriguez
    ------
    
    IPS Meeting Minutes
    
    Monday, July 15, 2002  (60 attendees)
    
    - There are currently 23 WG drafts. Of these,
        2 are in the RFC editor’s queue
        4 have completed WG last call
        1 has completed initial WG last call, but will need second.
        3 deal with last call issues, and will be allowed to expire w/o
    further processing.
          Most of the others are either ready for last call, or will be
    shortly.
    
    - The FC encapsulation document has completed WG last call, but is being
    held until FCIP and iFCP documents are ready to be forwarded to the AD’s
    for their review and IETF last call.
    - The iFCP and FCIP documents have completed WG last call, but are being
    held pending a final review against the IPS security document.
    - The IPS security document has completed WG last call.  A few technical
    and editorial comments must be addressed.  Waiting completion of the
    final draft, expected some time in August.
    - The iSCSI draft has completed its initial WG last call.  Many
    technical and editorial comments have been received.  Most have been
    addressed in a preliminary draft, and others addressed during the IPS WG
    meeting in Yokohoma.  The group is encouraged to review the working
    version of the draft, comments against the draft and their resolution at
    http://www.haifa.il.ibm.com/satran/ips/
    The current working version of the draft is located at 
    http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-15-working.p
    df
    The current list of comments and their resolution, if any, is available
    at
    http://www.haifa.il.ibm.com/satran/ips/iSCSI-WG-Last-Call-Issues-And-Res
    olution.txt
    - FC Mgmt MIB is ready for WG last call, and will be started this week
    
    iSCSI Plugfest
    - The 4th iSCSI Interoperability Plugfest will be held the week of July
    29 at UNH Interoperability Labs.
    - Contact for the plugfest is Stephen Schafer (stephens@iol.unh.edu, 603
    862 5083)
    - UNH Web site at www.iol.unh.edu
    - Past Plugfests have had 36 companies participate (34 US, 1 Japan, 1
    Israel)
    - Consisted of Disk, Bridge, Routers, Filers, Tape
    - Discovered many issues.  Info available on both IPS mailing list and
    IOL web site.
    - Tests divided into two categories – Interoperability and Compliance.
    Reference design for interoperability testing is available.
    - The 4th plugfest will focus on Login Phase conformance, Parameter
    Negotiation, Full feature phase conformance, error recover (new test
    tool spoofer), security (CHAP), and multiple conformance, Parameter
    Negotiation, Full feature phase conformance, error recover (new test
    tool spoofer), security (CHAP), and multiple connections per session.
    - Request made to make a list of companies participating in plugfests
    available.  This can help people justify participation to their
    companies.  This may be able to be accommodated – results are
    confidential, but companies participating should not be.
    
    Security Draft
    - Completed WG last call
    - 2 loose ends
      SRP Groups: 
      • Issue: SRP primes only probabilistically tested. Could use IKE
    grups, primes proven, but no generators.
      • Results: Now have generators for IKE groups (courtesy of Tom Wu),
    and independent probabilistic test of SRP primes have been performed
    (courtesy of Vince Cavanna)
      • Will go forward with these results
      (Note:  See Tuesday minutes for update -- Primality of SRP primes
    proven)
    
      AES Counter Mode
      • Currently SHOULD implement for all IP Storage Protocols (3DES CBC is
    must implement)
      • AES CTR Mode is not making good progress in the IPsec WG. The
    experts are engaged, but no current draft. Problems seem to center
    around the design of the counter.
      • AES CTR Mode is more suitable to 10Gb design, but AES CBC mode
    should be able to run at 10Gb as well. AES CBC is currently available. 
      • Q to group – What should be done
      • Nothing right now; pull AES CTR Mode at time of IETF last call if
    AES CTR Mode still not available, may replace at that time with AES CBC
    mode
      • Replace AES CTR Mode with AES CBC mode now
      • Make both AES CTR and AES CBC modes SHOULD now, and eliminate AES
    CTR mode later, if still not available. 
      • After much discussion, consensus by WG is that AES CBC mode should
    replace AES CTR mode now. (NOTE: This decision modified on Tuesday to
    change to AES CBC mode should AES CTR mode still not available by Aug
    31, based on information received from one of the IPsec WG Chairs)
      • This decision needs to be sent to mailing list to check for
    objections to this decision.
    
    SCSI MIB
    - Stable
    - Minor Wording and compile issues
    - Will be an 04 draft.
    - 04 will be ready for WG last call, in August/September time frame
    
    - Q: Related to relationship of iSCSI MIB to T10: This is an IETF draft.
    There will be no T10 document. Initially, when this draft adopted, it
    was at request of T10 – they contributed what they feel is needed in the
    MIB, but do not feel they have the expertise to develop the MIB.
    
    iSCSI
    - Long Lived Discovery Sessions: Currently no restrictions on what can
    PDUs can be used in discovery sessions. Targets only required to accept
    Logout and SendTargets. Has been restricted further, such that the
    initiator is limited to only sending those PDUs, and target is limited
    to responding to them (no NOPs, no Async Messages). Sessions are not
    intended to be long lived.
    - Appropriate Limits on Decimal Encoding: Can only encode values that
    have a fixed size, and that fixed size fits in 64 bits (e.g., if the
    value of a 128-bit parameter happens to fit in 64 bits, decimal cannot
    be used).
    - Size requirements for negotiation: How much text is an implementer
    required to accept because of login? This is important, in that
    implementations may have to set aside this much memory for each login in
    progress. The specification currently specifies 16K, unless SPKM then
    64K. Argued that max needed today is less than 1 K. Therefore, 4K
    requirement should be sufficient. Compromise at 8K. To be checked on the
    list for objections.
    - ErrorRecoveryLevel 0.5:  Support for only one of the two features
    required for ErrorRecoveryLevel 1 support. This is not going to be an
    official new level. 1 person objected to this. Rough consensus: For this
    scenario, an implementation must negotiate to ErrorRecoveryLevel 0,
    since it does not support all the functionality required at
    ErrorRecoveryLevel 1. An initiator may then try to initiate
    Within-connection recovery or within-command recovery after negotiating
    to ErrorRecoveryLevel 0, but must be prepared to work if the target
    rejects the attempt – the target may strictly operate at
    ErrorRecoveryLevel 0.
    - Use of "Irrelevant" in negotiations: Irrelevant is a value response,
    and is applicable for dependent keys, only when the key on which it is
    dependent is not negotiated to an appropriate value. Request made to add
    to the document all the scenarios in which Irrelevant is applicable.
    This is impractical – defining all the permutations in the document
    would add significant txt to the draft. As compromise, Julian will put
    in some examples in the document regarding the use of Irrelevant.
    - Bi-Directional Initial R2T useful? iSCSI/FC bridge developments do not
    think useful. FCP in the FC world uses the same parameter for its
    counterpart.  The BidiInitialR2T key appears in text only where being
    defined. Since never appears elsewhere in the document, then not needed.
    Decision to follow FCP and fold BidiInitialR2T into InitialR2T. To check
    with list for objections.
    - IANA issues: 
      • Current TCP user port of 3260 defined. Should we allocate a system
    port when we go to RFC? Yes. But, current user port will also be kept.
      • Registry for vendor-specific key values. Can use reverse DNS name or
    IANA registration. Simple to set up registry with IANA. This will be
    done, but with a restriction, such as only keys with a special symbol
    such as an “@” or “_” included will be registered by IANA. This insures
    that the draft can define new keys in the future without possibility of
    defining a vendor specific key.
    - Data SNACK resegmentation: This topic is being discussed by David
    Black, Julian Satran and John Hufferd, along with Mallikarjun. A small
    design team will be formed, to come back with a proposed resolution on
    Tuesday.
     
    Tuesday, July 16, 2002  (74 attendees)
     
    Update: Primality of SRP Primes have been proven recently – announced on
    mailing list.
     
    Update: AES-CTR mode. Information on Monday some 6 weeks old. Barbara
    Fraser, IPsec co-chair indices that a draft is not yet available, but it
    is happening, and will likely occur shortly, in time for IPS to make use
    of it without hampering IPS drafts schedules. It should go forward in
    IPsec WG very quickly, without lots of iterations. (This information
    subsequently confirmed with draft author)
    -Proposal: Decision made yesterday to replace AES-CTR mode with AES-CBC
    delayed, until no later than August 31. If AES-CTR draft is still not
    available by that date, or not in reasonably stable shape, then the
    replacement will be made.
    
    Data SNACK resegmentation
    - Small design team, comprised of David Black, Julian Satran, John
    Hufferd, Marjorie Krueger, Mallikarjun Chadalapaka, and Pat Thaler met
    Monday between Monday and Tuesday's sessions and came up with a proposed
    compromise solution.
    - Problem summary:  
      • Command active on connection
      • Initiator reduces size of PDU
      • Initiator does not have all data for outstanding command, requests
    retransmission.
      • Since PDU size is smaller, cannot retransmit same PDUs as previous;
    data must be resegmented.
    - Proposed Solution:
      BegRun=0 and RunLength=0 mean send all unacked data
      With Data SNACK that means all data resent are exact replicas except
    the usual fields that can change
      With the new SNACK (R-Data) 
      •  BegRun and RunLength always 0
      •  Data MAY be resegmented
      •  Carries a tag (SNACK Tag) at offset 0x20
      •  SNACK Tag can be built as a number (1-0xffffffffe)
      •  Target must return a status carrying this tag as the last (or only)
    status
      •  StatSN does not change
      •  DataSN contiguity kept by target
      •  SNACK Tag is lost on reassign
      •  ExpDataSN reflects the information known to initiator at Logout
     
    
    


Home

Last updated: Fri Aug 02 01:18:59 2002
11514 messages in chronological order