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.
(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. 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.
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 are covered by normative references to RFC4012 which updates
RFC2725 and are therefore false-positives.
- 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
