Finding and Using Geofeed Data
draft-ietf-opsawg-finding-geofeeds-17

[Ballot discuss]
Roman and Russ did the heavy lifting already, but I think I have a bit more
fiddling to do regarding the validation procedures (just getting them
internally consistent, I think)...

(2)
We are careful to note that:

  The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
  present exactly as shown.

How do we construct the bits (address range?) that come after the quoted
strings?  Do they only matter for matching start/end, or are we supposed
to check them in the validation procedure?

[Ballot comment]
Thanks for addressing my DISCUSS and answering my question.

Thank you for the work on this document, and thank you to the shepherd for a very well-written and in-depth shepherd write up: it was very informative and very appreciated.

Francesca

[Ballot comment]
Thanks for addressing my DISCUSS and answering my question below.

Francesca

==== Original Ballot  2021-05-18 =======

Thank you for the work on this document, and thank you to the shepherd for a very well-written and in-depth shepherd write up: it was very informative and very appreciated.

I have one DISCUSS point (that should be easy to fix) and a question.

Francesca

1. -----

  then BASE64 encoded and line wrapped to 72 or fewer characters.

FP: Please add a (normative) reference to RFC 4648 and specify if Section 4 ("base64") or Section 5 ("base64url") is to be used.

2. -----

  then BASE64 encoded and line wrapped to 72 or fewer characters.

FP: Less of a comment and more of a question: what is the reason for setting the line length, and specifically to 72 (or fewer) characters?

[Ballot comment]
(Updated ballot)
Thank you to Kyle Rose for the SECDIR review.

Thank you for addressing my DISCUSS and various COMMENTs.

======
** Section  4. Per “the RPKI certificate covering the inetnum: object's address range is included in the [RFC5652] CMS SignedData certificates field”, can a more specific statement be made highlight which certificate field in providing the IP information.  Propose:

OLD
... the RPKI certificate covering the inetnum: object's address range is included in the [RFC5652] CMS SignedData certificates field

NEW
... the RPKI certificate covering the inetnum: object's address range is included in the IP Address Delegation certificate extension [RFC3779] field.

See https://mailarchive.ietf.org/arch/msg/opsawg/zYwS9OHWhzkXrfXVUu4ZG16-2GI/ for follow-up discussion on this.

** Section 4.  Per the format of the signature appended to the geofeed file:
      # RPKI Signature: 192.0.2.0/24
      # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
      # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
      ...
      # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
      # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
      # End Signature: 192.0.2.0/24

-- The does the label “192.0.2.0/24” relate to the rest of the geofeed file and the inetnum: value?

** Appendix A.  The end-user certificate has a sbgp-ipAddBlock field which is “IPv4: inherit IPv6: inherit”.  However, the parent CA is encoding an IPv4 only range so it seems misplaced that there is a IPv6 reference there.

See https://mailarchive.ietf.org/arch/msg/opsawg/zYwS9OHWhzkXrfXVUu4ZG16-2GI/ for follow-up discussion on this.

[Ballot discuss]
Roman and Russ did the heavy lifting already, but I think I have a bit more
fiddling to do regarding the validation procedures (just getting them
internally consistent, I think)...

(1)
Here:

  As the signer specifies the covered RPKI resources relevant to the
  signature, the RPKI certificate covering the inetnum: object's
  address range is included in the [RFC5652] CMS SignedData
  certificates field.

we say that the signing certificate is included in the SignedData
certificates field.  That makes sense, as SignedData is a SEQUENCE
including "certificates [0] IMPLICIT CertificateSet OPTIONAL", and
CertificateSet, as a SET OF CertificateChoices, allows for the literal
"Certificate" branch of CertificateChoices.

But later on, we say that:

  1.  Obtain the signer's certificate from an RPKI Repository.  The
      certificate SubjectKeyIdentifier extension [RFC5280] MUST match
      the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
      [RFC5286].  If the key identifiers do not match, then validation
      MUST fail.

which entails fetching the certificate from a directory, based on the
SubjectKeyIdentifier.

Why do we need to obtain the certificate twice in two different ways?


(2)
We are careful to note that:

  The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
  present exactly as shown.

How do we construct the bits (CIDR block?) that come after the quoted
strings?  Do they only matter for matching start/end, or are we supposed
to check them in the validation procedure?

[Ballot comment]
Thanks to Kyle Rose for the secdir review, and all who participated in
the subsequent discussion.

Publishing this document on the stanards-track does make one wonder
whether RFC 8805 should be adopted at least into the IETF stream and
possibly to the standards-track as well...

My colleagues have done a great job commenting on aspects that I also
was unsure about; I will try (and no doubt fail) to deduplicate.

The length of my comments notwithstanding, thank you for putting
together this document: it seems useful without trying to boil any
oceans, and I hope my comments can help improve it.

Section 1

  This document specifies how to augment the Routing Policy
  Specification Language (RPSL) [RFC2622] inetnum: class to refer

Interestingly, I don't see "inetnum" at all in RFC 2622 (but the
treatment in RFC 2725 is helpful to some extent).  Should we be
referencing 2725 (or something else) in addition to 2622?

Section 3

  The URL's use of the web PKI can not provide authentication of IP
  address space ownership.  It is only used to authenticate a pointer
  to the geofeed file, [...]

I'm a little confused by the use of the phrase "authenticate a pointer
to the geofeed file".  My understanding is that the "pointer to the
geofeed file" is the URL itself, i.e., it is a pointer from the RPSL
stanza to the geofeed file, and that dereferencing the URL retrieves the
geofeed file itself (i.e., not a pointer).  In particular, the URL (and
any Web PKI usage therein) does not do anything to authenticate the RPLS
stanza in which the URL appears.  IIUC, it would be okay to just drop
that bit and say "It is only used to authenticate the domain name in the
URL, and provide confidentiality and integrity for the geofeed file in
transit".  Am I missing something?

  If a geofeed CSV file describes multiple disjoint ranges of IP
  address space, there are likely to be geofeed references from
  multiple inetnum: objects.

We might note that such files with geofeed references from multiple
inetnum: objects are not compatible with our signing procedure (right?)
and thus vaguely discouraged.

Section 4

  address range.  One needs a format that bundles the relevant RPKI
  certificate with the signature and the digest of the geofeed text.

If the signature is distributed alongside the file being signed, why is
it necessary to bundle the digest of the file being signed with the
signature?  This just invites security-relevant implementation bugs
where the validator just accepts the precomputed digest and does not
validate that the contents of the geofeed file actually have that
digest.
(There is, however, value in the CMS SignedData including the digest
*algorithms* used in signatures.  I don't know if that was the intent
here.)

  text.  Trailing space characters MUST NOT appear on a line of text.
  That is, the space or tab characters must not be followed by the
    sequence.  [...]

Is the restriction on Unicode characters of category "space separator"
("space characters") or the two listed characters?  (Why just those two,
and not form feed as well?)

  The address range of the signing certificate MUST cover all prefixes
  in the geofeed file it signs; and therefore must be covered by the
  range of the inetnum:.

Maybe I'm just confused about what "covered by he range of the inetnum:"
means, but I only see (at least so far) requirements that the signing
cert cover all addresses in the file, and that we fetch from the
most-specific inetnum: object with a geofeed reference.  Can't I still
sign with a cert that covers a broader range of addresses than the
intenum: object used to fetch?

  Identifying the private key associated with the certificate, and
  getting the department with the Hardware Security Module (HSM) to
  sign the CMS blob is left as an exercise for the implementor.  On the

I thought there was some previous discussion of this but now I can't
find it: I assume that a HSM is not mandatory for holding the RPKI
certificate's private key.  In that case, I'd consider "getting the
department that controls the private key (which might be trapped in a
Hardware Security Module, HSM)".

  1.  Obtain the signer's certificate from an RPKI Repository.  The
      certificate SubjectKeyIdentifier extension [RFC5280] MUST match
      the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
      [RFC5286].  If the key identifiers do not match, then validation
      MUST fail.

We want RFC 5652 again, here (5286 is IP Fast Reroute: Loop-Free
Alternates, which is of no relevance to this document).

  4.  Verify that the IP Address Delegation certificate extension
      [RFC3779] covers the address range of the geofeed file.  If the
      address range is not covered, then validation MUST fail.

"address range of the geofeed file" is probably under-specified, since
the file could in theory include multiple disjoint ranges.  I assume we
want to say something like "covers all the addresses and/or address
ranges in the geofeed file" and make the grammar in the last sentence
match.

  5.  Validation of the signing certificate MUST ensure that it is part
      of the current manifest and that the resources are covered by the
      RPKI certificate.

Is "the signing certificate" different from "the RPKI certificate"?

Also, I suggest clarifying what "the resources" are that are covered.

Also^2, "the current manifest" would be a great place to put in a
reference to the relevant document(s)

Section 5

  If and only if the geofeed file is not signed per Section 4, then
  multiple inetnum: objects MAY refer to the same geofeed file, and the
  consumer MUST use only geofeed lines where the prefix is covered by
  the address range of the inetnum: object they have followed.

Does "geofeed lines" here mean "lines/entries in the geofeed file", as
opposed to "the geofeed: attribute in the intenum: class"?
(Also, didn't we say earlier that geofeed files could have entries that
don't map up to a CIDR block and thus don't have a well-defined prefix?)

  To minimize the load on RIR whois [RFC3912] services, use of the
  RIR's FTP [RFC0959] services SHOULD be the preferred access.  This

Preferred access for which objects/resources?

  If an inetnum: for a wide prefix (e.g. a /16) points to an RPKI-
  signed geofeed file, a customer or attacker could publish an unsigned
  equal or narrower (e.g. a /24) inetnum: in a whois registry which has
  weak authorization.

I might reiterate that the rule for fetching from the most-specific
inetnum: object with a geofeed reference means that the spoofed data
will take effect (for the affected prefix), and possibly also that if
validators could always require signatures, the attack would be stymied
(but of course that is not happening anytime soon).

Appendix A

Those are some interesting Subject CNs in the non-root certs, but I
guess they work...

I only did some cursory spot-checking of the examples, and not a full
work-up.

NITS

Section 1

  of the service.  This is often done using the source IP address used
  to contact the service.  [...]

I'd consider s/using/by using/ or s/using/based on/

Section 2

  Content providers and other parties who wish to locate an IP address
  to a geographic locale need to find the relevant geofeed data.  In

I'd suggest s/to locate/to associate/

  and high granularity can be quite large.  The size of a file can be
  even larger if an unsigned geofeed file combines data for many
  prefixes, dual IPv4/IPv6 spaces are represented, etc.

I'm not sure how the unsigned nature of the geofeed file is relevant for
discussing its large size.

Section 3

  The Routing Policy Specification Language (RPSL), and [RFC2622] and
  [RFC4012] used by the Regional Internet Registries (RIRs) specifies

Is the ", and" needed?

Section 4

  Should the authenticator be syntactically incorrect per the above,
  the authenticator is invalid.

"The above" seems to be mostly discussing the geofeed file being signed,
not the authenticator per se.

  Borrowing detached signatures from [RFC5485], after file
  canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
  would be used to create a detached DER encoded signature which is

Why "would be used" (vs "is used")?

  All of these steps MUST be successful to consider the geofeed file
  signature as valid.

  As the signer specifies the covered RPKI resources relevant to the
  signature, the RPKI certificate covering the inetnum: object's
  address range is included in the [RFC5652] CMS SignedData
  certificates field.

  Identifying the private key associated with the certificate, and
  getting the department with the Hardware Security Module (HSM) to
  sign the CMS blob is left as an exercise for the implementor.  On the
  other hand, verifying the signature requires no complexity; the
  certificate, which can be validated in the public RPKI, has the
  needed public key.

The last two paragraphs here seem to be copy/paste leftovers, as they
(or a edited copy) already appeared prior to the detailed/enumerated
validation procedure.

  [I-D.spaghetti-sidrops-rpki-rsc] describes and provides code for a
  Cryptographic Message Syntax (CMS) profile for a general purpose
  listing of checksums (a 'checklist'), for use with the Resource
  Public Key Infrastructure (RPKI).  It provides usable, albeit
  complex, code to sign geofeed files.

I don't see any code in the draft itself ("provides"), but probably
there is code referenced from it.

Section 5

  their RIR/NIR and/or any provider LIR which has assigned prefixes to

Interestingly, RIR is not listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt (and LIR not
listed at all!).  This is the first time we use LIR, so we should expand
it.

  It is good key hygiene to use a given key for only one purpose.  To
  dedicate a signing private key for signing a geofeed file, an RPKI CA
  may issue a subordinate certificate exclusively for the purpose as
  shown in Appendix A.

"subordinate certificate" seems to be a very uncommon phrase (and mostly
only appears as part of "subordinate certificate authority").  Perhaps
"a dedicated certificate" or "a leaf certificate" would work just as
well?

[Ballot discuss]
I may have missed something, but why does Section 5 advocate for use of HTTPS to fetch geofeed files in the second paragraph, and then FTP in the seventh?  Which is right?  Or perhaps both are right, but there's some context being assumed here that I don't have.  In any case, please clarify.

[Ballot comment]
Nice job on the shepherd writeup.

In Section 5, "https" should be "HTTPS" since you're describing a protocol and not a URI scheme (or if you meant to do the latter, please say so).

[Ballot comment]
Thanks for this document, it looks useful. I have some comments and questions below.


0. I’d like to thank George Michaelson for a thorough and helpful, not to say exemplary, shepherd’s report.


1. Section 3:

  Ideally, RPSL would be augmented to define a new RPSL geofeed:
  attribute in the inetnum: class.  Until such time, this document

I, too, am curious as to why this ideal solution isn’t considered achievable.

I’m also a little confused by the way you seem to be arguing with yourself in this section. First you tell me that change control for RPSL is vested in the operator community (by implication, not the IETF). A few paragraphs later you say:

  While we leave global agreement of RPSL modification to the relevant
  parties, we specify that a proper geofeed: attribute in the inetnum:
  class MUST be "geofeed: ", and MUST be followed by a single URL which

Is it up to them? Or is it up to you? I don’t get it. I mean, I’m fine with what you’ve specced, but when you fence it off with disclaimers that say RPSL modification isn’t up to you, it leaves me confused.

Perhaps your point is that the IETF gets to specify the geofeed: attribute, but only the RIRs get to decide when they will start using it? This is generally true of everything the IETF does, of course, but OK. But if that’s what you mean, it really wasn’t clear to me from reading the text.

By the way, I bet you should expand “RIR“ on first use.


2. Section 3:

  Until all producers of inetnum:s, i.e. the RIRs, state that they have
  migrated to supporting a geofeed: attribute, consumers looking at
  inetnum:s to find geofeed URLs MUST be able to consume both the
  remarks: and geofeed: forms.  This not only implies that the RIRs
  support the geofeed: attribute, but that all registrants have
  migrated any inetnum:s from remarks: use to geofeed:s.

The referent of “this” in the last sentence isn’t clear. Maybe you mean “migrated”? Rewriting as ‘“Migrated” not only implies…’ would clarify, if so.


3. Section 3:

  Any particular inetnum: object MUST have at most, one geofeed
  reference, whether a remarks: or a proper geofeed: attribute when it
  is implemented.  If there is more than one, all are ignored.

This makes me think the geofeed: attribute will never, ever be adopted, because you’ve just created a flag day requirement. Why not permit both the remarks: and geofeed: versions to enable transition? Presumably you'd need some tie-break rule in case they're pointing different places, but that doesn't seem like a deal-breaker.


4. Section 5:

  If and only if the geofeed file is not signed per Section 4, then
  multiple inetnum: objects MAY refer to the same geofeed file, and the
  consumer MUST use only geofeed lines where the prefix is covered by
  the address range of the inetnum: object they have followed.

Presumably this only works with unsigned geofeeds because you’re implicitly requiring that the geofeed file be signed only once. Is there any particular driver for this sign-only-once requirement? On a cursory review of §4, I don’t see anything that would make multiple signatures impracticable.

I note that §3 says

  If a geofeed CSV file describes multiple disjoint ranges of IP
  address space, there are likely to be geofeed references from
  multiple inetnum: objects.

While the text in §5 doesn’t actually give the lie to this quote (since I can read it as “if an unsigned geofeed CSV file…”) it does seem like the document is pulling in two different directions.

At the very least, if there is a requirement that only a single signature be present in a geofeed file, can you say that explicitly in §4?


5. Section 5:

  An entity fetching geofeed data using these mechanisms MUST NOT do
  frequent real-time look-ups to prevent load on RPSL and geofeed
  servers.  [RFC8805] Section 3.4 suggests use of the [RFC7234] HTTP

Nit: I think you need a comma between “look-ups” and “to”. Or re-word as “To prevent undue load on RPSL and geofeed servers, an entity fetching geofeed data using these mechanisms MUST NOT do frequent real-time look-ups.” (I also added “undue” because of course every transaction induces SOME load.)


6. General Comment:

While I notice some reviewers have expressed discomfort with the occasional lighthearted use of language (“fetching with tweezers”, etc), I found that it made the document more fun to read without hindering clarity in the slightest. In short, it made it a better spec. Thank you.

[Ballot comment]
Thanks for this document, it looks useful. I have some comments and questions below.


0. I’d like to thank George Michaelson for a thorough and helpful, not to say exemplary, shepherd’s report.


1. Section 3:

  Ideally, RPSL would be augmented to define a new RPSL geofeed:
  attribute in the inetnum: class.  Until such time, this document

I, too, am curious as to why this ideal solution isn’t considered achievable.

I’m also a little confused by the way you seem to be arguing with yourself in this section. First you tell me that change control for RPSL is vested in the operator community (by implication, not the IETF). A few paragraphs later you say:

  While we leave global agreement of RPSL modification to the relevant
  parties, we specify that a proper geofeed: attribute in the inetnum:
  class MUST be "geofeed: ", and MUST be followed by a single URL which

Is it up to them? Or is it up to you? I don’t get it. I mean, I’m fine with what you’ve specced, but when you fence it off with disclaimers that say RPSL modification isn’t up to you, it leaves me confused.

Perhaps your point is that the IETF gets to specify the geofeed: attribute, but only the RIRs get to decide when they will start using it? This is generally true of everything the IETF does, of course, but OK. But if that’s what you mean, it really wasn’t clear to me from reading the text.

By the way, I bet you should expand “RIR“ on first use.


2. Section 3:

  Until all producers of inetnum:s, i.e. the RIRs, state that they have
  migrated to supporting a geofeed: attribute, consumers looking at
  inetnum:s to find geofeed URLs MUST be able to consume both the
  remarks: and geofeed: forms.  This not only implies that the RIRs
  support the geofeed: attribute, but that all registrants have
  migrated any inetnum:s from remarks: use to geofeed:s.

The referent of “this” in the last sentence isn’t clear. Maybe you mean “migrated”? Rewriting as ‘“Migrated” not only implies…’ would clarify, if so.


3. Section 3:

  Any particular inetnum: object MUST have at most, one geofeed
  reference, whether a remarks: or a proper geofeed: attribute when it
  is implemented.  If there is more than one, all are ignored.

This makes me think the geofeed: attribute will never, ever be adopted, because you’ve just created a flag day requirement. Why not permit both the remarks: and geofeed: versions to enable transition?


4. Section 5:

  If and only if the geofeed file is not signed per Section 4, then
  multiple inetnum: objects MAY refer to the same geofeed file, and the
  consumer MUST use only geofeed lines where the prefix is covered by
  the address range of the inetnum: object they have followed.

Presumably this only works with unsigned geofeeds because you’re implicitly requiring that the geofeed file be signed only once. Is there any particular driver for this sign-only-once requirement? On a cursory review of §4, I don’t see anything that would make multiple signatures impracticable.

I note that §3 says

  If a geofeed CSV file describes multiple disjoint ranges of IP
  address space, there are likely to be geofeed references from
  multiple inetnum: objects.

While the text in §5 doesn’t actually give the lie to this quote (since I can read it as “if an unsigned geofeed CSV file…”) it does seem like the document is pulling in two different directions.

At the very least, if there is a requirement that only a single signature be present in a geofeed file, can you say that explicitly in §4?


5. Section 5:

  An entity fetching geofeed data using these mechanisms MUST NOT do
  frequent real-time look-ups to prevent load on RPSL and geofeed
  servers.  [RFC8805] Section 3.4 suggests use of the [RFC7234] HTTP

Nit: I think you need a comma between “look-ups” and “to”. Or re-word as “To prevent undue load on RPSL and geofeed servers, an entity fetching geofeed data using these mechanisms MUST NOT do frequent real-time look-ups.” (I also added “undue” because of course every transaction induces SOME load.)


6. General Comment:

While I notice some reviewers have expressed discomfort with the occasional lighthearted use of language (“fetching with tweezers”, etc), I found that it made the document more fun to read without hindering clarity in the slightest. In short, it made it a better spec. Thank you.

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Thank you to George Michaelson for his shepherd's write-up (including the WG consensus). Nice to have acknowledged him.

Thank you Jean-Michel Combes for the INT-DIR Last Call review at:
https://datatracker.ietf.org/doc/review-ietf-opsawg-finding-geofeeds-08-intdir-lc-combes-2021-05-14/

The telechat INT-DIR review by Wassim Haddad also seconds a good opinion of this document.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 3 --
Having a standards track document relying on a 'remarks:' attribute looks really weird. Should it rather be informational ? NB: I understand that changing the RPSL syntax is mostly mission impossible.

Should the case when both "remarks: Geofeed" and "geofeed" are present but differ be mentioned ?

-- Section 4 --
What happens if the public key of the certificate is changed? Should the cert serial number be part of the signature? Or at least mention the obvious that the signature must be re-executed when the cert if changed (e.g., in section 5).

-- Section 5 --
Is there any reason why the doc shepherd is not acknowledged ?

== NITS ==

I find the use of the colon in "inetnum:" quite annoying and confusing. The use of quotes in the last § of section 3 is easier to read and parse

-- Section 3 --
Do the examples really need to be in IPv4 ? ;-)

-- Section 4 --
The use of "department" in "getting the department with the Hardware Security Module" is difficult to understand by non-English native readers (at least for me as I had to re-read it twice and guess the meaning).

[Ballot discuss]
Thank you for the work on this document, and thank you to the shepherd for a very well-written and in-depth shepherd write up: it was very informative and very appreciated.

I have one DISCUSS point (that should be easy to fix) and a question.

Francesca

1. -----

  then BASE64 encoded and line wrapped to 72 or fewer characters.

FP: Please add a (normative) reference to RFC 4648 and specify if Section 4 ("base64") or Section 5 ("base64url") is to be used.

[Ballot comment]
2. -----

  then BASE64 encoded and line wrapped to 72 or fewer characters.

FP: Less of a comment and more of a question: what is the reason for setting the line length, and specifically to 72 (or fewer) characters?

[Ballot discuss]
The validation process for the signature computed in Section 4 seems underspecified. 

For example, let’s consider the example in Appendix A.  Through a whois query for 192.0.2.0 one finds a “remarks:        Geofeed ” field which leads to a geofeed file which had the detached CMS signature blob “# RPKI Signature: 192.0.2.0/24” depicted at the end of Appendix A.  What reference or text guides how to validate that signature in the RPKI (akin to the level of detail in Section 3.3 of RFC7909 or RFC6125)?

I’m inferring that the steps would roughly be:

** Download the end-entity certificate identified by the subjectKeyIdentifier field via the pointer/URI in the “subjectInfoAccess”  field extracted from the CMS signature blob

** Download the intermediate certificate identified by the authorityKeyIdentifier field via the pointer/URI in the “caIssuer” field extracted from the CMS signature blob

** Based on the RIR identified in the whois query, download the RPKI trust anchor of the RIR

** Validate the certificate chain from the RPKI trust anchor down to the end-entity certificate.  Check that all of the basicConstraints, certificatePolicies, etc. are accurate.  Check the CRL.

** Verify that the end-entity certificate contains the IP address of interest (192.0.2.0) in the sbgp-ipAddrBlock field

** Validate the signature using the algorithm identified in the CMS signature blog using the end-entity certificate

Is that the process?  Is that stated somewhere in the document or available via reference?

[Ballot comment]
Thank you to Kyle Rose for the SECDIR review.

** Section 3.  "It is only used to authenticate a pointer to the geofeed file and transport integrity of the data."

To separate the notion of the transport security provided with TLS and the object security provided by the RPKI signature, it might be cleaner to say:

TLS and the web PKI authenticate the domain name in the URL and provides confidentiality and integrity for the geofeed file in transit.

** Section 4.  Per “Borrowing detached signatures from [RFC5485] …”, I’m having trouble following which concept is being borrowed to elevate this to a normative reference.

** Section 4.  Per “the RPKI certificate covering the inetnum: object's address range is included in the [RFC5652] CMS SignedData certificates field”, can a more specific statement be made to say that it would be the sbgp-ipAddrBlock field in the certificate?

** Section 4.  Per the format of the signature appended to the geofeed file:
      # RPKI Signature: 192.0.2.0/24
      # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
      # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
      ...
      # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
      # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
      # End Signature: 192.0.2.0/24

-- Are the header “# RPKI Signature: 192.0.2.0/24” and footer “# End Signature: 192.0.2.0/24” syntactically required?  If would seem so, but that’s never explicitly stated and can only be inferred via the example.  It would be helpful to explicitly clarify that.

-- Is that header case sensitive (e.g., is “rpki SiGnAtUrE:” equally valid?)?

-- The does the label “192.0.2.0/24” relate to the rest of the geofeed file and the inetnum: value?

** Section 6. Privacy Considerations. 

Unfortunately, [RFC8805] provides no privacy  guidance on avoiding or ameliorating possible damage due to this
  exposure of the user.  In publishing pointers to geofeed files as
  described in this document, the operator should be aware of this
  exposure in geofeed data and be cautious.  All the privacy  considerations of [RFC8805] Section 4 apply to this document.

Isn’t the different between RFC8805 which provided the underlying format shared “ad hoc feed discovery and verification [that have] a modicum of established practice” and this document from a privacy perspective that this work would create an API-of-sorts with the potential of dramatically increasing access and ease of IP-to-location information?

** Appendix A. 

Section 4 says: “As the signer specifies the covered RPKI resources relevant to the signature, the RPKI certificate covering the inetnum: object's address range is included in the [RFC5652] CMS SignedData    certificates field.” I was expecting the end-entity certificate to encode “192.0.2.0/24” in the sbgp-ipAddrBlock field.  The CA certificate has this IP block, but the end-entity certificate decodes the sbgp-ipAddBlock field to “IPv4: inherit IPv6: inherit”.  Is that expected -- to have both an ipv4 and ipv6 annotation (since the previous certificate in the chain only mentioned IPv4), and not explicitly repeat the IPv4 value?

** Editorial

-- Abstract.  Typo. s/Intrastructure/Infrastructure/

-- Section 1.  Editorial. Per “An optional, utterly awesome but slightly complex means …”, what does the colloquial “utterly awesome” add?

-- Section 2.  Editorial.
  This document also suggests optional signature, which authenticates
  the data when present, for geofeed files to provide stronger
  authenticity to the data.

Saying “authenticates” and “authenticity” in the same sentence made it difficult parse.  Likewise,  s/suggests optional signatures/suggests an optional signature/.  Perhaps:
NEW
This document also suggests an optional signature to strongly authenticate the data in the geofeed files.

-- Section 3. Typo. s/contol/control/

-- Section 3.  Typo. s/survery/survey/

-- Section 5.  Editorial.  Consider not using “fetching with tweezers” for additional clarity.

[Ballot comment]
"Ideally, RPSL would be augmented to define a new RPSL geofeed:
  attribute in the inetnum: class.  Until such time, this document
  defines the syntax of a Geofeed remarks: attribute which contains an
  HTTPS URL of a geofeed file."

If the ideal solution is to produce a standards track document that creates a new RPSL attribute, I don't understand why the Working Group didn't simply do that, instead of messing with the remarks and then coming up with a transition plan for moving from this design to the future one.

[Ballot comment]
Section 4, paragraph 4, comment:
>    sequence.  Other nonprintable characters, such as backspace,
>    are not expected.  For robustness, any nonprintable characters MUST

"are not expected" - but what if they are *encountered*?

Section 5, paragraph 3, comment:
>    The geofeed files SHOULD be published over and fetched using https
>    [RFC8446].

Section 2 has a "MUST" for https, so this could become a MUST as well?

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 1, paragraph 5, nit:
-    An optional, utterly awesome but slightly complex, means for
-                                                    -
+    An optional, utterly awesome but slightly complex means for

Section 2, paragraph 2, nit:
-    geographic locale(s).
-                    - -
+    geographic locales.

Section 2, paragraph 3, nit:
-    Section 3 this document specifies how to find the relevant [RFC8805]
-    geofeed file given an IP address.
+    Section 3, this document specifies how to find the relevant [RFC8805]
+            +
+    geofeed file, given an IP address.
+                +

Section 2, paragraph 5, nit:
-    Geofeed data do have privacy considerations, see Section 6
+    Geofeed data do have privacy considerations, see Section 6.
+                                                              +

Section 2, paragraph 6, nit:
-    This document also suggests optional signature, which authenticates
-                                                                      -
+    This document also suggests optional signatures, which authenticate
+                                                  +

Section 3, paragraph 3, nit:
-    defines the syntax of a Geofeed remarks: attribute which contains an
-                            ^                          ^ ^^^
+    defines the syntax of a geofeed remarks: attribute that contains an
+                            ^                          ^ ^^

Section 3, paragraph 7, nit:
-    The URL's use of the web PKI can not provide authentication of IP
-                                    -
+    The URL's use of the web PKI cannot provide authentication of IP

Section 3, paragraph 8, nit:
-    Until all producers of inetnum:s, i.e. the RIRs, state that they have
-    migrated to supporting a geofeed: attribute, consumers looking at
-                          --
+    Until all producers of inetnum:s, i.e., the RIRs, state that they have
+                                          +
+    migrated to supporting geofeed: attributes, consumers looking at
+                                            +

Section 3, paragraph 8, nit:
-    migrated any inetnum:s from remarks: use to geofeed:s.
-                                        ----
+    migrated any inetnum:s from remarks: to geofeed:s.

Section 3, paragraph 9, nit:
-    Any particular inetnum: object MUST have at most, one geofeed
-                                                    -
-    reference, whether a remarks: or a proper geofeed: attribute when it
-    is implemented.  If there is more than one, all are ignored.
-                              ^^                    ^^
+    Any particular inetnum: object MUST have at most one geofeed
+    reference, whether a remarks: or a proper geofeed: attribute, when it
+                                                                +
+    is implemented.  If there are more than one, all MUST be ignored.
+                              ^^^                    ^^^^^^

Section 3, paragraph 11, nit:
-    As inetnum: objects form a hierarchy, Geofeed references SHOULD be at
-                                          ^
+    As inetnum: objects form a hierarchy, geofeed references SHOULD be at
+                                          ^

Section 3, paragraph 12, nit:
-    which have identical address ranges, then the geofeed reference on
-    ^ ^^^
+    that have identical address ranges, then the geofeed reference on
+    ^ ^^

Section 3, paragraph 13, nit:
-    the inetnum: which refers to them.  I.e. an INETNUM object for a
-                                        ^^ ^    ^^^^^^^
+    the inetnum: which refers to them.  For example, an inetnum object for a
+                                        ^^^^ ^^^^^^^    ^^^^^^^

Section 3, paragraph 14, nit:
-    as the other registries; therefore, when fetching from ARIN via FTP
+    as for the other registries; therefore, when fetching from ARIN via FTP
+      ++++

Section 4, paragraph 2, nit:
-    The question arises of whether a particular [RFC8805] geofeed data
-                      ---
-    set is valid, i.e. authorized by the 'owner' of the IP address space
-    and is authoritative in some sense.  The inetnum: which points to the
-                                                      ^ ^^^
-    [RFC8805] geofeed file provides some assurance.  Unfortunately the
+    The question arises whether a particular [RFC8805] geofeed data
+    set is valid, i.e., is authorized by the 'owner' of the IP address space
+                      ++++
+    and is authoritative in some sense.  The inetnum: that points to the
+                                                      ^ ^^
+    [RFC8805] geofeed file provides some assurance.  Unfortunately, the
+                                                                  +

Section 4, paragraph 6, nit:
-    identical to or a subset of A.  'Address range' is used here because
+    identical to or a subset of A.  'Address range' is used here, because
+                                                                +

Section 4, paragraph 9, nit:
-    sign the CMS blob is left as an exercise for the implementor.  On the
+    sign the CMS blob, is left as an exercise for the implementor.  On the
+                    +

Section 5, paragraph 2, nit:
-    inetnum: objects.  They also provide means of [sub-]assigning IP
-                                                  ^    ^
+    inetnum: objects.  They also provide means of (sub-)assigning IP
+                                                  ^    ^

Section 5, paragraph 3, nit:
-    The geofeed files SHOULD be published over and fetched using https
-                                          - ^^
+    The geofeed files SHOULD be published via and fetched using https
+                                          ^^

Section 5, paragraph 7, nit:
-    users without such authorization the same result can be achieved with
+    users without such authorization, the same result can be achieved with
+                                    +

Section 5, paragraph 8, nit:
-    frequent real-time look-ups to prevent load on RPSL and geofeed
+    frequent real-time look-ups, to prevent load on RPSL and geofeed
+                              +

Section 6, paragraph 2, nit:
-    described in this document the operator should be aware of this
+    described in this document, the operator should be aware of this
+                              +

Section 3, paragraph 3, nit:
> , where the token "Geofeed" is case sensitive, followed by a URL which will
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 3, paragraph 9, nit:
>  one geofeed reference, whether a remarks: or a proper geofeed: attribute, w
>                                ^^^^^^^^^
The plural noun "remarks" cannot be used with the article "a". Did you mean "a
remark" or "remarks"?

Section 3, paragraph 13, nit:
> as been sub- divided into one or more longer prefixes. Currently, the regist
>                                  ^^^^^^^^^^^
Use only "longer" (without 'more') when you use the comparative.

Section 4, paragraph 2, nit:
>  An approach where RPSL was signed a la [RFC7909] would be good, except it w
>                                    ^^^^
'a la' is an imported foreign expression, which originally has a diacritic.
Consider using "à la"

"S", paragraph 1, nit:
> geofeed file, one MUST ignore data outside of the referring inetnum: object's
>                                    ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 7, paragraph 2, nit:
> urces to cross-validate the data. All of the Security Considerations of [RFC
>                                  ^^^^^^^^^^
Consider using "all the".

Section 9, paragraph 2, nit:
> ded running code, and Kevin Pack. Also to geolocation providers that are con
>                                  ^^^^
Did you forget a comma after a conjunctive/linking adverb?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-opsawg-finding-geofeeds-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

a new registration is to be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-ct-geofeedCSVwithCRLF
Reference: [ RFC-to-be ]

IANA notes that the authors have requested value 47 for this registration. This registration is complete and IANA will change the reference to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-05-04):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-finding-geofeeds@ietf.org, ggm@algebras.org, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Finding and Using Geofeed Data) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Finding and
Using Geofeed Data'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-05-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes how to find and authenticate geofeed data.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5485: Digital Signatures on Internet-Draft Documents (Informational - Internet Engineering Task Force (IETF))
    rfc8805: A Format for Self-Published IP Geolocation Feeds (Informational - Independent Submission)

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

The document references https://github.com/massimocandela/geofeed-finder
which is a working implementation of reading the field from sources,
written by the authors.


    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 ggm@apnic.net

    Who is the Responsible Area Director?

The responsible Area Director is Robert Wilton

    (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, all but 2 were 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
        and the Internet-Drafts Checklist). Boilerplate checks are
        not enough; this check needs to be thorough.

The document refers to IPv6 and is clear that all usage of IPv4 implies IPv6
in the noted inetnum and inet6num objects. However, idnits did identify there
are no worked examples in IPv6.

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

- Downref: Normative reference to an Informational RFC: RFC 5485
- Downref: Normative reference to an Informational RFC: RFC 8805

These normative references to informative documents have been discussed with the Authors.
I believe they will be difficult to resolve, and may mean the document sits in "proposed standard"
pending completion of standards-track completion for these information references, or suitable
alternatives.

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

The document references https://github.com/massimocandela/geofeed-finder
which is a working implementation of reading the field from sources,
written by the authors.


    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 ggm@apnic.net

    Who is the Responsible Area Director?

The responsible Area Director is Robert Wilton

    (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, all but 2 were 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
        and the Internet-Drafts Checklist). Boilerplate checks are
        not enough; this check needs to be thorough.

The document refers to IPv6 and is clear that all usage of IPv4 implies IPv6
in the noted inetnum and inet6num objects. However, idnits did identify there
are no worked examples in IPv6.

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

- Downref: Normative reference to an Informational RFC: RFC 5485
- Downref: Normative reference to an Informational RFC: RFC 8805

These normative references to informative documents have been discussed with the Authors.
I believe they will be difficult to resolve, and may mean the document sits in "proposed standard"
pending completion of standards-track completion for these information references, or suitable
alternatives.

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

The document references https://github.com/massimocandela/geofeed-finder
which is a working implementation of reading the field from sources,
written by the authors.


    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 ggm@apnic.net

    Who is the Responsible Area Director?

The responsible Area Director is Robert WiltonÂ

    (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, all but 2 were 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
        and the Internet-Drafts Checklist). Boilerplate checks are
        not enough; this check needs to be thorough.

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

- Downref: Normative reference to an Informational RFC: RFC 5485
- Downref: Normative reference to an Informational RFC: RFC 8805

These normative references to informative documents have been discussed with the Authors. I believe they will be difficult to resolve, and may mean the document sits in "proposed standard" pending completion of standards-track completion for these information references, or suitable alternatives.

    (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
        ()
        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 ggm@apnic.net

    Who is the Responsible Area Director?

The responsible Area Director is Robert WiltonÂ

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