Hi, I am still working on an update to the document.
It's encouraging to hear that another group is looking at maintaining RPSTIR. When I discussed the 6 months with Rob we felt that this should be doable (he can correct me if I am wrong). In our case we have had a working implementation of the algorithm for quite some time, and those changes by themselves are not hard. With the new OIDs we do need to change some things around - making this dependent on OIDs rather than a local configuration setting, but it's not a big deal. I think it's reasonable that the ability to update implementations from both RP implementations and CA implementations should factor in to a mandatory to implement time frame for RPs, and later CAs. But I also believe that we should be somewhat ambitious, especially w.r.t. RPs because their implementation is on the critical path. CAs can only start to publish when RPs support this. Regards Tim > On 08 Aug 2016, at 16:54, Declan Ma <[email protected]> wrote: > > Folks, > > I recall Tim has suggested a schedule for transition to the new validation > algorithm during Berlin meeting. His proposal is to mandate RP support for > the new all 6 months after the doc is published as an RFC. > > My team is now responsible for RPSTIR update. > > I am afraid that the proposal is sorta aggressive. IMHO, six-months after > publication of the RFC may be too soon. Although this WG has been through > discussions of the validation-reconsidered, but the conclusion was just > reached. > > This is really a fundamental change to both RP and CA, I anticipate we need > more time to have RP software code changed and thoroughly tested, to > accommodate the new validation procedures. > > Anyway, we are evaluating the time frame,trying to give absolute dates as > soon as possible. > > > BTW, OID issue has not been yet with IANA feedbacks. We can’t be sure how > long it will take to go through the IESG approval process, incurring > uncertainty. I am not reassured whether it is prudent to get started with > RPSTIR update right away. > > I am therefore looking forwards to seeing more discussions and comments in > this thread, especially from other RPKI implementers. > > > Di > > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
