Skip to main content

Finding and Using Geofeed Data
draft-ietf-opsawg-9092-update-11

Yes

(Robert Wilton)

No Objection

Jim Guichard
(Andrew Alston)

Recuse


Note: This ballot was opened for revision 09 and is now closed.

Erik Kline
Yes
Comment (2024-02-10 for -10) Sent
# Internet AD comments for draft-ietf-opsawg-9092-update-10
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S5

* "... processing is too hard."

  Perhaps there's a better wording that might be found here.  "imposes
  significant computational complexity" or something?
John Scudder
Yes
Comment (2024-02-13 for -10) Sent
Thanks for this document. I confined myself to reviewing the diff versus RFC 9092. I have just one minor question and an even-more-minor nit.

The question:

In RFC 9092 you have,

   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.

In this document, you have liberalized from "all are ignored" and now allow them to coexist:

   Any particular inetnum: object SHOULD have, at most, one geofeed
   reference, whether a remarks: or a proper geofeed: attribute when it
   is implemented.  A geofeed: attribute is preferred, of course, if the
   RIR supports it.  If there is more than one type of attribute in the
   intetnum: object, the geofeed: attribute SHOULD be used.
   
As far as I'm concerned, this is just fine and indeed an improvement, who doesn't like coexistence after all? But I wonder what changed that made it OK? (I think we might have debated this a bit when 9092 was approved, but I'm too lazy to go back and check...)

The nit:

192.0.2.0/12 (in Section 3) isn’t what I consider a well-formed prefix, since the third octet has a set bit but isn’t under the mask. I would’ve said 192.0.0.0/12. (Or better still 192.0/12, but that form seems to be disfavored.)
Jim Guichard
No Objection
Murray Kucherawy
No Objection
Comment (2024-02-15 for -10) Sent
All of the SHOULDs in Section 3 seemed to lack some prose about why one might legitimately deviate from the advice presented.  Absent that, I'm wondering why they aren't all MUSTs.

===

Feedback from Orie Steele, incoming ART AD:

"An optional utterly awesome but slightly complex means for authenticating geofeed data is also defined in ..."

Not sure how I feel about that many modifiers in front of security topics, such as "authenticating".

Thanks for the ARTART review, given the emphasis on UTF-8, it would be nice to see samples that include international names, and characters.

"This SHOULD NOT be used for bulk retrieval of geofeed data."

Under what circumstances SHOULD it be used for bulk retrieval?

In Section 5:

"It is a digest of the main body of the file signed by the private key of the relevant RPKI certificate for a covering address range."

I think you mean digest of the canonicalized UTF-8 bytes produced according to the procedure that follows.

"For robustness, any non-printable characters MUST NOT be changed by canonicalization."

This seems risky, is there a common understanding of non printable characters?

"Any end-of-file marker used by an operating system is not considered to be part of the file content. When present, such end-of-file markers MUST NOT be covered by the digital signature."

This mounts to a deny list, that is not specified... seems risky.

I suspect many signatures might fail to validate due to differences in the canonicalization implementations, it would be good to provide a complete set of test vectors for this approach.
Paul Wouters
(was Discuss) No Objection
Comment (2024-02-22) Sent
Thanks for the discussion on the items raised. I've updated my ballot to No Objection (I did not ballot 'Yes' because I did not find all my raised points addressed, but these issues did not raise to the level requiring further discussion)
Roman Danyliw
No Objection
Comment (2024-02-14 for -10) Sent
Thank you to Tim Hollebeek for the SECDIR review.

** Section 3. Editorial.  Consider this clarification.
OLD
   At the time of publishing this document, change control effectively
   lies in the operator community.

NEW
At the time of publishing this document, change control of RPSL effectively lies in the operator community.

** Section 3.

   Any particular inetnum: object SHOULD have, at most, one geofeed
   reference, whether a remarks: or a proper geofeed: attribute when it
   is implemented.  A geofeed: attribute is preferred, of course, if the
   RIR supports it.  If there is more than one type of attribute in the
   intetnum: object, the geofeed: attribute SHOULD be used.

Is there a reason that the second SHOULD, to prefer the geofeed: attribute isn’t a MUST?  Otherwise, there isn’t deterministic behavior on which attribute will be used and geofeed: won’t necessarily be preferred.

** Section 3
   For inetnum:s covering the same address range, or an inetnum: with
   both remarks: and geofeed: attributes, a signed geofeed file SHOULD
   be preferred over an unsigned file.

Is the net result of this guidance that when encountering a both types of attributes, and despite preferring the geofeed, an implementation still needs to download both and see which one is signed?  Effectively: 

If there is more than one type of attribute in the intetnum: object, the geofeed: attribute SHOULD be used unless the remarks: is signed?

** Section 4.

   To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's FTP
   [RFC0959] services SHOULD be used for large-scale access to gather
   inetnum:s with geofeed references.  This uses efficient bulk access
   instead of fetching via brute-force search through the IP space.

This guidance was in RFC9092 (July 2021).  Has anything changed in the ecosystem that would allow the use of at least SFTP?
Zaheduzzaman Sarker
No Objection
Comment (2024-02-13 for -10) Not sent
Thanks for working on this specification. 

I support Paul's discuss on the point of securing FTP.
Éric Vyncke
No Objection
Comment (2024-02-13 for -10) Sent for earlier
# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-9092-update-10

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Michael Richardson for the shepherd's detailed write-up including the WG consensus *BUT* it lacks the justification of the intended status.

Other thanks to Sheng Jiang, the Last Call Internet directorate reviewer:
https://datatracker.ietf.org/doc/review-ietf-opsawg-9092-update-06-intdir-lc-jiang-2023-11-20/ (and I have seen interactions with the draft authors)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## No IPv6 Examples

I can only strongly regret, esp knowing the authors, that the examples are IPv4 only.

Note: this issue prevents me to strongly support this document with a YES ballot.

## Section 3

Should the text be more normative rather than plain text 
```
The migration not only implies that the RIRs support the geofeed:	
attribute, but that all registrants have migrated any inetnum:	
ojects from remarks: to geofeed: attributes
```
Warren Kumari
Recuse
Comment (2024-02-05 for -10) Not sent
immanorther...
Robert Wilton Former IESG member
Yes
Yes (for -09) Unknown

                            
Andrew Alston Former IESG member
No Objection
No Objection (for -10) Not sent