<?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.3.10 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-kuehlewind-update-tag-04" category="bcp" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="New Tag Definitions">Definition of new tags for relations between RFCs</title>
    <seriesInfo name="Internet-Draft" value="draft-kuehlewind-update-tag-04"/>
    <author initials="M." surname="Kuehlewind" fullname="Mirja Kuehlewind">
      <organization>Ericsson</organization>
      <address>
        <email>mirja.kuehlewind@ericsson.com</email>
      </address>
    </author>
    <author initials="S." surname="Krishnan" fullname="Suresh Krishnan">
      <organization>Kaloom</organization>
      <address>
        <email>Suresh@kaloom.com</email>
      </address>
    </author>
    <date/>
    <abstract>
      <t>An RFC can include a tag called "Updates" which can be used to
link a new RFC to an existing RFC. On publication of such an RFC, the existing
RFC will include an additional metadata tag called "Updated by" which provides a
link to the new RFC. However, this tag pair is not well-defined and therefore it
is currently used for multiple different purposes, which leads to confusion about
the actual meaning of this tag and inconsistency in its use.</t>
      <t>This document recommends the discontinuation of the use of the updates/updated
by tag pair, and instead proposes three new tag pairs that have well-defined
meanings and use cases.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>An RFC can include a tag called "Updates" which can be used to
link a new RFC to an existing RFC. On publication of such an RFC, the existing
RFC will include an additional metadata tag called "Updated by" which provides a
link to the new RFC. However, this tag pair is not well-defined and therefore it
is currently used for multiple different purposes, which leads to confusion about
the actual meaning of this tag and inconsistency in its use.</t>
      <t>The "Updates/Updates by" tag pair is currently used consistently as different working
groups or areas tend to apply different meanings to it. Opinions also differ greatly 
about the obligations on implementors for the updated RFC. While updating an RFC never
makes the updated RFC invalid, updates can contain bug fixes or critical changes.
Some groups apply the update tag only to these kind of changes with the
expectation that new implementations are also obliged to implement the new
updating RFC. Some other groups use the update tag to define optional extensions
or new uses of extension points in the current protocol. This disconnect leads to a
situation where it is desirable to add a "mandatory-to-implement" indication to an
existing RFC.</t>
      <t>Groups or individuals that apply such restrictive conditions to the Updates tag,
consequently usually do not use the update tag for any extensions or addition to
a protocol. However, as there is no other way in the current metadata scheme to
link a new RFC to an existing RFC, not using the Updates tag makes it harder to
find these new RFCs. While implementors might well benefit from some
extensions or additions, they might not be aware of them and either not use them
or, in the worst case, implement an alternate mechanism instead.</t>
      <t>Currently the Updates/Updated by tag pair mainly provides a way to link two
documents. The cases mentioned above clearly benefit from such a linkage
which the expectation that readers of updated RFC as least look or also read the updating
RFC. Additionally, there are more cases where such a linkage could be useful to improve
awareness of some newer related technology without providing any indication on the 
importance of the linked document. As the conditions for the use of the Updates tag 
are not clear, often it is not used in such cases.</t>
      <t>This document recommends the discontinuation of the use of the Updates/Updated
by tag pair, and instead proposes three new tag pairs that have well-defined
meanings and use cases.</t>
    </section>
    <section anchor="requirements-language" numbered="true" toc="default">
      <name>Requirements Language</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
    </section>
    <section anchor="new-definitions" numbered="true" toc="default">
      <name>New Definitions</name>
      <t>Based on the problems identified above this document defines three new tag pairs
with the following meanings:</t>
      <t>Amends/Amended by: This tag pair is used with an amending RFC that changes the
amended RFC. This could include bug fixes, behavior changes etc. This is
intended to specify mandatory changes to the protocol. The goal of this tag pair
is to signal to anyone looking to implement the amended RFC that they MUST also
implement the amending RFC.</t>
      <t>Extends/Extended by: This tag pair is used with an extending RFC that defines an
optional addition to the extended RFC. This can be used by documents that use
existing extension points or clarifications that do not change existing protocol
behavior. This signals to implementers and protocol designers that there are
changes to the extended RFC that they need to consider but not necessarily
implement.</t>
      <t>See Also/See Also: This is intended as a catch-all tag where two documents are
related loosely but do not fit either of the above categories. The main
intention of this tag is to provide a forward reference from the existing RFC to
the RFCs that may be of interest to read. However, it is not recommenced to
use this tag extensively.</t>
      <t>These three tags MUST only be used for the defined meanings, mostly with respect
to the implication on implementation requirements. This document does
not mandate the use of these tags if one of the described use cases apply. Tags
are optional metadata that are useful to understand the context of RFCs and navigate
the RFC series. All three tags can only be used to reference other RFCs (and not as
reference to external sources).</t>
      <t>If a new RFC amends an old RFC while also defining an extension, usually it is 
sufficient to use the "Amends" tag. However, both tags could be used as well.
In any case, it is more important to explain clearly in the abstract what
is amended/extended by the new RFC (see section <xref target="explain-in-abstract" format="default"/>).</t>
      <t>As today with "updates", none of the new tags makes the extended/amended
RFC invalid. An implementation that conforms to the amended RFC still conforms
to that RFC, even when an amendment is published. However, an implementation
can, and hopefully should, of course be updated to also conform to the new RFC 
with the amendment. If only conformance to the new RFC is desired, obsoleting
the respective RFC with a new full (bis) specification may be more appropriate and
should be consider instead.</t>
      <section anchor="cross-stream-use-and-maturity-levels" numbered="true" toc="default">
        <name>Cross-stream use and maturity levels</name>
        <t>This document does not impose any restrictions on the status or maturity level of
the RFC that uses these new tags in relation the RFC that gets amended/extended.
Further, no restrictions are made on the use of these tags across RFC streams.</t>
        <t>However, it is expected that some cases are less likely, e.g. an IETF-stream
RFC gets amended by an RFC from another stream. For amendments that effectively
change the originally RFC is is expected that the same consensus process is applied.
This document does not specify any detailed process requirements on how this is achieved.</t>
        <t>Examples exist where non
IETF-stream documents update IETF-stream documents. However, these updates usually
utilise an existing extension point and therefore the use of "Extends" would be expected
in future, e.g. RFC 3579 (RADIUS Support For EAP) which is a document in the
Independent Submission Stream updates RFC 2869 (RADIUS Extensions), an IETF stream
document. In fact, this new, more clear definition of tags could even lead to
an increase in cross stream usage of the "Extends" tag (if adopted by other
streams, which is still open for discussion and may be reflected in future versions
of this document).</t>
      </section>
    </section>
    <section anchor="additional-recommendations" numbered="true" toc="default">
      <name>Additional Recommendations</name>
      <section anchor="discontinuation-of-the-use-of-updatesupdated-by" numbered="true" toc="default">
        <name>Discontinuation of the Use of Updates/Updated by</name>
        <t>[NOTE: This is open for discussion and we would like opinions on 
whether the use of Updates needs to be discontinued for all future 
documents or not. This requires further discussion with the 
RFC Editor and the other stream managers to see if we can have a 
unified policy for all streams]</t>
        <t>This document makes the updates tag obsolete for future use: it MUST NOT
be used in new IETF stream documents.  The new tags are to be used
instead, beginning with the publication of this document as an RFC.</t>
        <t>However, the Updates/Updated by tag pair will remain in existing documents 
and there is no plans to change these metadata in order to apply the new tags
instead. While it would be possible to change the "Updated by" tag in the metadata
without republishing the updating RFC, the mapping to either "Amended by", "Extended
by", or "See also" is not always straight forward and as such would require building
consensus for each RFC separately. Further, simply replacing the tag would in any way
not be sufficient, as also RFCs that currently do not have an updates tag would
probably qualify to have one of the new tags defined in this document.</t>
      </section>
      <section anchor="formatting-style-of-amendments" numbered="true" toc="default">
        <name>Formatting Style of Amendments</name>
        <t>This document does not impose any requirements on the form of the amendment
made. Some RFCs use and OLD/NEW style to highlight actual text changes others
simply describe the changes in text. Both can make sense in certain situation.
However, this document does recommend to use the OLD/NEW rather for smaller and
a limited number of changes, while if larger or many changes are needed, a new
document revision that obsoletes the old RFC should be considered.</t>
      </section>
      <section anchor="explain-in-abstract" numbered="true" toc="default">
        <name>Indication of Linkage in the Abstract and Introduction</name>
        <t>The RFC style guide <xref target="RFC7322" format="default"/> recommends to indicate updates in the abstract
and introduction. Note that both is needed as the abstract is meant to function
in a stand-alone fashion. This document will keep this practice for the new
Amends/Amended by and Extends/Extended by tag pairs as well. It is further
recommended to provide additional information about the extension in the
abstract or introduction for the Extends/Extended by tag pair in order to
provide the reader some assistance whether he or she also needs to read the rest
of extending RFC.</t>
        <t>For the See Also/See Also tag pair, additional information of the linked RFC may
be added in the introduction but there is no expectation to name these RFC in
the abstract.</t>
      </section>
    </section>
    <section anchor="future-work" numbered="true" toc="default">
      <name>Future work</name>
      <t>There will be a need to update the RFC Style Guide <xref target="RFC7322" format="default"/> (and specifically
Section 4.1.4.) in order to discuss the new tags if and when this document is
published.</t>
      <t>Further, the "updates" attribute is part of the "xml2rfc" Version 3 Vocabulary <xref target="RFC7991" format="default"/>. 
Therefore an extension to <xref target="RFC7991" format="default"/> is need as well. This may be done by a future version of
this draft or in a separate draft, e.g. with other extension or amendments to <xref target="RFC7991" format="default"/>.</t>
    </section>
    <section anchor="alternative-approaches" numbered="true" toc="default">
      <name>Alternative Approaches</name>
      <t>This document proposes three new meta data tag pairs to address the problem that the use of
the "Updates" tag is currently undefined which causes confusion due to various different practices
applied in different group and after all a waste of time in recurring discussion about using
or not using the tag.</t>
      <t>Alternatively, in order to solely solve the problem of avoiding unnecessary discussion time, it would
also be possible to document that the "Updates" tag is undefined and as such there are no 
strict rules about applying it or any implications of using it. This was proposed by the IESG
providing an IESG statement for community discussion and lead to community feedback indicating 
that this solution is not preferred.</t>
      <t>However, rather than defining three new tags, one could also just clearly define the meaning of the existing
update tag. Still, this could also be confusing as it would not apply to RFCs that are already published.
So re-naming and defining one tags, instead of three, would be an alternative. This one tag
could either cover all three usages that are described in this draft or only one (probably the one
as defined by the proposed "Amends" tag, as this is usually seen as the most important one).</t>
      <t>This draft proposes three tags as those tags are considered to cover most of the usages that we
see today for the "Updates" tag, assuming that these cases are benefiting from a forward reference
of an already published RFC to a new RFC. Especially separating changes to an existing RFC, as often done
by use of the OLD/NEW notation, from extension/additions to an RFC is one of the main confusion and 
discussion points and therefore this draft proposes different tags for it. However, if it is observed that
not all proposed tags are actively used in future, or their usage is still not sufficiently clear,
it should be considered to deprecate the unused tags and therefore restrict forward references to
only some of the identified usages.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The changes in this document do not have directly impact the security of any protocol
or mechanism specified in the RFC series. However, amendments or extensions can help
to improve security or discuss security-related issues. Therefore, the use of the
proposed tags and their clear definition can also support such RFCs in their intended
goals regarding security.</t>
      <t>If a document is amended, it is expected that the same consensus process is used as for
the original document as an amended can be see as an actual change of the original document.
For extension points usually the originally specification also defines requirement for an
extension mechanism to be used, e.g. in form of policy for IANA registries. Of course,
the requirement must be considered when extending a protocol.</t>
      <t>There is a risk that this experiment fails by either not seeing adoption from the community
or not addressing the discussed problems sufficiently (ambiguity of use, implications for
implementations). However, it is not expected that the proposed tags will make these problem worse.
In the worst case, if the experiment is decided to be reverted in future and the Updates tag
should be used instead again, this will likely not make the situation worse or more confusing
than it already is either. Maybe this effort is than seen as a waste of time but the same recurring
discussions about using or not using the Updates tag (especially during IESG review but also
before that in the working group discussion) are a waste of time as well.</t>
    </section>
    <section anchor="acknowledgments" numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Alexey Melnikov, Alvaro Retana, Barry Leiba,
Eric Vyncke, Heather Flanagan, Martin Vigoureux, Brian Carpenter and Sandy
Ginoza for their reviews and comments that improved this document.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC7322" target="https://www.rfc-editor.org/info/rfc7322">
          <front>
            <title>RFC Style Guide</title>
            <author initials="H." surname="Flanagan" fullname="H. Flanagan">
              <organization/>
            </author>
            <author initials="S." surname="Ginoza" fullname="S. Ginoza">
              <organization/>
            </author>
            <date year="2014" month="September"/>
            <abstract>
              <t>This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series.  It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC.  Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide.  This document obsoletes RFC 2223, "Instructions to RFC Authors".</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7322"/>
          <seriesInfo name="DOI" value="10.17487/RFC7322"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7991" target="https://www.rfc-editor.org/info/rfc7991">
          <front>
            <title>The "xml2rfc" Version 3 Vocabulary</title>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization/>
            </author>
            <date year="2016" month="December"/>
            <abstract>
              <t>This document defines the "xml2rfc" version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts.  It is heavily derived from the version 2 vocabulary that is also under discussion.  This document obsoletes the v2 grammar described in RFC 7749.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7991"/>
          <seriesInfo name="DOI" value="10.17487/RFC7991"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAEVP7GAAA+1ba48bR3b9Xr+iMvoiARzK0jrxer5kx9LIHqwejkfyIthd
BEV2kVM7zW5uV/eMGEP/Pec+6tHkeGMgQIAAAdY7JLu7+tZ9nHvuvaXz83PT
9OvO7fyFbQa3Gc/vJn/b+ofQNefTvnGjPx/d9vyrr80YxhZ3vfab0IUx9J3t
N7bzDxbXo930gx186+hCtCs/Pnjf2Z/evIrGrVaDv7+w73HvR7etVoiGXnBh
f3l9+fHqi1njy7YfDhd2td4bE/bDhR2HKY4vv/rq269eGhNH1zX/4dq+w0MH
H80+XNg/j/16YWM/jIPfRHw67OjDX41x03jbDxfG2nP8Z23o4oV9t7R/zFvk
n2X378LwN3d8qR+2F/ZqCOsY+45/8TsX2gu7o7uXRVd/8HrTct3v5i+8wQuH
EG8711Wvu5kGH2/nV/htf8T2eIn8Lrn1D3d8gdc3XT/soOp7f2Ggp25TfzXn
5+fWreI4uPVozCVbwa5dB3HW7dR468hk+KVtfWPPPrGV45l9uA3rW75x5e0U
cW3sTRu6OzxAdqZlxt7iuv8c4hi6Lf20tB86u59WbVi75BVxwkKOX7yw463P
Dxha4yG0bZGls65p2Btca3d+dJDmMQEbuzokGfdDfx8aH60T+SAVvUWFXNof
+gd/7wd6d4i81t6FweJz14/2wbfteUNOiEXhUPQsPKYfvA2jwU3raRh8N7YH
0QK59m5qx7BvvW3CZuPpKvY87Pvo4XEiVOtdE0mUdd9tpkiqcKt+Gg2JBlNM
vD/Xkd6goywaSQBtIBqgI9+tD/gGQSK9fGnMR7oPMTrt6KWDh/3xid50S9JE
PAjNTln39DOezB/Fus/lb2NWh6yPhb4ab3UN6ZS3g6cG71Ng8430mxvtrbv3
M+UZ3U7kheila4cVluKCu9A0rTfmib3uxqFvpjWJ+P8O+X/fIX220XP9y6qo
t3UkcV6MfnGxEvqhH+7IDtuhn/YREGjd4HEH7m3YuPs9Hin3Z5fDtTDC1nvk
Eko5ro293me3WILeZHi/bIoe/rDV7ARFhB10RxHVD5K7Sqw0YrI/3YZWfyIF
ifPAojCj2bk7H48fgZbuXRuaRYo59lwKTwf9raat3YTPnre4HuBf8Ca7vnXd
liLmpt95qzqQLZfVWbF9R7+xWyHOoLKGbKbPw4PHW7pk/Oe9X4/i9xy05IJ5
s7p/aFjUxUrhsCr3JMc1eeusDhawJ8dMYlK8HwmJdcSNbb/XAPKfYcnIuR4b
J2kmAhnInq/YfR86uFfoeD11HYopZPa+XVqBQIa6Drsrju1MDKNC3wPFDFyC
vA+RGAa3gv3opgZBZc92cGsHcx/Ox/487/YMb20SUDCWmBmWGPN9dky6E1GO
sFFAFEMxtiBDj2AAlIPJ5IIfMeFAihLoaGEoFvzfpxQdWI4cvGckeESn5Jyu
O1SK5CBRiCJEdJWqMtC4KCgiGKOWe3CHYy1ngIvrW2jkNyHsQmWlr0fbsxIa
gbLF0OCVWG8TBNJiBsSYwmsWhruwvRUwBN538KPRboZ+B2q3I8d+bPuR0fyg
j5JUyBTugRxc8t+O0cwH3n6l4R28cZF0AQyKI+euRRUHlAja0Q8dWWLnKdRC
3KV8Cc94lTGuUsLzkhwKIILHUfiWLMGWgGIlWTz0JiX4SN6uedTSD9gkJYVV
T44Fxx+wzlw7nNp4Jbf1RqBfUtwRFAAUYRGOvRq24ClYFwoAvbxj5RI00M3F
FTVTLu1lTo3tYaEeRtreUbISqSUQ52IhJqa20TS+mVpFHOjDGzZX5yMLRrYm
L/FaTRA4QfVd3/bbA8McAbooUmD5UEdwLwY1WBv1gOvWmQeRIFgs6Rk7EQCv
gjWngcKeas82tE9yITbDArfAIxVw1LMob8rOExH6H7K3I6f6X2JvT+xPAKgw
cBxE+xY5ZiLf4tR/h3BDwGALZ+8+3Xw8W8hf+/4Df/7p6t8+Xf909Zo+3/xw
+fZt/mD0jpsfPnx6+7p8Kk+++vDu3dX71/IwfrWzn8zZu8t/P5Ntn3348eP1
h/eXb88khmslk5ngXvA1ZBU/7AdPXuRQa/qIxLsSK3336kf74mv7yy//BL9+
+eLFt1++6Jffv/jma3yBG3fyMk698pXAxgD24QC0CKIAStuHESHDkBtv+4fO
UgAsuYKzFsqkureuec13jlxFfRWWQ6LaATMbCvdNyOE+35ZY7VEDm5T+4cJt
2z9QYCTjoiK8ZI97zn8YmC4ko9Z8jZ2XlyHYozsV68V5Es8giuF0HcYDXkiC
OxHozHQWsAG8LhDh0ef9uNZnQjRkHl4J1orAqrABkKcsXV7ZJzVlNgCm1INa
1JyV9kFMmZYKWyIenLYOQE/GNU5Vxyyn2olsk3MJezNhoHnk7sILrighQa3y
9zfplXPYXLHJquAdmTJVuV2BfDzReFUTrQ7ZSTTU8XNhMSc0i8zRugGetlY+
KJIIAxG1l3Sf9G6SLVUC0XKcKZWSCwVMeoZ52LbzCYJyujBHxq13WFmi8+Ic
XD0QmVhNkuTBApEvsIf2UIwEm9wgMi5huefpw0VyNpudzVH6xc7Xt+cUvmQs
yVhIw5UiScqUgeBA0VPenbKaKP0qq1Co1hQtLazgNZFT5hdHLwivLiLeqpwA
MiH9IBM2SBJc6iB1cX6vq1XlY1zAEY0SXe0cUQJamwEPTJQWpgRe8cGSp1IS
Wks9LYRIZVJnucdul5bxnq8S4nCXj2OD8TB5X0qaqXxNuLMAJYjEjdj5IRSR
EaP2JptVKXten+DmknwS+c8o2PtoaBcCFP4oYUaVM2wsRb6apgB/znLC3ZfU
j4yc2HP0lYqfKf5QU5apIwI1aonOtR00Rq9ha9DvHYIEdaZPNrLRizdckrMV
TVIEzxTJJkuWF7rOiz7lVbFjZLByA+4mWw0kceynAfHwDAFwvamIuxOmQS9q
JbQemHRLpcwJSQrbDBGLXI+Iu5g4bQATgSGwz9XJmWQUrvgrF1v1lIV4cxXb
44gj3rE01x3zNSXa/AbmjYmtjbKtfUsFcyK7ytFTQxN7cNwTUfB+7gv+1j0X
+zRC1dFz0wmZXZc9x//SUl++kMqIB/aNU0c909r9jGqc4kG5zV0q//Te5yqI
qVoAsPaJV0se7blXm4GvzkCIcKITeoeECh7hegsK5gq3y+mZowFq4EZXvPV1
rLvjlxt4m3CZ235Pzkxl6y0ZacFdBDgQTLsq7QxKnuQlKs1RP8sWwpFlWdrr
jTi0PuPUTevnUmnu6b2r2LeeKwu6RRGC6mdpyVHK5AdJXPt0FeIzZQkJORT3
2IUQzmDAQyBIwD6N7I4u5+RRCrcnT57YV0Mf4zkcwbsdOzZpZ+fGaQjjAQUR
IDAe03cCHw5Fclh+5FAKf20s0V6AEOPEiXa+IHSdYSEl6lhVxgJdXZ6j2NnN
Wz+eev3SvJkGAgvy17kwXJah4ktSnaKkW5MS1PlIEUT+jzKGVJHkEiQDl2cK
oFi+paqtDXeeikG/BBjA9a6vPr5RxXJM1HJTkGonjZOb6wTp5PalfUPlZ3Ip
TW9+sxHHQLJXdsINvSFsA9ehybVOpGVbuJ34ABAONoGXEHWgeykDBNLgrxg5
UVKycoOkEKj3m56vcxQpGLxfsigtvL4NUGHDJNFRIEbJ4Eo0ACymUlJFOrTt
8+jFWROZTJi6jArZZgJ+BPZK+2vk76i5XHnFmdLZM9R2GjhJl6AviEH4sVcb
k7p/98/ffGuf/nT5+vrTjb2Z9gTgbL2ryx+faf+ZVFH0KjiOHND4PfkCfrqZ
VrsQWbwbDUTdE73i5e//pbziKrd/ni2Sk6nXmFLTI8FsAOzaZkdILbQxQblE
U17mYSVRMbq23PDojYwlqAdNBaSVEMk4Qb0MzQlFZcScnoJyuAYsQpyc3dpo
VC2KQgTkAcIdMyfqAEyiAcEfRjSYpxU3zqq3MLx2UTfzwvAZF+ylL4PaXZsM
TstNoN3rxzsNn8T4p60rY/7yZxTgV4U//5rID149hmAAd2k3HlcNvJ2Du3Kz
1E8hZh+1Si9dEKWTRMt116UvRmiKqFQ+qOEXcR+jXy1Vzk2MPlfQC3dQhbLV
cEMcEvYcpGoEW4AJHzwzM26WOGumTgryfQ++esjSqV3/8tfjDHE8GBBWranO
8/O6MyjkgiA29U5MYkswOeWCysFrDOCiIueK0uqgR41mOKq7AY3M7rIyjgZi
Ry2TqKhc4/9/19TkqdlAM2qKmII5xWQmw412oUHBpClecDz6wrixSq9N42oI
knabtpd7x2PBKqTjGLTfX+WI2aSOay5JhemNJjUUB688KrW06+GHqGIHibSL
oIXfWemoUMMqNQIMf4Wlz6gKJRp1lkov1z64A6OJ44Z1KvlIT9Q9os6h7Ekd
HCVnaKljYEoKIyfyyDFaXezdgC1SLZOZQCT2R9QE+l6nHXGhq40azmkQxWjH
vNB87mIx9Sv1ZZnlafEr0dHNfJyXNtTMcivc+XfkJEqe0Bbf/RiXTiXjcQeP
GRolE7AntsHNeGj58ctMDX4bNZvnaGmQgc2mij2tZogm6YiLt5344Ie3r5+/
v/oTDHYQ37qF2Vo2nc5Puf5L3QwGl2hU/anqlFJRb6G94pGl/Y6KJYIaggxL
ppV04wceF+a51tLMZ8fzHeeGcl2eJanhF+Sm5C9xR6NrhkFDTfldoKjopt1K
Ghgq3kIrRABh64YtXSMO25VuHPfAAd7E4Jmem6q5fR9irnQS5gkapgL0lJZ7
IeRI3U0FT291bKDxepmKPzJKfZrA/vLkscJOOtXCa8ly24laLNLe/eZ3L19+
+TJrxfdphFBg+6jqNNJrLy9e2vc9dx+wVa57Q1S96OStFKxU5XotbjdTJ6cg
KAYtdxLO+TgTeAvAh9ad+zWD7J33e7H+nlYMa5/bLmSBk/4uq+mR/mQ1Ekg1
ub1mATWNmqwVqQFzc6qwi3zYKJ0mKMUwG19pXt49z00rgyXB/5F4dSIwSQYp
EmmCJVWIi3SigKvMRDS4KoCPaYsjk4w8y6L6yKTRc9XLfaNCnfQP62nL4zqY
j5fI5UDiKJnj/oRtfq6C1TTOsuJsUNfz+TDNjNJSMLU7Mdt7IxyCzk6wq9Pn
wGNTDkoxXpohayQIiH6vkVACgftLubCmQuJGmyZfL18sv14+m6Vl5VlzICfq
S1SQ+hNzkArRlAaFKbUqJ+fUarGAeQDlNLJCkM/GTLE/79qXw2Z9Zn8W+mt/
Z3/u1241AZ4O2Ma/0j6+/fbFly9LK4rgwqbuaZHUsl++LwVqiQAOOGXeDYUi
BdAR7ZbKnXZGZyTFqSmANfvKz1oeMeUSnlmEOKprZyIJgddRMzVALqmZgQzv
T9LcI2M+4jI2H1HSgR+fehi8GkpHTKUoFjZuKoqkVcz85E6XMnQ6iMX9inKa
qJk4Kd67IfRTfagnwVQ0WmSTusplPkAipGczeqHUNBIHvWPLh52XNgjJwpSy
qjkYc/jsgemHo4MI1I80plIl9SVq96WcRL2vvr33M9Xgte6+l5ny1KX5wqF+
M4m1yKzTMMQcUc9sp6zpE/UWpdakrwzSgQdGmjh2mKhzIBtmOkzCBfY+HnuX
JrrM9KNcV4+GOpO75N7o9dXN96YenvMv3K+SORehM2UA1D3j4bjU0wq5umGD
QFq59V0ewWNRo3unYrdvJ0YSpb977l9Lys+sRlkKnupKU3o25AQtobCUWp3V
/rcpjrlBrCeOhNdXp9mqQ37lOA1YHlXgSqaqJYWSbESJLpbqgnm7FCM1KZYz
VJRZDlUP1txQtjkHhIt+m7Il2oJsJs3sWUrsc1HqmOrMCbxXLalPGm1WSPGx
7u81ckRX3JqoZJsNu+fQxV1aWvRppuvM0Tqk7cLK1WWyC9VNfz1eJJ2BNDKI
dOBbyQ/Nfqq2PpZ+lg9DsBhHQCbVLH3rc3NyqEmi+B1tmZfOJyXKph+8oRpe
evmJZczCj6SO0078S+Iz1t1MPVZD16U5eTqSI/LANjoyfD4oVY58XnFOVc1w
mqCFq8HnyaEqF/VMCWUhOupRHQRJnB7eyBG/EBFzgnmeT0Tp0toTreouLtSr
o6BwTlNFuE6HjzuEpxYrOJ4P/hPolL7xRlvHKAH8cK/NWCP1b1scKlvZaXc3
9z9St1GMCD4ofbfcPuPubC5ZaeTAJ3IMXvtYgSHHEgE+6zww7KYiwWzDqYN+
anpSrOHQYfqpSq0ObYgzws2RzW8odRFCvlIpUi/u41EteFTSlfK6QeW6pr0h
iohHcy87rcpeeCizearS8gE15XKFfNZTyDIjKmykH+rDhdz+8u3elCNa1Ytz
py3/dp6m5AHBpWNvUebiaOxgjkwvig/DaXt2zTEGVI7aWeYkyeAre+IaQdst
dBaEKuEtzEWxlARL49CKjKYxxOPDjX88LkijTOzM1POH4y5amnToEQ3CJL0g
HQNtT6n/nKyy5GLk5NBGAtmjycd8IFYGu342odAzpOUMZeUtpX2o9DV0uUlS
dT2vL99fko4DhQdZ+UMaGy50fFfetqPsPI9ALg1K1VWdWE31Cw8LhhDvbOEP
ZJ4hyA5caOmUeX2UE6rlxRqZ3ZfjEpmgJIaoZDjRRHVhGefI4asZnDx1u1XY
ThppUzoWmskWucDRmepnjx61OPWveQhw0cYNIMlFiY3SgVTP8/Lx+HhqYjZZ
MzxTXQet2Hl6ACnmw4PU/a6OM1YTUoVdISVuizSh9IjFk/GelTMXIqmtTl2T
pNwl6oeKQRmmc2HMmZKsyZZb2nfusNLM4jcbiu4Qhf4lBnFcC2jBLMGZq4Iq
ecW6LLAnZUF9ivOpL3m5mbi6YA5M3SukbnoVn/1apQTo0ugq/VMFLV/K259J
FjsSOp964Opufdf1D61vtrl7iTv4n6fFen4iQ//uDuWg/0xn0Xzbhbv+foEf
UGaBgKLa69zCfucGVCdvfVi5haF/oGZ/PnTrO3jID14I9ZuWphs093+Hihpb
+DlsEbB++oynhwB1v3LDnk9tsX/c4P8O5vvQ9f/pEn8Kg+pF0Fp6Q2kuq8mh
OWreWvNfSvn5TVU4AAA=

-->

</rfc>
