Re: [Sidrops] Genart last call review of draft-ietf-sidrops-rpki-tree-validation-02

[Warren Kumari <[e-mail]>]

On Mon, Aug 6, 2018 at 4:17 AM Tim Bruijnzeels <[e-mail]> wrote:
>
> 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.

This is listed as an Informational document - from RFC2026, Section 4.2.2:
   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3).

I believe that having this sort of document, which describes how an
implementation is, er, implemented is useful to the community - we
have many "theoretical" type document, having more "and this is how it
actually got implemented / works" seems well within the Informational
series, and Ops Area mandate.

W


> 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 <[e-mail]> 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
> >
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf