idnits 2.17.00 (12 Aug 2021) /tmp/idnits16949/draft-tschofenig-rai-reducing-delays-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** 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.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 4583 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-behave-turn has been published as RFC 5766 == Outdated reference: A later version (-04) exists of draft-ietf-ecrit-local-emergency-rph-namespace-03 == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 == Outdated reference: draft-ietf-geopriv-radius-lo has been published as RFC 5580 == Outdated reference: draft-ietf-radext-design has been published as RFC 6158 == Outdated reference: draft-peterson-rai-rfc3427bis has been published as RFC 5727 -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rai H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational H. Schulzrinne 5 Expires: April 29, 2010 Columbia University 6 M. Isomaki 7 Nokia 8 October 26, 2009 10 A Pragmatic Approach for Reducing Delays in Publishing Documents within 11 the Real-time Applications and Infrastructure (RAI) Area 12 draft-tschofenig-rai-reducing-delays-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 29, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 During the last year, participants in the Real-time Applications and 51 Infrastructure (RAI) area have been quite active in discussing 52 proposals that could improve their way of working. This document is 53 a contribution to that discussion and focuses on the reduction of 54 delays experienced in producing specifications. We believe that this 55 is one of the main problems in the RAI area (and quite likely in 56 other areas of the IETF as well) and it requires attention. A number 57 of side effects, caused by the long specification work, are 58 illustrated in this document. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Reasons for Delays . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 67 6. Informative References . . . . . . . . . . . . . . . . . . . . 16 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 70 1. Introduction 72 Many participants in the Real-time Applications and Infrastructure 73 (RAI) area have noticed that it takes several years for a 74 specification from the initial working group item to the published 75 RFC. A brief look at http://www.arkko.com/tools/lifecycle/ (for 76 documents like ICE, SIP Location Conveyance, SIP configuration 77 framework) very quickly confirms this observation. Several years are 78 quickly spent. In various cases these delays have had negative 79 effects on the deployment situation and on interoperability. In some 80 other cases the relationship between a long delay and lack of 81 deployment cannot be directly observed and there are more complex 82 reasons that can only be analysed on a per-specification basis. For 83 example, some of the interoperability problems that got discussed 84 during the SIP Interoperability Workshop at IETF#70 (see http:// 85 www.sipforum.org/component/option,com_docman/task,cat_view/gid,42/ 86 Itemid,75) may have been caused by specifications with too many 87 options. 89 The authors are not aware of a detailed and structured analysis of 90 the documents within the RAI area with respect to their delays. With 91 some documents there is the question whether additional delay is 92 actually problematic, particularly when they have a research 93 character. One could argue that optimizations to the process should 94 not be started without a detailed analysis of the main causes for 95 these delays. Unfortunately, the delays are the effects of actions 96 taken by individuals and blaming them for the problems is not 97 helpful, particularly since the accused persons are very likely to 98 disagree. 100 Protocol specifications that are not deployed are useless regardless 101 how fast they found their way through the IETF. This document, 102 however, does not attempt to discuss problems of publishing 103 specifications that do not meet market demands (especially since 104 different IETF participants target different market segments, some of 105 which might not even closely reflect the properties of the Internet). 107 Instead, this document only focuss on delays assuming that the only 108 problem to be solved is that specifications are not published in a 109 timely fashion. 111 2. Reasons for Delays 113 The authors believe that the following list provides a fairly 114 complete list of reasons for delays in the process of publishing a 115 specification: 117 Interworking between different working groups: 119 While it may sound fairly unproblematic to work on a single 120 specification in different working groups experience has shown the 121 opposite. Typically, the problems are related to the lack of 122 understanding of the usage scenarios, different schedules and 123 priorities, unclear responsibilities, different workstyles in 124 different groups, etc. A similar problem can also be observed 125 when special expert groups need to get involved, e.g., in the form 126 of XML directorates, reviews of URI schemes, application layer 127 design aspects. 129 Examples that support the above statement can be found with RADIUS 130 GEOPRIV [I-D.ietf-geopriv-radius-lo] (interaction between GEOPRIV 131 and RADEXT), HELD [I-D.ietf-geopriv-http-location-delivery] 132 (interaction between GEOPRIV and the APPS area), and SIP Location 133 Conveyance [I-D.ietf-sip-location-conveyance] (interaction between 134 GEOPRIV and SIP). 136 Interworking with other SDOs: 138 Similarly to the interworking between different IETF working 139 groups one might already expect problems in the interworking with 140 other SDOs as the differences might quickly increase due to the 141 different set of participants, fairly different standardization 142 procedures and deadlines ('yes, in some SDOs deadlines are taken 143 serious even though they are completely artificial'), different 144 architectural approaches, different business models, different 145 target markets (e.g., enterprise networks, cellular networks, 146 military networks) different security assumptions. 148 Examples can be found throughout the IETF. In the RAI area the 149 SIP change process (see [RFC3427] and the currently discussed 150 revision of it [I-D.peterson-rai-rfc3427bis]) build the basis of 151 the interworking. Unfortunately, it turned out that in practice 152 problems show up with the lack of participation of persons in both 153 organizations. A high priority item from, for example, the TISPAN 154 leads to a lot of confusion and lack of interest in the IETF RAI 155 area due to the lack of context. There are, however, different 156 models in the IETF as well where a lot of the actual protocol work 157 is outsourced to the respective organization. An example would be 158 the RADEXT working group with their work on RADIUS [RFC2865]; a 159 protocol that is being used by a number of SDOs. Although the 160 specifications that are sometimes produced outside the IETF do not 161 meet the quality expectations in the IETF they do at least not 162 cause resources from IETF participants to be wasted when there is 163 little to no interest in that specific work. To provide a minimum 164 degree of guidance rules have been outlined that should be 165 followed when defining new extensions for RADIUS, see 166 [I-D.ietf-radext-design]. 168 Disagreement about architectural approaches: 170 Sometimes document authors have a different architectural approach 171 in mind that is incompatible with a large part of the working 172 group members. Often, these aspects are discovered fairly late in 173 the process particularly when the document lacks a description of 174 the assumptions and the security architecture. Often, the 175 problems are related to the interworking with other SDOs as the 176 solution approach developed with the IETF specification as seen by 177 the authors as a building block that has then to be fit into an 178 architecture developed elsewhere (often without explicitly stating 179 who else would be doing that work). 181 Examples include the stream of work regarding GETS/MLPP (partially 182 done in the IEPREP working group). 184 Review marathon: 186 Getting a document through the IETF process does not happen 187 without reviews. There are reviews before the document becomes a 188 WG item, reviews while the document is within the group, some 189 chairs demand reviews before they issue a WGLC to probe 190 'readiness', someone in between reviews by special expert groups 191 are done (also by other SDOs and external groups, if necessary), 192 then comes the WGLC, review by the responsible AD, review by the 193 IESG, review by directorates (and there are many of those) and 194 (depending on the type of document and history) an IETF Last Call. 195 Everybody has an opinion, often not necessarily a technical 196 opinion, on how documents should be written and why other solution 197 approaches have not been explored. Reviewers need time and then 198 the review comments often cannot be ignored but need to be 199 discussed and resolved. When reviews happen later in the process 200 then text changes are often expected to keep the reviewer happy. 201 IESG members frequently put DISCUSSes on reviews and this 202 increases their priority allowing a single person to, for example, 203 delay the publication of a document for an extended period of 204 time. From a psychological point of view reviewers are in the 205 unfortunate position that they have the feeling that something 206 must be improved as an outcome of the review activity. As soon as 207 documents leave the working group the transparency is largely 208 lost, despite IESG comments being sent to the authors, WG chairs 209 and responsible ADs and despite information being available in the 210 I-D tracker. Mentally, many working group members consider 211 documents to be 'done' when they leave the working group. 213 The authors are not arguing that reviews are unnecessary but there 214 has to be balance with respect to the goal that is about to be 215 accomplished. 217 Degeneration of the 3-level Standards Track process: 219 RFC 2026 [RFC2026] describes the 'Internet Standards Process' and 220 describes the level of Standards Track documents, namely 'Proposed 221 Standard' to 'Draft Standard' to 'Internet Standard'. It appears 222 that IETF participants are less likely to spend their time on 223 advancing documents from 'Proposed Standard' to 'Draft Standard', 224 particularly since the industry to a large extent does not 225 understand the standards process anyway. More and more it can be 226 observed how a fairly small group of people get together and 227 produce de-facto standards by finishing specifications in an 228 astonishing time frame together with a large number of 229 implementations that the Internet community is willing to deploy. 230 The standards process utilized in the IETF is, unfortunately, not 231 tailored to these type of developments. Experimental documents on 232 the other hand, although easier to publish through the IETF, have 233 the stigma of being very unbaked. In certain environments the 234 label of 'experimental' is considered as a problem. Putting 235 normative references to informational or experimental RFCs in 236 Standards Track documents later makes the publication process more 237 complex due to the need for Down-Refs [RFC3967]. 239 Feature creep and overall complexity: 241 Setting up a working group takes some time, getting working group 242 members to agree that a certain document has to become WG item 243 also takes a lot of time, the time it takes to publish it as an 244 RFC takes even longer and producing more extensions involves also 245 a certain overhead (e.g., re-chartering, new working group/BOF, 246 new milestones, support from the working group). It is therefore 247 not surprising that document authors/edtiors or the working group 248 are sometimes tempted to add a tiny feature here and another small 249 feature there. 251 A further favorite 'passion' is to generalize the solution. In 252 theory this is a good idea since the same protocol can then be 253 used in a variety of different usage scenarios. In most case, 254 this has lead to more complexity, much longer time to finish the 255 specification and sometimes none of the use cases are consequently 256 covered appropriately. For some, the SIP configuration framework 257 might be an example. 259 Lack of time: 261 The IETF to a large extend consists of volunteers (rather than 262 standardization specialists and consultants), who have a fairly 263 limited time budget. Those who are involved in the development of 264 standards tend to have time constraints (e.g., authors, WG 265 participants, WG chairs, ADs, Expert Reviewers, etc.). This is 266 quite normal. 268 Problems arise when the lack of time causes considerable delays in 269 completing work other people rely on. Consider the following 270 hypothetical case. Bob is an expert in writing specifications and 271 he has a lot of energy and enthusiasm. He is assigned as the main 272 editor of a specification. The work on the specification takes 273 some time (typically years) but Bob does his job well and the 274 community respects him. Over time Bob develops new interests, 275 might even change his job and does not show the same availability 276 anymore. Still, Bob remains in charge of the document and Bob 277 does not recognize that he is unable to commit the necessary time 278 to get the job done. A similar situation can happen in any other 279 role previously mentioned. 281 Missing running code: 283 Although most people would agree that running code is very useful 284 many specifications are not backed up with it. Since 285 specifications change a lot over the lifetime before being 286 published as an RFC (even at a very late stage) it can be pretty 287 frustrating to have running code in an early stage. The standards 288 process considers interoperable code but due to the long time it 289 takes to publish specifications it is rarely utilized. 291 As an example, the TURN specification [I-D.ietf-behave-turn] has 292 changed quite considerably over time. Those who implemented 293 earlier versions essentially had to re-write their code. 295 Onerous extensibility rules: 297 Many document authors feel insecure when writing IANA 298 consideration sections and for some reasons these consideration 299 sections often demand Standards Track documents to introduce new 300 extensions. 302 A recent example can be found with the Service URN document 304 [RFC5031], which requires a Standards Track document for 305 allocating a new top-level top-level service labels. With the new 306 extensions that the working group had seen it became cumbersome to 307 progress these documents in a timely fashion through the working 308 group. 310 AD and IESG overload: 312 Some documents need significant time after leaving the working 313 group until they are published. It is unclear that these delays 314 yield significantly better documents in the end. Part of the 315 problem is that the current IETF area director model seems to 316 assume that ADs spend the equivalent of a full-time job on their 317 "volunteer" job, which appears to be unrealistic, particularly 318 when ADs have been in office for several years. Compared to other 319 organizations, the AD "span of control" is very large, supervising 320 twenty or more working group chairs. 322 Exhaustion: 324 As the publication process wears on, the amount of change per time 325 unit continuously decreases. Because of the long delays, authors 326 are often working on many documents in parallel, making it 327 difficult for them to switch context and remember all the issues 328 when they update documents. As the initial excitement about a 329 problem fades after a few years, editing such documents becomes a 330 chore, further delaying the publication. This leads to author 331 exhaustion. 333 Thus, to the extent possible, most documents should be finished in 334 no more than three IETF meetings: gauge interest and agreement on 335 basic approach during the first IETF meeting and assign reviewers, 336 reach consensus on the technical issues during the second IETF 337 meeting and get a final WG approval during the third one, if 338 needed. 340 3. Suggestions 342 Below, we present a set of suggestions to reduce publication delays. 343 We believe that many of the suggestions can be used together, and 344 some can be used experimentally to see if they produce significant 345 improvements. 347 Improving the chartering process: 349 It takes far too long to add an item to a charter. If there's 350 interest in the working group and the document is below a certain 351 size and complexity (based on the judgement by the WG chair) and 352 three reviewer volunteers, the document should just get into the 353 next cycle. 355 State assumptions clearly: 357 Sometimes a specific protocol specification is target for usage in 358 a certain environment (or envisioned context). The working group 359 may be fine with such an approach but often the document does not 360 state the usage environment. This often leads to confusion in the 361 review process. For example, some documents are being progressed 362 through the IETF where the main use case can be found in the 3GPP 363 IMS architecture. Maybe the document assumes that other 364 organizations utilize the specification in a specific context. 365 There are often additional operational aspects that need to be 366 considered in order to come to a complete solution. 368 A recent example can be found in the work on 369 [I-D.ietf-ecrit-local-emergency-rph-namespace] where the document 370 essentially only specifies the syntax but the semantic is supposed 371 to be provided by organizations outside the IETF. 373 Delegate down: 375 In most organizations, middle management is given significant 376 decision authority, usually described by the financial impact of a 377 decision. A CEO of company does not approve every contract, user 378 manual or feature list. The current IETF review model is 379 predicated on the notion that the IESG reviews protocols to ensure 380 that they do not damage the Internet. However, most of the 381 current RAI documents are extensions and bug fixes that are likely 382 to have only local effects. 384 To reduce AD and IESG load, working group chairs should be able to 385 handle most documents until they reach the RFC editor, unless 386 there is an objection during IETF last call. IESG members are 387 expected to voice their objection during that last call period, 388 triggering formal IESG review. Only efforts that introduce new 389 protocols or are likely to have significant Internet-wide impact 390 require more extensive review. 392 When a document is added to the WG work list, it should be flagged 393 to indicate that it will require a full review. All other 394 documents receive a lighter late-stage review. 396 Clearly label IETF discussion slots: 398 Given the three-meeting model mentioned earlier, the IETF meeting 399 presentations should be structured accordingly, with a clear set 400 of questions to be answered. For example, the first presentation 401 needs to answer questions about architectural assumptions, 402 relation to other work, dependencies, importance of the problem 403 and alternative approaches. Working group chairs should work with 404 document authors to structure presentations, possibly providing 405 templates. In this model, the second discussion is crucial and 406 should be given ample time, if necessary enhancing the plenary 407 working group meeting with break-out meetings before and after the 408 WG meeting slot. (It is a waste of time to have 200 people listen 409 to a discussion where only a handful can really make significant 410 contributions.) 412 Journal-like review model: 414 When a new document is submitted to the working group, the working 415 group chair determines at latest at the next IETF meeting whether 416 there is sufficient interest to pursue this work. If so, he or 417 she seeks at least three reviewers from the working group. If 418 such reviewers cannot be found, the document lacks sufficient 419 interest. Authors may suggest qualified reviewers. Reviewers are 420 given a two-month review deadline, so that reviews would typically 421 arrive mid-cycle between IETF meetings. The basic process could 422 follow the GenArt review model, which could proceed in parallel. 423 As needed, a specialized reviewer might be assigned to only look 424 at specific issues, such as XML usage, security aspects or 425 congestion control. 427 The reviews should be tracked in an issue tracker, in addition to 428 being disseminated via the working group mailing list. As a 429 short-term measure until the IETF tools are enhanced, existing 430 conference review tools might be used, as they offer definable 431 review forms (e.g., to separate editorial and technical issues) 432 and automated review reminder mechanisms. 434 This approach closely models the review process used by scientific 435 journals and technical conferences. 437 Increasing implementation feedback: 439 When documents are able to progress faster through the IETF 440 participants should feel encouraged to provide an update that 441 includes bug fixes and other corrections based on implementation 442 efforts. A possible approach to accomplish this today is to 443 publish documents as informational and experimental RFCs (faster) 444 and to advance them to Standars Track once implementation (or even 445 deployment) experience is available. 447 Delegate work to other SDOs: 449 We believe that the updated version of the SIP Change Process 450 [I-D.peterson-rai-rfc3427bis] goes into the right direction 451 already. 453 Additional WG chair training: 455 We suggest to use some of the WG chair training lunches to offer 456 room for discussions on how to avoid delays in progressing 457 documents and to collect the best current practises. 459 Virtual interim meetings: 461 Many document authors do their IETF work in the two-week period 462 around the submission deadlines before an IETF meeting. This 463 leads to fairly low document update cycles. A tool to increase 464 the time that is spent on documents per IETF cycle working style 465 is to hold virtual interim meetings (i.e., phone conferences). 466 This is common practice also in other organizations and helps to 467 stay focused on open issues. Sometimes chairs regularly contact 468 the main document authors to discuss the editing progress and the 469 status of open issues. It is useful to allow working group 470 members to participate and distribute notes about this informal 471 communication. 473 Keep track of the WG status: 475 Sometimes no progress is made because there is uncertainty about 476 who is responsible for taking the next step. Periodic reminders 477 (even with tool support) would help to make the workflow more 478 visible. Examples of these periodic status updates can be found 479 here 480 http://www.ietf.org/mail-archive/web/ecrit/current/msg05785.html, 481 http://www.ietf.org/mail-archive/web/ops-area/current/ 482 msg00467.html and 483 http://www.ietf.org/mail-archive/web/saag/current/msg02242.html. 485 Document status updates: 487 Each document must have an dedicated editor. This person is 488 responsible for making sure that the status of the document is 489 known. Ensuring a regular interval for reporting is helpful, such 490 as once a month. The fact that such a short report (a few lines 491 in most cases) is written already reminds the editor to look at 492 open issues, which often helps to make progress. 494 Too often, document editors erroneously believe that it is the 495 responsibility of the working group to drive the process and the 496 lack of feedback is an indication that the document is ready. 498 Keep your ADs informed: 500 As previously argued it is important to keep the working group 501 informed about the current status. In the same style it is 502 important to let the ADs know what the current status of the work 503 is. Regular phone conference calls, e.g. once a month, are a 504 possible approach. 506 Assign new editors: 508 If the original author clearly cannot complete the work in a 509 timely fashion, the working group chair should routinely re-assign 510 an editor to the document, after, say, a one-year delay since the 511 -00 draft. If no other person is capable to take that role, this 512 indicates that the document is either too long, too complicated or 513 of insufficient interest to merit further consideration as-is and 514 needs to be split up, simplified or abandoned. 516 Enhance I-D tracker: 518 The I-D tracker should indicate who is supposed to be reviewing 519 the document and by what deadline. It should also clearly 520 indicate who has the "token" on the document, i.e, whether the 521 next action is expected to come from the working group chair, a 522 reviewer or set of reviewers, a directorate, or the authors. 524 Posting minutes: 526 The working group chair(s) must publish the meeting minutes (of a 527 face-to-face or virtual interim meeting) within a few days after 528 the meeting. This helps to ensure that action items can be 529 captured by the participants. Too often details are lost with 530 longer delays and the benefit of the meeting may get lost. 532 Prepare meeting slides appropriately: 534 Slides are a common way to present open issues and to provide a 535 status update during (virtual) interm and face-to-face meetings. 536 Often the slides are available to working group chairs a few 537 minutes before the meeting starts. Furthermore, the style of 538 slides often does not serve as a suitable form to discuss the 539 content. Since small time slots are allocated there is no time to 540 get many of the participants up-to-speed with the discussed issue 541 leaving a large number of the participants clueless. Although it 542 is the seen as the responsibility of the participant to read into 543 the subject it is also questionable whether a presentation with 544 only a handfull of persons understanding the issue is really 545 helpful. Instead, the document editor and the document authors 546 should consider using alternative means of preparing the content 547 in a suitable format to ensure that a large number of persons are 548 actually able to provide a feedback. An example, for such an 549 approach can be found with blog posts http://www.hueniverse.com/ 550 hueniverse/2009/04/ 551 explaining-the-oauth-session-fixation-attack.html or 552 http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html. 554 The IETF meetings are about discussion and discussions need to be 555 prepared. Not everybody is able to have get a definitive opinion 556 while listening to a 5-10 minute (particularly when the topic is 557 complex). Consider that not everyone is given with the gift to 558 give presentations that are easy to understand (considering also 559 the language barrier). Consequently, if the audience is not 560 prepared then there is no discussion. Trying to close open issues 561 will be difficult. 563 Stay connected: 565 Exchanging information about ongoing activies and challenges in a 566 timely fashion it is vital to have other persons contact 567 information (e.g. IM nicknames, various phone numbers, etc.). An 568 email conversation is often not timely enough. A working group 569 chair, for example, should at least have the contact details of 570 the ADs responsible for the working group, the document authors 571 and the key working group members. 573 4. Security Considerations 575 This document discusses process related aspects that are not directly 576 related to security. However, the outcome of an improved process 577 might have a positive impact on security provided by the deployed 578 specifications. 580 5. Acknowledgements 582 We would like to thank all of those you care about the process 583 related aspects in the IETF as they contribute to the impact of the 584 work produced by the IETF in the future. We would also like to thank 585 everyone participating on the RAI area mailing list for their input 586 during the RAI reorganization discussions. 588 We would particularly like to thank Benoit Claise for his feedback to 589 the document. 591 6. Informative References 593 [I-D.ietf-behave-turn] 594 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 595 Relays around NAT (TURN): Relay Extensions to Session 596 Traversal Utilities for NAT (STUN)", 597 draft-ietf-behave-turn-16 (work in progress), July 2009. 599 [I-D.ietf-ecrit-local-emergency-rph-namespace] 600 Polk, J., "IANA Registering a SIP Resource Priority Header 601 Namespace for Local Emergency Communications", 602 draft-ietf-ecrit-local-emergency-rph-namespace-03 (work in 603 progress), March 2009. 605 [I-D.ietf-geopriv-http-location-delivery] 606 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 607 "HTTP Enabled Location Delivery (HELD)", 608 draft-ietf-geopriv-http-location-delivery-16 (work in 609 progress), August 2009. 611 [I-D.ietf-geopriv-radius-lo] 612 Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 613 Aboba, "Carrying Location Objects in RADIUS and Diameter", 614 draft-ietf-geopriv-radius-lo-24 (work in progress), 615 May 2009. 617 [I-D.ietf-radext-design] 618 Weber, G. and A. DeKok, "RADIUS Design Guidelines", 619 draft-ietf-radext-design-09 (work in progress), 620 October 2009. 622 [I-D.ietf-sip-location-conveyance] 623 Polk, J. and B. Rosen, "Location Conveyance for the 624 Session Initiation Protocol", 625 draft-ietf-sip-location-conveyance-13 (work in progress), 626 March 2009. 628 [I-D.peterson-rai-rfc3427bis] 629 Peterson, J., Jennings, C., and R. Sparks, "Change Process 630 for the Session Initiation Protocol (SIP) and the Real- 631 time Applications and Infrastructure Area", 632 draft-peterson-rai-rfc3427bis-04 (work in progress), 633 October 2009. 635 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 636 3", BCP 9, RFC 2026, October 1996. 638 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 639 "Remote Authentication Dial In User Service (RADIUS)", 640 RFC 2865, June 2000. 642 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 643 and B. Rosen, "Change Process for the Session Initiation 644 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 646 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 647 Documents may Refer Normatively to Documents at a Lower 648 Level", BCP 97, RFC 3967, December 2004. 650 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 651 Emergency and Other Well-Known Services", RFC 5031, 652 January 2008. 654 Authors' Addresses 656 Hannes Tschofenig 657 Nokia Siemens Networks 658 Linnoitustie 6 659 Espoo 02600 660 Finland 662 Phone: +358 (50) 4871445 663 Email: Hannes.Tschofenig@gmx.net 664 URI: http://www.tschofenig.priv.at 666 Henning Schulzrinne 667 Columbia University 668 Department of Computer Science 669 450 Computer Science Building 670 New York, NY 10027 671 US 673 Phone: +1 212 939 7004 674 Email: hgs+ecrit@cs.columbia.edu 675 URI: http://www.cs.columbia.edu 677 Markus Isomaki 678 Nokia 679 P.O.BOX 100 680 00045 NOKIA GROUP 681 Helsinki 682 Finland 684 Phone: 685 Email: markus.isomaki@nokia.com