idnits 2.17.1 draft-mule-ietf-cablelabs-collaboration-03.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, updated by RFC 4748 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 432. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (January 31, 2007) is 6287 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J-F. Mule 3 Internet-Draft CableLabs 4 Intended status: Informational W. Townsley 5 Expires: August 4, 2007 Cisco Systems 6 January 31, 2007 8 CableLabs - IETF Standardization Collaboration 9 draft-mule-ietf-cablelabs-collaboration-03.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/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 4, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes the collaboration and liaison relationship 43 between the Internet Engineering Task Force (IETF) and the Cable 44 Television Laboratories, Inc. (CableLabs). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Basis of Collaboration . . . . . . . . . . . . . . . . . . . . 5 50 3. Document Sharing . . . . . . . . . . . . . . . . . . . . . . . 6 51 4. Participation in the IETF Process . . . . . . . . . . . . . . 7 52 5. Designated Liaison Managers and Responsibilities . . . . . . . 8 53 6. Formal Liaison Statements . . . . . . . . . . . . . . . . . . 10 54 7. Contributions . . . . . . . . . . . . . . . . . . . . . . . . 11 55 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 57 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 58 11. Common Work Areas . . . . . . . . . . . . . . . . . . . . . . 15 59 12. Informative References . . . . . . . . . . . . . . . . . . . . 16 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 61 Intellectual Property and Copyright Statements . . . . . . . . . . 18 63 1. Introduction 65 This document contains a set of principles and guidelines that serves 66 as the basis for establishing a liaison relationship between the 67 Cable Television Laboratories, Inc. and the Internet Engineering Task 68 Force (IETF). This cooperation framework is intended to secure 69 timely development of technical specifications that facilitate 70 maximum interoperability with existing Internet systems, devices, and 71 protocols. 73 CableLabs is a non-profit research and development consortium that is 74 dedicated to pursuing new cable telecommunications technologies and 75 to helping its cable operator members integrate those technical 76 advancements into their business objectives. Within CableLabs, 77 specification activities are organized into projects such as 78 DOCSIS(r), PacketCable(tm) and OpenCable(tm), and technical work is 79 conducted in focus teams. Product vendors, manufacturers and cable 80 operator members are invited to join the focus teams which create 81 technical specifications. From time to time, individuals involved 82 with CableLabs focus teams submit CableLabs technical requirements or 83 requirement specifications to IETF in order to seek expert reviews 84 and solicit comments to create solutions that foster product 85 interoperability beyond cable. The submissions related to CableLabs 86 specifications may for example include use cases, protocol 87 requirements, draft MIB modules, and proposed solutions for comments 88 such as new DHCP options. CableLabs also references the work of IETF 89 and Request For Comments in its specifications. The list of 90 CableLabs projects and specifications available publicly can be found 91 at the CableLabs web site, http://www.cablelabs.com. 93 Within the IETF, activities are undertaken within a framework of 94 Areas, with specific activities being undertaken by working groups 95 that are chartered within each Area. Working group output is 96 reviewed by the Internet Engineering Steering Group (IESG) and 97 published by the RFC-Editor. IETF activities are based on a 98 principle of open contribution and participation by any interested 99 party. Details on the Internet Standards Process followed by IETF 100 can be found in [RFC2026]. Information on IETF working groups, 101 current work item drafts, meeting schedules, and mailing lists are 102 published on the IETF web site, http://www.ietf.org. 104 The IETF and CableLabs are forming a liaison relationship with a 105 mutual desire to support the integrity of specifications developed by 106 each body. CableLabs does not develop standards other than through 107 its participation with Standards Defining Organizations (SDOs) like 108 the IETF. 110 The preferred approach is that CableLabs uses the IETF specifications 111 unchanged, if feasible, and communicates requirements for change to 112 the IETF, as needed. The parties intend to work together in an 113 effort to avoid duplication of work. 115 Within the framework of this liaison relationship, each organization 116 will operate according to its own rules and procedures, including 117 rules governing Intellectual Property Rights (IPR), specification 118 elaboration, approval, and maintenance. 120 2. Basis of Collaboration 122 In the further development of CableLabs specifications, the benefit 123 of adopting IETF specifications has been identified. Although this 124 document recognizes the importance of interoperability of the 125 CableLabs specifications with the existing Internet and hence the use 126 of IETF standards, CableLabs recognizes that additions or 127 modifications might be needed in order to make the IETF 128 specifications meet the needs of CableLabs. In such cases, a 129 CableLabs individual or a vendor participant working on a CableLabs 130 specification may take its concerns directly to the appropriate IETF 131 working groups for resolution. When no appropriate working group can 132 be found or it is not known where to direct the communication, or in 133 the case of resolution of consequent matters, the issue will be 134 raised through the CableLabs designated liaison manager to the IETF 135 liaison manager. 137 The IETF may also need to ask questions of CableLabs in order to 138 refine its understanding of CableLabs requirements or may wish to 139 offer guidance to CableLabs on the effective use of IETF 140 specifications. Where possible, these communications will occur in 141 the context of a discussion between CableLabs and an IETF working 142 group. In the event that a working group level discussion is deemed 143 inappropriate for the desired communication, the matter will be 144 raised through the IETF's designated liaison manager to CableLabs. 146 3. Document Sharing 148 Both CableLabs and the IETF encourage the sharing of specification 149 documents and draft requirements that are of mutual interest. 151 All IETF documents are publicly available from the IETF web site, and 152 discussion of documents is hosted on open mailing lists. 154 CableLabs documents intended for public consumption include CableLabs 155 Technical Reports and CableLabs Specifications that are in an 156 approved and published status. These documents have the CableLabs 157 ISSUED status and they are published for open access on CableLabs' 158 web site, http://www.cablelabs.com, or 159 http://www.cablelabs.com/specifications/archives/. 161 In order for the IETF to make any reference (informative or 162 normative), the document must be in an approved and published state, 163 and publicly available. It is expected that CableLabs will share 164 relevant information with IETF participants via individual IETF 165 Contributions as described in [RFC3978] and without requiring a non- 166 disclosure agreement. 168 CableLabs and the IETF will work to update and exchange, when 169 appropriate and on a regular basis, a list of dependencies between 170 each organization's specifications and work in progress. 172 4. Participation in the IETF Process 174 The Internet Standards Process is described in [RFC2026]. 175 Participation in the IETF process is open to any individual willing 176 to contribute. This naturally includes individuals who also 177 represent or otherwise contribute to the development of CableLabs 178 specifications. Such individuals may freely participate in IETF 179 mailing list discussions, submit and review Internet Drafts, and 180 attend IETF meetings in order to assist the IETF in refining its 181 understanding of CableLabs requirements as well as offering CableLabs 182 an opportunity to receive informal guidance on CableLabs' use of IETF 183 specifications. The vast majority of technical discussions and 184 decision making within the IETF is undertaken on open mailing lists. 185 Interested individuals should subscribe to and participate on these 186 lists. 188 5. Designated Liaison Managers and Responsibilities 190 When the informal working group level of interaction is insufficient, 191 matters can be raised through a liaison channel. CableLabs and the 192 IETF shall each establish liaison functions for communication with 193 the other organization and each shall appoint one individual acting 194 as a liaison manager as described in [RFC4052] and [RFC4053]. 196 Formal communications from CableLabs will be initiated by the 197 designated CableLabs liaison manager by sending a liaison statement 198 to the IETF liaison manager; these must follow the procedures 199 described in [RFC4053]. The role of the IETF liaison manager is 200 defined in [RFC4052] and [RFC4691]. The IETF liaison manager is not 201 responsible for notifying CableLabs of new work to be undertaken by 202 the IETF. Instead, the designated CableLabs liaison manager or 203 delegates should subscribe to IETF lists announcing the creation or 204 rechartering of IETF working groups (ietf-announce) and the lists 205 announcing new work (new-work). 207 5.1. IETF Liaison Manager to CableLabs 209 The preferred way for organizations to work with IETF is through the 210 working groups. However, IETF has a limited number of liaison 211 relationships and liaison managers with other organizations when 212 conditions warrant the appointment of a specific person. 214 The Internet Architecture Board (IAB) shall appoint a specific person 215 to serve as the IETF liaison manager to CableLabs. The role and 216 responsibilities of the IETF liaison manager to CableLabs are 217 described below. In particular, it is expected that the designated 218 liaison manager will act as an initial contact point in IETF for 219 administrative aspects of this collaboration that cannot easily be 220 handled in other ways (e.g., at a technical level by interactions 221 with IETF Working Groups or Area Directors). It is agreed that the 222 role does not carry the expectation of attendance at CableLabs 223 meetings or participation in CableLabs specification development 224 processes, and it is anticipated that all liaison efforts assigned to 225 this individual will be carried out by electronic mail. It is 226 understood that the IETF liaison manager does not have the ability to 227 make exceptions to, or special provisions for, IETF policies and 228 procedures. 230 It is expected that the individual appointed to the liaison manager 231 role would: 233 o perform all tasks as defined in [RFC4052] and in [RFC4691], 234 o 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 o convey liaisons statements from the IETF to CableLabs as described 239 in [RFC4053], and be responsible for shepherding CableLabs 240 communication to the relevant parts of the IETF, 242 o be able to raise issues with CableLabs technical leadership as 243 well as the IAB members and IETF Area Directors, as required. 245 CableLabs meetings are normally only open to delegates from CableLabs 246 members or those manufacturers who have signed the appropriate 247 agreements to participate in CableLabs projects or meetings. 249 5.2. CableLabs Liaison Manager to IETF 251 CableLabs shall establish an IETF liaison function and name an 252 individual to be the CableLabs liaison Manager to IETF for matters 253 pertaining to the CableLabs- IETF cooperation. The CableLabs liaison 254 manager to IETF is expected to work with the concerned IETF and 255 CableLabs projects and focus teams and to support the interaction 256 between CableLabs and the IETF. 258 6. Formal Liaison Statements 260 Whenever possible, and as the preferred primary method of 261 communication and coordination of activity, communication at the 262 working group level is strongly encouraged. 264 When deemed necessary, formal communication between CableLabs and 265 IETF is also permitted. These communications are to be recorded in 266 the form of Liaison Statements, and the IETF will use the CableLabs 267 liaison manager to convey these statements between the IETF and 268 CableLabs. The procedure for proper handling of incoming liaison 269 statements defined in [RFC4053] must be followed by both, the liaison 270 manager named by IETF and the liaison manager designated by 271 CableLabs. It is important to note that all liaison statements made 272 by the IETF or directed to the IETF shall be published by the IETF as 273 public documents. All liaison statements made by the IETF will 274 comply with the IETF IPR policy as documented in [RFC3978], [RFC3979] 275 and any updates. 277 7. Contributions 279 Individuals involved in CableLabs' projects and willing to contribute 280 to IETF may make contributions to the IETF in their capacity as IETF 281 participants, under the IETF's IPR policy, as documented in [RFC3978] 282 and [RFC3979]. 284 IETF participants whose companies are CableLabs members or have 285 signed the appropriate agreements with CableLabs may also make 286 contributions to CableLabs' projects and specifications. 288 CableLabs mailing lists are not open to the general public. It is 289 recommended that work of mutual interest be discussed on the relevant 290 IETF mailing lists. 292 The IETF and CableLabs will not co-develop any documents or material. 294 8. Security Considerations 296 This document does not directly affect the security of the Internet. 298 9. IANA Considerations 300 This section provides some guidelines for IANA to consider when 301 adding references to a CableLabs specification in its registries. 303 CableLabs maintains current and archived specification repositories. 304 When a specification is updated, a copy of the previous version is 305 moved to the archived repository to provide a stable reference. 307 IANA should add a pointer to both the current and archive 308 specification repositories when referencing a CableLabs 309 specification, for example: 311 o For a DOCSIS or cable modem related specification, consider adding 312 a reference to both http://www.cablemodem.com/specifications/ and 313 http://www.cablelabs.com/specifications/archives/ ; 315 o For a PacketCable specification, consider adding a reference to 316 both http://www.packetcable.com/specifications/ and 317 http://www.cablelabs.com/specifications/archives/ 319 10. Acknowledgments 321 The authors wish to thank the following individuals for their 322 comments and contributions: Ralph Brown, Brian Carpenter, Leslie 323 Daigle, Ralph Droms, Alain Durand, Simon Krauss, Thomas Narten, Dan 324 Romascanu, and Dave Oran. 326 It is also acknowledged that this document is inspired from [RFC3113] 327 and [RFC3131]. 329 This document was produced using the xml2rfc tool (RFC2629). 331 11. Common Work Areas 333 This section may be removed from future versions of this document. 334 It is provided here to give some background information on the areas 335 that may be common to both CableLabs and the IETF. 337 At the time of this writing, IETF working groups which are of 338 particular interest to CableLabs include: 340 dhcwg, kerberos, ipcdn, sip, sipping, simple, speermint, iptel, 341 behave, avt, mmusic, aaa, geopriv, disman, msec, enum, ecrit, ipv6, 342 mip6, netconf, isms, bridge, entmib, magma, v6ops, dnsext, ipsec, 343 l2vpn, zeroconf, l2tpext, and tls. 345 12. Informative References 347 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 348 3", BCP 9, RFC 2026, October 1996. 350 [RFC3113] Rosenbrock, K., Sanmugam, R., Bradner, S., and J. Klensin, 351 "3GPP-IETF Standardization Collaboration", RFC 3113, 352 June 2001. 354 [RFC3131] Bradner, S., Calhoun, P., Cuschieri, H., Dennett, S., 355 Flynn, G., Lipford, M., and M. McPheters, "3GPP2-IETF 356 Standardization Collaboration", RFC 3131, June 2001. 358 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 359 RFC 3978, March 2005. 361 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 362 Technology", BCP 79, RFC 3979, March 2005. 364 [RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes 365 for Management of IETF Liaison Relationships", BCP 102, 366 RFC 4052, April 2005. 368 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 369 Handling Liaison Statements to and from the IETF", 370 BCP 103, RFC 4053, April 2005. 372 [RFC4691] Andersson, L., "Guidelines for Acting as an IETF Liaison 373 to Another Organization", RFC 4691, October 2006. 375 Authors' Addresses 377 Jean-Francois Mule 378 CableLabs 379 858 Coal Creek Circle 380 Louisville, CO 80027 381 USA 383 Email: jf.mule@cablelabs.com 385 W. Mark Townsley 386 Cisco Systems 387 7025 Kit Creek Road 388 PO Box 14987 389 Research Triangle Park, NC 27709 390 USA 392 Email: mark@townsley.net 394 Full Copyright Statement 396 Copyright (C) The IETF Trust (2007). 398 This document is subject to the rights, licenses and restrictions 399 contained in BCP 78, and except as set forth therein, the authors 400 retain all their rights. 402 This document and the information contained herein are provided on an 403 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 404 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 405 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 406 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 407 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 408 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 410 Intellectual Property 412 The IETF takes no position regarding the validity or scope of any 413 Intellectual Property Rights or other rights that might be claimed to 414 pertain to the implementation or use of the technology described in 415 this document or the extent to which any license under such rights 416 might or might not be available; nor does it represent that it has 417 made any independent effort to identify any such rights. Information 418 on the procedures with respect to rights in RFC documents can be 419 found in BCP 78 and BCP 79. 421 Copies of IPR disclosures made to the IETF Secretariat and any 422 assurances of licenses to be made available, or the result of an 423 attempt made to obtain a general license or permission for the use of 424 such proprietary rights by implementers or users of this 425 specification can be obtained from the IETF on-line IPR repository at 426 http://www.ietf.org/ipr. 428 The IETF invites any interested party to bring to its attention any 429 copyrights, patents or patent applications, or other proprietary 430 rights that may cover technology that may be required to implement 431 this standard. Please address the information to the IETF at 432 ietf-ipr@ietf.org. 434 Acknowledgment 436 Funding for the RFC Editor function is provided by the IETF 437 Administrative Support Activity (IASA).