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

[George Michaelson <[e-mail]>]

Reviewing my sources, I found I had missed a normative reference to
RFC4012 which subsumes RFC2725 and these two documents define inetnum
and inet6num fully,

Therefore the non-IETF normative references for [INETNUM] and
[INET6NUM] are false positives. These are informative and worth
citing, but do not obviate changes to the draft since normative
references to the objects exist already in the reference set.

No other part of my shepherd write-up needs changing at this time. For
completeness, the write-up is attached, with this modification.

-George


On Tue, Feb 16, 2021 at 2:54 PM George Michaelson <[e-mail]> wrote:
>
> 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.