|
[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 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 |