Hi Linda, We took this to the WG because we wanted a few things out of it: 1) get feedback and ensure that the algorithm used by our validator is correct (even if it is not the only way to do this) 2) provide transparency to our users 3) provide a reference that other Relying Party implementers might find useful
I believe that these goals were achieved. We received valuable feedback from the WG and had good discussions with other implementers. Note that I say ‘we’ because I was involved in this while working at the RIPE NCC. By now I have a new position, and as such I don’t mind removing myself from the author list possibly in favour of someone who is going to be involved in the future of this particular implementation. Personally really I don’t mind very much whether this document becomes an RFC or not, it already served its main purposes #1 and #2, but it seems a relatively small remaining step to do and ensure #3 -> i.e. have a description of one implementation that others may find useful. Having it as an RFC rather than an expired draft, bundled with the software, will make it easier to find and it shows that others reviewed the document for clarity and correctness. That said, it takes a lot of work and process from us, and everyone else. And by definition this is a moving target. The implementation will change (in fact v3 is just (about to be) released), and then the RFC is outdated. So, I will not opt for this full (informational) RFC path again for future implementations I am involved in. It would be nice if there were a more light-weight document track that could be used for this though! We really benefitted from the feedback and users have said that they like the transparency. Kind regards, Tim Bruijnzeels > On 3 Aug 2018, at 22:11, Linda Dunbar <[email protected]> wrote: > > Reviewer: Linda Dunbar > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-sidrops-rpki-tree-validation-02 > Reviewer: Linda Dunbar > Review Date: 2018-08-03 > IETF LC End Date: 2018-08-10 > IESG Telechat date: Not scheduled for a telechat > > Summary: > This draft describes one sample implementation of validating the content of > RPKI certificate Tree. The description is clear, especially clearly described > which section of RFC6487 are based for its implementation. > > Major issues: > None. > > Minor issues: > None. > > Nits/editorial comments: > Section 9.1. the Hash Collisions is more of design in-complete instead of > "Security Considerations". So is the section 9.2 In addition, why the > implementation description has to be an RFC? clog up the RFCs > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
