> This document creates an IANA registry for the "BGP origin validation > state".
which is highly inappropriate, as the three and only three states are cast in stone. this should be removed if we're going to progress the document. > 2) Documenting change on BGP decision process changes: Section 3. > Basically the origin validation happens before any other policy > applied. This goes beyond the iBGP community but even for stand-alone > routers. In this sense, you can implement RPKI in a device without > modifying any existing policy description. and this was codified in rfc 6811. now you get to compare the two, because any inconsistency would be bad. > 3) Documentation of non-standard BGP communities: Over the years, we > have seen a number of attempts to document and standardise providers > communities with less than great results. One particularly use case > (that I suffered) is when you have to merge two networks due to an > acquisition, standardised communities are very helpful. last para of rfc 7115 sec 5 Validity state signaling SHOULD NOT be accepted from a neighbor AS. The validity state of a received announcement has only local scope due to issues such as scope of trust, RPKI synchrony, and management of local trust anchors [LTA-USE]. > And lets not forget: Running Code: Last but not least…the draft has > been delayed more than what it should and several implementations > (including two from Cisco) has running code + documentation + > training. As we are pushing to improve adoption of RPKI, I rather > spend time adding the missing pieces that removing what is not > broken…although the need may not be obvious for everyone. actually, code removal is not an evil, quite the opposite. but, as i said > i do not support publication. i am not strongly opposed. it's just > one more bit of ietf work that is not obviously needed. randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
