<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.6 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-atlas-external-normref-00" category="bcp">

  <front>
    <title abbrev="I-D">Normative References in RFCs from Open Source</title>

    <author initials="A." surname="Atlas" fullname="Alia Atlas">
      <organization>Juniper Networks</organization>
      <address>
        <email>akatlas@juniper.net</email>
      </address>
    </author>
    <author initials="E." surname="Lear" fullname="Eliot Lear">
      <organization>Cisco</organization>
      <address>
        <email>lear@cisco.com</email>
      </address>
    </author>
    <author initials="J." surname="Halpern" fullname="Joel Halpern">
      <organization>Ericsson</organization>
      <address>
        <email>Joel.Halpern@ericsson.com</email>
      </address>
    </author>
    <author initials="H." surname="Flanagan" fullname="Heather Flanagan">
      <organization>RFC Editor</organization>
      <address>
        <email>rse@rfc-editor.org</email>
      </address>
    </author>
    <author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
      <organization>Individual</organization>
      <address>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2017" month="October" day="29"/>

    <area>General</area>
    
    

    <abstract>


<t>IETF procedures generally require that a standards track RFC may not
  have a normative reference to a non standards track specification except those from other <vspace />
   standards bodies. This document creates an External Specification registry, similar to the 
   DownRef registry that has been created based on <xref target="RFC3967"/> and permits normative 
   references to community accepted external specifications.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The IETF follows the Standards Process <xref target="RFC2026"/> that describes to what a standards track RFC can normatively refer. Information that is normatively referenced is required to be understood and may be necessary for implementation of the RFC. Essentially, if a technology can be normatively referenced, then a standards track RFC can be created that uses that technology.</t>

<t>Of course, the need to collaboratively build Internet technology is well discussed in <xref target="RFC2026"/> Section 7 and the ability to reference external Open Standard specifications as well as proprietary specifications is described.  Specifically,</t>

<t><list style='empty'>
  <t>Other proprietary specifications may be incorporated by reference to
a version of the specification as long as the proprietor meets the
requirements of section 10.  If the other proprietary specification
is not widely and readily available, the IESG may request that it be
published as an Informational RFC.</t>
</list></t>

<t>The ID-nits checklist at <eref target="https://www.ietf.org/id-info/checklist.html">https://www.ietf.org/id-info/checklist.html</eref> warns:</t>

<t><list style='empty'>
  <t>Normative and informative references to non-IETF documents are
permitted. However, it is best to minimize such normative
references, because assessing their status when the IETF document
advances on the standards-track is very difficult. It is important
to use the exact title, author name(s), organization and publication
date.</t>
</list></t>

<t>When a Working Group wishes to build based upon existing Open Source
technology, the lack of clarity around how that technology’s status
will be assessed can either discourage such a dependency or add
unnecessary work by requiring republication as an Independent Stream
RFC, which will still require a downwards reference <xref target="RFC3967"/>.</t>

<t>This document provides clarity and a simple process to make it easy to
reference Open Source technology that the IETF community agrees is
acceptable.</t>

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119, BCP 14
<xref target="RFC2119"/>.</t>

</section>
<section anchor="what-can-be-normatively-referenced" title="What Can Be Normatively Referenced?">

<t>There are five basic requirements for a normative reference.</t>

<t><list style="numbers">
  <t>Is it stable, mature, and immutable (except for errata)?  <vspace blankLines='1'/>
Stable means that there are not expected to be frequent updated
 versions. Mature is equivalent to being at least similar to a
 Proposed Standard RFC. Immutable means that the referenced content
 is not expected to change after RFC publication, except for minor
 error corrections.  This might be achieved by referencing a
 particular dated version or a subsection of the document.</t>
  <t>Is it generally easily accessible and not subject to
confidentiality restrictions?</t>
  <t>Is it a specification that describes the technology in sufficient
detail that someone else can design their own implementation to
properly interoperate with it and others’ different implementations?  <vspace blankLines='1'/>
The IETF generally prefers specifications over code.  Code itself
lacks context to fully understand the intent or support an
interoperable different implementation. There may, of course, be
exceptions where an algorithm or codec is really most clearly
described in code.  For example, while <xref target="RFC6716"/> has normative
code, there is also detailed documentation.  If it is necessary to
reference code, a distribution is preferred because that can be
clear on the public interfaces and intent of the code.</t>
  <t>Is it intended as a public interface?</t>
  <t>Are the IPR associated with the normative reference clearly and
publicly documented so that the Working Group participants can make an
informed decision about building on top of the specified technology?</t>
</list></t>

</section>
<section anchor="procedure-to-be-used" title="Procedure to be Used">

<t>This procedure is modeled on that defined in <xref target="RFC3967"/> and
<xref target="RFC8067"/> for managing down references in RFCs.  A registry of
external non-SDO references that have been accepted by the community,
as indicated by at least the first published RFC with a normative
references to a particular item, SHOULD be maintained for references
that may see reuse.  That registry should indicate the reference, the
RFC(s) normatively referring to it, and a pointer to any IPR
information that is provided by the same source (e.g. Open Source
Organization) as the external non-SDO reference. A mechanism for this
registry could be the same as is done in datatracker for the DownRef
registry where the sponsoring AD updates the registry.</t>

<t>The following procedures apply to external non-SDO references that are
not yet in the External References registry.  Information included in
calls for Working Group adoption, Working Group Last Call, and IETF
Last Call SHOULD include any normative references to external non-SDO
technology and a pointer to any IPR that is provided by the same
source as the external non-SDO technology. Working Group and IETF
participants should use this information in their evaluations. The
Document Shepherd <xref target="RFC4858 "/> SHOULD indicate in her or his report
whether the document contains any external non-SDO references that are
not in the external references registry. This will call the
responsible Area Director’s attention to verify that the referenced
item is acceptable.</t>

<t>The Working Group Chairs and responsible Area Director SHOULD verify
that the referenced item meets the requirements described earlier. If
the desired reference is to code, then the responsible Area Director
MUST determine whether it provides sufficient context, clarity of
intent, and intentional public interfaces.  Judgement calls are
expected here as circumstances will vary.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>It is possible that external technology does not meet the security or
privacy expectations for Standards Track RFCs. This may require
additional considerations from the referring document.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>There are no IANA considerations.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Thanks to Lucy Lynch for encouraging more thought on what can be done
to better the interaction between the IETF and Open Source work.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC3967" target='https://www.rfc-editor.org/info/rfc3967'>
<front>
<title>Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level</title>
<author initials='R.' surname='Bush' fullname='R. Bush'><organization /></author>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
<date year='2004' month='December' />
<abstract><t>IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies).  For example, a standards track document may not have a normative reference to an informational RFC.  Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards.  This document clarifies and updates the procedure used in these circumstances.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='97'/>
<seriesInfo name='RFC' value='3967'/>
<seriesInfo name='DOI' value='10.17487/RFC3967'/>
</reference>



<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC8067" target='https://www.rfc-editor.org/info/rfc8067'>
<front>
<title>Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='January' />
<abstract><t>RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels (&quot;downrefs&quot;), 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>
<seriesInfo name='BCP' value='97'/>
<seriesInfo name='RFC' value='8067'/>
<seriesInfo name='DOI' value='10.17487/RFC8067'/>
</reference>



<reference  anchor="RFC2026" target='https://www.rfc-editor.org/info/rfc2026'>
<front>
<title>The Internet Standards Process -- Revision 3</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1996' month='October' />
<abstract><t>This memo documents the process used by the Internet community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='9'/>
<seriesInfo name='RFC' value='2026'/>
<seriesInfo name='DOI' value='10.17487/RFC2026'/>
</reference>



<reference  anchor="RFC4858" target='https://www.rfc-editor.org/info/rfc4858'>
<front>
<title>Document Shepherding from Working Group Last Call to Publication</title>
<author initials='H.' surname='Levkowetz' fullname='H. Levkowetz'><organization /></author>
<author initials='D.' surname='Meyer' fullname='D. Meyer'><organization /></author>
<author initials='L.' surname='Eggert' fullname='L. Eggert'><organization /></author>
<author initials='A.' surname='Mankin' fullname='A. Mankin'><organization /></author>
<date year='2007' month='May' />
<abstract><t>This document describes methodologies that have been designed to improve and facilitate IETF document flow processing.  It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication.  Before this, the Area Director responsible for the working group has traditionally filled the shepherding role.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='4858'/>
<seriesInfo name='DOI' value='10.17487/RFC4858'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC6716" target='https://www.rfc-editor.org/info/rfc6716'>
<front>
<title>Definition of the Opus Audio Codec</title>
<author initials='JM.' surname='Valin' fullname='JM. Valin'><organization /></author>
<author initials='K.' surname='Vos' fullname='K. Vos'><organization /></author>
<author initials='T.' surname='Terriberry' fullname='T. Terriberry'><organization /></author>
<date year='2012' month='September' />
<abstract><t>This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances.  It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s.  Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6716'/>
<seriesInfo name='DOI' value='10.17487/RFC6716'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIABU59VkAA41ZbW8bxxH+ToD/YeF8SAKQtKQkdiwUsRVJjmXIlmvJMIqi
KJZ3S95Gx9vL7p5oJgjQv9G/11/SZ2b23mjJbYKY9HFvXp+ZeWYzn8+nk2hj
aY7VW+c3Oto7o96blfGmykxQtlLvX54GtfJuo65qU6lr1/jMTCd6ufTm7lhd
zM+mk9xlld5ASO71Ks51LHWYm0/R+EqX8wqSvVnNDw5wUkccOzo4fDo/PJgf
PZtOMjxZO787Vsusnk5s7Y9V9E2IRwcHzw6OoMkbfax+MZXxupxOppMQdZX/
U5eugqidCdNJbY/V36PLZio4H6Er4NuOlIZ/0Bu6iYXzx9OJgr8K/9gqHKuT
hTohS+WROHBSWj186vz6WL1uKlsbr96auHX+Nv1kNtqWx0rfsrsvfpVDi8rE
PT3nC3VptB+qOS+ti4OnrObUhsyNZJc48CKjx4vMbUisGsh9vVCvdAmd1VD0
a2fK8XMWfu5tFoKrRvLp7CKdfWHSiVYVn2RFrxbqZakrvdbyuih6ZXQsEJXR
T6wLkFHnuY1OvEvKfDAv/CqbG/5lgZNjLXDnRlcxNF4PtLw2q9X4Oau4qHJ7
Z/OGENGr+BWHAY64sCauXqzpoXgznVQtvAkFZOF3z548bb8fHR4+a7//eDB4
fnD0pP3+/Y8//HhMkmy12pf15OnhE/5tOpnP50ovQ/Q6IxywdRfnNy9V7V1m
8sajqtaC5XKnvPmtsd6oWOiotGJka58HRe/fciA3eqcqR7JUoVGdWnWu4PVU
qSo6/qH6TESoTWZXFlVm8av5lJk6Qp0LRoracQ6VGNq/vHS5NQEZKWxQKO9m
Y6qoMpRihAO6UueputX1SIE3awvnd6g/u7Gl9mQZVIj8M7et0F26U+J3oaHP
oLeI+FwtdcCfkPbHHylRf/4JnbkCTjc2hkEEWKzvGxa0IeEb1GLcKZ2RtxDV
tqJxNMKiT9nG5nmJtvYVkBW9y5uMTsjvNzCfU7hyZem2gf257kL1jhIbghhL
iIGx7FduQubtUqzaPpzhDOHsPGJQwJ0FDEk4QyBYng2fHyOvc/olISknXUuj
mio3PkTncg4cgQhPK0OWagQeopXd1KWhvIoOt2LHYNFCnYeA55YwOlN2BcOj
yYrKlW69Y3tJ2L22zEhI9QVP8WabZ/aqCRQg+tarWBAe6d+rFdLZoHOwWNgv
DmZIhF4636pfNrbMKXPIshkKoshsTVmqHE20CQQrW40ydW040+opx4mU6KUt
CT3Q09dXhyAZgsm3PTwpnbThE+Vee7QhCvbeKaqoBI0cnnYFRMEWt39SV1yW
XxCSMmqrzPmaIkF1sxt1BJKj1R1wMEjvuB/AUIzRNX3Sj60+gGNjTOSHJCWB
i7ASSFBIQTs8gP0XIth92WISwwCOamtzShrFG0DILX2/Q6vWyzLl+eL8+hf2
kBSbEBP+IzwmOXWzLG0o4LHmXjSoFGSIADwo3LN5RS0jK0x2i7dQhFH9pYix
DsePH2+3W54VNI0e23xOvf1xd3RRxE35k9pqj/nUZqbnSeTAYBjstSE04zl3
jbZ7wlQv5nMXi5T8V25rkKAZ+WapC5KvDt2oQvf8HdlqsqIvNElFq2SG45lG
+SAKqKFgkUcEz3oqvdgAilSIsW1erRmMivxOs51ODnS1OpdahSmwaoeqWSF/
TRnRjdhAtAwQLC1SYChpJwHmE8adYiY5U8K2eH5/E76d0cDWlf09IY7aOOWv
hwVxwpSxj9I7PoJlkTu/eNfUwAtyzTGVOpfx0NQ8z5AmOjnipn39C5xK8gmw
zTCPeC5ALMwo3Ha/8fznX/8OKXzTydailJdteKGS2pexjHPqJ9Cm1ylHGiUN
E3JkZgeHEeF8OmmqvuEScZQCpVIik70ZxKFDcismosmgOsBdgOcZcmmhhS2C
w/izZQ5QjKG65UbbF/9gcC6kEoZjHEUK7oSQdgFBNDRNbAwEISqB473Rt4ag
aXTYcUPpNQwCPuy3Es8Wc4NRvPaG9gmEVaYyFfuiLdJbwwGCC4/efLi+eTST
T/X2ir+/P//rh4v352f0/frVyeVl90VOTCf429WHy3SAvvWvnl69eXP+9kze
fnPyN3yQu4+u3t1cXL09uXxEEyEWZFkXIO1NmqOWZkrtTZRm0/XttBkpYo4z
9fPpO3X4/XQigwWPUtiJT3ykiJwitz+bvneg5XVbVv6861aUT/y3om4ClNts
3HlpaN9L/5KyQ5RpoHyFKL0U50A4xWGLVPBj9U1igSTOeIwO/S2bQIvBtRzZ
GF2FLpnJLOrd5hOaeuxoxoobNCLW1FTFuQhJIwf08Q0bQJ2D/LjTJZ3lV6kC
IB0bDlregCsKxydSVTuquW7UMi+56JwYWzgkQ5lDzqqYFqXwmdlZoSuULRZV
1DHlcFCGMzWIDbpw2mAoTHiAUetl8sE1ocYbuy4iN4mssGjloyHMPoqAWvtI
nRROcqD6sUwpDc2yHalpTLdQ5MwetXntFweEjedmRqVqKSCUY3IVsn411IxR
rgjFyubC5KgKsXxEbHnsAaf8u1ay3iMG+wS2GFU5wB8aGg2WA51j3ttS3glu
Y7CYK1NiNFDDhBC7rtJkQqvap51kJ7EG48udlBt9R4zQ7WLBtsEzZhfha55I
FNu4Jya0CO7Ieh+rmvMR9hmUQwqQ0twgl6f4gKpgyhVLoYkRBEmfGLCrhiQl
Vt0yRctAoxSGpqbBqNIW3LtBmXnIZtquqLZAdGY8nhLTJZJDmGMksqlbqUFM
iXLt0LGLjXJieybcn/3cOJRSRncG5Y4ljLpV8vQlFf0nTYbwVCnTsKAVFnSY
drEB34AQem+WugB06TI4JQmH3BamyR/igsJk+sEX3XhHSwI1jVCAcdkwCmxI
aaIVpuU1DCjZGcQU8q3lLFK1EuqVzngrzbuUSBWxzwSM71uc8+95Yo6fyXgu
e8cPC3XihdhcvHtP899llquWIcmbyD07eAo92QFIs2j8rQ0R3g6ub1hjiiPt
wdZ0z8Ee8+QlNAnBpFADvNwxsPg0UagQCeASqvfoPXW6rlyft6PoXXsFkbr3
h0AdO7GD7n6CcrFB4ErZwVMnWNlqsDz1O3kaenRrggfcNuk6iCwjYjIkxeky
ETA56W8AHAquW66IM1+fXY2YtNwQ0ECkK4JupV/uUoYTwwAJ0KQip/qW37vx
QgdXFoU72Byo8XM29RDvYwqvh23bRrOZqcQullS1gI3mqJDX/Zvgn2QzrS/B
ED4AZR4XeNi5HQrXlHln73iGzWTvgongz5/v2cweYZ6Ns8TcascQZpurHYF2
cE01uD5IxK+LXgBFByqZxH1jFuvFmEdfDYj7t+2O+HCyUDUYyzRebdhwUIRW
dU5n7PPS9Lq1bMM0MIAOTEbNCwhckddNe2U0kCLNUMCO5ug4HCdniYKEFEo5
PFgE5fKGzg5u4nRdl7zp/08I8u5G83VnojBG09+BDW7MO81qdIGDPb1scq4g
uvIuS2Fz4y6gc1cLCxk/vyQQn+IlyTeNt+mke9hiMqlgBNzTnsJ9bg53pQex
9EX4TCcJPw/BY3irs+du58uo/aXSkAFAO+cojIlIGHDJJt3i0RidTs5a8n5d
mBoQyaVT0bWtonueNkip4CCJ9jjkoOAJSuMbK19heL0bUjCmASj0wPH4/4GS
QNK94O8DCbdeXusIFFL3ACYBm1kd5pBWZ5Zop/Nfw4RI8014E3FIuxrsXD0J
RvmjXfG8Hm9bUgvjPJwWGs0x3cc8oLqNn6hMLW6PeLPK7t5ovLr0VIRmpOX7
zRWJMUwQaer3g9Sme9xEPKok7gHTphPeFcFJ6F4FnaRNoh1suj1dbVndrNt+
aQQJb5gNOIRcJn3GMlDXr5t8bQQZXMic8W7DEKqGKW498ENkkTLOKb7TXUf6
ii4eG1Z/Sl7lRHkJzfKz3LZgAxJ/OdodkAYlmzsjCw6FXWqyFUuBqT12rmyX
1p/Ee6nv9LfXN+3lbHvZ3167WfJK57lNkchGZsr/POgA4GXeD3YWvko/eXty
r3s3g51STo2lL1Qr4iS7rdwWVEQiHuRtXd0yRC4bOHe5q7JCltlK7mTImI3j
IeEa2s9QLtueS/K8AfaIA8WYqp0zrGUHw+OtGd6dESqGFx50mQMv/wtmJyAL
Px0AAA==

-->

</rfc>

