Murray Kucherawy has entered the following ballot position for draft-ietf-opsawg-9092-update-10: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
