Hi all, > On 26 Oct 2016, at 17:35, Christopher Morrow <morrowc.li...@gmail.com> wrote: > > which leaves to be dealt with by Chicago 2 documents: > draft-ietf-sidr-rpki-tree-validation
You may have just seen the -03 version posted. This version now includes a scope section to make it clear that: This document describes how the RIPE NCC RPKI Validator version 2.23 has been implemented. Source code to this software can be found here: [github]. The purpose of this document is to provide transparency to users of (and contributors to) this software tool, as well as serve to be subjected to scrutiny by the SIDR Working Group. It is not intended as a document that describes a standard or best practices on how validation should be done in general. The full name of the document "RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator" was always clear on the scope. And we mentioned it at various occasions. The short name "RPKI Tree Validation" may be somewhat confusing - we are open to suggestions btw.. plus, if the IETF (SIDR-OPS most likely) wants to take on the work of making a general validation document, we would be happy to contribute to it in separate document. We really value the feedback that we got from the working on this document. Although not all feedback is reflected in the current implementation (and therefore in the main body of the document) - we have included these discussions in the Security Considerations section. We believe that none of these issues qualify as showstoppers to the software described at this time, but we may well address them in future releases. There was some discussion at the last IETF about how to deal with a document like this. It describes a moving target. Our implementation is subject to change after all. We prefer to tackle it by going for last call on this document describing version 2.23 as soon as is allowed by IETF, in the SIDR WG. As far as we are concerned this is done. Of course if there is any remaining unclarity we will address. If and when future releases of our software include significant changes in the validation algorithm, we plan to document transparently. Pragmatically speaking we believe that minor things can be documented in the README of future releases (.. works like RFC-### with these exceptions). For bigger changes however, or whenever our code stabilises again, we would probably seek to either update the existing document, or create a new document. We would prefer to run any such work through SIDR-OPS once established, but individual submission is also an option. In the end what matters to us most is that we have a clear description of how the code works, and provide full transparency on considerations. Kind regards Tim & Oleg _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
