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

From: Randy Bush <[email-masked]>
Date: Sat, 04 Aug 2018 10:06:14 -0700

> why the implementation description has to be an RFC? clog up the RFCs

because this is engineering, not academic research; no requirement for
original contribution.  having the workings of a protocol implementation
well documented helps others interoperate, gives them ideas for their
own implementations, ...  we have a long trail of vendorX's
implementation of coffee ice cream.  it is helpful.

< insert snark comparison to 342 'bright ideas' about how to get one's
  name on an rfc for useless work >

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 6 Aug 2018 10:17:12 +0200

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-masked]> 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
>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 6 Aug 2018 10:19:09 -0400

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

-- 
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

---

From: Rob Austein <[email-masked]>
Date: Tue, 07 Aug 2018 14:25:46 -0400

Speaking as another person implementing these protocols: I found this
document useful as a checklist of issues to think about, along with
commentary on how one implementation handled them.  As it happened, I
ended up doing most things slightly differently (Tim and I were each
on at least our third implementations by this point, and had talked
about a lot of it as we went along), but I still found it useful.

I suspect that a new implementor coming in cold would also find this
valuable, for more obvious reasons.

If this isn't enough to make a draft worthy of publication anymore,
push the IETF over and bury it, we're done.

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 03 Aug 2018 13:11:18 -0700

Reviewer: Linda Dunbar
Review result: Ready

Summary:

Major issues:
None.

Minor issues:
None.

Nits/editorial comments: