idnits 2.17.1 draft-krishnan-review-process-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 570. 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 (July 13, 2008) is 5758 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4677 (Obsoleted by RFC 6722) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Informational P. Eronen 5 Expires: January 14, 2009 Nokia 6 E. Gray 7 Ericsson 8 July 13, 2008 10 Guidelines to authors and reviewers regarding the IETF review process 11 draft-krishnan-review-process-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 14, 2009. 38 Abstract 40 This document describes the authors' experiences with the IETF review 41 process and provides guidelines to draft authors and reviewers on how 42 to effectively participate in it. This document does not define the 43 IETF review process itself. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Sources of reviews . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Guidelines for authors . . . . . . . . . . . . . . . . . . . . 4 50 3.1. Who responds to reviews . . . . . . . . . . . . . . . . . 4 51 3.2. Before reading the review . . . . . . . . . . . . . . . . 4 52 3.3. Responding to reviews . . . . . . . . . . . . . . . . . . 4 53 3.3.1. Timeframe for response . . . . . . . . . . . . . . . . 5 54 3.3.2. Contents of a response . . . . . . . . . . . . . . . . 5 55 3.4. Keeping track of the issues . . . . . . . . . . . . . . . 7 56 3.5. New version of the draft . . . . . . . . . . . . . . . . . 7 57 4. Guidelines for reviewers . . . . . . . . . . . . . . . . . . . 8 58 4.1. Level of review . . . . . . . . . . . . . . . . . . . . . 8 59 4.2. Recipients of the review . . . . . . . . . . . . . . . . . 9 60 4.3. Classification of the issues . . . . . . . . . . . . . . . 10 61 4.4. Prioritization of the issues . . . . . . . . . . . . . . . 10 62 4.5. Reviewing changes . . . . . . . . . . . . . . . . . . . . 11 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 68 Intellectual Property and Copyright Statements . . . . . . . . . . 14 70 1. Introduction 72 The Tao of the IETF [RFC4677] provides an informal overview of the 73 inner workings of the IETF. This document is intended to augment the 74 information available in [RFC4677] and is mainly concerned about 75 reviews. 77 An Internet Draft's life cycle begins when the author(s) submit the 78 document as a personal draft; it may become a Working Group draft, 79 and usually ends when the draft is published as an RFC, or is 80 abandoned and eventually expires. During its lifetime, a draft is 81 likely to receive review comments from a number people. 83 In our experience, inefficient handling of review comments is one big 84 source of delay and frustration in the IETF standards process. The 85 goal of this document is to help document authors in dealing with 86 reviews in an effective manner. 88 2. Sources of reviews 90 An internet draft gets reviewed at different stages of its lifecycle 91 by different sets of people. When the draft is in the initial stages 92 it gets reviewed mostly by the members of the working group that the 93 draft targets. But as the draft progresses, it gets reviewed by a 94 much more varied set of people with differing fields of expertise. 95 These reviews are performed with a very different point of view than 96 the wg reviews and are likely to bring out cross-area issues. The 97 different sources from which the author can receive reviews are 99 o Working Group participants: Reviews from working group 100 participants are not just reviews, but also an important method of 101 participating in the working group. This document deals primarily 102 with late reviews though some of the concepts may be applicable to 103 early reviews (such as reviews from WG participants) as well. 104 o Other IETF participants -- especially during IETF last call 105 o Review from the area specific review teams. Some review teams try 106 to review all documents -- these include Gen-ART (General Area 107 Review Team) assisting the General Area Director, and SecDir 108 (Security Directorate) assisting the Security Area Directors. 109 Other review teams are more specialized: for example, MIB Doctors 110 review only MIB documents. 111 o Reviews from IESG members: after IETF last call, 112 o Reviews from the IAB 114 3. Guidelines for authors 116 3.1. Who responds to reviews 118 There are several persons who can respond to a received review. If 119 the document is an individual document, it is customary for the 120 author to respond to the review. If the document has several 121 authors, they should co-ordinate among themselves before responding. 122 Otherwise the reviewer may receive conflicting responses from 123 different authors. If the document is a working group document, 124 ideally the WG chairs or the document shepherd should coordinate 125 things, since the author and reviewer cannot unilaterally decide to 126 make substantial changes. The coordination effort (by WG chairs 127 and/or document shepard) may be more or less active, depending on the 128 working group. 130 3.2. Before reading the review 132 Receiving a long review, or a critical review for your favorite 133 document can be disheartening. Before reading the review -- or at 134 the very least, before starting to reply -- it's good to remind 135 yourself about a crucial difference between Internet Draft reviews, 136 and say, reviews about books or movies. 138 A good movie review attempts to give a balanced view: if the reviewer 139 liked the movie, the review will say good things about it. However, 140 a typical review of an Internet Draft will comment only the parts 141 that the reviewer did not like and wants to see changed. 143 The reviewer may well think that your work is excellent quality, and 144 a valuable contribution to Internet engineering -- but it is not 145 common to say this in a review. Thus, when you start reading a 146 review, imagine that the review started with a positive comment -- 147 after all, the reviewer considered this important enough to review 148 it! 150 Hint for reviewers: it helps if you start your review with a positive 151 overall opinion. Although it may not seem so, there's a big 152 difference between saying "The following things have to be fixed:" 153 and "This is a well-written and valuable document; however, I'd like 154 to propose some minor improvements for the following things:" 156 3.3. Responding to reviews 158 Reviewers spend a non-trivial amount of time in performing a review, 159 and reviews also play an important part in how IETF determines 160 consensus. Thus, the single most important rule for handling reviews 161 is the following: every review merits a response. 163 Even if the review said "everything looks ok", saying "thank you for 164 reviewing this" is part of common courtesy. If the reviewer raised 165 issues, a response is deserved, irrespective whether the authors 166 agree with the reviewer or not. 168 3.3.1. Timeframe for response 170 The authors are expected to respond to the reviews within a 171 reasonable amount of time. What constitutes a reasonable amount of 172 time is left to the judgement of the persons involved. e.g. If a 173 document is up for IESG review on a certain date, it may be useful to 174 respond before that date. It is possible that the authors may be 175 unavailable to respond to a review within a given timeline since they 176 may be sick/on vacation/busy with dayjob etc. In this case, the 177 document shepherd (if any) can respond to the review and follow up 178 with the authors at a later time. If the review is not responded to 179 in a timely fashion, then other folks are likely to assume that there 180 is a real problem that needs to be addressed, rather than finding out 181 that the reviewer simply misread the document (reviewers make 182 mistakes too). 184 3.3.2. Contents of a response 186 3.3.2.1. The initial response 188 The initial response that the author sends might be as simple as a 189 single mail that acknowledges the receipt of the review and the 190 intent of the author to look into the contents of the review. It is 191 often helpful if the responding author(s) can also provide some 192 indication of when a subsequent response will be provided to the 193 comments/issues contained in the review -- assuming that a response 194 cannot be provided at once. This sort of response can be helpful in 195 telling the difference between a review that has been forgotten, and 196 one that is being actively worked on. e.g. If the author is busy 197 with his/her day job or on vacation, the document shepherd can ask 198 some other working group member to evaluate the review. 200 3.3.2.2. The substantial response 202 In the substantial response the author tries to address the concerns 203 raised in the review. There are several ways to do this: 205 o Accept the concern as valid and propose a solution 206 o Accept the concern as valid and propose a timeline for a solution 207 o Accept the concern as valid and solicit text from the reviewer for 208 a solution. 210 o Ask for clarifying information to better understand the concern 211 o Explain why the concern is invalid (out of scope, already covered 212 in the document, misunderstanding, etc.) 213 o Other responses that may apply in special cases 214 o Any combination of the above 216 The substantial response needs to be sent at least to the reviewer, 217 the relevant working groups and the mailing list of the reviewing 218 body(if any). It can also be sent to the other recipients of the 219 original review. 221 3.3.2.2.1. Common issues with the substantial response 223 This section tries to document some common mistakes that authors make 224 while responding to a review. 226 o If the reviewer has not understood some part of the draft, a very 227 common response is to explain the topic in email. However, often 228 that explanation should really be in the draft itself, not just in 229 emails to the authors, so that future readers will also understand 230 the text. 231 o Soliciting text from the reviewer should not be used as a default 232 response. It can be helpful, if the authors, even after asking 233 for more information, do not understand the reviewer's concern. 234 It can also be used as a technique for reducing the number of 235 iterations required to arrive at text that is acceptable to the 236 reviewer, or to help in producing review comments that are direct, 237 with a specific focus toward some resolution. Note that, if the 238 author understands the concern, it may be best if an author 239 proposes text -- since text proposed by an author may be less 240 likely to introduce stylistic discontinuities, or result in other 241 issues that an author (who is likely to be more familar with the 242 history of the draft) might avoid. 243 o The reviewer should not be pushy while trying to suggest new text. 244 Instead of writing "Here is the fix for my problem" that imposes 245 the reviewer's will on the author, he or she might write "Here is 246 my proposal for one way to fix this issue; there may of course be 247 other ways to do so. Please consult with the WG and decide on the 248 text to adopt". 249 o Simply accepting the concern as valid is a response that is often 250 seen, but is really good enough only when the solution is obvious 251 (fixing a typo, etc.). For complex comments, saying "I'll change 252 this in the next draft version" may not be enough, since it it may 253 make it difficult for the reviewer to verify the fix, or may 254 result in a fix that is not acceptable to the reviewer. 256 3.4. Keeping track of the issues 258 When the author makes an attempt in good faith to resolve all the 259 issues raised by the reviewer, it is possible that some of the issues 260 are left unresolved in the revised version of the draft. In order to 261 prevent this from happening, it is useful to keep a systematic record 262 of the issues and the associated resolutions. One common way of 263 doing this is by using an issue tracker. The IETF tools team 264 provides an issue tracker on request to any of the working groups and 265 the chairs can add authorized users for the tracker. When the issues 266 are raised by the reviewer, the author can open the issue on the 267 issue tracker and close it when it is resolved. The author can also 268 add the suggested resolution text into the tracker. This way both 269 the author and the reviewer can keep tabs on the change process 270 without missing out any issues. 272 For a document in Working Group Last Call or IETF wide Last Call it 273 is considered good practice for the WG chair or the document shepherd 274 to ensure that someone posts a summary of all the comments received 275 during the last call, and current proposal for handling them. If the 276 WG chair or shepherd does not do this, the task of producing a 277 summary falls to the author, or authors. Note that - if no such 278 summary is produced - it will be very difficult for working group 279 members (or the IETF at large) to determine that the changes made 280 were in line with the changes discussed and agreed to. This summary 281 could include links to mailing list archives, or if an issue tracker 282 is used, issue numbers or links to "tickets". 284 3.5. New version of the draft 286 The details of dealing with response resolutions may vary slightly 287 from working group to working group, but -- generally -- the 288 following approaches are used at the indicated stages: 290 o Prior to acceptance as a WG draft, Author(s) are free to publish a 291 new version with or without including specific resolutions - 292 bearing in mind that acceptance by a WG is only likely if a) the 293 text is essentially headed in the right direction and b) the WG is 294 inclined to believe the current Author(s) are the right ones for 295 the job. 296 o Once accepted as a WG draft, and through completion of a final WG 297 Last Call, the Author(s) need confirmation (typically from 298 discussions on the working group mailing list, or at meetings and 299 subsequently confirmed on the mailing list) of all substantive 300 changes prior to publishing a modified version. Prior to last 301 call, the necessary confirmation may simply be a general direction 302 proposed and accepted at an IETF meeting and not refuted in 303 minutes published. Often prior to last call, the Author(s) may 304 explicitly solicit help from WG members who've expressed concerns 305 about specific portions of draft in an effort to reach convergence 306 in a subsequent IETF WG meeting. Once Last Call has started, each 307 substantive change will typically require explicit confirmation on 308 the WG mailing list. 309 o Once the document has entered IESG processing (post WG Last Call), 310 new versions should not be posted unless the document shepherd or 311 (responsible) AD explicitly says so. Typically, this will occur 312 only after the responsible individual is certain that the Authors 313 have addressed all of the outstanding comments - both substantive 314 and editorial. 315 o At any point after WG Last Call, the IESG may decide that all 316 remaining comments may be addressed via a note to the RFC Editor. 317 Typically, this would occur if all remaining comments are 318 relatively minor, strictly editorial or of a type that would best 319 be dealt with by the RFC Editor in any case. 321 4. Guidelines for reviewers 323 4.1. Level of review 325 The level of review performed on the draft varies greatly based on 326 the source of the review and on the stage of the document lifecycle. 327 In the earlier stages of the lifecycle, the document is usually 328 reviewed by the members of the relevant working group(s) only, 329 although the working group chairs and (usually) ADs should take at 330 least a brief look at the draft. Let's call these reviews "early 331 reviews". 333 At this point the comments on the draft are deeply technical and 334 mainly remove obvious errors from the draft. It is also a good idea 335 for working group members, working group chairs and/or ADs, to review 336 early drafts for "meta issues" (such as Internet Architecture impact, 337 special security exposures, manageablity, scale, consistency with 338 chartered goals, etc.) that may be a problem later and result in 339 potentially going back to the drawing board. Reviewer(s) and 340 author(s) are usually from similar backgrounds and are able to 341 understand the underlying technologies and jargon in a consistent 342 fashion. 344 The reviews that occur after the draft has been progressed from the 345 working group have a very different focus with respect to the 346 contents of the draft. They explore broader aspects of the draft 347 (such as security, operations, readability, etc.) that are not 348 usually on the top of the list of priorities of the authors and the 349 early reviewers - at least during most reviews. They also explore 350 how the mechanisms proposed in the document fit into the Internet 351 architecture as a whole and what detrimental effects they will have, 352 if any. Note that these reviews are where it will come out if the 353 very earliest reviews did not consider where the drafts were going 354 because it is at this point that a poorly directed draft is very 355 likely to stall. Let's call these "late reviews". 357 The person performing the review should consider this when the review 358 is being performed and concentrate their efforts on the right parts 359 of the document. 361 4.2. Recipients of the review 363 The list of recipients of the review is tricky to get right. The 364 main idea is to make sure all the relevant people receive the review. 365 The recipient list is determined mainly by the following factors. 367 o The timeframe of the review (early vs. late) 368 o The contents of the review (editorial vs. technical) 370 Early reviews are usually performed by active participants of a 371 working group. The preferred destination for these reviews is the 372 working group mailing list since it can be reasonably assumed that 373 the persons interested in the document are subscribed to the mailing 374 list. This applies for both technical and editorial issues. 375 Alternately editorial issues can be resolved using a private mail to 376 the author(s). 378 Late reviews are usually performed by persons who are not active 379 participants of the working group and who usually review the draft 380 from a different point of view than the working group. If the 381 contents of the review are mainly editorial in nature, the reviews 382 can be sent just to the authors, the working group chair(s), the 383 document shepherd(s). If the review is of a more technical nature it 384 is considered polite to include the working group mailing list and/or 385 the IETF discussion list. As it is not reasonable to assume that the 386 reviewer will subscribe to the working group mailing list just for 387 discussing this issue, the working group chair(s) need to make sure 388 that this review will get past any moderation controls imposed on 389 non-subscribers by the working group mailing list. 391 4.3. Classification of the issues 393 While writing a review, the reviewer needs to distinguish between 394 different types of comments. On a really high level review comments 395 may be classified into two types 397 o Actionable comments: These comments contain statements that can be 398 either proved or disproved. e.g. "The protocol described in this 399 document will not work in networks with lossy link layers". This 400 creates the opportunity for the reviewer and working group to 401 discuss the issue in terms that can be tested. In order to ask 402 the working group to do so, a reviewer should be able to back his/ 403 her statement with a reasonably clear, worked set of reasons for 404 the assertion. A working group can go about disproving the 405 statement, and if it fails to do so, it can either make the 406 necessary technical changes or write up an applicability statement 407 that documents the cases where the protocol works well enough to 408 be useful. 409 o Observations: These comments are not testable statements but 410 merely opinion/commentary of the reviewer. e.g. " I think this 411 protocol should run on top of TCP rather than on top of UDP 412 because it needs reliable transport". This kind of comments may 413 be very valuable as well, but they should not blindly overrule the 414 consensus of the working group. These should be treated as issues 415 that the wg and the author need to evaluate carefully. 417 Reviewers should be sensitive to the difference between their 418 personal opinions (and preferences) and issues that will affect the 419 correct operation or interoperation of the documents under review. 421 4.4. Prioritization of the issues 423 A review often results in a list of issues or requested 424 clarifications. The reviewer may choose to list them in the order 425 they appear in the document. For long drafts, where structure and 426 content maturity is fairly well established, this approach is easier 427 to follow. Alternatively (and possibly preferably, depending on the 428 maturity of the draft and other factors), the reviewer can use 429 another classification scheme where the issues are grouped together 430 by importance and/or potential impact on the draft. This makes it 431 easier for eventual recipients of the review to attach the 432 appropriate priority for resolving the issues. At early stages of 433 draft maturity, this approach can be critical, because resolving some 434 issues may impact on appropriate resoluton alternatives for other 435 issues. If a review is sent on behalf of a reviewing body (such as 436 might be the case with a review reported by a liaison statement), 437 this also helps the beneficiary of the review in taking a position on 438 the document. For example, A reviewer might classify issues into the 439 following categories 441 o Major 442 o Minor 443 o Editorial 444 o Nits 446 The purpose of such a prioritization scheme might be to indicate the 447 level of discomfort the reviewing entity will feel with the results 448 of any resolution that does not address the concerns at each level of 449 priority. 451 It is almost always a good idea to separate at least the editorial 452 comments (and NITs) from those impacting on the substance of the 453 draft at any stage of draft maturity. A key reason for doing this is 454 that this allows most people who will read the review to concentrate 455 on the portions of the review that impact on the substance of the 456 document, primarily to ensure that they do not have fundamental 457 issues with the review comments or proposed resolutions. Note that 458 this is not a license to put forward omission of key words (such as 459 "not") as minor editorial comments (or NITs). 461 If comments are grouped in any way, however, the grouping may very 462 well be "of the essence" of the comments. In other words, if the 463 responder does not agree with the distinctions made by the reviewer, 464 they should be clear about this. This is, in part, to ensure that 465 something that a reviewer thought to be minor -- but which an author 466 felt to be fundamental -- receives the right amount of attention on 467 reading by others. 469 4.5. Reviewing changes 471 Once the authors submit a new revision of the draft, the reviewer can 472 look over the new revision to see if the agreed changes have been 473 made to the draft. If the reviewer finds out that some changes have 474 not been made, he/she can alert the authors of this fact. There are 475 tools available that can make the reviewer's life easier in this 476 regard. The rfcdiff tool can be used to identify the changes made in 477 the latest version of the draft. The reviewer can just look over 478 these changes instead of rereading the entire draft. The reviewers 479 can also keep track of issues using the issue tracker used by the 480 authors(if one was used). If the reviewer is satisfied with the 481 changes, he/she can send out a mail to the original recipients of the 482 review mentioning this. If not, a new generation of the review cycle 483 is started and the steps described earlier are redone. 485 5. Acknowledgements 487 The authors would like to thank Bernard Aboba, Thomas Narten, Frank 488 Ellermann, Ted Hardie, Paul Hoffman, Thomas Goldbeck-Lowe, Scott 489 Brim, Joel Halpern, Brian Carpenter, Iain Calder, Dan Romascanu and 490 SM for their contributions to this document. 492 6. IANA Considerations 494 This document does not require any action from the IANA. 496 7. Security Considerations 498 This document does not create any new security issues. 500 8. Normative References 502 [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's 503 Guide to the Internet Engineering Task Force", RFC 4677, 504 September 2006. 506 Authors' Addresses 508 Suresh Krishnan 509 Ericsson 510 8400 Decarie Blvd. 511 Town of Mount Royal, QC 512 Canada 514 Phone: +1 514 345 7900 x42871 515 Email: suresh.krishnan@ericsson.com 517 Pasi Eronen 518 Nokia Research Center 519 P.O. Box 407 520 FI-00045 Nokia Group 521 Finland 523 Email: pasi.eronen@nokia.com 524 Eric Gray 525 Ericsson 526 900 Chelmsford Street 527 Lowell, MA 528 USA 530 Email: Eric.Gray@Ericsson.com 532 Full Copyright Statement 534 Copyright (C) The IETF Trust (2008). 536 This document is subject to the rights, licenses and restrictions 537 contained in BCP 78, and except as set forth therein, the authors 538 retain all their rights. 540 This document and the information contained herein are provided on an 541 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 542 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 543 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 544 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 545 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 546 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 548 Intellectual Property 550 The IETF takes no position regarding the validity or scope of any 551 Intellectual Property Rights or other rights that might be claimed to 552 pertain to the implementation or use of the technology described in 553 this document or the extent to which any license under such rights 554 might or might not be available; nor does it represent that it has 555 made any independent effort to identify any such rights. Information 556 on the procedures with respect to rights in RFC documents can be 557 found in BCP 78 and BCP 79. 559 Copies of IPR disclosures made to the IETF Secretariat and any 560 assurances of licenses to be made available, or the result of an 561 attempt made to obtain a general license or permission for the use of 562 such proprietary rights by implementers or users of this 563 specification can be obtained from the IETF on-line IPR repository at 564 http://www.ietf.org/ipr. 566 The IETF invites any interested party to bring to its attention any 567 copyrights, patents or patent applications, or other proprietary 568 rights that may cover technology that may be required to implement 569 this standard. Please address the information to the IETF at 570 ietf-ipr@ietf.org.