<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.ietf.org/authoring/rfc2629.xslt' ?>

<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc toc="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc
  category="bcp"
  updates="3967"
  submissionType="IETF"
  ipr="trust200902"
  docName="draft-leiba-3967upd-downref-03">

  <front>
    <title abbrev="Document Down-Ref Update">
    Updating when Standards Track Documents may Refer Normatively to Documents at a Lower Level
    </title>

    <author initials='B.' surname="Leiba" fullname='Barry Leiba'>
      <organization>Huawei Technologies</organization>
      <address>
        <phone>+1 646 827 0648</phone>
        <email>barryleiba@computer.org</email>
        <uri>http://internetmessagingtechnology.org/</uri>
      </address>
    </author>

    <date/>

    <area>General</area>
    <workgroup></workgroup>

    <abstract>
      <t>
        RFC 3967 specifies a process for allowing normative references to
        documents at lower maturity levels ("downrefs"), which involves calling
        out the downref explicitly in the last call notice.  That requirement has
        proven to be unnecessarily strict, and this document updates RFC 3967,
        allowing the IESG more flexibility in accepting downrefs in Standards
        Track documents.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>
        <xref target="RFC3967"/> notes the importance of assuring that normative
        references from Standards Track and Best Current Practice (BCP) documents
        are appropriately mature, and specifies a process for allowing normative
        references to documents at lower maturity levels ("downrefs").
        That process starts at Last Call (see Section 3 of <xref target="RFC3967"/>):
        <list style="empty">
          <t>
            For Standards Track or BCP documents requiring normative reference to
            documents of lower maturity, the normal IETF Last Call procedure will
            be issued, with the need for the downward reference explicitly
            documented in the Last Call itself.  Any community comments on the
            appropriateness of downward references will be considered by the IESG
            as part of its deliberations.
          </t>
        </list>
      </t>
      <t>
        Section 2 of <xref target="RFC3967"/> lists some conditions under which downrefs
        may make sense.  In addition to those, it has become common for working groups
        to produce foundational documents at Informational status, which contain
        important information such as terminology definitions and architectural
        design and considerations, and those documents are often needed as normative
        references in the Standards Track protocol documents that follow.
      </t>
      <t>
        The requirement to explicitly mention the downrefs and the need for them in the
        Last Call message has proven to be unnecessarily restrictive, and has often
        resulted in unnecessary repetitions of Last Call, with the corresponding delay
        and with no real benefit.
      </t>
    </section>

    <section title="The IESG's Responsibility with Respect to Downrefs">
      <t>
        The process in RFC 3967 is hereby updated to specify that explicitly documenting
        the downward references in the Last Call message is strongly recommended, but not
        required.  The responsible AD should still check for downrefs before sending out
        the last call notice, but if an undetected downref is noticed during last call
        or IESG review, any need to repeat the last call is at the discretion of the IESG.
        However, the process in RFC 3967 is not fundamentally altered:
        If the IESG decides not to repeat the last call, the status of the
        affected downrefs is not changed, and the process in RFC 3967
        will still apply if those downrefs are used in the future.
      </t>
      <t>
        This gives the IESG the responsibility to determine the actual maturity level of
        the downward reference with respect to the document at hand, and to decide whether
        or not it is necessary to explicitly ask the IETF community for comments on the
        downref on a case-by-case basis.  In making that decision, the IESG should take
        into account the general discussion in RFC 3967.
        The responsible AD should make sure that the omission is recorded as a comment
        in the datatracker.
      </t>
    </section>

    <section title="IANA Considerations">
      <t>
        There are no IANA considerations for this document.
      </t>
    </section>

    <section title="Security Considerations">
      <t>
        Referencing immature protocols can have security and stability implications, and the
        IESG should take that into account when deciding whether re-consulting the community
        is useful.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.3967" ?>
    </references>
  </back>
</rfc>
