Re: [Sidrops] 6486bis: referenced object validation

[Tim Bruijnzeels <[e-mail]>]

Hi Job, all,

> On 4 Dec 2020, at 15:37, Job Snijders <[e-mail]> wrote:
> 
> On Fri, Dec 04, 2020 at 02:13:40PM +0100, Benno Overeinder wrote:
>> Not looking back, but looking ahead, I want to focus on how we solve
>> issues and discuss them in sidrops.  And indeed, if there is an
>> impasse, organise a virtual meeting and discuss the matter to make
>> progress.
> 
> Yes, I took it as a sign of convergent thinking. Progress indeed.
> 
> However, my question remains, looking forward, what can be done
> differently in the future?
> 
> Some suggestions from my side:

Thank you for taking the time to suggest ways to improve!

We can continue this discussion here, or perhaps even have a separate thread on this. I don't really mind either way. I am just happy with this effort.

>    - SIDROPS must require multiple implementations before sending an
>      Internet-Draft towards the IESG. To meet this requirement,
>      Implementers should write an implementation report and share it
>      with the group, at least detailing the behavior for each normative
>      term.

works for me

>    - Please listen to operators who report (hard to troubleshoot, hard
>      to explain) network outages which resulted from RPKI processing.
>      RPKI ROV is supposed to be an incrementally deployable 'fail open'
>      mechanism.

Yes, of course.

Also listen to software implementers, and RPKI infrastructure (CA/repo) operators, or anyone who speaks up here. People who do, do so because they all believe strongly in making things better. So, respect each other and trust people's motives. When there is pushback perceived, then this is most likely because the other party is trying to make a point, and not necessarily because they don't acknowledge your issue.

And before I offend anyone with this.. we all suffer from cognitive bias in how we read what the other people wrote, and might have thought, or not said, etc. So, really I mean this as a constructive thought. 1-on-1 emails may also help to get some clarity - now that we do not get to meet anyone in person, before mis communications get out of hand.


>    - Implementers should more often share/construct the actual X.509
>      files rather than attempting to document the hypothetical states
>      of the RPKI in natural language (avoid English or Dutch). We can
>      all load X.509 files into our implementations, set currenttime to
>      the test case at hand, and discuss results.

There has been talk of an effort in the dark past, which was abandoned. But in short, yes, I think it would be great if we had a way to achieve this.

>    - Implementers should feel empowered to make improvements to their
>      software (for the benefit of their users), especially if there is
>      perceived ambiguity in RFC texts. An implementer doesn't need the
>      blessing of the whole IETF before making a change.
> 
>    - Sometimes RFCs are wrong, or worse: the then-WG kicked the ball
>      down the road and state 'up to the implementer' (aka 'local
>      policy'); in which case the implementer will have to weigh the
>      advantages of perceived 'RFC compliance' vs the effects of the
>      behavior in the BGP Default-Free Zone. See the previous point.
> 
>    - The RPKI is a system that has been deployed on the Internet, this
>      sometimes means operators need to quickly deploy fixes to address
>      ongoing issues. Time is of the essence when it comes to security
>      or reliability issues. So 'code first, RFC later', which goes well
>      with point 1: 'implementations first, then publish RFC'.

On the above three points. Generally speaking plausible, and agreed. However, it's not always easy to achieve.

On 6486 in particular there was a strong desire communicated by operators that RPs behave the *same* way. Which is why we were hesitant to implement the changes suggested by you in the GH issue. In fact we even agree with the approach in the issue. But it's different from where the -bis text is headed until now. We felt that the desire for universal behaviour (-bis) outweighed the rush to make a quick change here. You are welcome to disagree with that assessment, but understand that there was well intended reasoning behind it.

> You mentioned some kind of testbed, indeed it would be wonderful if we
> can easily reproduce states of the RPKI and allow implementers to
> provide annotations on why software (versions) behaves in a certain
> way. The December 1st, 2020 case is definitely one I'd add to the
> testbed archive.

It would be. I think this is an effort in itself. Do you have a proposal in mind?

> 
>>> The real goal is to keep the network running, where in this context
>>> our role is to create software for network operators for them to
>>> securely validate the wishes of the Internet number resource
>>> holders.
>> 
>> Agree to that!
>> 
>> Let's keep the good spirit of collaboration and learning together.
> 
> For sure!


For sure!

Tim

> 
> Kind regards,
> 
> Job