Skip to main content

Shepherd writeup
draft-ietf-opsawg-finding-geofeeds

    (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.

Back