Hi Q, all,
> On 16 Aug 2024, at 11:11, Q Misell wrote:
>
> > But it’s still not clear to me what the challenge would look like.
>
> It might help to look over my attempt at defining this in my PR:
> https://github.com/bgp/draft-ietf-peering-api/pull/30
>
At a glance… yes something like this
> But it’s still not clear to me what the challenge would look like.
It might help to look over my attempt at defining this in my PR:
https://github.com/bgp/draft-ietf-peering-api/pull/30
--
Any statements contained in this email are personal to the author and are
not
It would help if I actually pushed the branch I was working on to Github,
whoops! The pad branch should now be there with my work.
--
Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifica
Hi Job,
> On 15 Aug 2024, at 14:39, Job Snijders wrote:
>
> On Thu, Aug 15, 2024 at 02:28:46PM +0200, Tim Bruijnzeels wrote:
>> It is unclear to me how section 9.3 of draft-ramseyer-grow-peering-api
>> intends to use RPKI Signed Checklists (RSC) to prove authority for an
>> ASN.
>>
>> I think
On Thu, Aug 15, 2024 at 02:28:46PM +0200, Tim Bruijnzeels wrote:
> It is unclear to me how section 9.3 of draft-ramseyer-grow-peering-api
> intends to use RPKI Signed Checklists (RSC) to prove authority for an
> ASN.
>
> I think it would be beneficial to have a dedicated RPKI object for
> this ins
Hi Q,
I have some comments, orthogonal to Job’s comments, so let me reply to the
thread root…
1. One object, one ASN, one URI?
The object defines a single ASN and a single URI. However, there is no way to
prevent that CAs publish multiple PAD objects for the same ASN, or that a
parent CA publ
Hi Q,
> On 13 Aug 2024, at 15:18, Q Misell wrote:
>
> I've made a fork of Krill with support for this draft. It's available at
> https://github.com/as207960/krill(and https://github.com/as207960/rpki-rs for
> the required updates to rpki-rs).
I see the forked code, but no commits or PRs for y
or the like)
>
>
>
> Regarding the URI restrictions, enforcing that the URL does not contain a
> query string nor a trailing slash makes sense to me. If we can try to reduce
> the client-side url parsing requirements, that seems like a nice benefit.
>
>
>
> Jenny
&
, sidr...@ietf.org
Subject: [GROW] Re: [Sidrops] Peering API Discovery
Thanks for the input on the ASN. 1. I wasn't sure on what string type to use
(there's so many to pick from!) so a second perspective is great. The
additional restrictions on the URI come from me thinking it uncl
Thanks for the input on the ASN.1. I wasn't sure on what string type to use
(there's so many to pick from!) so a second perspective is great.
The additional restrictions on the URI come from me thinking it unclear
what's supposed to happen if there's a query string etc in the URL.
Does a base URI
Dear Q,
I'd revise the ASN.1 as following:
* use IA5String so the peeringApiUri field is somewhat similar to an
AccessDescription (which is a GeneralName CHOICE to an IA5String),
what you'd also find in a SubjectInfoAccess or AuthorityInfoAccess.
* Define after first use (as appears to be the
11 matches
Mail list logo
