On Mon, May 09, 2022 at 05:08:53PM +0200, Theo Buehler wrote:
> On Mon, May 09, 2022 at 02:59:06PM +0200, Claudio Jeker wrote:
> > On Mon, May 09, 2022 at 12:53:05PM +0200, Theo Buehler wrote:
> > > Regarding the spec:
> > >
> > > * isn't it a bit unfortunate that the ResourceBlock contains an
>
On Mon, May 09, 2022 at 01:07:17PM +, Job Snijders wrote:
> On Mon, May 09, 2022 at 12:11:22PM +0200, Claudio Jeker wrote:
> > why does the draft allow for optional filenames? What the heck is the
> > digest then covering some random gunk?
>
> Yes, that is entirely possible. Some folks in the
On Mon, May 09, 2022 at 02:59:06PM +0200, Claudio Jeker wrote:
> On Mon, May 09, 2022 at 12:53:05PM +0200, Theo Buehler wrote:
> > Regarding the spec:
> >
> > * isn't it a bit unfortunate that the ResourceBlock contains an ipAddrBlocks
> > member which isn't an IPAddrBlocks as in RFC 3779 but ra
On Mon, May 09, 2022 at 01:07:17PM +, Job Snijders wrote:
> On Mon, May 09, 2022 at 12:11:22PM +0200, Claudio Jeker wrote:
> > why does the draft allow for optional filenames? What the heck is the
> > digest then covering some random gunk?
>
> Yes, that is entirely possible. Some folks in the
On Mon, May 09, 2022 at 12:11:22PM +0200, Claudio Jeker wrote:
> why does the draft allow for optional filenames? What the heck is the
> digest then covering some random gunk?
Yes, that is entirely possible. Some folks in the working group
requested the filename to be optional, I abided. In inter-
On Mon, May 09, 2022 at 12:53:05PM +0200, Theo Buehler wrote:
> > As the various same-named-but-different 'parse' structs are not easily
> > interchangeable without more refactoring, I marked them "XXX:". Perhaps
> > we can work on that in tree?
>
> I'm fine with fixing that in-tree. Sorry about t
> As the various same-named-but-different 'parse' structs are not easily
> interchangeable without more refactoring, I marked them "XXX:". Perhaps
> we can work on that in tree?
I'm fine with fixing that in-tree. Sorry about this mistake, I made it
many times. I wish the various 'struct parse' wer
On Sun, May 08, 2022 at 08:05:08PM +, Job Snijders wrote:
> Dear Theo, fellow developers,
>
> Many thanks for the first review pass, much appreciated.
>
> > This is a good first step. I have a few initial comments inline. Once you
> > fix
> > those, review of the rest will be easier.
> >
>
Dear Theo, fellow developers,
Many thanks for the first review pass, much appreciated.
> This is a good first step. I have a few initial comments inline. Once you fix
> those, review of the rest will be easier.
>
> The main thing is: please remove all the copy-pasted functions that had no
> chan
On Sun, May 08, 2022 at 04:18:13PM +, Job Snijders wrote:
> Dear all,
>
> This changeset adds support for decoding and verifying the cryptographic
> validity of RPKI Signed Checklists (RSC) files. The draft [1] is in
> Working Group Last Call, the wire image is considered stable.
>
> A RS
Dear all,
This changeset adds support for decoding and verifying the cryptographic
validity of RPKI Signed Checklists (RSC) files. The draft [1] is in
Working Group Last Call, the wire image is considered stable.
A RSC is a Cryptographic Message Syntax (CMS) profile for a general
purpose
11 matches
Mail list logo
