Stephen Farrell has entered the following ballot position for draft-ietf-sidr-bgpsec-ops-13: 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/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-bgpsec-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I reviewed -12 but I think all these comments are as (ir)relevant as ever;-) - general: given where we are with deployment I wonder would it be a good idea if this document explicitly said sometthing to the effect that "it's early days, this is what we think is the BCP but that may change over time, so while we think doing this is right, be careful to not paint yourself into a corner when doing this." - intro: this seems to say: first do rpki and only when that's finished start on bgpsec - is that really what's meant? The rest of the document makes me doubt that. I think what you maybe meant was "Any specific ASN needs to have setup RPKI for itself before it can speak BGPsec." - intro, 3rd para: where are the "special operational considerations" explained? A reference would be good. If there's no good reference, I'm not clear why saying this is useful. (Actual operators might find this clear of course, in which case, please ignore me.) - section 2: this refers to the BGPsec overview which refers back to this document, but says that this is informational rather than a BCP. Just noting that in case there's confusion and that's not just a typo or a case of the overview not having been updated. I expect the fix is to change the text in the overview. - section 5: What does "fully BGPSEC enabled" mean exactly? That could be referring to signing or to validation of signatures (with or without hard fails) or to never emitting unsigned or accepting unsigned announcements or to some combination of the above. It might be better to avoid use of such a term in order to avoid having to define it for now. (This relates also to the mail subsequent to Mirja's comments.) - section 7: MED could do with expansion and a reference. - section 7: I'm not clear what you mean by "RPKI version skew." You could explain that or maybe use another basis to explain why R0 and R1 might disagree, e.g. revocation status info availability or freshness maybe. - section 8: "forward signed to R" is a bit opaque (for me anyway, before I read the protocol draft). Maybe better to explain this a bit more. - I-D nits complains about some easily fixable things (about which I do not care:-) _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
