idnits 2.17.1 draft-iesg-sponsoring-guidelines-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 721. 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 (March 5, 2007) is 6261 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.narten-iana-considerations-rfc2434bis' is mentioned on line 623, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3932 (Obsoleted by RFC 5742) == Outdated reference: A later version (-09) exists of draft-ietf-proto-wgchair-doc-shepherding-07 == Outdated reference: A later version (-04) exists of draft-iab-rfc-editor-01 == Outdated reference: A later version (-05) exists of draft-klensin-rfc-independent-02 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko (Editor) 3 Internet-Draft Ericsson 4 Intended status: Informational March 5, 2007 5 Expires: September 6, 2007 7 Guidance on Area Director Sponsoring of Documents 8 draft-iesg-sponsoring-guidelines-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 6, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This note discusses the process related to "individual submissions", 42 publication of RFCs by finding a sponsoring Area Director to take it 43 through IETF and Internet Engineering Steering Group (IESG) review. 44 This note covers both the the processing in the IESG as well as 45 guidance on when such sponsoring is appropriate. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 51 3. Submission . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 4 53 5. Choosing Documents to Sponsor . . . . . . . . . . . . . . . . 5 54 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 7. Summary of Changes to Existing Procedures . . . . . . . . . . 10 56 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 57 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 60 10.2. Informative References . . . . . . . . . . . . . . . . . 11 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 62 Appendix B. Secretariat Response to Submissions . . . . . . . . . 12 63 Appendix C. PROTO Write-Up . . . . . . . . . . . . . . . . . . . 13 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 Intellectual Property and Copyright Statements . . . . . . . . . . 17 67 1. Introduction 69 "Individual submissions" are documents intended to become RFCs 70 through the IETF, without being submitted by a Working Group (WG). 71 The publication of these documents requires the authors to find 72 sponsoring Area Director (AD) to take it through IETF and Internet 73 Engineering Steering Group (IESG) review. Accordingly, this 74 publication method is sometimes called the "AD Sponsored" method. 76 The note is concerned with the IESG processing by the AD Sponsored 77 method. This note also provides guidance for choosing between 78 individual submissions and independent submissions through the RFC 79 Editor. 81 This note describes procedures and working methods. It does not 82 change any underlying rules such as those in RFC 2026 [RFC2026] or 83 the operation of the RFC Editor as defined in [I-D.iab-rfc-editor]. 84 The note also does not change the procedures related to independent 85 submissions or other RFC streams [I-D.iab-rfc-editor] 86 [I-D.klensin-rfc-independent]. 88 2. Requirements language 90 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 91 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 92 described in [RFC2119]. 94 3. Submission 96 Individual submissions enter the process through an agreement with an 97 AD. Such agreements are usually the result of the AD tracking the 98 work earlier, or discussions between the authors and the AD. And 99 sometimes the AD agrees with a WG that a particular document should 100 be progressed as an individual submission. 102 Similar to the process for WG submissions, the authors may find a 103 willing external Shepherd [I-D.ietf-proto-wgchair-doc-shepherding]. 104 The task of the Shepherd is to manage the discussions relating to the 105 document's process through the system. The Shepherd will also 106 provide a write-up similar to Document Shepherd Write-ups for WG 107 documents. Appendix C explains how to interpret the normal write-up 108 template for individual submissions. If no Shepherd can be 109 identified, the tasks of the Shepherd fall on the AD. In that case 110 the authors should, however, provide the write up so that the AD has 111 the necessary background information about the proposal. When the AD 112 has the write-up he or she can insert the document into the data 113 tracker and set its parameters correctly (e.g., the area, intended 114 status and ballot information). 116 If for some reason the authors cannot identify the most relevant Area 117 Director, they should contact to the General Area Director first. 118 This replaces the previous practice of writing to the IESG as a 119 whole. 121 Messages sent to iesg-secretary@ietf.org prompt the secretariat to 122 send a response that suggests the authors should follow the 123 appropriate submission procedure for their desired method, such as 124 finding an AD to sponsor an individual submission. The response can 125 also suggest that the authors should also consider the normal IETF 126 publication path through an existing working group, or consider 127 proposing a BoF at a future IETF meeting. An example note is shown 128 in Appendix B. 130 Finally, authors who consider making either an individual submission 131 through the IETF or an independent submission via the RFC Editor 132 should be aware that some documents either have to be from the IETF 133 or would benefit from being from the IETF. For instance, the 134 document may request an IANA allocation from a space that has a 135 Standards Action IANA rule (see RFC 2434 [RFC2434]). Such actions 136 can not come from independent submissions. For a discussion of when 137 a document can not be processed as an independent submission, see RFC 138 3932 [RFC3932]. 140 One possibility for such documents is to process them as AD Sponsored 141 submissions. Other alternatives include finding or creating a 142 suitable WG to process the document or abandoning the document 143 altogether. The authors are responsible for the decision to proceed 144 with a particular approach among the set of allowed options. The 145 authors are also responsible for the effort of proposing a Birds-of- 146 a-Feather (BoF) session, convincing the IESG or one of the ADs that 147 the document needs to be sponsored, etc. 149 4. Processing Rules 151 AD Sponsored documents to Standards Track require review in the IETF, 152 IETF Last Call, and IESG approval. AD Sponsored documents to 153 Experimental/Informational require some form of review in the IETF 154 and IESG approval. While RFC 2026 does not require the latter type 155 of documents to go through an IETF Last Call, this note suggests that 156 it is always performed. It is needed to ensure adequate review and 157 transparency in a situation where the pending publication of the 158 document may not be known by any Working Group or the IETF community 159 at large. 161 As RFC 2026 states, when a proposed standards action comes from 162 outside Working Groups, the IETF Last Call period is at least four 163 weeks. If the IESG believes that the community interest would be 164 served by allowing more time for comment, it may decide on a longer 165 Last-Call period or to explicitly lengthen a current Last-Call 166 period. 168 The exact nature of the review within the IETF is not specified, but 169 it is expected that documents be posted for review in the relevant WG 170 mailing lists. Often no relevant mailing list exists, in which case 171 area-specific or IETF main discussion list can be used. Individual 172 reviewers, review teams, and review boards for specific topics can 173 also be used. If no sufficient review has been obtained, the AD 174 should solicit it explicitly. 176 Note that discussing topics outside the charter of a WG can cause 177 loss of focus in a WG, if a WG list is chosen for discussion. This 178 should be considered when seeking review and when deciding to adopt 179 documents for sponsoring. On the other hand, work closely related to 180 a WG but strictly outside its charter should always be brought to the 181 WG's attention during review. 183 Sponsored submissions are treated in the same manner with other 184 submissions in the actual IESG evaluation process. Existing discuss, 185 appeal, recusing, etc. rules apply also to sponsored submissions. 187 5. Choosing Documents to Sponsor 189 This section provides some guidelines for the use of the AD 190 Sponsoring method. Such guidelines are useful when authors contact 191 the AD and suggest that their document be sponsored. The rules are 192 also useful in controlling the load on the IESG, and to ensure 193 fairness. AD Sponsored documents are the only way to publish 194 Standards Track documents outside WGs. IETF documents may also have 195 a higher priority at the RFC Editor processing queue than independent 196 submissions. 198 When considering the choice between a sponsored document and an RFC 199 Editor submission, the RFC 3932 rules play a role [RFC3932]. If it 200 is likely that the document would generate a 3 (harmful to IETF 201 work), 4 (violates IETF procedures) or 5 (extension requires IETF 202 review) response based on RFC 3932 it is not appropriate for an 203 independent submission. Sometimes such documents are suitable 204 candidates for being sponsored, however. It would be useful to add, 205 say, IANA rules or IPv6 considerations to an old specification that 206 did not have them and for which no WG can be found. Such additions 207 to standards track RFCs need to be on the standards track themselves, 208 preventing the use of independent submissions. 210 In general, the decision to sponsor a document involves AD 211 discretion. It is necessary for the AD to be willing to spend effort 212 on the document. The following considerations should be applied: 214 Document Track 216 Documents that need to be on the Standards Track can only be 217 published via WGs or the AD Sponsored method. 219 Documents that fall under this class should either be handled by 220 the IETF in some manner or be dropped. This ultimate decision 221 depends on, among other things, on the value of the document's 222 contribution and whether it fits within the mission of the IETF. 224 The AD should also consider whether the normal IETF WG/BoF process 225 should be employed instead. Some situations where this is 226 impractical have been noted in Section 6. 228 IANA Rules 230 Documents that request "IETF Consensus" or "Standards Action" IANA 231 allocations also need to be WG submissions or AD Sponsored 232 documents. 234 On the other, documents intended to satisfy "Specification 235 required" could be processed as independent submissions. 237 Benefit from IETF Review 239 All AD sponsored documents go through IETF Last Call, and also 240 receive additional review from the sponsoring AD, the IESG, and 241 may also be reviewed by solicited experts and WGs. 243 Does the document need such IETF-wide review, or is RFC Editor's 244 Independent Submission Review (ISR) sufficient? For instance, the 245 AD can decide that while a particular document could be an 246 independent submission, the added review would be useful and would 247 benefit the community. 249 As an example, the AD may expect that a particular protocol will 250 be widely deployed, and that providing additional IETF review 251 makes the protocol more likely to be useful for the community and 252 less likely to cause problems. 254 Availability of Reviewer Resources 256 Are there persons that can help with the review of the document 257 during, for instance, the IETF Last Call? Is there a risk that 258 such persons become distracted from their chartered work at the 259 IETF because of the extra reviews being requested? 261 Fairness 263 ADs should be fair in choosing the documents that they decide to 264 sponsor. For instance, they should not give priority in accepting 265 or processing documents on company or personal criteria; the 266 content of the document and its relevance to the Internet 267 community should be the guiding factor. 269 Where an AD is one of the authors or significant contributors in a 270 document, he or she can not be the sponsoring AD. 272 Relevance 274 The above process issues need to be considered together with the 275 relevance the document has for the Internet community. Does it 276 solve an important problem? Does it describe an issue that 277 affects a significant number of users in the Internet? Does it 278 create an interface or convention where widespread 279 interoperability would be necessary? 281 For instance, a document that describes a serious vulnerability or 282 an architectural issue in protocols in the AD's area is a good 283 candidate for being sponsored. Clarifications and small updates 284 of protocols in the AD's area are also good candidates when no 285 suitable working working group exists, and the scale of the change 286 does not warrant the creation of one. 288 A document specifying a particular vendor's proprietary protocol 289 is typically more suitable as an independent submission than being 290 sponsored by an AD. A document specifying an alternate approach 291 to an existing Standards Track solution is typically not a likely 292 candidate either. But this is a judgment call. For instance, if 293 there is general agreement in a WG for publishing a "road not 294 followed" document for the record, but the WG itself considers it 295 out of scope, AD sponsoring might be appropriate. 297 Quality 299 As with relevance, the quality of the document and the expected 300 outcome of the IETF review process affect the decision. In 301 general, the AD should only sponsor documents that he or she 302 believes in; the decision to sponsor should only be taken after at 303 least as detailed review as the AD performs for regular WG 304 submissions. 306 As with BoFs, it is possible that the IETF community is divided or 307 unable to agree on a proposal, even if the proposal itself is of 308 high quality and relevant. The AD should consider the likelihood 309 of achieving consensus in IETF review, if relevant for the type of 310 document in question. 312 History 314 Sometimes the IETF, IESG, and the WG has more information about 315 the history of the document than the RFC Editor. This is the case 316 with the "road not followed" documents mentioned above as well as 317 with other documents recently seriously considered in the IETF. 318 If the publication of these documents is appropriate, they are 319 likely more suitable as individual submissions than as independent 320 submissions. 322 ADs can always decline to sponsor a given document. 324 It may take a while to find the right AD. Sometimes the contacted AD 325 may suggest that the document fits better in another AD's area of 326 expertise. Or the author may realize that a more suitable AD exists. 327 Legitimate search for the right AD should not be confused with 328 authors going through several ADs trying to find one that will 329 sponsor their document. For BOF requests, this practice has been 330 termed "AD shopping." 332 To identify cases of AD shopping, it is recommended that ADs send a 333 brief note to the IESG when they have turned down a sponsoring 334 request, accompanied by an indication if this was due to unsuitable 335 topic for the AD or some other reason. This allows the other ADs to 336 recognize that they are being asked for the same document again. 337 This should not necessarily cause the second AD to automatically turn 338 down the request. However, it is recommended that he or she query 339 the ADs that have turned down sponsorship in the past and incorporate 340 this information into their own decision. 342 6. Discussion 344 AD Sponsored submissions represent a significant workload to the 345 IESG. Reasons for the popularity of these submissions include the 346 interest of the ADs to progress work in their fields, the difference 347 in time-to-RFC-publication IETF documents enjoy over independent 348 submissions, the ability to avoid the IESG notes that independent 349 submissions get, and the wider review IETF documents get. 351 Improvements in the efficiency of the RFC Editor processing are 352 likely to increase the popularity of the independent submissions, 353 which represent a smaller load for the IESG. Similarly, ongoing work 354 [I-D.klensin-rfc-independent] may change the tone of the IESG notes. 355 However, the speed of the independent submissions channel depends to 356 a large extent on its review stage, and it has generally been easier 357 to find reviewers for IETF documents. 359 In any case, the IESG can handle some amount of sponsored documents. 360 The system is self-regulating in the sense that if the IESG becomes 361 too busy, the ADs are less likely to adopt sponsored documents; there 362 is no requirement for them to sponsor any submissions. 364 The interesting question is why there was no WG to deal with the 365 issue in the proposal, if it is so important and useful. One reason 366 for this can be that our BoF process tends works better for large 367 efforts than small. The process also favors focused efforts which 368 may make it hard to report issues that cross multiple WGs or areas. 369 Running a BoF and creating a WG takes time and requires a significant 370 number of persons to be involved in the effort. Some of the 371 situations where this can be problematic include: 373 o Corrections and small updates of existing RFCs when the WG that 374 created the original RFCs no longer exists. 376 o Draft Standard revisions of Proposed Standard RFCs when the WG no 377 longer exists. 379 o IANA considerations updates for old protocol specifications to 380 bring them up to today's requirements. Many old protocol 381 specifications had no IANA considerations, for instance. 383 o Architectural issues that cross multiple WGs or areas, but are not 384 being handled currently by the IAB. 386 o Registration of values and formats in frameworks, such as media 387 type registrations. 389 Some areas employ area-specific WGs that can be used to process some 390 of these. For instance, TSVWG in the Transport area produces 391 documents as a real WG, resulting in less need for AD sponsoring. 392 Other areas such as Internet and Security have area-specific 393 discussion forums that do not act like WGs. The Routing area employs 394 both models with their RTGAREA group for discussion and RTGWG for WG- 395 like operation for "catchall" documents. In the Operations and 396 Management Area the MIB Doctors team discusses procedural and 397 technical issues, reviews documents, and sometimes issues documents 398 related to the MIB quality review process. 400 7. Summary of Changes to Existing Procedures 402 The "talk to the appropriate AD" and "submit via RFC Editor" 403 approaches are promoted over submitting documents via the 404 secretariat. This allows the ADs to discuss the appropriate 405 submission method with the authors, and does not require the 406 secretariat to think about policy issues such as whether a document 407 is worthwhile for being sponsored. 409 Submissions sent to iesg@ietf.org are not considered. 411 New text is adopted for the secretariat's response to submissions. 413 It should also be noted that Section 4.2.3 of RFC 2026 states "Unless 414 they are the result of IETF Working Group action, documents intended 415 to be published with Experimental or Informational status should be 416 submitted directly to the RFC Editor." This has not been operational 417 practice for some time, however. A number of Informational and 418 Experimental documents have been submitted as AD Sponsored documents. 419 The rationale behind this is the wider review that can be achieved, 420 but this is one area where current procedures have deviated from RFC 421 2026. However, RFC 2026 is not technically violated, since in these 422 cases the IESG serves as the submitter to the RFC Editor in place of 423 the author. 425 8. Security Considerations 427 There are no security considerations beyond those normally involved 428 in the IETF processing of proposals for new RFCs. 430 9. IANA Considerations 432 There are no IANA considerations. 434 10. References 436 10.1. Normative References 438 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 439 3", BCP 9, RFC 2026, October 1996. 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 445 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 446 October 1998. 448 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 449 Procedures", BCP 92, RFC 3932, October 2004. 451 [I-D.ietf-proto-wgchair-doc-shepherding] 452 Levkowetz, H., "Document Shepherding From Working Group 453 Last Call to IESG Approval", 454 draft-ietf-proto-wgchair-doc-shepherding-07 (work in 455 progress), June 2006. 457 10.2. Informative References 459 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 460 Documents may Refer Normatively to Documents at a Lower 461 Level", BCP 97, RFC 3967, December 2004. 463 [I-D.iab-rfc-editor] 464 Daigle, L., "The RFC Series and RFC Editor", 465 draft-iab-rfc-editor-01 (work in progress), July 2006. 467 [I-D.klensin-rfc-independent] 468 Klensin, J., "Independent Submissions to the RFC Editor", 469 draft-klensin-rfc-independent-02 (work in progress), 470 May 2006. 472 Appendix A. Acknowledgements 474 This note has been prepared as a result of discussions in the IESG. 475 The members of the IESG at the time this was written were: 477 Bill Fenner 479 Brian Carpenter 481 Cullen Jennings 483 Dan Romascanu 485 David Kessens 486 Jari Arkko 488 Jon Peterson 490 Lars Eggert 492 Lisa Dusseault 494 Magnus Westerlund 496 Mark Townsley 498 Ross Callon 500 Russ Housley 502 Sam Hartman 504 Ted Hardie 506 In addition, the editor would like to thank Leslie Daigle, John 507 Klensin, and Pekka Savola for input. 509 Appendix B. Secretariat Response to Submissions 511 Individual submission requests sent to iesg-secretary@ietf.org prompt 512 the secretariat to send a response suggesting an alternative 513 submission process. Example response note is shown below. 515 "We cannot process your request. Please make an independent 516 submission through the RFC Editor, or find an IETF Area Director 517 to sponsor your draft as an individual submission to the 518 IETF. Also, please consider the normal IETF publication path 519 through an existing working group, or consider proposing a BoF at 520 a future IETF meeting. 522 Please see RFC 3932 for guidance on which documents may be 523 suitable as independent submission through the RFC Editor. If you 524 choose this option, please send your publication request to 525 527 If you wish to seek Area Director sponsorship for an 528 individual submission, the best solution is to contact the 529 most relevant Area Director directly, with an explanation of 530 why the draft is appropriate for IETF publication. The Area 531 Director is also the best source of advice about whether an 532 existing WG, or a BoF, may be applicable. The Area Directors 533 and WGs are listed at: 535 http://www.ietf.org/html.charters/wg-dir.html 537 If for some reason you cannot identify the most relevant Area 538 Director, please talk to the General Area Director first. 540 The IETF Secretariat" 542 Appendix C. PROTO Write-Up 544 A write-up should accompany any request for sponsoring. This 545 write-up should follow the the Document Shepherd Write-up template 546 given in Section 3.1 of [I-D.ietf-proto-wgchair-doc-shepherding]. 547 However, as there is no working group, questions that relate to the 548 the working group need to be interpreted in the context of the 549 interested community instead. It is assumed that an interested 550 community exists in all cases, and that individual submissions are 551 not prepared in complete isolation. 553 In addition, under item 1.k the authors should indicate if the 554 document been considered in any existing or past WG, and if yes, 555 describe why the work was not adopted as a work item there. 557 The initial template of the edited write-up is included below for 558 ease of copying pasting the questions elsewhere. But changes are 559 expected over time. Any future changes to 560 [I-D.ietf-proto-wgchair-doc-shepherding] need to be applied, for 561 instance. The latest version of this template is available from the 562 IESG section of the IETF web site. 564 (1.a) Who is the Document Shepherd for this document? Has the 565 Document Shepherd personally reviewed this version of the document 566 and, in particular, does he or she believe this version is ready 567 for forwarding to the IESG for publication? 569 (1.b) Has the document had adequate review both from key members of 570 the interested community and others? Does the Document Shepherd 571 have any concerns about the depth or breadth of the reviews that 572 have been performed? 574 (1.c) Does the Document Shepherd have concerns that the document 575 needs more review from a particular or broader perspective, e.g., 576 security, operational complexity, someone familiar with AAA, 577 internationalization or XML? 579 (1.d) Does the Document Shepherd have any specific concerns or 580 issues with this document that the Responsible Area Director 581 and/or the IESG should be aware of? For example, perhaps he or 582 she is uncomfortable with certain parts of the document, or has 583 concerns whether there really is a need for it. In any event, if 584 the interested community has discussed those issues and has 585 indicated that it still wishes to advance the document, detail 586 those concerns here. 588 (1.e) How solid is the consensus of the interested community behind 589 this document? Does it represent the strong concurrence of a few 590 individuals, with others being silent, or does the interested 591 community as a whole understand and agree with it? 593 (1.f) Has anyone threatened an appeal or otherwise indicated extreme 594 discontent? If so, please summarize the areas of conflict in 595 separate email messages to the Responsible Area Director. (It 596 should be in a separate email because this questionnaire is 598 (1.g) Has the Document Shepherd personally verified that the 599 document satisfies all ID nits? (See 600 http://www.ietf.org/ID-Checklist.html and 601 http://tools.ietf.org/tools/idnits/). Boilerplate checks are not 602 enough; this check needs to be thorough. Has the document met all 603 formal review criteria it needs to, such as the MIB Doctor, media 604 type and URI type reviews? 606 (1.h) Has the document split its references into normative and 607 informative? Are there normative references to documents that are 608 not ready for advancement or are otherwise in an unclear state? 609 If such normative references exist, what is the strategy for their 610 completion? Are there normative references that are downward 611 references, as described in [RFC3967]? If so, list these downward 612 references to support the Area Director in the Last Call procedure 613 for them [RFC3967]. 615 (1.i) Has the Document Shepherd verified that the document IANA 616 consideration section exists and is consistent with the body of 617 the document? If the document specifies protocol extensions, are 618 reservations requested in appropriate IANA registries? Are the 619 IANA registries clearly identified? If the document creates a new 620 registry, does it define the proposed initial contents of the 621 registry and an allocation procedure for future registrations? 622 Does it suggested a reasonable name for the new registry? See 623 [I-D.narten-iana-considerations-rfc2434bis]. If the document 624 describes an Expert Review process has Shepherd conferred with the 625 Responsible Area Director so that the IESG can appoint the needed 626 Expert during the IESG Evaluation? 628 (1.j) Has the Document Shepherd verified that sections of the 629 document that are written in a formal language, such as XML code, 630 BNF rules, MIB definitions, etc., validate correctly in an 631 automated checker? 633 (1.k) The IESG approval announcement includes a Document 634 Announcement Write-Up. Please provide such a Document 635 Announcement Writeup? Recent examples can be found in the 636 "Action" announcements for approved documents. The approval 637 announcement contains the following sections: 639 Technical Summary 641 Relevant content can frequently be found in the abstract and/or 642 introduction of the document. If not, this may be an 643 indication that there are deficiencies in the abstract or 644 introduction. 646 Working Group Summary 648 Was there anything in the discussion in the interested 649 community that is worth noting? For example, was there 650 controversy about particular points or were there decisions 651 where the consensus was particularly rough? Was the document 652 considered in any WG, and if so, why was it not adopted as a 653 work item there? 655 Document Quality 657 Are there existing implementations of the protocol? Have a 658 significant number of vendors indicated their plan to implement 659 the specification? Are there any reviewers that merit special 660 mention as having done a thorough review, e.g., one that 661 resulted in important changes or a conclusion that the document 662 had no substantive issues? If there was a MIB Doctor, Media 663 Type or other expert review, what was its course (briefly)? In 664 the case of a Media Type review, on what date was the request 665 posted? 667 Personnel 669 Who is the Document Shepherd for this document? Who is the 670 Responsible Area Director? 672 The write-up is entered into the ID Tracker in the "Comment" field. 674 Author's Address 676 Jari Arkko 677 Ericsson 678 Jorvas 02420 679 Finland 681 Email: jari.arkko@ericsson.com 683 Full Copyright Statement 685 Copyright (C) The IETF Trust (2007). 687 This document is subject to the rights, licenses and restrictions 688 contained in BCP 78, and except as set forth therein, the authors 689 retain all their rights. 691 This document and the information contained herein are provided on an 692 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 693 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 694 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 695 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 696 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 697 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 699 Intellectual Property 701 The IETF takes no position regarding the validity or scope of any 702 Intellectual Property Rights or other rights that might be claimed to 703 pertain to the implementation or use of the technology described in 704 this document or the extent to which any license under such rights 705 might or might not be available; nor does it represent that it has 706 made any independent effort to identify any such rights. Information 707 on the procedures with respect to rights in RFC documents can be 708 found in BCP 78 and BCP 79. 710 Copies of IPR disclosures made to the IETF Secretariat and any 711 assurances of licenses to be made available, or the result of an 712 attempt made to obtain a general license or permission for the use of 713 such proprietary rights by implementers or users of this 714 specification can be obtained from the IETF on-line IPR repository at 715 http://www.ietf.org/ipr. 717 The IETF invites any interested party to bring to its attention any 718 copyrights, patents or patent applications, or other proprietary 719 rights that may cover technology that may be required to implement 720 this standard. Please address the information to the IETF at 721 ietf-ipr@ietf.org. 723 Acknowledgment 725 Funding for the RFC Editor function is provided by the IETF 726 Administrative Support Activity (IASA).