(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
Why is this the proper type of RFC? Is this type of RFC
indicated in the title page header?
The authors have requested Internet Standards track. The document
proposes changes (an additional type field) to RFC 4012/7909 (RPSL)
which is itself proposed standard. The document does indicate the
RFC type in the title page.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement
Write-Up. Recent examples can be found in the "Action"
announcements for approved documents. The approval announcement
contains the following sections:
Technical Summary:
(from the Abstract)
Providers of Internet content and other services may wish to customize
those services based on the geographic location of the user of the
service. This is often done using the source IP address used to
contact the service. Also, infrastructure and other services might
wish to publish the locale of their services. [RFC8805] defines
geofeed, a syntax to associate geographic locales with IP addresses.
But it does not specify how to find the relevant geofeed data given
an IP address.
This document specifies how to augment the Routing Policy Specification
Language (RPSL) [RFC4012] inetnum: class [INETNUM] to refer to
geofeed data, and how to prudently use them. In all places inetnum:
is used, inet6num: should also be assumed [INET6NUM].
Working Group Summary:
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or were
there decisions where the consensus was particularly rough?
The WG discussion was not controversial. Constructive criticism was
accepted and reflected in revisions to the document.
Document Quality:
Are there existing implementations of the protocol?
There are active discussions in one RIR to implement the proposed
field in their deployed RPSL Whois. There are discussions commencing
in another RIR. Commentary included an author of a third RPSL
implementation.
The email:
https://mailarchive.ietf.org/arch/msg/opsawg/FoRMmqkdNU6MOaTgNQs9sa-Tn9Q/
from Job Snijders shows a worked example of detached CMS signatures
as documented in this draft, using openly available tools.
The document references https://github.com/massimocandela/geofeed-finder
which is a working implementation of reading the field from sources,
written by the authors.
Have a significant number of vendors indicated their plan to
implement the specification?
RPSL based IRR sources vest with two primary sources, the RIPE NCC
Whois, and IRRd. Both are involved in discussions for the potential
deployment of this new field. A variant of RIPE NCC Whois is operated
by another RIR and is highly likely to adopt the field. The NRO
Engineering coordination group (ECG) has been approached to consider
support for the field in all IRR. Use of the "remarks" and "comments"
structures is always possible.
Are there any reviewers that merit special mention as having
done a thorough review, e.g., one that resulted in important
changes or a conclusion that the document had no substantive
issues?
There were no especially remarkable review inputs which required
changes to the document. There is a general sense the document
addresses a real world problem, of merit. The solution is plausible
and low cost for high gain.
If there was a MIB Doctor, YANG Doctor, Media Type or other
expert review, what was its course (briefly)? In the case of a
Media Type review, on what date was the request posted?
There is no applicable MIB, YANG, media or other expert review. At
least one of the in-WG reviewers of the document is an RPSL systems
author and supports the proposal.
Personnel
Who is the Document Shepherd?
The document Shepherd is George Michaelson ggm@apnic.net
Who is the Responsible Area Director?
The responsible Area Director is Robert Wilton <rwilton@cisco.com>
(3) Briefly describe the review of this document that was
performed by the Document Shepherd. If this version of the
document is not ready for publication, please explain why
the document is being forwarded to the IESG.
I undertook a review of WG mail history and related traffic in the
RIPE NCC region "DB-WG" mailing list across 2020 and 2021. Noting
that in the RIPE region a concern of GDPR privacy was raised, which
is understood to be strictly irrelevant since no personal identifying
information (PII) is latent in the proposed geofeed: field, or its
use by a delegate of Internet addresses.
- https://www.ripe.net/ripe/mail/archives/db-wg/2020-October/006657.html
- https://www.ripe.net/ripe/mail/archives/db-wg/2021-January/006771.html
Broadly speaking, there was good support for the intent of this
proposal from one of the five principle communities likely to depend
on deployment of it in the regional RIR Whois service (IRR, RPSL) and it
is under consideration in at least one other RIR region.
In the WG, the proposal was non-contentious, and secured good
supportive discussion. Over 2020 and 2021 a total of 11 people
engaged actively in the WG discussion including WG chair and the
Authors.
The document was run through the idnits process, which identified
a small number of potential issues, all but 2 were resolved in the 03 version
before closure of the document for publication. These were downref
issues relating to normative RFC references and are discussed below
in (15)
(4) Does the document Shepherd have any concerns about the depth
or breadth of the reviews that have been performed?
The document is brief, and to the point. The reviews are equally
brief, and to the point. its a simple proposal, simple to understand,
and of reasonably high utility.
(5) Do portions of the document need review from a particular
or from broader perspective, e.g., security, operational
complexity, AAA, DNS, DHCP, XML, or internationalization?
If so, describe the review that took place.
There is no compelling case for a specific review in security,
complexity, AAA, DNS. One of the authors has been a member of the
security directorate, there is no substantive complexity, the AAA
problem is covered by the management rights to the RPSL object(s)
being modified, there is no DNS burden, no new DNS RR or content
types in the DNS, no changes to DNS semantics are implied.
The document does not use XML. The document does use ASN.1 which
was reviewed and modified to ensure consistency with the relevant
(CMS) standards.
The document does not demand non-UTF8 or other non-i8n capable
labels or technology.
The security considerations note the potential for weak security
in RPSL to permit an "attack" on a more specific prefix. This is
analogous to the more-specific-prefix attack in BGP itself. It is
not clear if there is any defense against this, given the security
vests with the publisher, and not innately with the data.
It is arguable a complex set of rules could be derived about the
applicability and meaning of a signed assertion, and if that demanded
relying parties therefore only accept signed more specifics, But
that is probably beyond the scope of the geofeed: defining document.
The Signed data ameliorates the security concerns of weak control
of RPSL since the RPKI signature demands authority proofs down from
the issuer for the address ranges.
(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area
Director and/or the IESG should be aware of? For example,
perhaps he or she is uncomfortable with certain parts of
the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those
issues and has indicated that it still wishes to advance
the document, detail those concerns here.
There are no obvious concerns or issues which demand the AD or IESG
intervene.
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions
of BCP 78 and BCP 79 have already been filed. If not, explain
why?
Yes, the authors have disclaimed IPR and made full disclosures in
the normal manner.
(8) Has an IPR disclosure been filed that references this
document? If so, summarize any WG discussion and conclusion
regarding the IPR disclosures.
No IPR disclosure has been made relating to this document.
(9) How solid is the WG consensus behind this document? Does
it represent the strong concurrence of a few individuals,
with others being silent, or does the WG as a whole understand
and agree with it?
The document did not receive significant objecting technical
discussion. It is strong concurrence of a few individuals with the
weight of the list silent, but it is clear from discussion here and
on related lists that the context and need for this service is
understood in the operations community of interest.
(10) Has anyone threatened an appeal or otherwise indicated
extreme discontent? If so, please summarize the areas of
conflict in separate email messages to the Responsible
Area Director. (It should be in a separate email because
this questionnaire is publicly available.)
There has been no indication of concern or an impending appeal process.
(11) Identify any ID nits the Document Shepherd has found in
this document. (See <http://www.ietf.org/tools/idnits/>
and the Internet-Drafts Checklist). Boilerplate checks are
not enough; this check needs to be thorough.
The document refers to IPv6 and is clear that all usage of IPv4 implies IPv6
in the noted inetnum and inet6num objects. However, idnits did identify there
are no worked examples in IPv6.
2 downref, external or obsolete references have been detected by
the idnits process and are detailed below in section (15)
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type,
and URI type reviews.
See above: they're not relevant.
(13) Have all references within this document been identified
as either normative or informative?
Yes. there are idnits which relate to non-normative downrefs. They
need to be understood and discussed out before publication. There
is some chance some of them are unavoidable.
(14) Are there normative references to documents that are not
ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for
their completion?
There are no un-published normative references.
(15) Are there downward normative references references (see
RFC 3967)? If so, list these downward references to support
the Area Director in the Last Call procedure.
- Downref: Normative reference to an Informational RFC: RFC 5485
- Downref: Normative reference to an Informational RFC: RFC 8805
These normative references to informative documents have been discussed with the Authors.
I believe they will be difficult to resolve, and may mean the document sits in "proposed standard"
pending completion of standards-track completion for these information references, or suitable
alternatives.
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page
header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract
and Introduction, explain why, and point to the part of
the document where the relationship of this document to
the other RFCs is discussed. If this information is not
in the document, explain why the WG considers it unnecessary.
Except for the explicit request for inclusion of a new field type
in RPSL, No. There is no change in status of any existing RFCs
(the RPSL in question is not currently defined in an RFC but this
request would have the same effect on an external normative documented
structure in the RIPE NCC document space)
(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its
consistency with the body of the document. Confirm that
all protocol extensions that the document makes are
associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries
have been clearly identified. Confirm that newly created
IANA registries include a detailed specification of the
initial contents for the registry, that allocations
procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested
(see RFC 8126).
No special IANA actions are required. An OID has to be allocated
from the existing OID registry in publication and is marked as a
TBD:
Quoting from the draft:
IANA is asked to register 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:
Description OID Specification
-----------------------------------------------------------------
id-ct-geofeedCSVwithCRLF 1.2.840.113549.1.9.16.1.47 [RFC-TBD]
(18) List any new IANA registries that require Expert Review
for future allocations. Provide any public guidance that the
IESG would find useful in selecting the IANA Experts for these
new registries.
No new registry is implied in this document
(19) Describe reviews and automated checks performed by the
Document Shepherd to validate sections of the document
written in a formal language, such as XML code, BNF rules,
MIB definitions, YANG modules, etc.
The document proposes use of a new OID in constructing a CMS detached
signature. At least one successful instance of the necessary ASN.1
was constructed and validated by a WG participant.
(20) If the document contains a YANG module, has the module
been checked with any of the recommended validation tools
(<https://trac.ietf.org/trac/ops/wiki/yang-review-tools>)
for syntax and formatting validation? If there are any
resulting errors or warnings, what is the justification
for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?
No Yang was implicated in this document.