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

["Joe Clarke (jclarke)" <[e-mail]>]

Thank you for your excellent write-up and continued diligence as
shepherd, George.

I've sent the document up to the IESG with your revised write-up.

Joe

On 2/16/21 00:18, George Michaelson wrote:
> 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.