idnits 2.17.1 draft-isoc-sun-nfs-agreement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '...ay also distr...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9539 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group The Internet Society 3 Internet-Draft Sun Microsystems 4 March 1998 6 An agreement between the Internet Society, 7 the IETF and Sun Microsystems, Inc. 8 in the matter of NFS V.4 protocols 10 12 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 30 This Request for Comments records an agreement between Sun 31 Microsystems, Inc. and the Internet Society to permit the flow of 32 Sun's Network File System specifications into the Internet Standards 33 process conducted by the Internet Engineering Task Force. 35 Note: 36 This RFC is NOT a standard. It is an official public record of an 37 agreement between Sun Microsystems and the Internet Society. The 38 referenced RFCs 1094 dated March 1989 ("NFS: Network File System 39 Protocol Specification") and 1813 dated June 1995 ("NFS Version 3 40 Protocol Specification") are not attached to the document below, but 41 are incorporated by reference. 43 AGREEMENT BETWEEN THE INTERNET SOCIETY, 44 THE IETF AND SUN MICROSYSTEMS, INC. 45 IN THE MATTER OF NFS V.4 PROTOCOLS 47 This Agreement is made this 3rd day of March, 1998 by and between Sun 48 Microsystems, Inc. ("Donor") and the Internet Society. In 49 consideration of the mutual covenants and conditions set forth below, 50 the parties hereto agree as follows: 52 1. License Grant. For good and valuable consideration, receipt and 53 sufficiency of which is hereby acknowledged, and solely for the 54 purpose specified in Paragraph 2 below, Donor hereby grants to the 55 Internet Society ("Licensees" which, for the purposes of this 56 Agreement, shall include the Internet Engineering Task Force 57 ("IETF"), the IETF Secretariat, and their respective members, 58 officers, employees, contractors and participating individuals) a 59 cost-free, perpetual, non-exclusive, worldwide right and license 60 under any copyrights owned or otherwise licensable by Donor, under 61 any Sun patent rights that are essential to practice the 62 Specification, and any other Sun intellectual property rights to use, 63 reproduce, distribute, perform, display and prepare derivative works 64 of the Specification, and to authorize others to do so. For the 65 purposes of this Agreement, "Specification" means the technical 66 specification described more fully in Exhibit A, which Donor will 67 make available as the initial point for development of the 68 specification for NFS Version 4 as described hereunder, together with 69 any technical specifications based thereon developed by Licensees. 71 2. Statement of Purpose. The licenses granted in Section 1 are 72 granted for the sole purpose of seeking to make the Specification an 73 Internet standard. 75 3. Evolution of the Specification. Donor further grants to Licensees 76 a worldwide right and license to further evolve, develop and modify 77 the Specification for the purpose of making the Specification an 78 Internet Standard through the Internet Standardization Process (as 79 specified in RFC 2026); Donor may not grant a license involving the 80 Specification to any other party, including any standards group, that 81 would authorize such party to evolve, develop, modify or promote the 82 Specification as a standard. In particular, Donor acknowledges that 83 if it performs any evolution, development or modification of the 84 Specification outside of the Internet Standardization Process, that 85 this should be clearly indicated as being a non-standard development, 86 and that no reference to the Internet Standards Process is allowed 87 for any such Specification developed outside of the Internet 88 Standards Process. 90 4. Non-Confidentiality. Donor hereby acknowledges that Licensees 91 assume no obligation to maintain any confidentiality with respect to 92 the Specification licensed hereunder. Licensees acknowledge that any 93 rights not expressly granted herein are reserved by Donor. Donor 94 represents that, to the best of its knowledge, there are no 95 infringement claims against the Specification. 97 5. Future License. Donor hereby acknowledges that Licensees have no 98 duty to publish or otherwise use or disseminate the Specification, 99 including, in particular, an obligation to raise the Specification to 100 the Internet standards-track. Provided that the Specification is 101 elevated to "Proposed Standard" level within 24 months of the 102 execution of this Agreement, Donor hereby agrees to license the 103 Specification to others at no charge and otherwise under 104 substantially similar terms as those granted to Licensee herein (with 105 the exception that such use of the Specification by such Licensees 106 shall be for purposes of implementing and complying with the Standard 107 rather than for making the Specification an Internet Standard), so 108 long as such licensees of the Specification implement and comply with 109 the Internet standard. In the event the Specification is not 110 elevated to "Proposed Standard" level within 24 months of the 111 execution of this Agreement, then the license granted in Section 3 of 112 this agreement shall terminate. 114 6. DISCLAIMER OF WARRANTY. THE SPECIFICATION IS PROVIDED TO 115 LICENSEES "AS IS", AND ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR 116 IMPLIED, INCLUDING FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY 117 AND NONINFRINGEMENT ARE HEREBY DISCLAIMED. 119 7. LIMITATION OF LIABILITY. IN NO EVENT WILL DONOR BE LIABLE FOR ANY 120 LOST REVENUE, PROFITS OR DATA, OR FOR DIRECT, SPECIAL, INDIRECT, 121 CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND 122 REGARDLESS OF THEORY OF LIABILITY ARISING OUT OF THE USE OR INABILITY 123 TO USE THE SPECIFICATION, EVEN IF DONOR HAS BEEN ADVISED OF THE 124 POSSIBILITY OF SUCH DAMAGES. 126 8. Acknowledgment. Donor agrees to permit Licensees to use Donor's 127 name and address to indicate the original source of the 128 Specification. 130 9. Miscellaneous. This Agreement constitutes the entire agreement 131 between the parties concerning its subject matter, and supersedes all 132 prior written or oral agreements and discussions. All additions or 133 modifications to this agreement must be made in writing and must be 134 signed by an authorized representative of each party. If any term or 135 condition of this Agreement is declared void or unenforceable as 136 provided herein or by a court of competent jurisdiction, the 137 remaining provisions shall remain in full force and effect. The 138 parties agree to comply strictly with all applicable export control 139 laws and regulations. Where no U.S. Federal law governs, this 140 agreement will be governed by the law of the State of California 141 without reference to its conflict of laws provision. 143 IN WITNESS WHEREOF, the parties hereto have caused this Agreement to 144 be executed by their duly authorized representatives. 146 Signature /S/ Rich Green Date 3 March 1998 147 Name Rich Green 148 Title VP Solaris 149 SunSoft, Inc. 151 Signature /S/ Donald M. Heath Date 6 March 1998 152 Name Donald M. Heath 153 Title President and CEO of the Internet Society 155 Exhibit A The specifications embodied in RFCs 1094 and 1813, minus 156 the portions of RFCs 1094 and 1813 that assume that NFS Version 2 and 157 Version 3 operate over XDR and ONC RPC.* The control of ONC RPC 158 program number 100003 (NFS) for the purpose of generating Version 159 numbers 4 and onward. 161 *Note: ISOC already has a license to use XDR and ONC RPC (see IETF 162 RFC 1790), and thus may determine whether or not to create an NFS 163 Version 4 that uses XDR and/or ONC RPC. 165 Security Considerations Since this document records an agreement 166 rather than describes a technology security is not directly effected 167 but, that said, one of the aims of an IETF NFS working group should 168 be to ensure that a standards track NFS protocol has adequate 169 security. 171 Editor's Address 173 Scott Bradner 174 Harvard University 175 1350 Mass Ave. Rm 876 176 Cambridge, MA 02138 178 phone - +1 617 495 3864 179 email - sob@harvard.edu