[OPSAWG] Document Shepherd write-up for draft-ietf-opsawg-finding-geofeeds

[George Michaelson <[e-mail]>]

I volunteered to be document shepherd for draft-ietf-opsawg-finding-geofeeds

Here is my write-up in Q & A form, as agreed with the WG chair.

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

    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 [e-mail]

    Who is the Responsible Area Director?

The responsible Area Director is Robert Wilton <[e-mail]>

    (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, to be 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. It is 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.

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

- Possible downref: Non-RFC (?) normative reference: ref. 'INET6NUM'
- Possible downref: Non-RFC (?) normative reference: ref. 'INETNUM'

These could be replaced by the RFC2280/RFC2622 but the RPSL RFC's do
not actual 'define' the inetnum: and inet6num: objects. Although
RFC4012/RFC7909 refer to them, again they do not provide normative
definitions. RFC1786 defines inetnum, but does not define inet6num.

The RIPE NCC documentation is (I believe) the best definition of
specification of these terms. I do not see external normative
reference as a problem in this case.

- Downref: Normative reference to an Informational RFC: RFC 2818
- Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652)
- Downref: Normative reference to an Informational RFC: RFC 5485
- Downref: Normative reference to an Informational RFC: RFC 8805

These normative references to informative/obsoleted documents have
been referred to the Authors. I believe they will resolve in an 03
version or during IESG review.


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