[要約] RFC 8805は、自己公開IPジオロケーションフィードの形式を定義するもので、IPアドレスと地理的位置情報の関連付けを標準化します。このRFCの目的は、異なるシステム間でIPジオロケーション情報を共有するための一貫した形式を提供することです。
Independent Submission E. Kline
Request for Comments: 8805 Loon LLC
Category: Informational K. Duleba
ISSN: 2070-1721 Google
Z. Szamonek
S. Moser
Google Switzerland GmbH
W. Kumari
Google
August 2020
A Format for Self-Published IP Geolocation Feeds
自己発行IPジオロケーションフィードの形式
Abstract
概要
This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location.
このドキュメントは、ネットワークオペレーターがIPアドレスプレフィックスと簡略化された地理位置情報へのマッピングを公開できる形式を記録しています。これは、通称「地理位置情報フィード」と呼ばれています。利害関係者は、これらのフィードをポーリングおよび解析して、他のジオロケーションデータソースおよび手順を更新またはマージできます。このフォーマットでは、意図的に大まかなレベルの場所のみを指定できます。
Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds.
ある会議の場所から次の場所に移動するネットワークを運用している一部の技術組織は、小規模な地理位置情報フィードを実験的に公開しています。
This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated.
このドキュメントでは、現在展開されている形式について説明します。少なくとも1人の消費者（Google）がこれらのフィードを地理位置情報データパイプラインに組み込んでおり、かなりの数のISPがそれを使用して、プレフィックスの地理位置をどこに置くべきかを知らせています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは関係なく、RFCシリーズへの貢献です。 RFC Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8805.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8805で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよび文書の作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
1.1. Motivation
1.2. Requirements Notation
1.3. Assumptions about Publication
2. Self-Published IP Geolocation Feeds
2.1. Specification
2.1.1. Geolocation Feed Individual Entry Fields
2.1.1.1. IP Prefix
2.1.1.2. Alpha2code (Previously: 'country')
2.1.1.3. Region
2.1.1.4. City
2.1.1.5. Postal Code
2.1.2. Prefixes with No Geolocation Information
2.1.3. Additional Parsing Requirements
2.2. Examples
3. Consuming Self-Published IP Geolocation Feeds
3.1. Feed Integrity
3.2. Verification of Authority
3.3. Verification of Accuracy
3.4. Refreshing Feed Information
4. Privacy Considerations
5. Relation to Other Work
6. Security Considerations
7. Planned Future Work
8. Finding Self-Published IP Geolocation Feeds
8.1. Ad Hoc 'Well-Known' URIs
8.2. Other Mechanisms
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Sample Python Validation Code
Acknowledgements
Authors' Addresses
Providers of services over the Internet have grown to depend on best-effort geolocation information to improve the user experience. Locality information can aid in directing traffic to the nearest serving location, inferring likely native language, and providing additional context for services involving search queries.
インターネット上のサービスのプロバイダーは、ユーザーエクスペリエンスを向上させるために、ベストエフォートの位置情報に依存するようになりました。地域情報は、最寄りのサービス提供場所にトラフィックを誘導し、可能性のある母国語を推測し、検索クエリを含むサービスに追加のコンテキストを提供するのに役立ちます。
When an ISP, for example, changes the location where an IP prefix is deployed, services that make use of geolocation information may begin to suffer degraded performance. This can lead to customer complaints, possibly to the ISP directly. Dissemination of correct geolocation data is complicated by the lack of any centralized means to coordinate and communicate geolocation information to all interested consumers of the data.
たとえば、ISPがIPプレフィックスが展開されている場所を変更すると、地理位置情報を利用するサービスでパフォーマンスが低下する可能性があります。これは顧客の不満につながる可能性があり、ISPに直接つながる可能性があります。正しい地理位置情報データの普及は、地理位置情報を調整してデータのすべての関心のある消費者に伝達するための集中手段がないために複雑になっています。
This document records a format whereby a network operator (an ISP, an enterprise, or any organization that deems the geolocation of its IP prefixes to be of concern) can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures.
このドキュメントは、ネットワークオペレーター（ISP、企業、またはそのIPプレフィックスの地理位置情報に問題があると見なす組織）がIPアドレスプレフィックスのマッピングを、地理位置情報と呼ばれる簡略化された地理位置情報に公開できる形式を記録しています。フィード"。利害関係者は、これらのフィードをポーリングおよび解析して、他のジオロケーションデータソースおよび手順を更新またはマージできます。
This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated.
このドキュメントでは、現在展開されている形式について説明します。少なくとも1つの消費者（Google）がこれらのフィードを地理位置情報データパイプラインに組み込んでおり、かなりの数のISPがそれを使用して、プレフィックスの地理位置をどこに置くべきかを知らせています。
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
As this is an informational document about a data format and set of operational practices presently in use, requirements notation captures the design goals of the authors and implementors.
これは、現在使用されているデータ形式と一連の運用方法に関する情報ドキュメントであるため、要件の表記には、作成者と実装者の設計目標が含まれています。
This document describes both a format and a mechanism for publishing data, with the assumption that the network operator to whom operational responsibility has been delegated for any published data wishes it to be public. Any privacy risk is bounded by the format, and feed publishers MAY omit prefixes or any location field associated with a given prefix to further protect privacy (see Section 2.1 for details about which fields exactly may be omitted). Feed publishers assume the responsibility of determining which data should be made public.
このドキュメントでは、データを公開するための形式とメカニズムの両方について説明します。公開されたデータの運用責任を委任されているネットワークオペレーターは、データの公開を望んでいると想定しています。プライバシーリスクは形式によって制限されます。フィードの発行元は、プレフィックスまたは特定のプレフィックスに関連付けられた場所フィールドを省略して、プライバシーをさらに保護できます（どのフィールドを正確に省略できるかについては、セクション2.1を参照してください）。フィード発行者は、どのデータを公開するかを決定する責任を負います。
This document does not incorporate a mechanism to communicate acceptable use policies for self-published data. Publication itself is inferred as a desire by the publisher for the data to be usefully consumed, similar to the publication of information like host names, cryptographic keys, and Sender Policy Framework (SPF) records [RFC7208] in the DNS.
このドキュメントには、自己発行データの利用規定を伝達するメカニズムは組み込まれていません。 DNS内のホスト名、暗号化キー、Sender Policy Framework（SPF）レコード[RFC7208]などの情報の公開と同様に、公開自体は、データが有効に消費されることをパブリッシャーが望んでいると推測されます。
The format described here was developed to address the need of network operators to rapidly and usefully share geolocation information changes. Originally, there arose a specific case where regional operators found it desirable to publish location changes rather than wait for geolocation algorithms to "learn" about them. Later, technical conferences that frequently use the same network prefixes advertised from different conference locations experimented by publishing geolocation feeds updated in advance of network location changes in order to better serve conference attendees.
ここで説明するフォーマットは、地理位置情報の変更を迅速かつ便利に共有するためのネットワークオペレーターのニーズに対応するために開発されました。もともと、地理位置情報アルゴリズムがそれらについて「学習」するのを待つのではなく、地域の事業者が位置変更を公開することが望ましいと判断した特定のケースが発生しました。その後、会議の出席者により適切にサービスを提供するために、ネットワークロケーションの変更に先立って更新される地理位置情報フィードを公開することにより、異なる会議ロケーションからアドバタイズされる同じネットワークプレフィックスを頻繁に使用する技術会議。
At its simplest, the mechanism consists of a network operator publishing a file (the "geolocation feed") that contains several text entries, one per line. Each entry is keyed by a unique (within the feed) IP prefix (or single IP address) followed by a sequence of network locality attributes to be ascribed to the given prefix.
最も単純なメカニズムは、ネットワークオペレーターが1行に1つずつ、複数のテキストエントリを含むファイル（「地理位置情報フィード」）を公開することです。各エントリは、一意の（フィード内の）IPプレフィックス（または単一のIPアドレス）がキーとなり、その後に、特定のプレフィックスに帰する一連のネットワークローカリティ属性が続きます。
For operational simplicity, every feed should contain data about all IP addresses the provider wants to publish. Alternatives, like publishing only entries for IP addresses whose geolocation data has changed or differ from current observed geolocation behavior "at large", are likely to be too operationally complex.
操作を簡単にするために、すべてのフィードには、プロバイダーが公開したいすべてのIPアドレスに関するデータを含める必要があります。ジオロケーションデータが変更されているか、または現在の観測されたジオロケーション動作と「全体」で異なるIPアドレスのエントリのみを公開するなどの代替手段は、操作が複雑すぎる可能性があります。
Feeds MUST use UTF-8 [RFC3629] character encoding. Lines are delimited by a line break (CRLF) (as specified in [RFC4180]), and blank lines are ignored. Text from a '#' character to the end of the current line is treated as a comment only and is similarly ignored (note that this does not strictly follow [RFC4180], which has no support for comments).
フィードはUTF-8 [RFC3629]文字エンコードを使用する必要があります。行は改行（CRLF）（[RFC4180]で指定）で区切られ、空白行は無視されます。 '＃'文字から現在の行の終わりまでのテキストはコメントとしてのみ扱われ、同様に無視されます（コメントをサポートしていない[RFC4180]に厳密に従っていないことに注意してください）。
Feed lines that are not comments MUST be formatted as comma-separated values (CSV), as described in [RFC4180]. Each feed entry is a text line of the form:
コメントではないフィード行は、[RFC4180]で説明されているように、コンマ区切り値（CSV）としてフォーマットする必要があります。各フィードエントリは、次の形式のテキスト行です。
ip_prefix,alpha2code,region,city,postal_code
ip_prefix、alpha2code、region、city、postal_code
The IP prefix field is REQUIRED, all others are OPTIONAL (can be empty), though the requisite minimum number of commas SHOULD be present.
IPプレフィックスフィールドは必須ですが、その他はすべて省略可能（空にすることができます）ですが、必要な最小数のカンマが存在する必要があります（SHOULD）。
REQUIRED: Each IP prefix field MUST be either a single IP address or an IP prefix in Classless Inter-Domain Routing (CIDR) notation in conformance with Section 3.1 of [RFC4632] for IPv4 or Section 2.3 of [RFC4291] for IPv6.
必須：各IPプレフィックスフィールドは、IPv4の場合は[RFC4632]のセクション3.1、IPv6の場合は[RFC4291]のセクション2.3に準拠したクラスレスドメイン間ルーティング（CIDR）表記の単一のIPアドレスまたはIPプレフィックスのいずれかである必要があります。
Examples include "192.0.2.1" and "192.0.2.0/24" for IPv4 and "2001:db8::1" and "2001:db8::/32" for IPv6.
たとえば、IPv4の場合は「192.0.2.1」と「192.0.2.0/24」、IPv6の場合は「2001：db8 :: 1」と「2001：db8 :: / 32」などです。
OPTIONAL: The alpha2code field, if non-empty, MUST be a 2-letter ISO country code conforming to ISO 3166-1 alpha 2 [ISO.3166.1alpha2]. Parsers SHOULD treat this field case-insensitively.
オプション：alpha2codeフィールドは、空でない場合、ISO 3166-1 alpha 2 [ISO.3166.1alpha2]に準拠する2文字のISO国コードである必要があります。パーサーは、このフィールドを大文字と小文字を区別せずに扱う必要があります（SHOULD）。
Earlier versions of this document called this field "country", and it may still be referred to as such in existing tools/interfaces.
このドキュメントの以前のバージョンでは、このフィールドを「国」と呼んでいましたが、既存のツール/インターフェースでは、そのように呼ばれる場合があります。
Parsers MAY additionally support other 2-letter codes outside the ISO 3166-1 alpha 2 codes, such as the 2-letter codes from the "Exceptionally reserved codes" [ISO-GLOSSARY] set.
パーサーは、「例外的に予約されたコード」[ISO用語集]セットの2文字コードなど、ISO 3166-1 alpha 2コード以外の他の2文字コードをさらにサポートする場合があります。
Examples include "US" for the United States, "JP" for Japan, and "PL" for Poland.
たとえば、米国は「US」、日本は「JP」、ポーランドは「PL」などです。
OPTIONAL: The region field, if non-empty, MUST be an ISO region code conforming to ISO 3166-2 [ISO.3166.2]. Parsers SHOULD treat this field case-insensitively.
オプション：地域フィールドは、空でない場合、ISO 3166-2 [ISO.3166.2]に準拠するISO地域コードでなければなりません。パーサーは、このフィールドを大文字と小文字を区別せずに扱う必要があります（SHOULD）。
Examples include "ID-RI" for the Riau province of Indonesia and "NG-RI" for the Rivers province in Nigeria.
例としては、インドネシアのリアウ州の「ID-RI」、ナイジェリアのリバーズ州の「NG-RI」などがあります。
OPTIONAL: The city field, if non-empty, SHOULD be free UTF-8 text, excluding the comma (',') character.
オプション：都市フィールドは、空でない場合、コンマ（ '、'）文字を除いて、自由なUTF-8テキストにする必要があります（SHOULD）。
Examples include "Dublin", "New York", and "Sao Paulo" (specifically "S" followed by 0xc3, 0xa3, and "o Paulo").
たとえば、「ダブリン」、「ニューヨーク」、「サンパウロ」（具体的には、「S」の後に0xc3、0xa3、「oパウロ」）が含まれます。
OPTIONAL, DEPRECATED: The postal code field, if non-empty, SHOULD be free UTF-8 text, excluding the comma (',') character. The use of this field is deprecated; consumers of feeds should be able to parse feeds containing these fields, but new feeds SHOULD NOT include this field due to the granularity of this information. See Section 4 for additional discussion.
オプション、非推奨：郵便番号フィールドは、空でない場合、コンマ（ '、'）文字を除いた自由なUTF-8テキストにする必要があります（SHOULD）。このフィールドの使用は非推奨です。フィードの利用者はこれらのフィールドを含むフィードを解析できなければなりませんが、この情報の粒度のため、新しいフィードにはこのフィールドを含めないでください。詳細については、セクション4を参照してください。
Examples include "106-6126" (in Minato ward, Tokyo, Japan).
たとえば、「106-6126」（東京都港区）などです。
Feed publishers may indicate that some IP prefixes should not have any associated geolocation information. It may be that some prefixes under their administrative control are reserved, not yet allocated or deployed, or in the process of being redeployed elsewhere and existing geolocation information can, from the perspective of the publisher, safely be discarded.
フィードパブリッシャーは、一部のIPプレフィックスに地理位置情報が関連付けられていないことを示す場合があります。管理上の制御下にある一部のプレフィックスが予約されているか、まだ割り当てられていないか、デプロイされていないか、既存のジオロケーション情報がパブリッシャーの観点から安全に破棄されている可能性があります。
This special case can be indicated by explicitly leaving blank all fields that specify any degree of geolocation information. For example:
この特殊なケースは、任意の程度の地理位置情報を指定するすべてのフィールドを明示的に空白のままにすることで示すことができます。例えば：
192.0.2.0/24,,,, 2001:db8:1::/48,,,, 2001:db8:2::/48,,,,
192.0.2.0/24 ,,,, 2001：db8：1 :: / 48 ,,,, 2001：db8：2 :: / 48 ,,,,
Historically, the user-assigned alpha2code identifier of "ZZ" has been used for this same purpose. This is not necessarily preferred, and no specific interpretation of any of the other user-assigned alpha2code codes is currently defined.
これまで、ユーザーが割り当てたalpha2code識別子「ZZ」は、これと同じ目的で使用されてきました。これは必ずしも好ましいとは限らず、ユーザーが割り当てた他のalpha2codeコードの特定の解釈は現在定義されていません。
Feed entries that do not have an IP address or prefix field or have an IP address or prefix field that fails to parse correctly MUST be discarded.
IPアドレスまたはプレフィックスフィールドがないフィードエントリ、または正しく解析できないIPアドレスまたはプレフィックスフィールドがあるフィードエントリは破棄する必要があります。
While publishers SHOULD follow [RFC5952] for IPv6 prefix fields, consumers MUST nevertheless accept all valid string representations.
パブリッシャはIPv6プレフィックスフィールドの[RFC5952]に従う必要がありますが、それでもコンシューマはすべての有効な文字列表現を受け入れる必要があります。
Duplicate IP address or prefix entries MUST be considered an error, and consumer implementations SHOULD log the repeated entries for further administrative review. Publishers SHOULD take measures to ensure there is one and only one entry per IP address and prefix.
重複するIPアドレスまたはプレフィックスエントリはエラーと見なす必要があります。コンシューマ実装は、さらなる管理レビューのために繰り返されたエントリをログに記録する必要があります（SHOULD）。パブリッシャは、IPアドレスとプレフィックスごとに1つだけのエントリが存在するように対策を講じる必要があります。
Multiple entries that constitute nested prefixes are permitted. Consumers SHOULD consider the entry with the longest matching prefix (i.e., the "most specific") to be the best matching entry for a given IP address.
ネストされたプレフィックスを構成する複数のエントリが許可されます。コンシューマは、最も長い一致するプレフィックス（つまり、「最も具体的な」）を持つエントリを、特定のIPアドレスに最も一致するエントリと見なす必要があります（SHOULD）。
Feed entries with non-empty optional fields that fail to parse, either in part or in full, SHOULD be discarded. It is RECOMMENDED that they also be logged for further administrative review.
部分的または全体的に解析に失敗した空ではないオプションフィールドを持つフィードエントリは、破棄する必要があります。また、管理上のレビューのためにログに記録することをお勧めします。
For compatibility with future additional fields, a parser MUST ignore any fields beyond those it expects. The data from fields that are expected and that parse successfully MUST still be considered valid. Per Section 7, no extensions to this format are in use nor are any anticipated.
将来の追加フィールドとの互換性のために、パーサーはそれが期待するものを超えるフィールドを無視しなければなりません（MUST）。予期され、正常に解析されるフィールドからのデータは、引き続き有効と見なされなければなりません（MUST）。セクション7に従って、このフォーマットの拡張機能は使用されておらず、予期されていません。
Example entries using different IP address formats and describing locations at alpha2code ("country code"), region, and city granularity level, respectively:
さまざまなIPアドレス形式を使用し、それぞれalpha2code（「国コード」）、地域、および都市の粒度レベルで場所を説明するエントリの例：
192.0.2.0/25,US,US-AL,, 192.0.2.5,US,US-AL,Alabaster, 192.0.2.128/25,PL,PL-MZ,, 2001:db8::/32,PL,,, 2001:db8:cafe::/48,PL,PL-MZ,,
192.0.2.0/25,US,US-AL ,, 192.0.2.5、US、US-AL、Alabaster、192.0.2.128/25,PL,PL-MZ ,, 2001：db8 :: / 32、PL ,,, 2001：db8：cafe :: / 48、PL、PL-MZ ,,
The IETF network publishes geolocation information for the meeting prefixes, and generally just comment out the last meeting information and append the new meeting information. The [GEO_IETF], at the time of this writing, contains:
IETFネットワークは、会議のプレフィックスの位置情報を公開し、通常は最後の会議情報をコメント化して、新しい会議情報を追加します。この記事の執筆時点での[GEO_IETF]には、次のものが含まれています。
# IETF106 (Singapore) - November 2019 - Singapore, SG 130.129.0.0/16,SG,SG-01,Singapore, 2001:df8::/32,SG,SG-01,Singapore, 31.133.128.0/18,SG,SG-01,Singapore, 31.130.224.0/20,SG,SG-01,Singapore, 2001:67c:1230::/46,SG,SG-01,Singapore, 2001:67c:370::/48,SG,SG-01,Singapore,
＃IETF106（シンガポール）-2019年11月-シンガポール、SG 130.129.0.0/16、SG、SG-01、シンガポール、2001：df8 :: / 32、SG、SG-01、シンガポール、31.133.128.0 / 18、SG、 SG-01、シンガポール、31.130.224.0 / 20、SG、SG-01、シンガポール、2001：67c：1230 :: / 46、SG、SG-01、シンガポール、2001：67c：370 :: / 48、SG、 SG-01、シンガポール、
Experimentally, RIPE has published geolocation information for their conference network prefixes, which change location in accordance with each new event. [GEO_RIPE_NCC], at the time of writing, contains:
実験的に、RIPEは会議ネットワークプレフィックスの地理位置情報を公開しており、新しいイベントごとに位置を変更します。 [GEO_RIPE_NCC]は、執筆時点では次の内容を含んでいます：
193.0.24.0/21,NL,NL-ZH,Rotterdam, 2001:67c:64::/48,NL,NL-ZH,Rotterdam,
193.0.24.0/21,NL,NL-ZH、ロッテルダム、2001：67c：64 :: / 48、NL、NL-ZH、ロッテルダム、
Similarly, ICANN has published geolocation information for their portable conference network prefixes. [GEO_ICANN], at the time of writing, contains:
同様に、ICANNはポータブル会議ネットワークプレフィックスの地理位置情報を公開しています。 [GEO_ICANN]の執筆時点では、次のものが含まれています。
199.91.192.0/21,MA,MA-07,Marrakech
2620:f:8000::/48,MA,MA-07,Marrakech
A longer example is the [GEO_Google] Google Corp Geofeed, which lists the geolocation information for Google corporate offices.
より長い例は、[GEO_Google] Google Corp Geofeedであり、Google本社の地理位置情報が一覧表示されます。
At the time of writing, Google processes approximately 400 feeds comprising more than 750,000 IPv4 and IPv6 prefixes.
執筆時点では、Googleは750,000を超えるIPv4およびIPv6プレフィックスを含む約400のフィードを処理しています。
Consumers MAY treat published feed data as a hint only and MAY choose to prefer other sources of geolocation information for any given IP prefix. Regardless of a consumer's stance with respect to a given published feed, there are some points of note for sensibly and effectively consuming published feeds.
消費者は公開されたフィードデータをヒントとしてのみ扱うことができ（MAY）、特定のIPプレフィックスに対して地理位置情報の他のソースを優先することを選択できます（MAY）。特定の公開されたフィードに対する消費者のスタンスに関係なく、公開されたフィードを慎重かつ効果的に消費するための注意点がいくつかあります。
The integrity of published information SHOULD be protected by securing the means of publication, for example, by using HTTP over TLS [RFC2818]. Whenever possible, consumers SHOULD prefer retrieving geolocation feeds in a manner that guarantees integrity of the feed.
公開された情報の完全性は、例えばHTTP over TLS [RFC2818]を使用するなど、公開手段を保護することによって保護されるべきです（SHOULD）。可能な限り、消費者はフィードの完全性を保証する方法で地理位置情報フィードを取得することを好むべきです。
Consumers of self-published IP geolocation feeds SHOULD perform some form of verification that the publisher is in fact authoritative for the addresses in the feed. The actual means of verification is likely dependent upon the way in which the feed is discovered. Ad hoc shared URIs, for example, will likely require an ad hoc verification process. Future automated means of feed discovery SHOULD have an accompanying automated means of verification.
自己公開IPジオロケーションフィードのコンシューマーは、パブリッシャーが実際にフィード内のアドレスに対して信頼できることを確認する必要があります。実際の検証方法は、フィードが発見された方法に依存している可能性があります。たとえば、アドホックな共有URIには、アドホックな検証プロセスが必要になる可能性があります。今後のフィード検出の自動化手段には、自動化された検証手段が付随する必要があります。
A consumer should only trust geolocation information for IP addresses or prefixes for which the publisher has been verified as administratively authoritative. All other geolocation feed entries should be ignored and logged for further administrative review.
コンシューマは、パブリッシャが管理上の権限があると確認されているIPアドレスまたはプレフィックスの位置情報のみを信頼する必要があります。他のすべての地理位置情報フィードエントリは無視して、今後の管理レビューのためにログに記録する必要があります。
Errors and inaccuracies may occur at many levels, and publication and consumption of geolocation data are no exceptions. To the extent practical, consumers SHOULD take steps to verify the accuracy of published locality. Verification methodology, resolution of discrepancies, and preference for alternative sources of data are left to the discretion of the feed consumer.
エラーや不正確さは多くのレベルで発生する可能性があり、地理位置情報データの公開と消費も例外ではありません。実用的な範囲で、消費者は公開された地域の正確さを検証するための措置をとるべきです。検証方法、不一致の解決、および代替データソースの選択は、フィードの利用者の裁量に任されています。
Consumers SHOULD decide on discrepancy thresholds and SHOULD flag, for administrative review, feed entries that exceed set thresholds.
消費者は、矛盾のしきい値を決定し、管理レビューのために、設定されたしきい値を超えるフィードエントリにフラグを設定する必要があります（SHOULD）。
As a publisher can change geolocation data at any time and without notification, consumers SHOULD implement mechanisms to periodically refresh local copies of feed data. In the absence of any other refresh timing information, it is recommended that consumers SHOULD refresh feeds no less often than weekly and no more often than is likely to cause issues to the publisher.
パブリッシャーはいつでも通知なしに地理位置情報データを変更できるため、消費者はフィードデータのローカルコピーを定期的に更新するメカニズムを実装する必要があります（SHOULD）。他の更新タイミング情報がない場合、コンシューマはフィードを週に1回以上、パブリッシャに問題を引き起こす可能性が高い頻度で更新する必要があります。
For feeds available via HTTPS (or HTTP), the publisher MAY communicate refresh timing information by means of the standard HTTP expiration model ([RFC7234]). Specifically, publishers can include either an Expires header (Section 5.3 of [RFC7234]) or a Cache-Control header (Section 5.2 of [RFC7234]) specifying the max-age. Where practical, consumers SHOULD refresh feed information before the expiry time is reached.
HTTPS（またはHTTP）を介して利用できるフィードの場合、パブリッシャーは標準のHTTP有効期限モデル（[RFC7234]）を使用して更新タイミング情報を通信できます（MAY）。具体的には、パブリッシャーは、max-ageを指定するExpiresヘッダー（[RFC7234]のセクション5.3）またはCache-Controlヘッダー（[RFC7234]のセクション5.2）を含めることができます。実際には、消費者は有効期限に達する前にフィード情報を更新する必要があります。
Publishers of geolocation feeds are advised to have fully considered any and all privacy implications of the disclosure of such information for the users of the described networks prior to publication. A thorough comprehension of the security considerations (Section 13 of [RFC6772]) of a chosen geolocation policy is highly recommended, including an understanding of some of the limitations of information obscurity (Section 13.5 of [RFC6772]) (see also [RFC6772]).
地理位置情報フィードの発行者は、公開前に、記載されたネットワークのユーザーに対するそのような情報の開示のプライバシーへの影響を十分に検討することをお勧めします。選択した地理位置情報ポリシーのセキュリティに関する考慮事項（[RFC6772]のセクション13）を完全に理解することを強くお勧めします。これには、情報の不明瞭さの制限（[RFC6772]のセクション13.5）の理解も含まれます（[RFC6772]も参照） 。
As noted in Section 2.1, each location field in an entry is optional, in order to support expressing only the level of specificity that the publisher has deemed acceptable. There is no requirement that the level of specificity be consistent across all entries within a feed. In particular, the Postal Code field (Section 2.1.1.5) can provide very specific geolocation, sometimes within a building. Such specific Postal Code values MUST NOT be published in geofeeds without the express consent of the parties being located.
セクション2.1で述べたように、エントリの各場所フィールドはオプションであり、パブリッシャーが許容できると見なした具体性のレベルのみを表現できるようにします。フィード内のすべてのエントリで特定性のレベルが一貫している必要はありません。特に、郵便番号フィールド（2.1.1.5節）は、建物内など、非常に具体的な地理位置情報を提供できます。このような特定の郵便番号の値は、特定された当事者の明示的な同意なしにジオフィードで公開してはなりません。
Operators who publish geolocation information are strongly encouraged to inform affected users/customers of this fact and of the potential privacy-related consequences and trade-offs.
地理位置情報を公開する事業者は、影響を受けるユーザー/顧客に、この事実と、プライバシーに関連する潜在的な影響およびトレードオフについて通知することを強くお勧めします。
While not originally done in conjunction with the GEOPRIV Working Group [GEOPRIV], Richard Barnes observed that this work is nevertheless consistent with that which the group has defined, both for address format and for privacy. The data elements in geolocation feeds are equivalent to the following XML structure ([RFC5139] [W3C.REC-xml-20081126]):
最初はGEOPRIVワーキンググループ[GEOPRIV]と連携して行われていませんでしたが、それでも、この作業はアドレス形式とプライバシーの両方についてグループが定義したものと一貫していると観察しました。地理位置情報フィードのデータ要素は、次のXML構造（[RFC5139] [W3C.REC-xml-20081126]）と同等です。
<civicAddress>
<country>country</country>
<A1>region</A1>
<A2>city</A2>
<PC>postal_code</PC>
</civicAddress>
Providing geolocation information to this granularity is equivalent to the following privacy policy (the definition of the 'building' Section 6.5.1 of [RFC6772] level of disclosure):
この粒度でジオロケーション情報を提供することは、次のプライバシーポリシーと同等です（[RFC6772]レベルの開示の「ビルディング」セクション6.5.1の定義の開示）：
<ruleset>
<rule>
<conditions/>
<actions/>
<transformations>
<provide-location profile="civic-transformation">
<provide-civic>building</provide-civic>
</provide-location>
</transformations>
</rule>
</ruleset>
As there is no true security in the obscurity of the location of any given IP address, self-publication of this data fundamentally opens no new attack vectors. For publishers, self-published data may increase the ease with which such location data might be exploited (it can, for example, make easy the discovery of prefixes populated with customers as distinct from prefixes not generally in use).
与えられたIPアドレスの場所のあいまいさには真のセキュリティがないため、このデータの自己公開は基本的に新しい攻撃ベクトルを開きません。パブリッシャーの場合、自己公開データにより、そのような位置データが悪用される可能性が高まる場合があります（たとえば、一般に使用されていないプレフィックスとは異なり、顧客が入力されたプレフィックスを簡単に発見できるようになります）。
For consumers, feed retrieval processes may receive input from potentially hostile sources (e.g., in the event of hijacked traffic). As such, proper input validation and defense measures MUST be taken (see the discussion in Section 3.1).
消費者にとって、フィード取得プロセスは、潜在的に敵意のあるソースからの入力を受け取る可能性があります（ハイジャックされたトラフィックが発生した場合など）。そのため、適切な入力検証と防御対策を講じる必要があります（セクション3.1の説明を参照）。
Similarly, consumers who do not perform sufficient verification of published data bear the same risks as from other forms of geolocation configuration errors (see the discussion in Sections 3.2 and 3.3).
同様に、公開されたデータの十分な検証を行わない消費者は、他の形式の地理位置情報設定エラーと同じリスクを負います（セクション3.2および3.3の説明を参照）。
Validation of a feed's contents includes verifying that the publisher is authoritative for the IP prefixes included in the feed. Failure to verify IP prefix authority would, for example, allow ISP Bob to make geolocation statements about IP space held by ISP Alice. At this time, only out-of-band verification methods are implemented (i.e., an ISP's feed may be verified against publicly available IP allocation data).
フィードのコンテンツの検証には、パブリッシャーがフィードに含まれるIPプレフィックスに対して権限があることの確認が含まれます。たとえば、IPプレフィックス権限の確認に失敗すると、ISPボブはISPアリスが保持するIPスペースについて地理位置情報ステートメントを作成できます。現時点では、アウトオブバンド検証方法のみが実装されています（つまり、ISPのフィードは、公開されているIP割り当てデータに対して検証される場合があります）。
In order to more flexibly support future extensions, use of a more expressive feed format has been suggested. Use of JavaScript Object Notation (JSON) [RFC8259], specifically, has been discussed. However, at the time of writing, no such specification nor implementation exists. Nevertheless, work on extensions is deferred until a more suitable format has been selected.
将来の拡張をより柔軟にサポートするために、より表現力豊かなフィード形式の使用が提案されています。具体的には、JavaScript Object Notation（JSON）[RFC8259]の使用について説明しました。しかし、執筆時点では、そのような仕様も実装も存在しません。それにもかかわらず、より適切なフォーマットが選択されるまで、拡張機能の作業は延期されます。
The authors are planning on writing a document describing such a new format. This document describes a currently deployed and used format. Given the extremely limited extensibility of the present format no extensions to it are anticipated. Extensibility requirements are instead expected to be integral to the development of a new format.
著者はそのような新しいフォーマットを説明するドキュメントを書くことを計画しています。このドキュメントでは、現在展開され使用されている形式について説明します。現在のフォーマットの拡張性は非常に限られているため、拡張することはできません。代わりに、拡張性の要件は、新しいフォーマットの開発に不可欠であると予想されます。
The issue of finding, and later verifying, geolocation feeds is not formally specified in this document. At this time, only ad hoc feed discovery and verification has a modicum of established practice (see below); discussion of other mechanisms has been removed for clarity.
このドキュメントでは、地理位置情報フィードを見つけて後で確認する問題は正式には指定されていません。現時点では、アドホックフィードの発見と検証だけが、確立された慣例のほんの一部です（下記を参照）。他のメカニズムの説明は、明確にするために削除されています。
To date, geolocation feeds have been shared informally in the form of HTTPS URIs exchanged in email threads. Three example URIs ([GEO_IETF], [GEO_RIPE_NCC], and [GEO_ICANN]) describe networks that change locations periodically, the operators and operational practices of which are well known within their respective technical communities.
今日まで、地理位置情報フィードは、メールスレッドで交換されるHTTPS URIの形式で非公式に共有されてきました。 3つのURIの例（[GEO_IETF]、[GEO_RIPE_NCC]、および[GEO_ICANN]）は、ロケーションを定期的に変更するネットワークを記述します。そのオペレーターと運用慣行は、それぞれの技術コミュニティーでよく知られています。
The contents of the feeds are verified by a similarly ad hoc process, including:
フィードのコンテンツは、以下を含む同様のアドホックプロセスによって検証されます。
* personal knowledge of the parties involved in the exchange and
* 交換に関与する当事者の個人的な知識
* comparison of feed-advertised prefixes with the BGP-advertised prefixes of Autonomous System Numbers known to be operated by the publishers.
* フィードアドバタイズされたプレフィックスと、パブリッシャーが運用していることが知られている自律システム番号のBGPアドバタイズされたプレフィックスとの比較。
Ad hoc mechanisms, while useful for early experimentation by producers and consumers, are unlikely to be adequate for long-term, widespread use by multiple parties. Future versions of any such self-published geolocation feed mechanism SHOULD address scalability concerns by defining a means for automated discovery and verification of operational authority of advertised prefixes.
アドホックメカニズムは、プロデューサーとコンシューマーによる初期の実験には役立ちますが、複数の関係者による長期にわたる広範囲な使用には十分とは言えません。そのような自己発行の地理位置情報フィードメカニズムの将来のバージョンでは、アドバタイズされたプレフィックスの操作権限の自動検出および検証の手段を定義することにより、スケーラビリティの問題に対処する必要があります。
Previous versions of this document referenced use of the WHOIS service [RFC3912] operated by Regional Internet Registries (RIRs), as well as possible DNS-based schemes to discover and validate geofeeds. To the authors' knowledge, support for such mechanisms has never been implemented, and this speculative text has been removed to avoid ambiguity.
このドキュメントの以前のバージョンでは、地域インターネットレジストリ（RIR）が運営するWHOISサービス[RFC3912]の使用と、ジオフィードを検出および検証するためのDNSベースのスキームを参照していました。著者の知る限りでは、そのようなメカニズムのサポートは実装されておらず、あいまいさを避けるためにこの推測的なテキストは削除されています。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[ISO.3166.1alpha2] ISO, "ISO 3166-1 decoding table", <http://www.iso.org/iso/home/standards/country_codes/iso-3166-1_decoding_table.htm>.
[ISO.3166.1alpha2] ISO、「ISO 3166-1デコードテーブル」、<http://www.iso.org/iso/home/standards/country_codes/iso-3166-1_decoding_table.htm>。
[ISO.3166.2] ISO, "ISO 3166-2:2007", <http://www.iso.org/iso/home/standards/ country_codes.htm#2012_iso3166-2>.
[ISO.3166.2] ISO、「ISO 3166-2：2007」、<http://www.iso.org/iso/home/standards/ country_codes.htm＃2012_iso3166-2>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-Separated Values (CSV) Files", RFC 4180, DOI 10.17487/RFC4180, October 2005, <https://www.rfc-editor.org/info/rfc4180>.
[RFC4180] Shafranovich、Y。、「カンマ区切り値（CSV）ファイルの一般的な形式とMIMEタイプ」、RFC 4180、DOI 10.17487 / RFC4180、2005年10月、<https://www.rfc-editor.org/info / rfc4180>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https://www.rfc-editor.org/info/rfc4291>。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、DOI 10.17487 / RFC4632、2006年8月、<https：// www.rfc-editor.org/info/rfc4632>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、DOI 10.17487 / RFC5952、August 2010、<https://www.rfc-editor.org/info/rfc5952> 。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<https://www.rfc-editor.org/info/rfc7234>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-20081126] Bray、T.、Paoli、J.、Sperberg-McQueen、M.、Maler、E。、およびF. Yergeau、「Extensible Markup Language（XML）1.0（Fifth Edition）」、 World Wide Web Consortium Recommendation REC-xml-20081126、2008年11月、<http://www.w3.org/TR/2008/REC-xml-20081126>。
[GEOPRIV] IETF, "Geographic Location/Privacy (geopriv)", <http://datatracker.ietf.org/wg/geopriv/>.
[GEOPRIV] IETF、「地理的な場所/プライバシー（geopriv）」、<http://datatracker.ietf.org/wg/geopriv/>。
[GEO_Google] Google, LLC, "Google Corp Geofeed", <https://www.gstatic.com/geofeed/corp_external>.
[GEO_Google] Google、LLC、「Google Corp Geofeed」、<https://www.gstatic.com/geofeed/corp_external>。
[GEO_ICANN] ICANN, "ICANN Meeting Geolocation Data", <https://meeting-services.icann.org/geo/google.csv>.
[GEO_ICANN] ICANN、「ICANN Meeting Geolocation Data」、<https://meeting-services.icann.org/geo/google.csv>。
[GEO_IETF] Kumari, W., "IETF Meeting Network Geolocation Data", <https://noc.ietf.org/geo/google.csv>.
[GEO_IETF] Kumari、W。、「IETF Meeting Network Geolocation Data」、<https://noc.ietf.org/geo/google.csv>。
[GEO_RIPE_NCC] Schepers, M., "RIPE NCC Meeting Geolocation Data", <https://meetings.ripe.net/geo/google.csv>.
[GEO_RIPE_NCC] Schepers、M。、「RIPE NCC Meeting Geolocation Data」、<https://meetings.ripe.net/geo/google.csv>。
[IPADDR_PY] Shields, M. and P. Moody, "Google's Python IP address manipulation library", <http://code.google.com/p/ipaddr-py/>.
[IPADDR_PY] Shields、M。およびP. Moody、「GoogleのPython IPアドレス操作ライブラリ」、<http://code.google.com/p/ipaddr-py/>。
[ISO-GLOSSARY] ISO, "Glossary for ISO 3166", <https://www.iso.org/glossary-for-iso-3166.html>.
[ISO用語集] ISO、「ISO 3166の用語集」、<https://www.iso.org/glossary-for-iso-3166.html>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https://www.rfc-editor.org/info/rfc2818>。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-editor.org/info/rfc3912>.
[RFC3912] Daigle、L。、「WHOIS Protocol Specification」、RFC 3912、DOI 10.17487 / RFC3912、2004年9月、<https://www.rfc-editor.org/info/rfc3912>。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139, February 2008, <https://www.rfc-editor.org/info/rfc5139>.
[RFC5139] Thomson、M。、およびJ. Winterbottom、「Presence Information Data Format Location Object（PIDF-LO）の改訂されたCivicロケーションフォーマット」、RFC 5139、DOI 10.17487 / RFC5139、2008年2月、<https：//www.rfc -editor.org/info/rfc5139>。
[RFC6772] Schulzrinne, H., Ed., Tschofenig, H., Ed., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", RFC 6772, DOI 10.17487/RFC6772, January 2013, <https://www.rfc-editor.org/info/rfc6772>.
[RFC6772] Schulzrinne、H.、Ed。、Tschofenig、H.、Ed。、Cuellar、J.、Polk、J.、Morris、J.、and M. Thomson、 "Geolocation Policy：A Document Format for Express Privacy Preferences for Location Information」、RFC 6772、DOI 10.17487 / RFC6772、2013年1月、<https://www.rfc-editor.org/info/rfc6772>。
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[RFC7208]キッターマン、S。、「電子メールでのドメインの使用を承認するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 7208、DOI 10.17487 / RFC7208、2014年4月、<https://www.rfc-editor.org / info / rfc7208>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
Included here is a simple format validator in Python for self-published ipgeo feeds. This tool reads CSV data in the self-published ipgeo feed format from the standard input and performs basic validation. It is intended for use by feed publishers before launching a feed. Note that this validator does not verify the uniqueness of every IP prefix entry within the feed as a whole but only verifies the syntax of each single line from within the feed. A complete validator MUST also ensure IP prefix uniqueness.
ここには、自己発行のipgeoフィード用のPythonのシンプルなフォーマットバリデーターが含まれています。このツールは、標準入力から自社発行のipgeoフィード形式のCSVデータを読み取り、基本的な検証を実行します。フィードを起動する前にフィード発行者が使用することを目的としています。このバリデーターは、全体としてフィード内のすべてのIPプレフィックスエントリの一意性を検証するのではなく、フィード内の各1行の構文のみを検証することに注意してください。完全なバリデーターは、IPプレフィックスの一意性も保証する必要があります。
The main source file "ipgeo_feed_validator.py" follows. It requires use of the open source ipaddr Python library for IP address and CIDR parsing and validation [IPADDR_PY].
メインのソースファイル「ipgeo_feed_validator.py」は次のとおりです。 IPアドレスとCIDRの解析と検証[IPADDR_PY]には、オープンソースのipaddr Pythonライブラリを使用する必要があります。
<CODE BEGINS> #!/usr/bin/python # # Copyright (c) 2012 IETF Trust and the persons identified as # authors of the code. All rights reserved. Redistribution and use # in source and binary forms, with or without modification, is # permitted pursuant to, and subject to the license terms contained # in, the Simplified BSD License set forth in Section 4.c of the # IETF Trust's Legal Provisions Relating to IETF # Documents (http://trustee.ietf.org/license-info).
<CODE BEGINS>＃！/ usr / bin / python＃＃Copyright（c）2012 IETF Trustおよび＃コードの作成者として識別された人物。全著作権所有。変更の有無にかかわらず、ソースおよびバイナリ形式での＃再配布および使用は、＃IETFトラストの法的規定のセクション4.cに記載されているSimplified BSD License＃に含まれ、それに含まれるライセンス条項に従って許可されます。 IETF＃ドキュメント（http://trustee.ietf.org/license-info）へ。
"""Simple format validator for self-published ipgeo feeds.
"" "自己発行のipgeoフィード用のシンプルなフォーマットバリデーター。
This tool reads CSV data in the self-published ipgeo feed format from the standard input and performs basic validation. It is intended for use by feed publishers before launching a feed. """
このツールは、標準入力から自社発行のipgeoフィード形式のCSVデータを読み取り、基本的な検証を実行します。フィードを起動する前にフィード発行者が使用することを目的としています。 「」
import csv import ipaddr import re import sys
import csv import ipaddr import re import sys
class IPGeoFeedValidator(object):
def __init__(self):
self.prefixes = {}
self.line_number = 0
self.output_log = {}
self.SetOutputStream(sys.stderr)
def Validate(self, feed): """Check validity of an IPGeo feed.
def Validate（self、feed）： "" "IPGeoフィードの有効性を確認します。
Args: feed: iterable with feed lines """
args：フィード：フィードライン "" "で反復可能
for line in feed: self._ValidateLine(line)
フィードの行の場合：self._ValidateLine（line）
def SetOutputStream(self, logfile): """Controls where the output messages go do (STDERR by default).
def SetOutputStream（self、logfile）： "" "出力メッセージの送信先を制御します（デフォルトではSTDERR）。
Use None to disable logging.
ロギングを無効にするには、Noneを使用します。
Args: logfile: a file object (e.g., sys.stdout) or None. """ self.output_stream = logfile
Args：logfile：ファイルオブジェクト（sys.stdoutなど）またはNone。 "" "self.output_stream = logfile
def CountErrors(self, severity):
"""How many ERRORs or WARNINGs were generated."""
return len(self.output_log.get(severity, []))
############################################################
def _ValidateLine(self, line):
line = line.rstrip('\r\n')
self.line_number += 1
self.line = line.split('#')[0]
self.is_correct_line = True
if self._ShouldIgnoreLine(line): return
if self._ShouldIgnoreLine（line）：return
fields = [field for field in csv.reader([line])][0]
self._ValidateFields(fields)
self._FlushOutputStream()
def _ShouldIgnoreLine(self, line):
line = line.strip()
if line.startswith('#'):
return True
return len(line) == 0
############################################################
def _ValidateFields(self, fields):
assert(len(fields) > 0)
is_correct = self._IsIPAddressOrPrefixCorrect(fields[0])
if len(fields) > 1:
if not self._IsAlpha2CodeCorrect(fields[1]):
is_correct = False
if len(fields) > 2 and not self._IsRegionCodeCorrect(fields[2]):
is_correct = False
if len(fields) != 5:
self._ReportWarning('5 fields were expected (got %d).'
% len(fields))
############################################################
def _IsIPAddressOrPrefixCorrect(self, field):
if '/' in field:
return self._IsCIDRCorrect(field)
return self._IsIPAddressCorrect(field)
def _IsCIDRCorrect(self, cidr):
try:
ipprefix = ipaddr.IPNetwork(cidr)
if ipprefix.network._ip != ipprefix._ip:
self._ReportError('Incorrect IP Network.')
return False
if ipprefix.is_private:
self._ReportError('IP Address must not be private.')
return False
except:
self._ReportError('Incorrect IP Network.')
return False
return True
def _IsIPAddressCorrect(self, ipaddress):
try:
ip = ipaddr.IPAddress(ipaddress)
except:
self._ReportError('Incorrect IP Address.')
return False
if ip.is_private:
self._ReportError('IP Address must not be private.')
return False
return True
############################################################
def _IsAlpha2CodeCorrect(self, alpha2code):
if len(alpha2code) == 0:
return True
if len(alpha2code) != 2 or not alpha2code.isalpha():
self._ReportError(
'Alpha 2 code must be in the ISO 3166-1 alpha 2 format.')
return False
return True
def _IsRegionCodeCorrect(self, region_code):
if len(region_code) == 0:
return True
if '-' not in region_code:
self._ReportError('Region code must be in ISO 3166-2 format.')
return False
parts = region_code.split('-')
if not self._IsAlpha2CodeCorrect(parts[0]):
return False
return True
############################################################
def _ReportError(self, message):
self._ReportWithSeverity('ERROR', message)
def _ReportWarning(self, message):
self._ReportWithSeverity('WARNING', message)
def _ReportWithSeverity(self, severity, message):
self.is_correct_line = False
output_line = '%s: %s\n' % (severity, message)
if severity not in self.output_log:
self.output_log[severity] = []
self.output_log[severity].append(output_line)
if self.output_stream is not None: self.output_stream.write(output_line)
self.output_streamがNoneでない場合：self.output_stream.write（output_line）
def _FlushOutputStream(self):
if self.is_correct_line: return
if self.output_stream is None: return
self.output_stream.write('line %d: %s\n\n'
% (self.line_number, self.line))
############################################################
def main():
feed_validator = IPGeoFeedValidator()
feed_validator.Validate(sys.stdin)
if feed_validator.CountErrors('ERROR'):
sys.exit(1)
if __name__ == '__main__':
main()
<CODE ENDS>
A unit test file, "ipgeo_feed_validator_test.py" is provided as well. It provides basic test coverage of the code above, though does not test correct handling of non-ASCII UTF-8 strings.
単体テストファイル「ipgeo_feed_validator_test.py」も提供されます。上記のコードの基本的なテストカバレッジを提供しますが、非ASCII UTF-8文字列の正しい処理はテストしません。
<CODE BEGINS> #!/usr/bin/python # # Copyright (c) 2012 IETF Trust and the persons identified as # authors of the code. All rights reserved. Redistribution and use # in source and binary forms, with or without modification, is # permitted pursuant to, and subject to the license terms contained # in, the Simplified BSD License set forth in Section 4.c of the # IETF Trust's Legal Provisions Relating to IETF # Documents (http://trustee.ietf.org/license-info).
<CODE BEGINS>＃！/ usr / bin / python＃＃Copyright（c）2012 IETF Trustおよび＃コードの作成者として識別された人物。全著作権所有。 ＃変更の有無にかかわらず、ソースおよびバイナリ形式での＃再配布および使用は、＃IETF Trustの法的規定のセクション4.cに記載されているSimplified BSD License＃に含まれ、それに含まれるライセンス条項に従って許可されます。 IETF＃ドキュメント（http://trustee.ietf.org/license-info）へ。
import sys from ipgeo_feed_validator import IPGeoFeedValidator
ipgeo_feed_validatorからsysをインポートしますimport IPGeoFeedValidator
class IPGeoFeedValidatorTest(object):
def __init__(self):
self.validator = IPGeoFeedValidator()
self.validator.SetOutputStream(None)
self.successes = 0
self.failures = 0
def Run(self):
self.TestFeedLine('# asdf', 0, 0)
self.TestFeedLine(' ', 0, 0)
self.TestFeedLine('', 0, 0)
self.TestFeedLine('asdf', 1, 1)
self.TestFeedLine('asdf,US,,,', 1, 0)
self.TestFeedLine('aaaa::,US,,,', 0, 0)
self.TestFeedLine('zzzz::,US', 1, 1)
self.TestFeedLine(',US,,,', 1, 0)
self.TestFeedLine('55.66.77', 1, 1)
self.TestFeedLine('55.66.77.888', 1, 1)
self.TestFeedLine('55.66.77.asdf', 1, 1)
self.TestFeedLine('2001:db8:cafe::/48,PL,PL-MZ,,02-784', 0, 0)
self.TestFeedLine('2001:db8:cafe::/48', 0, 1)
self.TestFeedLine('55.66.77.88,PL', 0, 1)
self.TestFeedLine('55.66.77.88,PL,,,', 0, 0)
self.TestFeedLine('55.66.77.88,,,,', 0, 0)
self.TestFeedLine('55.66.77.88,ZZ,,,', 0, 0)
self.TestFeedLine('55.66.77.88,US,,,', 0, 0)
self.TestFeedLine('55.66.77.88,USA,,,', 1, 0)
self.TestFeedLine('55.66.77.88,99,,,', 1, 0)
self.TestFeedLine('55.66.77.88,US,US-CA,,', 0, 0)
self.TestFeedLine('55.66.77.88,US,USA-CA,,', 1, 0)
self.TestFeedLine('55.66.77.88,USA,USA-CA,,', 2, 0)
self.TestFeedLine('55.66.77.88,US,US-CA,Mountain View,', 0, 0) self.TestFeedLine('55.66.77.88,US,US-CA,Mountain View,94043', 0, 0) self.TestFeedLine('55.66.77.88,US,US-CA,Mountain View,94043,' '1600 Ampthitheatre Parkway', 0, 1)
self.TestFeedLine（'55 .66.77.88、US、US-CA、Mountain View、 '、0、0）self.TestFeedLine（'55 .66.77.88、US、US-CA、Mountain View、94043'、0、0）セルフ.TestFeedLine（'55 .66.77.88、US、US-CA、Mountain View、94043、 '' 1600 Ampthitheatre Parkway '、0、1）
self.TestFeedLine('55.66.77.0/24,US,,,', 0, 0)
self.TestFeedLine('55.66.77.88/24,US,,,', 1, 0)
self.TestFeedLine('55.66.77.88/32,US,,,', 0, 0)
self.TestFeedLine('55.66.77/24,US,,,', 1, 0)
self.TestFeedLine('55.66.77.0/35,US,,,', 1, 0)
self.TestFeedLine('172.15.30.1,US,,,', 0, 0)
self.TestFeedLine('172.28.30.1,US,,,', 1, 0)
self.TestFeedLine('192.167.100.1,US,,,', 0, 0)
self.TestFeedLine('192.168.100.1,US,,,', 1, 0)
self.TestFeedLine('10.0.5.9,US,,,', 1, 0)
self.TestFeedLine('10.0.5.0/24,US,,,', 1, 0)
self.TestFeedLine('fc00::/48,PL,,,', 1, 0)
self.TestFeedLine('fe00::/48,PL,,,', 0, 0)
print ('%d tests passed, %d failed' % (self.successes, self.failures))
印刷（ '％dテストに合格、％d失敗'％（self.successes、self.failures））
def IsOutputLogCorrectAtSeverity(self, severity,
expected_msg_count):
msg_count = self.validator.CountErrors(severity)
if msg_count != expected_msg_count: print ('TEST FAILED: %s\nexpected %d %s[s], observed %d\n%s\n' % (self.validator.line, expected_msg_count, severity, msg_count, str(self.validator.output_log[severity]))) return False return True
if msg_count！= expected_msg_count：print（ 'TEST FAILED：％s \ nexpected％d％s [s]、observed％d \ n％s \ n'％（self.validator.line、expected_msg_count、severity、msg_count、str（ self.validator.output_log [severity]）））falseを返すtrueを返す
def IsOutputLogCorrect(self, new_errors, new_warnings):
retval = True
if not self.IsOutputLogCorrectAtSeverity('ERROR', new_errors):
retval = False
if not self.IsOutputLogCorrectAtSeverity('WARNING',
new_warnings):
retval = False
return retval
retvalを返す
def TestFeedLine(self, line, warning_count, error_count):
self.validator.output_log['WARNING'] = []
self.validator.output_log['ERROR'] = []
self.validator._ValidateLine(line)
if not self.IsOutputLogCorrect(warning_count, error_count):
self.failures += 1
return False
self.successes += 1 return True
self.successes + = 1はTrueを返します
if __name__ == '__main__':
IPGeoFeedValidatorTest().Run()
<CODE ENDS>
Acknowledgements
謝辞
The authors would like to express their gratitude to reviewers and early implementors, including but not limited to Mikael Abrahamsson, Andrew Alston, Ray Bellis, John Bond, Alissa Cooper, Andras Erdei, Stephen Farrell, Marco Hogewoning, Mike Joseph, Maciej Kuzniar, George Michaelson, Menno Schepers, Justyna Sidorska, Pim van Pelt, and Bjoern A. Zeeb.
著者は、ミカエルアブラハムソン、アンドリューアルストン、レイベリス、ジョンボンド、アリッサクーパー、アンドラスエルデイ、スティーブンファレル、マルコホゲウォニング、マイクジョセフ、マチェイクズニア、ジョージを含むが、これらに限定されないレビューアーと初期の実装者に感謝の意を表したいと思います。 Michaelson、Menno Schepers、Justyna Sidorska、Pim van Pelt、Bjoern A. Zeeb。
In particular, Richard L. Barnes and Andy Newton contributed substantial review, text, and advice.
特に、Richard L. BarnesとAndy Newtonは、大幅なレビュー、テキスト、およびアドバイスを提供しました。
Authors' Addresses
著者のアドレス
Erik Kline Loon LLC 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Erik Kline Loon LLC 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: ek@loon.com
Krzysztof Duleba Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Krzysztof Duleba Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: kduleba@google.com
Zoltan Szamonek Google Switzerland GmbH Brandschenkestrasse 110 CH-8002 Zürich Switzerland
Zoltan Szamonek Google Switzerland GmbH Brandschenkestrasse 110 CH-8002ZürichSwitzerland
Email: zszami@google.com
Stefan Moser Google Switzerland GmbH Brandschenkestrasse 110 CH-8002 Zürich Switzerland
Stefan Moser Google Switzerland GmbH Brandschenkestrasse 110 CH-8002ZürichSwitzerland
Email: smoser@google.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: warren@kumari.net