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
