idnits 2.17.1 draft-itu-isoc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 1998) is 9325 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) == Unused Reference: 'RFC2026' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC2223' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC2418' is defined on line 388, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2223 (Obsoleted by RFC 7322) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R.F. Brett, ITU-T TSAG Vice-Chair 2 Internet Draft Nortel Networks 3 Expires in six months S. Bradner, ISOC VP Standards 4 Harvard University 5 Glenn Parsons, Editor 6 Nortel Networks 8 October 1998 10 Collaboration between ISOC/IETF and ITU-T 11 13 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It 21 is inappropriate to use Internet Drafts as reference material or to 22 cite them other than as a "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Copyright Notices 31 Copyright (C) The Internet Society (1998). All Rights Reserved. 32 Copyright (C) ITU 1998. All Rights Reserved. 34 Overview 35 This document describes the collaboration process between the ITU-T 36 and ISOC/IETF. The process was documented by ITU-T at its TSAG 37 (Telecommunication Standardization Advisory Group) meeting in 38 September 1998 and focuses primarily on the ITU-T side of the 39 process. All participants at this meeting (including Study Group 40 chairmen and the ISOC Vice President for Standards) assisted in the 41 creation of this document. Subsequently, it was sent to all ITU-T 42 Study Groups and ISOC/IETF to ensure that everyone was aware of the 43 process. Feedback was requested by the next meeting of TSAG in 44 April 1999. This document is identical to the document produced 45 by TSAG. 47 Please send any comments on this document to ISOC at poised@tis.com 48 and for information to the ITU-T TSAG group at tsagco-op@itu.int 50 ISOC/IETF and ITU-T Collaboration 52 1 Scope 53 This Liaison is sent to all ITU-T Study Groups to encourage and aid 54 in the understanding of collaboration on standards development 55 between the ITU-T and the Internet Society (ISOC) / Internet 56 Engineering Task Force (IETF). Feedback to TSAG is encouraged 57 before its next meeting in April 1999. 59 2 Introduction 60 The telecommunication industry is faced with an explosion in growth 61 of the Internet and other IP (Internet Protocol) based networks. 62 Operators, manufacturers and software/application providers alike are 63 reconsidering their business directions and Standards Development 64 Organizations and Forums and Consortia are facing an immense 65 challenge to address this situation. These challenges were 66 considered by TSAG at its meeting in Geneva, 7-11 September 1998, 67 where it recognized that although the ITU-T and ISOC/IETF are already 68 collaborating in a number of areas, this collaboration must be 69 strengthened within the context of changes in work emphasis and 70 direction within the ITU-T on studies related to IP based networks. 72 For example, many Study Groups (e.g., 7, 8 & 16) already address 73 several the aspects of IP based networks. Further, new IP related 74 work activities are starting in other Study Groups (e.g., 4, 11 & 75 13). There are many potential areas of interest to ITU-T Study 76 Groups in the IP area that should be investigated (e.g., signaling, 77 routing, security, numbering & addressing, integrated management, 78 performance, IP - telecom interworking, access). Since many of 79 these areas are also being investigated by the IETF, there is a 80 requirement for close collaboration. 82 Recommendations A.4, A.5 and A.6 already document the process for 83 working with other organizations and their documents. Since there 84 are no specific guidelines on the process of collaboration with the 85 IETF, this liaison is meant to provide that information. The current 86 level of cooperation between the ITU-T and the IETF should be built 87 upon to ensure that the competence and experience of each 88 organization is brought to bear in the most effective manner and in 89 collaboration with the other. 91 3 Guidance on Collaboration 92 TSAG has been made aware of several instances of existing successful 93 collaboration between the ITU-T and ISOC/IETF. This section builds 94 on this existing process and details some of the more important 95 guidance points that Study Groups should be aware of in their 96 collaboration with ISOC/IETF. 3.1 How to interact on ITU-T or IETF 97 work items. 99 Study Groups that have identified work topics that are Internet 100 related should evaluate the relationship with topics defined in the 101 IETF. Current IETF Working Groups and their charters (IETF 102 definition of the scope of work) are listed in the IETF archives (see 103 section 3.5). A Study Group may decide that development of a 104 Recommendation on a particular topic may benefit from collaboration 105 with the IETF. 107 The Study Group should identify this collaboration in its work plan 108 (specifically in that of each Question involved), describing the goal 109 of the collaboration and its expected outcome. It is anticipated 110 that an IETF Working Group would also evaluate and identify areas of 111 relationship with the ITU-T and document the collaboration with the 112 ITU-T Study Group in its charter. 114 The following sections outline a process that can be used to enable 115 each group to learn about the others new work items. 117 3.1.1 How the ITU-T learns about existing IETF work items 118 The responsibility is on individual Study Groups to review the 119 current IETF Working Groups to determine if there are any topics of 120 mutual interest. Should a Study Group believe that there is an 121 opportunity for collaboration on a topic of mutual interest it should 122 contact both the IETF Working Group Chair and the Area Director 123 responsible. 125 3.1.2 How the ITU-T learns about proposed new IETF work items 126 The IETF maintains a mailing list for the distribution and discussion 127 of proposed new Working Group charters amongst the management team. 128 To add or change a subscription to this list, send a message to iesg- 129 secretary@ietf.org indicating who you are and that you would like to 130 subscribe to the New Work mailing list. Details on the list process 131 will be emailed to each subscriber. 133 It is recommended that each Study Group chairman (or a delegate) 134 subscribe to this list and monitor the new work items for possible 135 overlap or interest to their Study Group. It is expected that this 136 mailing list will see one or two messages per month. Chairmen should 137 identify their comments on these charters by responding to the IESG 138 mailing list at iesg@ietf.org clearly indicating their ITU-T position 139 and the nature of their concern. It should be noted that the IETF 140 turnaround time for new Working Group charters is one week. As a 141 result, the mailing list should be consistently monitored. 143 3.1.3 How the IETF learns about ITU-T work items 144 An initial list of Internet related topics in ITU-T Study Groups 145 based on the situation as of 11 September is being provided to the 146 Vice President of Standards for ISOC for distribution to the 147 appropriate IETF interested individuals and will be copied to all 148 ITU-T Study Group Chairmen. The intention is for Study Groups to 149 forward updates to the Vice President of Standards for ISOC as they 150 occur. 152 It is expected that any IETF Working Group interest with the topics 153 being covered by the ITU-T will be forwarded to individual Study 154 Group Chairmen (or the lead Study Group Chairman) by the Vice 155 President of Standards for ISOC. 157 3.2 Representation 158 ISOC, including its standards body IETF, have been admitted by the 159 ITU Council to participate in the work of the ITU-T. As a result, 160 ISOC delegates are therefore afforded equivalent rights to those of 161 other ITU-T Study Group participants (see 3.2.1). Conversely, ITU-T 162 delegates may participate in the work of the IETF as individuals or 163 be recognized as ITU-T delegates (see 3.2.2). To promote 164 collaboration it is useful to facilitate communication between the 165 organizations as further described below. 167 3.2.1 IETF Recognition at ITU-T 168 Participants from the IETF may participate in ITU-T meetings as ISOC 169 delegates if the appropriate IETF Working Group (or area) has 170 approved their attendance. This approval will be communicated to the 171 TSB in the form of a registration for a particular ITU-T meeting by 172 the Vice President of Standards for ISOC. 174 3.2.2 ITU-T Recognition at ISOC/IETF 175 ITU-T Study Group Chairmen can authorize one or more members to 176 attend an IETF meeting as an official ITU-T delegate speaking on 177 behalf of the Study Group (or a particular Rapporteur Group). The 178 Study Group Chairman communicates the ITU-T list of delegates by 179 email to the Vice President of Standards for ISOC and also to the 180 Study Group. The email address of the Vice President of Standards 181 for ISOC is vp-standards@isoc.org. 183 3.2.3 Communication contacts 184 To foster ongoing communication between the ITU-T and ISOC/IETF, it 185 is important to identify and establish contact points within ITU-T 186 Study Groups for specific IETF topics of mutual interest. It is 187 beneficial to identify these contact points early and in some cases 188 the contact point identified by each organization may be the same 189 individual. It is responsibility of a Study Group to establish the 190 contact points with the IETF and maintain the list on its web page. 192 An example of communication contacts that is suggested to Study 193 Groups has both a high level and a working level: 195 1. ITU-T Study Group Chairman and IETF Area Director 196 An IETF Area Director is the individual responsible for overseeing 197 a major focus of activity with a scope similar to that of an ITU-T 198 Study Group Chairman. These positions are both relatively long- 199 term (of several years) and offer the stability of contact points 200 between the two organizations for a given topic. 202 2. ITU-T Rapporteur and IETF Working Group Chair 203 An IETF Working Group Chair is an individual who is assigned to 204 lead the work on a specific task within one particular area with a 205 scope similar to that of an ITU-T Rapporteur. These positions are 206 working positions (of a year or more) that typically end when the 207 work on a specific topic ends. Collaboration here is very 208 beneficial to ensure the actual work gets done. Note that the 209 current IETF Area Directors and Working Group chairs can be found 210 in the IETF Working Group charters. The current ITU-T Study Group 211 chairmen and Rapporteurs are listed on the ITU-T web page. 213 Both the ITU-T and IETF may assign their contact point function(s) to 214 other individuals than those suggested as it deems appropriate. 216 3.2.4 Communication 217 Informal communication between contact points and experts of both 218 organizations is encouraged. However, note that formal communication 219 from an ITU-T Study Group, Working Party or Rapporteur to an 220 associated IETF contact point must be explicitly approved and 221 identified as coming from the Study Group, Working Party or 222 Rapporteur Group, respectively. Conversely, formal communication 223 from an IETF Working Group or Area Director must also be explicitly 224 approved and identified before forwarding to any ITU-T contact. 225 Formal communication is intended to allow the sharing of positions 226 between the IETF and the ITU-T outside of actual documents (as 227 described in 3.3). This would cover such things as comments on 228 documents and requests for input. The approved communication is 229 simply emailed from one body contact to another (the appropriate 230 mailing lists, as described in 3.2.5 may be copied). 232 3.2.5 Mailing Lists All IETF Working Groups and all ITU-T Study Group 233 Questions have associated mailing lists. 235 In the IETF, the mailing list is the primary vehicle for discussion 236 and decision making. It is recommended the ITU-T experts interested 237 in particular IETF working group topics subscribe to and participate 238 in these lists. The IETF Working Group mailing list subscription and 239 archive information are noted in each Working Group's charter. In 240 the ITU-T, the TSB has set up formal mailing lists for Questions, 241 Working Parties and other topics within Study Groups (more detail can 242 be found on the ITU website.). These mailing lists are typically 243 used for discussion of ITU-T contributions. Note that individual 244 subscribers to this list must be affiliated with an ITU-T member (at 245 this time, there is no blanket inclusion of all IETF participants as 246 members, however, as a member ISOC may designate representatives to 247 subscribe). Alternatively, ITU-T members operate personal mailing 248 lists on various topics with no restrictions on membership (e.g., 249 IETF participants are welcome). 251 3.3 Document Sharing 252 During the course of ITU-T and IETF collaboration it is important to 253 share working drafts and documents among the technical working 254 groups. Initial proposed concepts and specifications typically can 255 be circulated by email (often just repeating the concept and not 256 including the details of the specification) on both the IETF and ITU- 257 T mailing lists. In addition, working texts (or URLs) of draft 258 Recommendations or RFCs (Internet Drafts) may also be sent between 259 the organizations as described below. 261 3.3.1 IETF to ITU-T 262 IETF documents (e.g., Internet Drafts) can be submitted to a Study 263 Group as a Contribution from ISOC. In order to ensure that the IETF 264 has properly authorized this, the IETF Working Group must agree that 265 the specific drafts are of mutual interest and that there is a 266 benefit in forwarding them to the ITU-T for review, comment and 267 potential use. Once agreed, the Vice President Standards for ISOC 268 would review the Working Group request and give approval. The 269 contributions would then be forwarded (with the noted approval) to 270 the TSB for circulation as a Study Group Contribution. 272 3.3.2 ITU-T to IETF 273 A Study Group may send texts of draft new Recommendations to the IETF 274 as contributions in the form of Internet Drafts. Internet Drafts are 275 IETF temporary documents that expire six months after being 276 published. The Study Group must decide that there is a benefit in 277 forwarding them to the IETF for review, comment and potential use. 278 Terms of reference for Rapporteur Group meetings may authorize 279 Rapporteur Groups to send working documents, in the form of Internet 280 Drafts, to the IETF. In both cases, the document editor would be 281 instructed to prepare the contribution in Internet Draft format (in 282 ASCII and optionally postscript format as per RFC2223) and submit it 283 to the Internet Draft editor (email internet-drafts@ietf.org). 284 Alternatively, the Study Group or Rapporteur Group could agree to 285 post the document on a web site and merely document its existence 286 with a short Internet Draft that contains a summary and the document 287 URL. 289 Both the Rapporteur and the Document Editor should be identified as 290 contacts in the contribution. The contribution must also clearly 291 indicate that the Internet Draft is a working document of a 292 particular ITU-T Study Group. 294 3.3.3 ITU-T & IETF 295 It is envisaged that the processes of 3.3.1 & 3.3.2 will often be 296 used simultaneously by both an IETF Working Group and an ITU-T Study 297 Group to collaborate on a topic of mutual interest. It is also 298 envisaged that the outcome of the collaboration will be the 299 documentation in full by one body and its referencing by the other 300 (see section 3.4 for details). That is, common or joint text is 301 discouraged because of the current differences in approval, revision 302 and stability of approved documents for publication by each body. 304 3.4 Simple cross referencing 305 ITU-T Recommendation A.5, specifically its Annex A and the 306 application guidelines attached, describes the process for 307 referencing IETF RFCs in ITU-T Recommendations. IETF RFC2026, 308 specifically section 7.1.1, describes the process for referencing 309 other open standards (like ITU-T Recommendations) in IETF RFCs. 311 3.5 Additional items 312 Several URLs to IETF procedures are provided here for information: 314 RFC2223 - Instructions to RFC Authors, October 1997 315 ftp://ftp.isi.edu/in-notes/rfc2223.txt 316 RFC2026 - The Internet Standards Process Revision 3, October 1996 317 ftp://ftp.isi.edu/in-notes/rfc2026.txt 318 RFC2418 - IETF Working Group Guidelines and Procedures, September 319 1998 ftp://ftp.isi.edu/in-notes/rfc2418.txt 320 Current list and status of all IETF RFCs ftp://ftp.isi.edu/in- 321 notes/rfc-index.txt 322 Current list and description of all IETF Internet Drafts: 323 ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt 324 Current list of IETF Working Groups and their Charters: (includes 325 Area Directors and Chair contacts, Mailing list information, etc.) 326 http://www.ietf.org/html.charters/wg-dir.html 327 Current ITU-T information can be found on the ITU website: (includes 328 contacts, organization, Recommendations for purchase, mailing list 329 info, etc.) http://www.itu.int 331 5. Acknowledgments 332 The process was documented by ITU-T at its TSAG (Telecommunication 333 Standardization Advisory Group) meeting in September 1998. All 334 participants of this meeting (including Study Group chairmen and the 335 ISOC Vice President for Standards) assisted in the creation of this 336 document. Subsequently, it was sent to all ITU-T Study Groups and 337 ISOC/IETF to ensure that everyone was aware of the process. Feedback 338 is requested by the next meeting of TSAG in April 1999. 340 6. Security Considerations 341 This type of non-protocol document does not directly effect the 342 security of the Internet. 344 7. Authors' Addresses 346 ITU-T Contact: 347 R. F. Brett 348 Nortel Networks 349 P.O. Box 3511, Station C 350 Ottawa, ON K1Y 4H7 351 Canada 352 Phone: +1-613-828-0902 353 Fax: +1-613-828-9408 354 Email: rfbrett@nortel.ca 356 ISOC Contact: 357 Scott O. Bradner 358 Harvard University 359 Holyoke Center, Room 876 360 1350 Mass. Ave. 361 Cambridge, MA 02138 362 USA 363 Phone: +1 617 495 3864 364 Email: sob@harvard.edu 366 Editor: 367 Glenn W. Parsons 368 Nortel Networks 369 P.O. Box 3511, Station C 370 Ottawa, ON K1Y 4H7 371 Canada 372 Phone: +1-613-763-7582 373 Fax: +1-613-763-4461 374 Email: Glenn.Parsons@Nortel.ca 376 8. References 377 [A.4] ITU-T Recommendation A.4 - Communication process between ITU-T 378 and forums and consortia, October 1996. 379 [A.5] ITU-T Recommendation A.5 - Generic procedures for including 380 references to documents to other organizations in ITU-T 381 Recommendations, January 1998. 382 [A.6] ITU-T Recommendation A.6 - Cooperation and exchange of 383 information between ITU-T and national and regional standards 384 development organizations, September 1998. 385 [RFC2026] RFC 2026, The Internet Standards Process - Revision 3, 386 October 1996. 387 [RFC2223] RFC 2223, Instructions to RFC Authors, October 1997 388 [RFC2418] RFC 2418, IETF Working Group Guidelines and Procedures, 389 September 1998 391 9. Full ISOC Copyright Statement 393 Copyright (C) The Internet Society (1998). All Rights Reserved. 395 This document and translations of it may be copied and furnished to 396 others, and derivative works that comment on or otherwise explain it 397 or assist in its implmentation may be prepared, copied, published and 398 distributed, in whole or in part, without restriction of any kind, 399 provided that the above copyright notice and this paragraph are 400 included on all such copies and derivative works. However, this 401 document itself may not be modified in any way, such as by removing 402 the copyright notice or references to the Internet Society or other 403 Internet organizations, except as needed for the purpose of 404 developing Internet standards in which case the procedures for 405 copyrights defined in the Internet Standards process must be 406 followed, or as required to translate it into languages other than 407 English. 409 The limited permissions granted above are perpetual and will not be 410 revoked by the Internet Society or its successors or assigns. 412 This document and the information contained herein is provided on an 413 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 414 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 415 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 416 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 417 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 419 10. Full ITU Copyright Statement 421 Copyright (C) ITU (1998). All Rights Reserved. 423 No part of this publication may be reproduced or utilized in any form 424 or by any means, electronic or mechanical, including photocopying and 425 microfilm, without permission in writing from the ITU. 427 11. Annex A 428 APPLICATION GUIDELINES ON REFERENCING DOCUMENTS FROM OTHER 429 ORGANIZATIONS 431 PART I - Developed by TSAG at its January 1998 Meeting 433 The following guidelines should be used in conjunction with the 434 relevant provisions of Recommendations A.3, A.4, A.5 and A.23. 436 1. Ownership/Change Control 438 - When considering using material from other organizations it is 439 preferable to only include references to other standards, 440 rather than incorporate text from a standard in the body of a 441 Recommendation. Exceptionally, full text incorporation is 442 necessary rather than a reference where Recommendations having 443 regulatory connotations are concerned. 445 - Reference should be made to the particular issue of a standard. 446 In this way the ITU-T is in control of what is actually 447 referenced even if the source organization updates the 448 standard. 449 - References to standards from other organizations should only be 450 made where those organizations continue to provide public 451 access to the version referenced even when updated versions are 452 issued. 453 - When a draft Recommendation is being prepared and the intention 454 is to reference a standard from another organization, that 455 organization should be advised by the TSB of the ITU-T's 456 intention and should be requested to notify the ITU-T of any 457 impending changes to the standard and of any reissues of the 458 standard. (This request may be part of the correspondence 459 described in Recommendation A.5, section 2.4.) It is however 460 the responsibility of the Study Group to regularly review its 461 Recommendations and check if the references are correct and if 462 necessary to reissue the Recommendation with revised references 463 (and where necessary make changes in the body of the 464 Recommendation where the reference is made.). 465 - Should an organization intend to remove completely an earlier 466 version of a standard the ITU-T should be advised so that it 467 can either incorporate the text in the Recommendation or change 468 the reference to a later version. 470 2. Access 472 - The objective is to have referenced standards freely available 473 via the Web so that people purchasing a Recommendation may get 474 access to the references. A warning should be given to 475 purchasers of ITU-T Recommendations that they may have to 476 additionally purchase the referenced standards. This could be 477 done by including a note to such effect in the introduction to 478 Recommendations where references are included. 479 - When developing a Recommendation where consideration is being 480 given to using references to other standards the Study Group 481 should investigate with the TSB whether the referenced text 482 will be available free of charge or if a payment will be 483 required. This should be taken into account by the Study Group 484 as it may influence the decision to use the reference. 486 3. IPR 487 - In principle, if the IPR policy of the organization owning a 488 referenced standard is more stringent than that of the ITU-T 489 then there should not be any IPR problems with including the 490 reference. However, this may not be the case with all 491 organizations. Further guidelines are being prepared by the 492 Director of the TSB. 494 4. Approval 495 - The approval procedures in Resolution 1 have to be followed for 496 Recommendations containing references (wholly or in part) to 497 standards from other bodies even in the case where the 498 Recommendation is just a reference to another standard. 500 PART II - Developed by TSAG at its September 1998 Meeting 502 The following guidelines should be used in conjunction with 503 Recommendation A.5. 505 1. Nested References 506 Issue: RFCs often contain references to related RFCs and ITU-T 507 Recommendations which, in turn, may contain references to other 508 RFCs and Recommendations. It is unclear how to handle these nested 509 references in the context of A.5. 511 Guideline: Each time an RFC is referenced within an ITU-T 512 Recommendation, all references within that RFC should be listed in 513 the report documenting the decision of the Study Group. No further 514 treatment is necessary, although the Study Group may wish to 515 investigate those references further on a case-by-case basis. The 516 same guidelines apply when referencing the documents of other 517 organizations. 519 2. Subsequent Referencing of the Same Document 520 Issue: It is possible that the same RFC may be considered for 521 referencing in multiple Recommendations. It is unclear what 522 evaluation is required in subsequent references. 524 Guideline: The justification for referencing the same document in 525 different Recommendations is likely to be different. Consequently, 526 it is important that separate evaluations be made each time the 527 document is referenced. However, only items 1 - 8 in Appendix I 528 (and Annex A) of Recommendation A.5 need to be completed if the 529 referenced organization has already been qualified per Section 3 530 of A.5. Since items 9 and 10 are dependent on the organization and 531 not on the document, they need to be completed only the first time 532 a document from that organization is being considered for 533 referencing and only if such information has not been documented 534 already. 536 3. Availability of Referenced Document 537 Issue: Paragraph 2.2.10 of A.5 requires that the contributing 538 Study Group member provide a full copy of the existing document. 539 It is unclear whether paper copies are mandatory or whether 540 electronic availability, for example, on a Web site, is 541 sufficient. 543 Guideline: The objective is to have referenced documents available 544 via the Web at no cost so that the Study Group members may proceed 545 with their evaluation. Accordingly, if a referenced document is 546 available in this manner, it is sufficient for the contributing 547 member to provide its exact location on the Web. On the other 548 hand, if the document is not available in this manner, a full copy 549 must be provided (in electronic format if permissible by the 550 referenced organization, otherwise in paper format). 552 4. Referencing of IETF Documents 553 Issue: It is unclear whether or not it is appropriate to reference 554 RFCs that are not on the standards track (the "Informational" and 555 "Experimental" RFCs) or those that are at the first level of 556 standardization (the "Proposed Standard" RFCs). 558 Guideline: Some outputs of organizations may not be appropriate 559 for normative referencing, others may not be appropriate for any 560 referencing, normative or informative. In the case of the IETF, it 561 is not appropriate to make any references to "Internet Drafts" or 562 to "Historic" RFCs as noted in A.5. In addition, it is not 563 appropriate to make normative references to RFCs that are 564 considered "Informational" or "Experimental". References to RFCs 565 that have the status of "Proposed Standards" should be made with 566 caution and should be evaluated on a case-by-case basis because 567 such standards are considered immature in the sense that they may 568 change if problems are found in real implementations or if better 569 solutions are identified. 571 5. IETF Address Changes 572 The electronic address of the IETF archives has changed. 573 Accordingly the addresses in items 4 and 9.8 of Annex A should be 574 changed, respectively to: 575 http://www.ietf.org/ipr.html - for the IPR archive 576 http://www.rfc-editor.org/rfc.html - for the RFC archive