> You can't invest in the deployment of some types of requirements > (liability, costs) until the need is certain, i.e. post approval.
so we have noticed :( > Can you explain the concerns with having a longer time period in the > document? as we deploy, if we find a serious ops problem that means a change to the cp, it would be good to have it fixed very quickly. then again, it's the running code that really needs to be fixed. otoh, as the cp carries a legal liability tie-in, i can see that the rpki provider wants a long window in which both old and new requirement sets are valid. > Use case: > > 1) New CP comes out and specifies minimum standards in the area of > Facility, Management, And Operational Controls (rather the delegation > of such to the CPS) > > 2) Existing RPKI service providers need to assess this and decide > implications therein > > 3) If existing RPKI providers can't/won't meet the requirements, and > exit the business, they want to do so within 1 month due to 9.12.2 (to > prevent having non-CP compliant certs out there) > > You've got the time left over, after the RPKI service provider exits > the field, to scramble with the grandparent to select new service > providers... if someone mid-chain turns off, certs/roas below will no longer validate. so swinging from the grandparent must be make before break. > Hence, my suggestion that 30 days notice is rather short. i have no strong disagreement with a wider window. i remain confused by your characterization of the need. randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
