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 <[email protected]> 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 [email protected] >> >> Who is the Responsible Area Director? >> >> The responsible Area Director is Robert Wilton <[email protected]> >> >> (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. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
