Hi Q and Job, Thank you both for the draft and discussion!
I will add a section to draft-ramseyer-grow-peering-api to reference your document here. As our draft stands now, it’s missing details around API discovery, so thank you for writing something up here. I will include it in our upcoming revision. For those not at the GROW meeting, the consensus after the meeting was that API discovery should follow: 1) First, discover from RPKI 2) failing that, fall back to a record in WHOIS 3) failing that, query some external source (peeringDB 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 From: Q Misell <q=40as207960....@dmarc.ietf.org> Date: Thursday, August 1, 2024 at 3:19 AM To: Job Snijders <job=40fastly....@dmarc.ietf.org> Cc: grow@ietf.org <grow@ietf.org>, sidr...@ietf.org <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 unclear what's supposed 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 of https://example.net/peering?k=v<https://urldefense.com/v3/__https:/example.net/peering?k=v__;!!Bt8RZUm9aw!_ga4dyLmmMTtK22lu62OX7wFE-qp9wghkpFK1hlpFynctWCpO9ddbcirPihfvFyYHfZkdgrfgOEsRK9bgMDrkEzIr9g4$> then mean every request has to include that query parameter (e.g. https://example.net/peering/locations?asn=<https://urldefense.com/v3/__https:/example.net/peering/locations?asn=__;!!Bt8RZUm9aw!_ga4dyLmmMTtK22lu62OX7wFE-qp9wghkpFK1hlpFynctWCpO9ddbcirPihfvFyYHfZkdgrfgOEsRK9bgMDrkFJEIWCF$>65536&k=v)? This seems like extra unnecessary processing work for clients. A similar logic of client processing applies to the trailing slash restriction; all endpoints in the API are defined with a / at the start, and if there is no trailing slash in the PAD object then a client can string concatenate without extra processing. As for the authority I've seen enough cockups in authority parsing in URIs that it makes sense to me to forbid it entirely, as the API already includes its own authentication. ________________________________ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574<https://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!Bt8RZUm9aw!_ga4dyLmmMTtK22lu62OX7wFE-qp9wghkpFK1hlpFynctWCpO9ddbcirPihfvFyYHfZkdgrfgOEsRK9bgMDrkIvpFoSZ$>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876<https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!Bt8RZUm9aw!_ga4dyLmmMTtK22lu62OX7wFE-qp9wghkpFK1hlpFynctWCpO9ddbcirPihfvFyYHfZkdgrfgOEsRK9bgMDrkH5mlUCq$>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Wed, 31 Jul 2024 at 14:01, Job Snijders <job=40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org>> wrote: 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 common style) * Disallow AS 0 * s/id-mod-rpki-peering-api-discovery-2024/id-mod-rpkiPeeringApiDiscovery-2024/g ---- RpkiPeeringApiDiscovery-2024 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-rpkiPeeringApiDiscovery-2024(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS CONTENT-TYPE FROM CryptographicMessageSyntax-2010 -- RFC 6268 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; ct-peeringApiDiscovery CONTENT-TYPE ::= { TYPE PeeringAPIDiscovery IDENTIFIED BY id-ct-peeringApiDiscovery } id-ct-peeringApiDiscovery OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) peeringApiDiscovery(TBD) } PeeringAPIDiscovery ::= SEQUENCE { version [0] INTEGER DEFAULT 0, asn ASID, peeringApiUri IA5String } ASID ::= INTEGER (1..4294967295) END ---- The in the natural language description of the fields there is a mismatch: peeringApiUri vs peeringApiUri. I'd use peeringApiUri. I also agree that it should contain a valid HTTPS URI, but am not sure the additional restrictions such as query or trailing slash have any value. I'd remove everything what comes after "MUST NOT include". Kind regards, Job
_______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
