Terry Manderson has entered the following ballot position for draft-ietf-sidr-rfc6485bis-04: Discuss
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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm not so sure that this will be an easy DISCUSS to work through as I view this in light of future sustainability/deployability of RPKI and any protocol wedded to it (eg BGPSEC). Section 5 "Additional Requirements" suggests that both CAs and RPs "SHOULD" be capable of supporting a transition and thus able to support multiple RPKI alg. and key profiles. To me this "SHOULD" seems like it invites fragility in any such transition. An immediate example would be the root DNSSEC ksk rollover. An rather large amount of work is underway to ascertain the impact. By leaving the SHOULDs in place is this walking the same path? Let me ask another way. Under what situations is it actually appropriate for a CA or RP to be able to ignore the requirement of being able to support a phased introduction/deprecation of new/different RPKI algorithm and key profiles? And if they ignore such a recommendation does this make the entire RPKI infrastructure a fractured PKI by algorithm? _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr