[RPKI] deep dive on manifest handling (Was: APNIC had an unexpected drop in VRP 00:00 - 02:00)

[Tony Tauber]

Hi Tim,

Regarding:

> I would like to add that on the one hand it's probably good that this
> happened while the -bis is still in *draft*, because it gives us all an
> opportunity to remove ambiguity before its publication as an RFC. On the
> other hand, this is what you get when implementers are requested to make
> changes based on drafts.
>

We will look forward to seeing the fixed code and getting the document
clarified as a positive byproduct of this experience.

Thanks for being so responsive.

Tony

On Thu, Dec 3, 2020 at 4:24 AM Tim Bruijnzeels <tim at nlnetlabs.nl> wrote:

> Hi,
>
> > On 2 Dec 2020, at 22:33, Job Snijders via RPKI <rpki at lists.nlnetlabs.nl>
> wrote:
> >
> > I propose some of us continue discussion at sidrops at ietf.org where
> > through wordsmithing in the draft-ietf-sidrops-6486bis effort so we help
> > any future RPKI implementers from walking into the same problem.
>
> Indeed.
>
> We are perfectly fine with changing routinator's behaviour. The current
> implementation reflects our interpretation of the draft text, and recent
> sidrops discussions (e.g. it seems that over-claiming CA certificates
> should lead to a publication point being considered entirely invalid). So,
> there is ambiguity in the bis draft that needs to be addressed.
>
> I would like to add that on the one hand it's probably good that this
> happened while the -bis is still in *draft*, because it gives us all an
> opportunity to remove ambiguity before its publication as an RFC. On the
> other hand, this is what you get when implementers are requested to make
> changes based on drafts.
>
> Tim
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/rpki/attachments/20201203/f7bbcf04/attachment.htm>