@(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2003/263-002 PSARC/2003/264-002 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. A netadmin alias has been created as a point of contact for this contract at contract-2003-263-02@sun.com 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris Consolidation: OS/Networking Department or Group: Internet Engineering Bugtraq Category/SubCategory: kernel/tcp-ip kernel/multidata Responsible Manager: Mimi Wong 3. The CONSUMER is identified by the following: Product or Bundle: Solaris Consolidation: CS/Computer systems Department or Group: CPG - Cryptographic Products Group Bugtraq Category/SubCategory: venus/driver Responsible Manager: Mehdi Bonyadi The following hardwares/drivers are currently covered by this contract; additional drivers may be added in separate contracts: Venus (Gigaswift Ethernet with Encryption) 4. The INTERFACES are: Extension to the rules of DL_CAPABILITY_REQ/ACK interface for detecting the presence of DL_CAPABILITY-ignorant intermediate modules, i.e. "rules a-f". DL_CAPAB_ID_WRAPPER interface for providing module identification token on sub-capabilities which don't embed such token during capability negotiation. dlcapabsetqid() and dlcapabgetqid() interfaces for assigning and obtaining module identification token. DL_CAPAB_HCKSUM interface for providing information regarding hardware checksum capabilities during capability negotiation. PATTR_HCKSUM Multidata attribute used to carry hardware checksum information within Multidata messages. hcksum_assoc() and hcksum_retrieve() interfaces for setting and retrieving hardware checksum information. Details on the above are specified within PSARC/2003/263 and PSARC/2003/264 cases. 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing these INTERFACES is: PSARC/2001/070 PSARC/2002/276 PSARC/2003/263 PSARC/2003/264 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the stability levels listed in section 4 above: _N_ 7a. Although the stability level doesn't normally restrict it, SUPPLIER promises to only modify INTERFACES in an incompatible way as follows: _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will expose INTERFACES to a PARTNER, which is external to Sun, namely: _N_ 7c. Although the stability level doesn't normally allow it, CONSUMER will import INTERFACES from a separate consolidation. _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any portion of the INTERFACES, SUPPLIER will notify CONSUMER of the proposed new version, no later than the application for ARC approval of the new version. If SUPPLIER and CONSUMER are contained in the same consolidation, they have the option of arranging for simultaneous conversion to the new interfaces. If this is not possible, or if they are not in the same consolidation, then SUPPLIER will either make best effort to work with CONSUMER so that CONSUMER can detect which version of INTERFACES is being supplied, or else SUPPLIER will make best effort to supply both old and new versions of INTERFACES. If SUPPLIER cannot make both versions of INTERFACES available, and SUPPLIER and CONSUMER cannot devise a method whereby CONSUMER can detect which version of INTERFACES is being supplied, and the old version of CONSUMER will not run with the new version of SUPPLIER, then either the EOL process must be followed by SUPPLIER, or else a major release of SUPPLIER will be required, or the change will not be allowed. 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make best effort to accommodate such changes, which shall then be treated in accordance with paragraph 7 above. 9. Notwithstanding paragraphs 7 and 8, a change to any portion of the INTERFACES shall be regarded as a completely new set of INTERFACES which require both ARC approval and execution of a new contract. 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: The SUPPLIER will provide the CONSUMER with specifications for the DL_CAPABILITY_REQ/ACK, and all current and future capability negotiations which will become available over time. The SUPPLIER will provide the CONSUMER with specifications for the extended IP checksum offload interface. The SUPPLIER will gain agreement from the CONSUMER that the interfaces being proposed are sufficient to support the CONSUMERS needs prior to submitting the interfaces for ARC approval. 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: The SUPPLIER agrees to develop, test and support the PSARC/2003/263 and PSARC/2003/264 API within the IP network stack "ip" and the streams framework according to the specification provided with "DL_CAPABILITY_REQ/ACK" implementation of "DL_CAPABILITY_REQ" which accompanied PSARC/2001/070. The SUPPLIER agrees to develop, test and support the extension to DL_CAPABILITY_REQ/ACK within the IP network stack "ip" and the streams framework according to the specification provided with "DL_CAPABILITY-ignorant intermediate module detection" which accompanied PSARC/2003/263. The SUPPLIER agrees to develop, test and support the extended IP checksum offload interface within the IP network stack "ip" and the streams framework according to the specification provided with "Extended IP checksum offload interface" which accompanied PSARC/2003/264. The CONSUMER agrees to develop, test and support the PSARC/2001/070 API within the CPG consolidation device drivers according to the specification provided with any new capability that becomes available, and is meaningfull to support given the hardware. The CONSUMER agrees to develop, test and support the PSARC/2003/263 API within the CPG consolidation device drivers according to the specification provided for "DL_CAPABILITY-ignorant intermediate module detection" which accompanied PSARC/2003/263. The CONSUMER agrees to develop, test and support the PSARC/2003/264 API within the CPG consolidation device drivers according to the specification provided for "Extended IP checksum offload interface" which accompanied PSARC/2003/264. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: The PSARC 2003/263 extension to the DL_CAPABILITY framework is documented in the corresponding case materials/mail. The PSARC 2003/264 extended IP checksum offload interface is documented in the corresponding case materials/mail. SUPPLIER will provide to CONSUMER header files. In addition, updates to PSARC 2003/263 and 2003/264 materials will be made available to CONSUMER. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: Changes to the interface will be tested by the SUPPLIER using the existing test suites in addition to the exposure provided by ON. Changes that affect the counsumer will will also be tested by the consumer. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: This contract will terminate after mutual signed agreement between SUPPLIER and CONSUMER. 15. This contract is not valid until "signed" via agreement from the SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by this contract. E-mail agreement to the contract should be archived in the mail archive of CASE; verbal agreement to the contract should be noted in the meeting minutes. This contract remains valid until superseded or invalidated. For SUPPLIER: Mimi Wong Date: 5/13/2003 For CONSUMER: Mehdi Bonyadi Date: 5/13/2003 For ARC: PSARC Date: 5/14/2003 A copy of this contract shall be deposited in the CASE directory as "contract-" or in a "contracts" subdirectory. 16. (Not to be filled in until superseded or invalidated.) This contract was superseded or invalidated by CASE: For ARC: Date: