Human Readable ASPA Notation

Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Introduction This informational document defines a human readable ASPA notation for Validated ASPA Payloads (VAPs) . The main motivations for providing this notations style are:

This can help to create consistency between RPKI Relying Party software output (generators), making it easier for operators to compare results.
This can be used by RPKI Certificate Authorities (CA) command line interfaces and/or configuration, where an automated process parses this syntax. E.g. allowing a CA to provide a listing of intended VAPs which can be easily compared to RP output.
This can be used for documentation.

The chosen notation style can be read from left to right to mean that the holder of the customer ASN on the left authorizes one or more provider ASNs on the right. That said, this definition is informational. Implementations can choose to use their own notation styles instead of, or in addition to this.

ASPA Notation Definition This specification uses ABNF syntax specified in . notation = customer-asid separator providers customer-asid = asn separator = " => " providers = providers-one-line / providers-multiline providers-one-line = asn *(*wsp "," *wsp asn) providers-multiline = "[" *wspml asn *(*wspml "," *wspml asn) *wspml "]" asn = "AS" uint32 uint32 = %d0-4294967295 wsp = space / tab wspml = space / tab / cr / lf cr = %d13 lf = %d10 space = %d32 tab = %d9

customer-asid This field represents the customerASID defined in section 3.2 of

providers This field represents the providers defined in section 3.3 of . Note that the normative constraints which are defined in that section mean that following constraints apply to the content of ASPA objects:

There must be at least one provider-as.
The customer-asid "asn" value must not appear in any provider-as.
The elements of providers must be ordered in ascending numerical order by the "asn" value of the provider-as field.
Each "asn" value for used for a provider-as must be unique.

A generator MUST ensure that the output matches all these normative constraints. However, to be more resilient to input written by humans, a parser MUST accept a list of providers that is not correctly sorted (3) but otherwise valid.

provider-as This field represents a Provider AS as defined in section 3.3 of .

asn This field consists of the string "AS" followed by a decimal value of a 32-bit Autonomous System Number using the asplain presentation as specified in . Decimal values MUST represent a 32 bit value, and therefore MUST be part of the range 0-4294967295.

Example Notations Some example notations are listed below. The last example is not advised for readability but is technically allowed by this specification. AS65000 => AS65001 AS65000 => AS65001 AS65000 => AS65002 AS65000 => AS65001, AS65002,AS65003 AS65000 => [ AS65001, AS65002, AS65003 ] AS65000 => [ AS65001, AS65002, AS65003 ] AS65000 => [AS65001, AS65002 ,AS65003 ] The following example is valid for input only (i.e. while it is sorted in string order, it is not sorted in numerical order): AS65000 => [ AS4200000000, AS64496 ] note: private use AS number used because all documentation AS numbers have the same textual prefix.

IANA Considerations This document has no IANA actions.

Security Considerations TBD

Acknowledgements Thanks to Randy Bush for suggesting to allow only one possible notation for AS numbers.