changes since 9092 secting

This commit is contained in:
Randy Bush 2022-12-08 11:34:44 -08:00
parent f7c12c0e50
commit 25c5c151f3

View file

@ -8,7 +8,9 @@
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ymbk-sidrops-9020-update-00" submissionType="IETF" consensus="true" ipr="trust200902">
<rfc category="std" docName="draft-ymbk-sidrops-9092-update-00"
submissionType="IETF" consensus="true" ipr="trust200902"
obsoletes="9092" >
<front>
@ -79,9 +81,9 @@
<t>
This document specifies how to augment the Routing Policy
Specification Language inetnum: class to refer specifically to
geofeed data comma-separated values (CSV) files and describes an
optional scheme that uses the Routing Public Key Infrastructure
to authenticate the geofeed data CSV files.
geofeed data files and describes an optional scheme that uses
the Routing Public Key Infrastructure to authenticate the
geofeed datafiles.
</t>
</abstract>
@ -105,8 +107,8 @@
This document specifies how to augment the Routing Policy
Specification Language (RPSL) <xref target="RFC2725"
format="default"/> inetnum: class to refer specifically to
geofeed data CSV files and how to prudently use them. In all
places inetnum: is used, inet6num: should also be assumed <xref
geofeed data files and how to prudently use them. In all places
inetnum: is used, inet6num: should also be assumed <xref
target="RFC4012" format="default"/>.
</t>
<t>
@ -119,6 +121,31 @@
An optional utterly awesome but slightly complex means for
authenticating geofeed data is also defined.
</t>
<t>
This document obsoletes <xref target="RFC9092"/>. Changes from
<xref target="RFC9092"/> include the following:
<ul spacing="compact">
<li>
It is no longer assumed that a geofeed file is a CSV, comma
separated value list.
</li>
<li>
RIPE has implemented the geofeed: attribute.
</li>
<li>
Allow, but discourage, an inetnum: to have both a geofeed
remarks: attribute and a geofeed: attribute.
</li>
<li>
Stress that authenticating geofeed data is optional.
</li>
<li>
IP Address Delegation extensions must not use "inherit".
</li>
</ul>
</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
@ -207,7 +234,7 @@
<sourcecode type="rpsl"> <![CDATA[
inetnum: 192.0.2.0/24 # example
remarks: Geofeed https://example.com/geofeed.csv
remarks: Geofeed https://example.com/geofeed
]]></sourcecode>
<t>
While we leave global agreement of RPSL modification to the
@ -219,7 +246,7 @@
</t>
<sourcecode type="rpsl"><![CDATA[
inetnum: 192.0.2.0/24 # example
geofeed: https://example.com/geofeed.csv
geofeed: https://example.com/geofeed
]]></sourcecode>
<t>
Registries <bcp14>MAY</bcp14>, for the interim, provide a mix of
@ -249,13 +276,18 @@
</t>
<t>
Any particular inetnum: object <bcp14>MUST</bcp14> have, at
Any particular inetnum: object <bcp14>SHOULD</bcp14> have, at
most, one geofeed reference, whether a remarks: or a proper
geofeed: attribute when it is implemented. If there is more
than one, the geofeed: attribute SHOULD be used.
</t>
<t>
If a geofeed CSV file describes multiple disjoint ranges of IP
For inetnum:s covering the same address range, or an inetnum:
with both remarks: and geofeed: attributes, a signed geofeed
file SHOULD be preferred over an unsigned file.
</t>
<t>
If a geofeed file describes multiple disjoint ranges of IP
address space, there are likely to be geofeed references from
multiple inetnum: objects. Files with geofeed references from
multiple inetnum: objects are not compatible with the signing
@ -364,8 +396,8 @@
identical to or a subset of A. "Address range" is used here
because inetnum: objects and RPKI certificates need not align on
Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/>
prefix boundaries, while those of the CSV lines in a geofeed
file do.
prefix boundaries, while those of the lines in a geofeed file
do.
</t>
<t>
As the signer specifies the covered RPKI resources relevant to
@ -627,9 +659,10 @@
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
IANA has registered object identifiers for one content
type in the "SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1)" registry as follows:
The IANA is requested to change the Description of the object
identifier for the content type in the "SMI Security for S/MIME
CMS Content Type (1.2.840.113549.1.9.16.1)" registry to the
following:
</t>
<table anchor="iana_table">
@ -643,8 +676,8 @@
<tbody>
<tr>
<td>47</td>
<td>id-ct-geofeedCSVwithCRLF</td>
<td>RFC 9092</td>
<td>id-ct-geofeedwithCRLF</td>
<td>this document</td>
</tr>
</tbody>
</table>
@ -671,6 +704,7 @@
<?rfc include="reference.RFC.6486.xml"?>
<?rfc include="reference.RFC.8805.xml"?>
<?rfc include="reference.RFC.8933.xml"?>
<?rfc include="reference.RFC.9092.xml"?>
</references>
<references title="Informative References">
@ -1159,10 +1193,9 @@ following detached CMS signature.</t>
<contact fullname="John Scudder"/>, <contact fullname="Kyle
Rose"/> (SECDIR), <contact fullname="Martin Duke"/>, <contact
fullname="Murray Kucherawy"/>, <contact fullname="Paul
Kyzivat"/> (GENART), <contact fullname="Rob Wilton"/>, and
<contact fullname="Roman Danyliw"/>. The authors also thank
<contact fullname="George Michaelson"/>, the awesome document
shepherd.
Kyzivat"/> (GENART), <contact fullname="Rob Wilton"/>, <contact
fullname="Roman Danyliw"/>, and <contact fullname="Ties de
Kock"/>.
</t>
</section>