idnits 2.17.1 draft-mule-ietf-cablelabs-collaboration-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 423. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 2005) is 6768 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3668' is mentioned on line 281, but not defined ** Obsolete undefined reference: RFC 3668 (Obsoleted by RFC 3979) == Unused Reference: 'RFC3113' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'RFC3131' is defined on line 349, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Mark Townsley 3 Internet-Draft Cisco Systems 4 Category: Informational Jean-Francois Mule 5 Expiration Date: April 2006 CableLabs 6 October 2005 8 CableLabs-IETF Standardization Collaboration 9 draft-mule-ietf-cablelabs-collaboration-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document describes the collaboration between the Cable 37 Television Laboratories, Inc. (CableLabs) and the Internet 38 Engineering Task Force (IETF). 40 Contents 42 Status of this Memo.......................................... 1 44 1. Introduction.............................................. 2 46 2. Basis of Collaboration.................................... 4 48 3. Document Sharing......................................... 4 50 4. Participation in the IETF Process........................ 5 52 5. Designated Liaisons...................................... 5 54 6. Formal Liaison Statements................................ 6 56 7. Contributions............................................ 7 58 8. Co-development of Documents.............................. 7 60 9. Terms of Agreement....................................... 7 61 9.1 Limitation of Liability.............................. 7 63 10. Security Considerations.................................. 8 65 11. IANA Considerations...................................... 8 67 9. References................................................ 8 68 12.1 Normative References................................. 8 69 12.2 Informative References............................... 8 71 13. Authors' Addresses....................................... 8 73 Appendix A. Common Work Areas............................... 9 75 Specification of Requirements 77 In this document, several words are used to signify the requirements 78 of the specification. These words are often capitalized. The key 79 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 80 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 81 are to be interpreted as described in [RFC2119]. 83 1. Introduction 85 This document contains a set of principles and guidelines that serves 86 as the basis for establishing a cooperation framework between the 87 Cable Television Laboratories, Inc. and the Internet Engineering Task 88 Force (IETF). This cooperation is intended to secure timely 89 development of technical specifications that facilitate maximum 90 interoperability with existing Internet systems, devices, and 91 protocols. 93 CableLabs is nonprofit research and development consortium that is 94 dedicated to pursuing new cable telecommunications technologies and 95 to helping its cable operator members integrate those technical 96 advancements into their business objectives. Within CableLabs, 97 specification activities are organized into projects like CableHome, 98 DOCSIS, PacketCable and OpenCable and technical work is conducted in 99 focus teams. Product vendors or manufacturers are invited to join the 100 focus teams which create technical specifications. From time to time, 101 CableLabs submits specifications or technical requirements to IETF. 102 CableLabs also references IETF Request For Comments in its 103 specifications. The list of CableLabs projects and Specifications 104 available publicly can be found at the CableLabs web site, 105 . 107 Within the IETF, activities are undertaken within a framework of 108 Areas, with specific activities being undertaken by working groups 109 that are chartered within each Area. Working group output is 110 reviewed by the Internet Engineering Steering Group (IESG) and 111 published by the RFC-Editor. IETF activities are based on a 112 principle of open contribution and participation by any interested 113 party. Information on IETF working groups, current work item drafts, 114 meeting schedules, and mailing lists are published on the IETF web 115 site, . 117 The IETF and CableLabs, are cooperating with a mutual desire to 118 support the integrity of specifications developed by each body. 119 CableLabs does not develop standards other than through its 120 participation with Standards Defining Organizations (SDOs) like the 121 IETF. 123 The preferred approach is that the CableLabs uses the Internet 124 standards unchanged, if feasible, and communicates requirements for 125 change to the IETF, as needed. The parties intend to work together 126 in an effort to avoid duplication of work. 128 Each organization will operate according to its own rules and 129 procedures, including rules governing Intellectual Property Rights 130 (IPR), specification elaboration, approval, and maintenance. 132 This cooperation framework is intended to guide collaborative 133 efforts, and should be put into use in as much as it is applicable to 134 these efforts. If either party finds this framework inapplicable, 135 inappropriate or not in its best interests, then it may notify the 136 other party so that this framework may be modified or withdrawn, as 137 appropriate. Either party should have the right to terminate this 138 collaboration for any reason on some agreed-upon period of notice. 140 2. Basis of Collaboration 142 In the further development of CableLabs specifications, the benefit 143 of adopting Internet specifications has been identified. Although 144 this document recognizes the importance of interoperability of the 145 CableLabs specifications with the existing Internet and hence the use 146 of IETF standards, CableLabs recognizes that additions or 147 modifications might be needed in order to make the IETF Internet 148 specifications meet the needs of CableLabs. In such cases, CableLabs, 149 directly or via one of the vendor participants or entities working on 150 a CableLabs specification will take its concerns directly to the 151 appropriate IETF working groups for resolution. When no appropriate 152 working group can be found or it is not known where to direct the 153 communication, or in the case of resolution of consequent matters, 154 the issue will be raised through the CableLabs designated liaison to 155 the IETF. 157 The IETF may also need to ask questions of CableLabs in order to 158 refine its understanding of CableLabs requirements or may wish to 159 offer guidance to CableLabs on the effective use of Internet 160 specifications. Where possible, these communications will occur in 161 the context of a discussion between CableLabs and an IETF working 162 group. In the event that a working group level discussion is deemed 163 inappropriate for the desired communication, the matter will be 164 raised through the IETF's designated liaison to CableLabs. 166 3. Document Sharing 168 Both CableLabs and the IETF encourage the sharing of specification 169 documents and draft requirements that are of mutual interest. 171 All IETF documents are publicly available from the IETF web site, and 172 discussion of documents is hosted on open mailing lists. 174 CableLabs documents intended for public consumption include CableLabs 175 Technical Reports and CableLabs Specifications that are in ISSUED 176 status. They are published for open access on the CableLabs web site, 177 . 179 CableLabs and the IETF will work to update and exchange, when 180 appropriate and on a regular basis, a list of dependencies between 181 each organization's specifications and work in progress 183 4. Participation in the IETF Process 185 Participation in the IETF process is completely open. This allows 186 CableLabs and any CableLabs vendor contributor to participate to 187 whatever extent CableLabs considers appropriate in IETF meetings and 188 mailing list discussions to assist the IETF in refining its 189 understanding of CableLabs requirements and in meeting requirements 190 that the IETF deems appropriate. This close working relationship 191 also offers an excellent opportunity for CableLabs to receive 192 informal guidance from IETF on CableLabs use of Internet 193 specifications. 195 The vast majority of technical discussions and decision making within 196 the IETF is undertaken by using open mailing lists. It is 197 recommended that interested individuals subscribe to and participate 198 on these lists. 200 CableLabs is to be notified of new work to be undertaken by the IETF 201 via a nominated IETF liaison notification mechanism 203 5. Designated Liaisons 205 When the informal working group level of interaction is insufficient, 206 matters can be raised through a liaison channel. CableLabs and the 207 IETF shall each establish liaison functions for communication with 208 the other organization and shall appoint one or more individuals to 209 those functions. 211 5.1. IETF Liaison to CableLabs 213 The preferred way for organizations to work with IETF is through the 214 working groups. However, IETF has a limited number of individual 215 liaison roles with other organizations when conditions warrant the 216 appointment of a specific person. 218 The Internet Architecture Board (IAB) shall appoint a specific person 219 to serve as the CableLabs Liaison. The role of the IETF's CableLabs 220 Liaison is to act as an initial contact point in IETF for 221 administrative aspects of this collaboration that cannot easily be 222 handled in other ways (e.g., at a technical level by interactions 223 with IETF Working Groups or Area Directors). It is agreed that the 224 role does not carry the expectation of attendance at CableLabs 225 meetings or participation in CableLabs specification development 226 processes, and it is anticipated that all liaison efforts assigned to 227 this individual will be carried out by electronic mail. It is 228 understood that the liaison does not have the ability to make 229 exceptions to, or special provisions for, IETF policies and 230 procedures. 232 It is expected that the individual appointed to this role would: 234 - be informed by CableLabs, when appropriate, of CableLabs 235 activities within the IETF,including new work proposals, and be 236 able to report those using appropriate channels within the IETF, 238 - convey liaisons statements from CableLabs to the IETF, and be 239 responsible for shepherding CableLabs communication to the 240 relevant parts of the IETF, 242 - report to CableLabs on progress with IETF consideration of 243 CableLabs liaison statements, and 245 - have direct access to the CableLabs technical leadership as well 246 as direct access to the IAB and IETF Area Directors, as required. 248 CableLabs meetings are normally only open to delegates from CableLabs 249 members or those manufacturers who have signed the appropriate 250 agreements to work on CableLabs. 252 5.2. CableLabs Liaison to IETF 254 The CableLabs shall establish an IETF liaison to be the initial 255 contact point in CableLabs for matters pertaining to the CableLabs- 256 IETF cooperation. The CableLabs-IETF liaison function, therefore, is 257 expected to work with the concerned IETF and CableLabs projects and 258 focus teams and to support the interaction between CableLabs and the 259 IETF. 261 6. Formal Liaison Statements 263 Whenever possible, and as the preferred primary method of 264 communication and coordination of activity, communication at the 265 working group level is strongly encouraged. 267 When deemed necessary, formal communication between CableLabs and 268 IETF is also permitted. These communications are to be recorded in 269 the form of Liaison Statements, and the IETF will use the CableLabs 270 liaison role to convey these statements between the IETF and 271 CableLabs. All liaison statements made by the IETF or directed to 272 the IETF shall be published by the IETF as public documents. All 273 liaison statements made by the IETF will comply with the IETF IPR 274 policy as documented in [RFC3667] and [RFC3668]. 276 7. Contributions 278 CableLabs members or entities working on CableLabs' projects may make 279 contributions to the IETF in their capacity as IETF participants, 280 under the IETF's IPR policy, as documented in [RFC3667] and 281 [RFC3668]. 283 IETF participants who are also CableLabs members or who have signed 284 the appropriate CableLabs rules, including its IPR policy. 286 CableLabs mailing lists are not open to the general public. It is 287 recommended that work of mutual interest be discussed on the relevant 288 IETF mailing lists. 290 CableLabs may make normative references to the IETF Proposed 291 Standard, Draft Standard, Standard, Best Common Practice and 292 Informational specifications that are published as part of the 293 "Request for Comments" (RFC) document series. 295 8. Co-development of Documents 297 The IETF and CableLabs will not co-develop any documents or material. 299 9. Terms of Agreement 301 9.1 Limitation of Liability 303 Neither the IETF or CableLabs makes any representations with respect 304 to and does not warrant the accuracy of any information or any 305 document. Without limiting the foregoing, each party agrees to 306 accept the terms of and reproduce any warranty disclaimers or 307 limitations of liability that are included in any reproduction of 308 published material made available to it under this cooperation 309 framework. 311 9.2. General 313 a. Neither CableLabs nor the IETF acquires any intellectual or 314 industrial property rights under this cooperation framework or 315 through any disclosure. No license to any patent, trademark, 316 copyright, or other proprietary right is granted here. 318 b. There is no obligation for either CableLabs or the IETF to 319 incorporate the materials presented by the other party. 321 c. This cooperation framework and the relationship between the IETF 322 and CableLabs does not constitute a partnership, joint venture, 323 agency, or contract of employment between the IETF and CableLabs. 325 10. Security Considerations 327 This type of non-protocol document does not directly affect the 328 security of the Internet. 330 11. IANA Considerations 332 There are no IANA Considerations 334 9. References 336 12.1 Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 342 RFC 3667, February 2004. 343 12.2 Informative References 345 [RFC3113] Rosenbrock, K., Sanmugam, R., Bradner, S., and 346 J. Klensin, "3GPP-IETF Standardization Collaboration", 347 RFC 3113, June 2001. 349 [RFC3131] Bradner, S., Calhoun, P., Cuschieri, H., Dennett, 350 S., Flynn, G., Lipford, M., and M. McPheters, 351 "3GPP2-IETF Standardization Collaboration", RFC 3131, 352 June 2001. 354 13. Authors' Addresses 356 W. Mark Townsley 357 Cisco Systems 358 7025 Kit Creek Road 359 PO Box 14987 360 Research Triangle Park, NC 27709 361 mark@townsley.net 363 Jean-Francois Mule 364 Cable Television Laboratories, Inc. 365 858 Coal Creek Circle 366 Louisville, CO 80027-9750 367 U.S.A. 368 Phone: +1 303 661 9100 369 Email: jf.mule@cablelabs.com 370 Appendix A. Common Work Areas 372 At the time of this writing, IETF working groups which are of 373 particular interest to Cablelabs include: 375 - dhcwg 376 - kerberos 377 - ipcdn 378 - sip, sipping, simple 379 - iptel 380 - behave 381 - avt, mmusic 382 - aaa 383 - geopriv 384 - disman 385 - msec 386 - enum, ecrit 387 - ipv6 388 - mip6 389 - netconf 390 - bridge 391 - entmib 392 - magma 393 - v6ops 394 - dnsext 395 - ipsec 396 - l2vpn 397 - zeroconf 398 - l2tpext 399 - tls 401 Intellectual Property Statement 403 The IETF takes no position regarding the validity or scope of any 404 Intellectual Property Rights or other rights that might be claimed to 405 pertain to the implementation or use of the technology described in 406 this document or the extent to which any license under such rights 407 might or might not be available; nor does it represent that it has 408 made any independent effort to identify any such rights. Information 409 on the procedures with respect to rights in RFC documents can be 410 found in BCP 78 and BCP 79. 412 Copies of IPR disclosures made to the IETF Secretariat and any 413 assurances of licenses to be made available, or the result of an 414 attempt made to obtain a general license or permission for the use of 415 such proprietary rights by implementers or users of this 416 specification can be obtained from the IETF on-line IPR repository at 417 http://www.ietf.org/ipr. 419 The IETF invites any interested party to bring to its attention any 420 copyrights, patents or patent applications, or other proprietary 421 rights that may cover technology that may be required to implement 422 this standard. Please address the information to the IETF at 423 ietf-ipr@ietf.org. 425 Disclaimer of Validity 427 This document and the information contained herein are provided on 428 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 429 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 430 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 431 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 432 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 433 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 435 Copyright Statement 437 Copyright (C) The Internet Society (2005). 439 This document is subject to the rights, licenses and restrictions 440 contained in BCP 78, and except as set forth therein, the authors 441 retain all their rights. 443 Acknowledgment 445 Funding for the RFC Editor function is currently provided by the 446 Internet Society.