@(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2007/401-01 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris (SUNWsmbsu) Consolidation: ON Department or Group: CIFS Server [PSARC 2006/715] Bugster Product/Category/SubCategory: solaris/utility/cifs Responsible Manager: Barry Greenberg (barry.greenberg@sun.com) 3. The CONSUMER is identified by the following: Product or Bundle: Solaris (SUNWkdcu) Consolidation: ON Department or Group: Solaris Security Technology Group (SSTG) Bugster Product/Category/SubCategory: solaris/kerberosv5_bundled/other Responsible Manager: Anup Sekhar (anup.sekhar@sun.com) 4. The INTERFACES are: dyndns_update (libsmbns.so.1) Consolidation Private smb_setdomainprops (libsmb.so.1) Consolidation Private There is also a core set of Service Principal Names (SPNs) that both the CONSUMER and SUPPLIER have agreed upon: host/ nfs/ HTTP/ root/ cifs/ host/ where fqhn is the fully qualified host name of the client and nbname is the NetBIOS name of the client. The set of SPNs are relevant to the possible services hosted by the client. The keys associated with these services are stored in the client's /etc/krb5/krb5.keytab file. 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing (Exporting) these INTERFACES is: PSARC/2006/715 Note that this case brought the functionality that these interfaces allow. They were not originally created/described in this case. 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: Name of Company: Name of Department or Group within Company: Responsible Manager: _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. Only one version of the INTERFACES will be provided at a time. Any changes made will have dependencies which is acceptable for the single consolidation. In regards to the SPNs listed section 4.; the CONSUMER OR SUPPLIER can change the set of SPNs, based on requirements to primarily add or delete elements from the set. However, the "host" SPN can not be removed from the set as there are requirements for this SPN for basic client configuration and maintenance. 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. No changes of the INTERFACES should be required by the CONSUMER. 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. The dyndns_update() INTERFACE may be eventually phased out as there are future plans to provide a public Dynamic DNS interface. 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: The SUPPLIER will inform the CONSUMER of any changes to the interface. As mentioned in 9., there will be some changes in the future to dyndns_update(). 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: The SUPPLIER agrees to support any bugs that may arise with the functionality associated with these INTERFACES. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: There will be no public documents describing the interfaces. The SUPPLIER has already provided comments in the source code describing the INTERFACES' use. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: After a change has been made the CONSUMER and SUPPLIER agree to test the utilities that are dependent on the funcionality associated with the INTERFACES. These utilities include domain and workgroup joins in smbadm(1M) and domain joins in kclient(1M). 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: The CONSUMER can send e-mail to contract-2007-401-01@sun.com, indicating that they wish to terminate the contract. The SUPPLIER can terminate the contract by providing sufficient notice to the CONSUMER. Sufficient notice would entail periods of supported release schedules, such as OpenSolaris, which is currently defined as six months. 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: Barry Greenberg Date: TBD For CONSUMER: Anup Sekhar Date: TBD For ARC: PSARC Date: TBD 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: