home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1871.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  7.6 KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          J. Postel
  8. Request for Comments: 1871                                           ISI
  9. Updates: 1602, 1603                                        November 1995
  10. BCP: 2
  11. Category: Best Current Practice
  12.  
  13.  
  14.                Addendum to RFC 1602 -- Variance Procedure
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This document specifies an Internet Best Current Practices for the
  20.    Internet Community, and requests discussion and suggestions for
  21.    improvements.  Distribution of this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    This document describes a modification to the IETF procedures to
  26.    allow an escape from a situation where the existing procedures are
  27.    not working or do not seem to apply.  This is a modification to the
  28.    procedures of RFC 1602 and 1603.
  29.  
  30. Introduction
  31.  
  32.    The current IETF procedures are documented in "The Internet Standards
  33.    Process -- Revision 2" [1], and "IETF Working Group Guidelines and
  34.    Procedures" [2].
  35.  
  36.    There may be situations where following the procedures leads to a
  37.    deadlock, or there may be situations where the procedures provide no
  38.    guidance.  In these cases it may be appropriate to invoke the
  39.    variance procedure described below.
  40.  
  41.    A revision of the rules specified in RFC 1602 is underway, but may
  42.    take some time. This document describes an interim amendment to RFC
  43.    1602, to avoid having to wait for this major revision in a state of
  44.    paralysis.
  45.  
  46. Guiding Principles
  47.  
  48.    Any variance from following the written rules must be a public
  49.    process with opportunity for all concerned parties to comment.
  50.  
  51.    The variance procedure should be similar to existing mechanisms and
  52.    involve existing bodies.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Postel                   Best Current Practice                  [Page 1]
  59.  
  60. RFC 1871                   Variance Procedure              November 1995
  61.  
  62.  
  63. The Variance Procedure
  64.  
  65.    Upon the recommendation of the responsible IETF Working Group (or, if
  66.    no Working Group is constituted, upon the recommendation of the
  67.    responsible ad hoc committee), the IESG may enter a particular
  68.    specification into, or advance it within, the standards track even
  69.    though some of the requirements of section 5 of RFC 1602 have not or
  70.    will not be met. The IESG may approve such a variance, however, only
  71.    if it first determines that the likely benefits to the Internet
  72.    community from entering or advancing the specification on the
  73.    standards track are likely to outweigh the costs to the Internet
  74.    community that result from noncompliance with section 5.  In
  75.    exercising this discretion, the IESG shall consider (a) the technical
  76.    merit of the specification, (b) the possibility of achieving the
  77.    goals of the Internet standards process without granting a variance,
  78.    (c) alternatives to the granting of a variance, (d) the collateral
  79.    and precedential effects of granting a variance, and (e) the IESG's
  80.    ability to craft a variance that is as narrow as possible.  In
  81.    determining whether to approve a variance, the IESG has discretion to
  82.    limit the scope of the variance to particular parts of section 5 and
  83.    to impose such additional restrictions or limitations as it
  84.    determines appropriate to protect the interests of the Internet
  85.    community.
  86.  
  87.    There are five aspects that are involved in the variance procedure:
  88.    (1) detecting the problem, (2) proposing a solution, (3) public
  89.    review, (4) accepting the solution, and (5) an appeal process.
  90.  
  91.    1. Detecting the problem
  92.  
  93.    The responsible IETF Working Group, (or, if no Working Group is
  94.    constituted, the responsible ad hoc committee), may bring the matter
  95.    of a variance before the IESG.
  96.  
  97.    2. Proposing the solution
  98.  
  99.    The IESG is responsible for proposing the solution.
  100.  
  101.    The IESG may enter a particular specification into, or advance it
  102.    within, the standards track even though some of the requirements of
  103.    section 5 of RFC 1602 have not or will not be met.
  104.  
  105.    In exercising this discretion, the IESG shall consider (a) the
  106.    technical merit of the specification, (b) the possibility of
  107.    achieving the goals of the Internet standards process without
  108.    granting a variance, (c) alternatives to the granting of a variance,
  109.    (d) the collateral and precedential effects of granting a variance,
  110.    and (e) the IESG's ability to craft a variance that is as narrow as
  111.  
  112.  
  113.  
  114. Postel                   Best Current Practice                  [Page 2]
  115.  
  116. RFC 1871                   Variance Procedure              November 1995
  117.  
  118.  
  119.    possible.
  120.  
  121.    The IESG should consult WG chair and appropriate WG members as
  122.    needed, and the wishes of the WG should also be taken into account.
  123.  
  124.    3. Public review
  125.  
  126.    There shall be an extended Last Call for public review.
  127.  
  128.    4. Accepting the solution
  129.  
  130.    The IESG is responsible for accepting the solution, and incorporating
  131.    comments from the Last Call.
  132.  
  133.    The IESG may approve such a variance, however, only if it first
  134.    determines that the likely benefits to the Internet community from
  135.    entering or advancing the specification on the standards track are
  136.    likely to outweigh the costs to the Internet community that result
  137.    from noncompliance with section 5 of RFC 1602.
  138.  
  139.    In determining whether to approve a variance, the IESG has discretion
  140.    to limit the scope of the variance to particular parts of section 5
  141.    of RFC 1602 and to impose such additional restrictions or limitations
  142.    as it determines appropriate to protect the interests of the Internet
  143.    community.
  144.  
  145.    5. The appeal procedure
  146.  
  147.    The IAB is responsible for hearing and deciding appeals.
  148.  
  149. Discussion
  150.  
  151.    When the IESG (on reviewing a recommendation for a variance) the has
  152.    determined that there is a situation where the existing written rules
  153.    do not apply or lead to a deadlock, the IESG may propose a solution
  154.    to the problem.
  155.  
  156.    The solution may be developed by the IESG or suggested to the IESG.
  157.  
  158.    The solution may either (1) decide the particular instance of the
  159.    matter, or (2) define a procedure for resolving matters of this kind.
  160.  
  161.    In any case, the proposed solution will be documented in an Internet
  162.    Draft and subjected to an extended Last Call.
  163.  
  164.    Depending on the results of the Last Call, the IESG will either
  165.    accept the solution; or revise the proposal, update the Internet
  166.    Draft, and initiate another extended Last Call.
  167.  
  168.  
  169.  
  170. Postel                   Best Current Practice                  [Page 3]
  171.  
  172. RFC 1871                   Variance Procedure              November 1995
  173.  
  174.  
  175.    When the IESG accepts a solution the Internet Draft shall be
  176.    forwarded to the RFC Editor and published as an RFC.
  177.  
  178.    The IAB shall be available to hear and decide on appeals of the use
  179.    this variance procedure.
  180.  
  181. Acknowledgements
  182.  
  183.    The contributions of the IAB and the IESG -- and Brian Carpenter,
  184.    Paul Mockapetris, Christian Huitema, Robert Elz, Frank Kastenholz,
  185.    and Scott Bradner, in particular -- are gratefully acknowledged.
  186.    Scott deserves special credit for working with the lawyers to get
  187.    that first paragraph in the "The Variance Procedure" section.
  188.  
  189. References
  190.  
  191.    [1] IAB, and IESG, "Internet Standards Process -- Revision 2", RFC
  192.        1602, IAB and IESG, March 1994.
  193.  
  194.    [2] Huizer, E., and D. Crocker, "IETF Working Group Guidelines and
  195.        Procedures", RFC 1603, SURFnet and Silicon Graphics, Inc., March
  196.        1994.
  197.  
  198. Security Considerations
  199.  
  200.    Security issues are not discussed in this memo.
  201.  
  202. Authors' Address
  203.  
  204.       Jon Postel
  205.       USC - ISI, Suite 1001
  206.       4676 Admiralty Way
  207.       Marina del Rey, CA  90292-6695
  208.       Phone: 310-822-1511
  209.       EMail: postel@isi.edu
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Postel                   Best Current Practice                  [Page 4]
  227.  
  228.