Human Readable ASPA Notation
draft-ietf-sidrops-aspa-notation-04

Network Working Group                                     T. Bruijnzeels
Internet-Draft                                                  RIPE NCC
Intended status: Informational                               O. Borchert
Expires: 5 April 2026                                               NIST
                                                                   D. Ma
                                                                    ZDNS
                                                              T. de Kock
                                                                RIPE NCC
                                                          2 October 2025

                      Human Readable ASPA Notation
                  draft-ietf-sidrops-aspa-notation-04

Abstract

   This document defines a human readable notation for Validated ASPA
   Payloads (VAP, see ID-aspa-profile) for use with RPKI tooling based
   on ABNF (RFC 5234).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 April 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Bruijnzeels, et al.       Expires 5 April 2026                  [Page 1]
Internet-Draft                ASPA Notation                 October 2025

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  ASPA Notation Definition  . . . . . . . . . . . . . . . . . .   3
     3.1.  customer-asid . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  providers . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.2.1.  provider-as . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  asn . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Example Notations . . . . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Introduction

   This informational document defines a human readable ASPA notation
   for Validated ASPA Payloads (VAPs) [I-D.ietf-sidrops-aspa-profile].

   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.

Bruijnzeels, et al.       Expires 5 April 2026                  [Page 2]
Internet-Draft                ASPA Notation                 October 2025

   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.

3.  ASPA Notation Definition

   This specification uses ABNF syntax specified in [RFC5234].

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

3.1.  customer-asid

   This field represents the customerASID defined in section 3.2 of
   [I-D.ietf-sidrops-aspa-profile]

3.2.  providers

   This field represents the providers defined in section 3.3 of
   [I-D.ietf-sidrops-aspa-profile].  Note that the normative constraints
   which are defined in that section mean that following constraints
   apply to the content of ASPA objects:

   1.  There must be at least one provider-as.
   2.  The customer-asid "asn" value must not appear in any provider-as.

Bruijnzeels, et al.       Expires 5 April 2026                  [Page 3]
Internet-Draft                ASPA Notation                 October 2025

   3.  The elements of providers must be ordered in ascending numerical
       order by the "asn" value of the provider-as field.
   4.  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.

3.2.1.  provider-as

   This field represents a Provider AS as defined in section 3.3 of
   [I-D.ietf-sidrops-aspa-profile].

3.3.  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 [RFC5396].  Decimal values MUST represent a 32 bit
   value, and therefore MUST be part of the range 0-4294967295.

4.  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):

Bruijnzeels, et al.       Expires 5 April 2026                  [Page 4]
Internet-Draft                ASPA Notation                 October 2025

   AS65000 => [ AS4200000000, AS64496 ]

   note: private use AS number used because all documentation AS numbers
   have the same textual prefix.

5.  IANA Considerations

   This document has no IANA actions.

6.  Security Considerations

   TBD

7.  Acknowledgements

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

8.  Normative References

   [I-D.ietf-sidrops-aspa-profile]
              Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley,
              R., and B. Maddison, "A Profile for Autonomous System
              Provider Authorization", Work in Progress, Internet-Draft,
              draft-ietf-sidrops-aspa-profile-20, 18 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-profile-20>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5396]  Huston, G. and G. Michaelson, "Textual Representation of
              Autonomous System (AS) Numbers", RFC 5396,
              DOI 10.17487/RFC5396, December 2008,
              <https://www.rfc-editor.org/info/rfc5396>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Bruijnzeels, et al.       Expires 5 April 2026                  [Page 5]
Internet-Draft                ASPA Notation                 October 2025

Authors' Addresses

   Tim Bruijnzeels
   RIPE NCC
   Email: tbruijnzeels@ripe.net

   Oliver Borchert
   NIST
   Email: oliver.borchert@nist.gov

   Di Ma
   ZDNS
   Email: madi@zdns.cn

   Ties de Kock
   RIPE NCC
   Email: tdekock@ripe.net

Bruijnzeels, et al.       Expires 5 April 2026                  [Page 6]