general, in-depth review.   The IESG review takes into account responses to the Last-Call and   will lead to one of these possible conclusions:Bradner                  Best Current Practice                 [Page 21]RFC 2418                Working Group Guidelines          September 1998   1. The document is accepted as is for the status requested.      This fact will be announced by the IETF Secretariat to the IETF      mailing list and to the RFC Editor.   2. The document is accepted as-is but not for the status requested.      This fact will be announced by the IETF Secretariat to the IETF      mailing list and to the RFC Editor (see [1] for more details).   3. Changes regarding content are suggested to the author(s)/WG.      Suggestions from the IESG must be clear and direct, so as to      facilitate working group and author correction of the      specification.  If the author(s)/WG can explain to the      satisfaction of the IESG why the changes are not necessary, the      document will be accepted for publication as under point 1, above.      If the changes are made the revised document may be resubmitted      for IESG review.   4. Changes are suggested by the IESG and a change in status is      recommended.      The process described above for 3 and 2 are followed in that      order.   5. The document is rejected.      Any document rejection will be accompanied by specific and      thorough arguments from the IESG. Although the IETF and working      group process is structured such that this alternative is not      likely to arise for documents coming from a working group, the      IESG has the right and responsibility to reject documents that the      IESG feels are fatally flawed in some way.      If any individual or group of individuals feels that the review      treatment has been unfair, there is the opportunity to make a      procedural complaint. The mechanism for this type of complaints is      described in [1].9. Security Considerations   Documents describing IETF processes, such as this one, do not have an   impact on the security of the network infrastructure or of Internet   applications.   It should be noted that all IETF working groups are required to   examine and understand the security implications of any technology   they develop.  This analysis must be included in any resulting RFCs   in a Security Considerations section.  Note that merely noting a   significant security hole is no longer sufficient.  IETF developed   technologies should not add insecurity to the environment in which   they are run.Bradner                  Best Current Practice                 [Page 22]RFC 2418                Working Group Guidelines          September 199810. Acknowledgments   This revision of this document relies heavily on the previous version   (RFC 1603) which was edited by Erik Huizer and Dave Crocker.  It has   been reviewed by the Poisson Working Group.11. References   [1] Bradner, S., Editor, "The Internet Standards Process -- Revision       3", BCP 9, RFC 2026, October 1996.   [2] Hovey, R., and S. Bradner, "The Organizations involved in the       IETF Standards Process", BCP 11, RFC 2028, October 1996.   [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall       Process: Operation of the Nominating and Recall Committees", BCP       10, RFC 2282, February 1998.   [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",       RFC 1796, April 1995.   [5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC       2223, October 1997.   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement       Level", BCP 14, RFC 2119, March 1997.12. Editor's Address   Scott Bradner   Harvard University   1350 Mass Ave.   Cambridge MA   02138   USA   Phone +1 617 495 3864   EMail: sob@harvard.eduBradner                  Best Current Practice                 [Page 23]RFC 2418                Working Group Guidelines          September 1998   Appendix:  Sample Working Group Charter   Working Group Name:        IP Telephony (iptel)   IETF Area:        Transport Area   Chair(s):        Jonathan Rosenberg <jdrosen@bell-labs.com>   Transport Area Director(s):        Scott Bradner <sob@harvard.edu>        Allyn Romanow <allyn@mci.net>   Responsible Area Director:        Allyn Romanow <allyn@mci.net>   Mailing Lists:        General Discussion:iptel@lists.research.bell-labs.com        To Subscribe: iptel-request@lists.research.bell-labs.com        Archive: http://www.bell-labs.com/mailing-lists/siptel   Description of Working Group:   Before Internet telephony can become a widely deployed service, a   number of protocols must be deployed. These include signaling and   capabilities exchange, but also include a number of "peripheral"   protocols for providing related services.   The primary purpose of this working group is to develop two such   supportive protocols and a frameword document. They are:   1. Call Processing Syntax. When a call is setup between two   endpoints, the signaling will generally pass through several servers   (such as an H.323 gatekeeper) which are responsible for forwarding,   redirecting, or proxying the signaling messages. For example, a user   may make a call to j.doe@bigcompany.com. The signaling message to   initiate the call will arrive at some server at bigcompany. This   server can inform the caller that the callee is busy, forward the   call initiation request to another server closer to the user, or drop   the call completely (among other possibilities). It is very desirable   to allow the callee to provide input to this process, guiding the   server in its decision on how to act. This can enable a wide variety   of advanced personal mobility and call agent services.Bradner                  Best Current Practice                 [Page 24]RFC 2418                Working Group Guidelines          September 1998   Such preferences can be expressed in a call processing syntax, which   can be authored by the user (or generated automatically by some   tool), and then uploaded to the server. The group will develop this   syntax, and specify means of securely transporting and extending it.   The result will be a single standards track RFC.   2. In addition, the group will write a service model document, which   describes the services that are enabled by the call processing   syntax, and discusses how the syntax can be used. This document will   result in a single RFC.   3. Gateway Attribute Distribution Protocol. When making a call   between an IP host and a PSTN user, a telephony gateway must be used.   The selection of such gateways can be based on many criteria,   including client expressed preferences, service provider preferences,   and availability of gateways, in addition to destination telephone   number.  Since gateways outside of the hosts' administrative domain   might be used, a protocol is required to allow gateways in remote   domains to distribute their attributes (such as PSTN connectivity,   supported codecs, etc.) to entities in other domains which must make   a selection of a gateway. The protocol must allow for scalable,   bandwidth efficient, and very secure transmission of these   attributes. The group will investigate and design a protocol for this   purpose, generate an Internet Draft, and advance it to RFC as   appropriate.   Goals and Milestones:   May 98    Issue first Internet-Draft on service framework   Jul 98    Submit framework ID to IESG for publication as an RFC.   Aug 98    Issue first Internet-Draft on Call Processing Syntax   Oct 98    Submit Call processing syntax to IESG for consideration             as a Proposed Standard.   Dec 98    Achieve consensus on basics of gateway attribute             distribution protocol   Jan 99    Submit Gateway Attribute Distribution protocol to IESG             for consideration as a RFC (info, exp, stds track TBBradner                  Best Current Practice                 [Page 25]RFC 2418                Working Group Guidelines          September 1998Full Copyright Statement   Copyright (C) The Internet Society (1998).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Bradner                  Best Current Practice                 [Page 26]