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 then mean every request has to include that query parameter (e.g. https://example.net/peering/locations?asn=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://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. 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> 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
