|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] IPS Yokohoma draft minutesPlease 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 editors 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 ADs 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 |