-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-carpenter-draft-adoption-00.xml
344 lines (287 loc) · 21.4 KB
/
draft-carpenter-draft-adoption-00.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
<?xml version='1.0' encoding='ascii'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.11 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-carpenter-gendispatch-draft-adoption-00" category="bcp" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="Process for Adoption of Drafts">Process for Working Group Adoption of Drafts</title>
<author initials="B.E." surname="Carpenter" fullname="Brian E. Carpenter">
<organization abbrev="Univ. of Auckland">The University of Auckland</organization>
<address>
<postal>
<street>School of Computer Science</street> <street>PB 92019</street>
<city>Auckland</city>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="F." surname="Gont" fullname="Fernando Gont">
<organization abbrev="SI6 Networks">SI6 Networks</organization>
<address>
<postal>
<street>Evaristo Carriego 2644</street>
<city>Haedo</city>
<region>Provincia de Buenos Aires</region>
<code>1706</code>
<country>Argentina</country>
</postal>
<email>[email protected]</email>
<uri>https://www.si6networks.com</uri>
</address>
</author>
<author initials="M." surname="Richardson" fullname="Michael Richardson">
<organization>Sandelman Software Works</organization>
<address>
<email>[email protected]</email>
<uri>https://www.sandelman.ca/mcr/</uri>
</address>
</author>
<date year="2020"/>
<area>General</area>
<workgroup>Network Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>IETF working groups often formally adopt drafts. This document
specifies minimum requirements for this process, thereby
extending RFC 2418. It also describes how an adopted draft
may be withdrawn from the working group process.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction" numbered="true" toc="default">
<t>According to <xref target="RFC2418" pageno="false" format="default"/>, the Internet-Drafts (I-D) mechanism is a "resource for posting and disseminating in-process copies of working group documents." However, most I-Ds start as
individual contributions and only become working group documents by a WG decision
generally referred to as "adoption." As noted in <xref target="RFC7221" pageno="false" format="default"/>, this process was not
previously documented as a formal step in the IETF WG process. This has sometimes
led to confusion about the significance of such adoption and about how it
fits into the IETF standards process. The present document is intended to define
a few formal rules about adoption to reduce such confusion.</t>
</section>
<section anchor="consequences-of-wg-adoption-of-an-internet-draft" title="Consequences of WG Adoption of an Internet-Draft" numbered="true" toc="default">
<t>After a draft has been formally adopted by a WG, its original authors no longer have
formal change control of the text. In addition to the normal consequence of posting
a draft, i.e., that it becomes an IETF Contribution under <xref target="RFC5378" pageno="false" format="default"/>, all future
substantive changes to the draft require WG consensus and are no longer at the authors'
sole discretion.</t>
<t>As a practical matter, the original authors usually continue to edit the document
and make routine editorial decisions, but substantive changes must be referred to
the WG and require WG rough consensus, consistently with <xref target="RFC2418" pageno="false" format="default"/>. It is
also possible that new authors or editors will join the draft, or that previous
authors may withdraw.</t>
<t>Adoption represents a commitment that the WG will spend time and effort on the
draft, but it does not guarantee that the draft will reach WG consensus and be
submitted to the IESG for publication as an RFC.</t>
</section>
<section anchor="rules-for-adoption-of-an-internet-draft" title="Rules for Adoption of an Internet-Draft" numbered="true" toc="default">
<t>A WG Adoption Call of an I-D is not a required step of the IETF standards process.
The WG chairs decide what documents belong in the WG, and can create new documents by fiat.
A simple situation would be if a WG decides that an existing document should be split into two pieces:
There is no reason to adopt each piece, that is needless bureaucracy.
A WG that decides to create a design team to solve a problem has implicitely agreed to adopt the result.
To not adopt the result is to say that the results of the WG mandated design team does not deserve first class agenda time.
Such a design team would have been created, for instance, when a WG can not decide between two competing individual drafts and decides to merge them.</t>
<t>It is legitimate for a draft to be submitted to the IESG as described in <xref target="RFC2026" pageno="false" format="default"/> without a formal adoption by a WG.</t>
<t>If WG Chairs choose to consult the WG about adopting a document, this is the recommended process.
The WG Chairs should also consider the additional guidelines in <xref target="RFC7221" pageno="false" format="default"/>.</t>
<t><list style="symbols">
<t>Any participant may request the adoption of a draft, after there has been a period of technical discussion of the draft in the relevant WG.</t>
<t>WG Chairs have discretion about when to issue an WG call for adoption, but they should do so regardless of their own opinions, when the WG discussion shows that there is clear interest
in the draft in question.</t>
<t>A WG Chair or WG Secretary must send a formal WG call for adoption of a draft to the WG mailing list with at least two weeks time to respond.</t>
<t>This proposal should remind all participants, not just the authors, of their obligation to disclose relevant intellectual property rights (IPR) under <xref target="RFC8179" pageno="false" format="default"/>.</t>
<t>Participants should consider the following aspects when responding to the WG call for adoption: <list style="symbols">
<t>The draft must fit within the current WG charter, or would do so with a simple modification to the charter.</t>
<t>The purpose of the draft should be clear.</t>
<t>The proposal should be useful.</t>
<t>The quality of writing should be sufficient for document to serve as the basis further work.</t>
<t>There should be no strong technical objections.</t>
<t>Any IPR disclosures should be acceptable.</t>
<t>The work should not be in conflict with work elsewhere in the IETF.</t>
</list></t>
<t>An informal summary of these criteria is: Is this a problem the WG wants to
solve in a way approximately as described in the draft?</t>
<t>After this period, a WG Chair must, in a timely fashion, consider the comments and discussion in order to judge whether there is rough consensus to adopt the draft, and whether there is enough interest in the work that its completion is likely.</t>
<t>If there is such consensus, this WG Chair will announce the result and, if positive, will
request the authors to post a new version using an appropriate naming convention.</t>
<t>This whole process is subject to the appeals process of <xref target="RFC2026" pageno="false" format="default"/>.</t>
</list></t>
</section>
<section anchor="withdrawal-of-an-adopted-internet-draft" title="Withdrawal of an Adopted Internet-Draft" numbered="true" toc="default">
<t>It sometimes happens that an adopted draft does not reach WG consensus to be submitted to the IESG for publication as an RFC due to lack of interest, lack of effort, or lack of consensus. In such a case, it may be desirable for the WG to formally withdraw the WG draft, such that it is explicitly removed from the WG's agenda and returned to the authors' control.</t>
<t>The withdrawal of WG document should be the result of an explicit decision by the relevant WG, and should follow the following recommendations.</t>
<t><list style="symbols">
<t>Upon evidence that progress on a WG draft has been stalled for a considerable period of time, a WG chair should evaluate the reasons of the apparent lack of progress. Such reasons may may include lack of interest, lack of effort, or lack of consensus.</t>
<t>When progress on a document has been stalled for a considerable period of time, a WG chair, in consultation with the WG draft authors and editors, should attempt to resume progress by taking appropriate actions that will normally depend on the nature of the lack of progress. For example, a WG draft that has been stalled due to apparent lack of interest may benefit from a call for a number of volunters to produce detailed reviews of the WG draft. Similarly, a WG draft that has been stalled due to lack of effort by its authors/editors may benefit from the incorporation of new WG draft editors or the replacement of some of the existing ones.</t>
<t>If after succesive failed attempts to make progress on a WG draft its completion remains unlikely, the WG Chairs may, at their own discretion, conclude that it is time for the WG to consider the formal withdrawal of the WG draft.</t>
<t>In such case, a WG Chair or WG Secretary must send a formal WG consensus call for withdrawal of the WG draft to the WG mailing list with at least two weeks time to respond, explaining the events that have triggered the aforementioned consensus call.</t>
<t>After this period, a WG Chair must, in a timely fashion, consider the comments and discussion in order to judge whether there is any concrete evidence that completion of the work may now be feasible, or whether completion of the work remains unlikely.</t>
<t>If further progress on the document remains unlikely, the WG Chair will announce the result of the consensus call and the formal withdrawal of the WG document. This will result in the document being removed from the WG's agenda and returned to the authors' control.</t>
<t>This whole process is subject to the appeals process of <xref target="RFC2026" pageno="false" format="default"/>.</t>
</list></t>
</section>
<section anchor="iana-considerations" title="IANA Considerations" numbered="true" toc="default">
<t>This document makes no request of IANA.</t>
</section>
<section anchor="security-considerations" title="Security Considerations" numbered="true" toc="default">
<t>This document should not affect the security of the Internet.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements" numbered="true" toc="default">
<t>Useful comments were received from [TBD] …</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2418" target="https://www.rfc-editor.org/info/rfc2418" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2418.xml" quote-title="true">
<front>
<title>IETF Working Group Guidelines and Procedures</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author>
<date year="1998" month="September"/>
<abstract><t>This document describes the guidelines and procedures for formation and operation of IETF working groups. 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="25"/>
<seriesInfo name="RFC" value="2418"/>
<seriesInfo name="DOI" value="10.17487/RFC2418"/>
</reference>
<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2026" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml" quote-title="true">
<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="RFC5378" target="https://www.rfc-editor.org/info/rfc5378" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5378.xml" quote-title="true">
<front>
<title>Rights Contributors Provide to the IETF Trust</title>
<author initials="S." surname="Bradner" fullname="S. Bradner" role="editor"><organization/></author>
<author initials="J." surname="Contreras" fullname="J. Contreras" role="editor"><organization/></author>
<date year="2008" month="November"/>
<abstract><t>The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. 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="78"/>
<seriesInfo name="RFC" value="5378"/>
<seriesInfo name="DOI" value="10.17487/RFC5378"/>
</reference>
<reference anchor="RFC8179" target="https://www.rfc-editor.org/info/rfc8179" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8179.xml" quote-title="true">
<front>
<title>Intellectual Property Rights in IETF Technology</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author>
<author initials="J." surname="Contreras" fullname="J. Contreras"><organization/></author>
<date year="2017" month="May"/>
<abstract><t>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879.</t></abstract>
</front>
<seriesInfo name="BCP" value="79"/>
<seriesInfo name="RFC" value="8179"/>
<seriesInfo name="DOI" value="10.17487/RFC8179"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC7221" target="https://www.rfc-editor.org/info/rfc7221" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7221.xml" quote-title="true">
<front>
<title>Handling of Internet-Drafts by IETF Working Groups</title>
<author initials="A." surname="Farrel" fullname="A. Farrel"><organization/></author>
<author initials="D." surname="Crocker" fullname="D. Crocker" role="editor"><organization/></author>
<date year="2014" month="April"/>
<abstract><t>The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication.</t></abstract>
</front>
<seriesInfo name="RFC" value="7221"/>
<seriesInfo name="DOI" value="10.17487/RFC7221"/>
</reference>
</references>
<section anchor="change-log" title="Change Log" numbered="true" toc="default">
<section anchor="draft-00" title="Draft-00" numbered="true" toc="default">
<t><list style="symbols">
<t>Original version</t>
</list></t>
</section>
</section>
</back>
<!-- ##markdown-source:
H4sIAHkQ1F4AA81aXY/cthV9X2D/AxE/pEFnxuuta8fz0qzXsbNAkxr+gIE2
RcGRqBlmJVEhqR0vAv/3nnsvKWk0u3Hb5KEBAsxqSOp+nHvuuRwvl8vTk2hj
bdbqtXeFCUFVzqsPzl/bdqteedd36qJ0XbSuVa5SL7yuYjg90ZuNNzeHu+5a
V7qi1Q2OL+nBstC+M200frk1bWlDp2OxW8p3Om1fnp1hn47YdH52js+nJw9U
iLot/6Vr1+Jx9L2hx7bz/EeI52dnz87OYZY3eq1emdZ4XZ+e7Ldr9YOJe7hz
6NPpyfV+ra7IktbEJVt7elLouFabAt8+6DuyIMCEx4++pncVrsTuterDUofC
2tOTzq5PT5SKrlirWxPoc3A+elNhm1IPVGkq3dcxYMmw4LaR7/lv2NvHnfN8
Dv23zB+Usi1WPV+pb1fqMgdt/FZi+txb3d6zwnkY+25n1PvW3hgfbLylvFz0
xXWNUI4LcyZp3eruJQFOGYRmfLJUb4udczWtv3RN1+PdeGRNW5jpqtfP1bPz
s0fPxmcFDFnf8Q7EFx49evT4fPqsb6O/pRzu1d+NPtxhGm1r5IuCsDKrAVrf
bOmLVeEaivDdgX25Uq9cG+cBfQk44B1u9iXH8u3Vk4ylcBy9u7/Ngfv2Rnsb
AAMkyluzder8yePHR84/PXsyD9R32pRufOjNFhXCZXdj28JqgEw9703rgrqw
3oQ7gnfhUWvRtvoodNUWbn4T7JM2WS5By6t6b9dqF2MX1g8f7vf71dHK+8L7
/Uq9scVO+zK4dh7k7+kbU9+5QiKNFJi6AbTfuiruUdNcvOHI/qbwf7QmVt+E
vAMo+DX7J8seYvND8qB1vtERNcJV+OblJVX88Pns/En+/Oc/PR2ef/3o6bM1
U1Bbzfc/PT9/xN8tl0vgAxjQRaS/r75991LtEw1tiYYC6ieaVvEZdX2rmAOF
K8MK5WuDAoP2jSE4hs4UtrImqMa2tukbwOHnHlmnr4WCI+3ohJMX+Mt4s7k9
PTEfI9EtXgv7mNJW6ioqXQcHAIXC2w1O3bm9QtDZBlOKFacnjb5VG6P2Nu7w
ZA9jvWvo6ENX8ltX2fPGlmVthL1BtN6VfcHdIf33ywNLTz/RiouicJ7tQ438
8ktKwqdP7MKMpoP6w9XyxVeqMYBPa0Oj4LJWXwD8rveF4Th0LkQ6DglXaDPB
IGKan9h2mSxFhXQUTFDYoSc54mH1hfrO7Q3oc6EanKjw4kCtyCN2gZJf2htb
9rrGWXDGbnryMPBrXVtT4FAn80gN56sNMq4+vEIOChssFcJWWhe2ok8Y75EH
hEQH9UVujzDqIqjWUYpsK9EiyEm0xvSrveZlaFRgKOv6gEPzq7FXU9QEeHDJ
dHQYR5tQCptyPgWFOywPcCXahkimFrvgddWT4cC56yPvD3bbAqWFRiug2Ia+
2KlsPEdG1hLaLKyrLAIBKLjx7dzsiRqmRhj8YQJsH5ygxGMjkC3WoN/aFoiD
W+gXyTXf18ixvHKwAosR2R4GsnWDGyuB6yVyiMqiZsbwQDSm2gY1MlcOgHBF
LVBL1XC4NuaosmFnSvlCkdvO2y2AWSvRAZQvBYmzxUk7fQNXkhOE9K0RkEnT
pVhFlDXqmCq2tNkv+qJNu0Y3aEuqCYoPGwkT0DYJNBqhjAmrgd2jLFxOIK16
BNkL2IgHCWxwS1V97D3sDP2GkkY0mIwN2RgJSGIqCiWb1YZeyoTYffRaC4ZS
OL7Ewa42VMGFNzEn6IKQ2xGrAmW1AvtGqlDaeBTQPvQcfgqdbXtDVhlES0wb
qJUsafS1UShQrDO8BofhpFyb4FPEQt3laQMFShw5KVnI6h17SydPnMf5290Y
ggV/hDSAFbCSSHbKf8zSluQ2MTUSGOwG8eCMtcB49hKMJwaj6i3S8pNLxZwS
zZ0BezITZOEJ0/XtQO0S3Ax0b1K9UbSBjMZGLjo+KDnHL0Nbgo9EDOysqQDa
qBwbACEvFlDoLJWuYVJS2157RNGY8TwBCh8JFY+yPMLKRpAGS6JUvDDG21fC
+f2mBiCEZhjGiGOq6DfMAvMh5e5CPij3S0J5Wrp8QYxD1uuc0lKoMxXkPeR1
evJOwgW8WMScEAXZtifHJ73AUA1kFiaGIJdBowrYxyzCCT9oHZXVcUUGB9t0
NTFv7MX9vetrCpey1dhgSqpJeieONB+tNMiBS8Mu7wldjUwJI++BOmvgxZqd
AIY5ApSgIHwjioXzxSszn2CZMRAAaEQbUITuCxTs7SrFl9cMRrnsIslZ6h+g
Nt3Qc5T/jeFqdwB+w7xKzlqoY0OsuoXALkc7KHRALaYuirqTZM2+IdvoaCB/
wJ58E3IiYWFDWWQZNLFogC8eGg/LKuQzqqLWcFPTSKu5EPDyt9z2DnZLVojY
pTeI0+WCcQndHKllLoALfMdZo+TL2xgwG2hv2kdZQUF2JgmaQYSIbhTRM8a2
MRgAyK2Gi4EZRdUYJGApBZ3envsWlhMC7qwxHQatOCoPEsifPjGFcIfNbXdo
tanfyau5lV5KFdD8GExSEZyXzJiTXk0SbsBo0jeUPk4ZkZI0/6NKS+9IoGb2
ZKKlJsYNJnVMWLrt8bQG54eZnGKToWXVRXurOmg+gK4DZzFnUv2bkLrVlFIy
5WrWA6zARzUAIBtvXck4g35tuYFRe+tDSCeMVJiowJva3NB7UxSXEwcZTGN7
TLFjBCGwEL49kbJgido1pTpZK5yMF9zmMJVUbzRigr24cMUa65WD7IdYbqUN
yvES6IntOGUfhpISqihqoz2LNFRYJMV86B8HMfd1RHpwjVoWPr815Jn2t9Jj
A3WaAWN3eTXJQQYvF7OtCUs1WE+aLIyEaZRAFBOq6jpIB2NlGDrXlsmkd0lS
o/mSUJZIeZonSlZAE2AgNFStP/XhQMUsJnFEh9rqLNUodjXVwJBhClRdmyJS
NdNLjY/Amt3ueOx5/earqRCjITTBdKleT+zIZh5AvnJ17fZcUTRIYhXnMXmb
Zq8Ur6OwrvOsv2QlLvHllEC+c0RTZoseAoixSt3OszDDOfsJwCT+uWk1ruRp
Yapf087V4Uu73ncUrYMaGdsWQ22+ZZY3LOuDqfp6tu5nxDtdkO29ZdqZ9MO+
goGWvKKQDB2Tegg3AS2EtNEQclDEntDPI9/hW1AR46HooQFanqI+8IDb/GR4
RA6TjUQ+SHwGC1ppmByji8J0UaM3zjziK8+0jkBJWqDlQQe9M9UArzF1MHsp
13H+y+XYqnS/gQj2TUN1KNFHGtAIkCOrUeZrdRWEm8dOnRUi45H0sLRySyS4
B4HqDis/cgeiPj7rLUOC/5IsSWxKtcgMupAOKVxBQFzI0VTEOK/SYcccd1AC
0jByhxyZCzud50UO1VtuSZsZzuJAZDPdfqg4MuXj1KONpuWdmQKzcxz7NHkF
7ua1MDj1ZnsNH1IOrqrxrDys5tmB4zFEgZWzbvE+Gvgmegd2LUgJohQszS0L
Xnp6ctDD0jwQecygRk5yky+OafoLcpkiWeuQddKjuqGnsOeG7hcHEmfG3O9o
cMtXEWw7ozuXOA4yaMvDCsBqoieSav+QBhOdJfhFGqKPVTtUzXA9ga6I09tR
7R7caI0i7o4p49f0z70zhiplrqx1cU2G5lwvhicyEzET5kfDO3mCl0sS8G4w
dDOg0qUbqUdP1Z0u97ik8KbhViGPbkM7FiTycXmuJxB+FMnM10qNu4Fnwy3e
h1dfDtpVhlWM9O3oe57F8+0D54Yp5iA79PLjWWKCQslgtmQYq0kgzlSOVFI6
RNrWrIMN2k+PdLlU79HIFAbc0kgB8MDrMCEQvpKknl3PQHPXdJclGjiTBUd8
otQAqsQ3PMFl02Bv3VMliP00EQ0TBBCouRHmfGdLVoong7ycEk3/27aoe2j8
/xFDSRdSQz90ecjJb3N5kboHZTKNmNRBpqgbKIQvAeQ2YjEocFRT08Ukr2DR
aCblX/Pt6JRctDRCySIzW5sxXxq+cJALBrAQ3UDlsB9H+yXdjXzUxK+LKQT4
4KOgpEo+yt5A31KYrSHZwyWkJ2JJtX2zAfljw42re9ojjMqX31TOEULUUI3d
WLOfjptsFLBhG1trX9/+57Ye4oPCSR0lJeNhvhY6spveC9A5aCqvs3Imzh/e
mrcm5vGmw6v4twa+1qV77WT/cJvgMEWt1NC4ZAYCGYHi6b6sEu8TGGQ4pUu3
e6p01hk9/eoDSPStNMhFjl2aheDiIl0gppFlHIxYCEiFTWiRFf8hs84kM0uf
Q6I7SFhyNRG40Lf+r4eYof0MULr/lb9xqlkwAyOOLPgpdzesiBLEkKSIcWNr
+BaTeAzWcM4RRFPOTF39n4gz3fIFL0XZzBrABD8pkKy8qBxatBW0qAoBo1tV
mVPS0fdsm0Nw1GhZ9k+hPL1i/gx67xdv6fUzjFCMPovQ9Or0C066WJUbsJlx
GyNd9feQBr+fAEy/HV78cMG/yHCb4q4gCmTy2yjTSLqYFE2L42hjEpKowN7T
gPe5cyYTk64qNpd+0srb8z1vkp/p9IviGlgCs23ll1h6+p7HzBHUe4IqZIux
Q4R//Me75y9+/KdarYbfTDfg8vQTlPzi81e35b8fyD+o4X8aQyH+W/6dIyn0
HK5/A7zThljRIwAA
-->
</rfc>