A Publication-Point-Based Incremental Validation Procedure for RPKI Relying Parties
draft-su-sidrops-rpki-rp-incremental-validation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yingying Su , Lancheng Qin , Dan Li | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-su-sidrops-rpki-rp-incremental-validation-00
SIDROPS Y. Su
Internet-Draft L. Qin
Intended status: Standards Track Zhongguancun Laboratory
Expires: 7 January 2027 D. Li
Tsinghua University
6 July 2026
A Publication-Point-Based Incremental Validation Procedure for RPKI
Relying Parties
draft-su-sidrops-rpki-rp-incremental-validation-00
Abstract
RPKI Relying Parties commonly perform top-down validation of the RPKI
certificate tree after repository synchronization. Existing
repository synchronization mechanisms can update the local repository
incrementally, avoiding a complete retrieval of all repository data.
However, after such an incremental repository update, an RP
implementation may still repeat full top-down validation over the
local repository. It means that the RP starts from the trust anchors
and performs complete validation checks for all currently reachable
RPKI objects encountered during the traversal. Repeating such
validation for objects whose validation inputs have not changed can
introduce unnecessary validation overhead.
This document specifies a publication-point-based incremental
validation procedure for RPKI RPs. The procedure is intended to
reduce redundant validation work after incremental repository
synchronization, while preserving the same validation result as a
full top-down validation over the same repository snapshot, trust
anchor set, validation policy, and validation time. This document
does not change the syntax or validation semantics of any RPKI
object.
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/.
Su, et al. Expires 7 January 2027 [Page 1]
Internet-Draft RPKI RP Incremental Validation July 2026
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 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Cache State and Bootstrapping . . . . . . . . . . . . . . . . 4
4. Incremental Validation Procedure . . . . . . . . . . . . . . 6
4.1. Trust Anchor Processing . . . . . . . . . . . . . . . . . 6
4.2. New CA Publication Point . . . . . . . . . . . . . . . . 7
4.3. Existing CA Publication Point . . . . . . . . . . . . . . 7
4.3.1. CA Effective Resource Context Checking . . . . . . . 8
4.3.2. Manifest and CRL Processing . . . . . . . . . . . . . 8
4.3.3. Publication-Point-Level Reuse . . . . . . . . . . . . 9
4.3.4. Object-Level Reuse . . . . . . . . . . . . . . . . . 9
4.3.5. Updating the Publication Point Cache . . . . . . . . 11
5. Failure Handling and Fallback . . . . . . . . . . . . . . . . 11
6. Correctness Considerations . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Normative References . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Su, et al. Expires 7 January 2027 [Page 2]
Internet-Draft RPKI RP Incremental Validation July 2026
1. Introduction
RPKI RPs validate RPKI data by traversing the certificate tree from
trust anchors to subordinate CAs and payload-carrying signed objects,
such as ROAs and ASPA. This top-down validation model ensures that
each object is evaluated in the context of its issuing CA, the
applicable manifest, the applicable CRL, the applicable effective
resource context, and the current validation time. However,
repeating full top-down validation after every repository
synchronization cycle can introduce significant validation overhead,
even when only a small portion of the publication point has changed.
This document specifies a publication-point-based incremental
validation procedure. The procedure uses cached validation state
associated with CA publication points, together with the current
manifest and CRL, to determine which validation results can be safely
reused and which checks must be re-executed. The RP still traverses
the currently reachable RPKI tree from the trust anchors. The
difference is that unchanged objects do not necessarily require
repeated parsing, signature verification, and full object validation
during every validation cycle.
This document specifies an optional procedure for reducing redundant
validation work inside an RP implementation. This document does not
define a new RPKI object format, does not change RRDP or rsync
behavior, and does not modify the validation semantics of RPKI
certificates, manifests, CRLs, ROAs, ASPA objects, or other RPKI
signed objects. The cache structures and identifiers described in
this document are conceptual; implementations may use equivalent
internal representations. The intended correctness property is that,
for the same repository snapshot, trust anchor set, validation
policy, and validation time, the incremental validation procedure
produces the same validated payload output as a full top-down
validation.
2. Requirements Language
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.
Su, et al. Expires 7 January 2027 [Page 3]
Internet-Draft RPKI RP Incremental Validation July 2026
3. Cache State and Bootstrapping
Incremental validation depends on validation state produced by a
previous validation cycle. When no usable cache exists, the RP first
obtains a complete local repository snapshot using its selected
synchronization mechanism, and then performs full top-down validation
from the trust anchors. During this initial validation, the RP
validates the currently reachable CA publication points, including
the manifest, CRL, and all objects referenced by each valid manifest.
The validation results produced during this process are used to build
the initial cache state.
The cache can be represented as a mapping from a CA identifier to the
validation state of the publication point associated with that CA:
ValidationCache = {
CA_ID -> PublicationPointState
}
A cache entry is created only for a CA that has been validated
successfully in a previous validation cycle and whose publication
point has a valid manifest and a valid CRL. A CA_ID identifies the
validated CA certificate object and the publication point associated
with that CA. The representation is:
CA_ID = (CA_certificate_URI, hash(CA_certificate_object))
A publication point cache entry contains the state needed to
determine whether the publication point, or individual objects in
that publication point, can be reused in a later validation cycle:
Su, et al. Expires 7 January 2027 [Page 4]
Internet-Draft RPKI RP Incremental Validation July 2026
PublicationPointState = {
ca_effective_resources,
manifest: {
uri,
hash,
thisUpdate,
nextUpdate,
},
crl: {
uri,
hash,
thisUpdate,
nextUpdate,
},
objects: {
(filename, file_hash) -> ObjectValidationState
}
}
For the publication point, ca_effective_resources records the
effective IP address and AS number resources of the CA certificate
under which the publication point was validated. For the manifest,
thisUpdate and nextUpdate refer to the time fields in the manifest
eContent. For the CRL, thisUpdate and nextUpdate refer to the CRL
validity interval.
The per-object validation state records the information needed to
decide whether a previous validation result can be reused in a later
validation cycle:
ObjectValidationState = {
uri,
filename,
hash,
object_type,
validation_status,
failure_reason,
cert_serial,
notBefore,
notAfter,
effective_resources,
derived_payload
}
Su, et al. Expires 7 January 2027 [Page 5]
Internet-Draft RPKI RP Incremental Validation July 2026
The cert_serial, notBefore, and notAfter fields record the serial
number and validity interval of the CA certificate or the EE
certificate associated with the signed object. The
effective_resources field is relevant only for valid subordinate CA
certificates and records the subordinate CA's current effective
resources. The derived_payload field is relevant only for valid
payload-carrying signed objects. For example, derived_payload
records the effective validated payload generated by ROA and ASPA
objects.
The failure_reason field is relevant only for objects that were
invalid in the cached state. This field requires distinguishing at
least failures caused by the validation time being earlier than the
relevant notBefore time and failures caused by CRL revocation. Such
objects can become valid in a later validation cycle if the current
validation time has entered the relevant validity interval, or if the
current CRL no longer revokes the relevant certificate serial number.
4. Incremental Validation Procedure
After the RP has obtained an updated local repository snapshot,
validation starts from the configured trust anchors and proceeds top-
down. In this document, the recursive validation process is modeled
as repeated execution of ValidatePP(CA) for each currently valid CA
encountered during the traversal.
For each accepted trust anchor or validated subordinate CA, the RP
computes the corresponding CA_ID. If no usable cache entry exists
for the CA_ID, the publication point is processed as a new CA
publication point as described in Section 4.2. If a usable cache
entry exists, the publication point is processed as an existing CA
publication point as described in Section 4.3.
4.1. Trust Anchor Processing
The RP starts validation from its configured trust anchors. Trust
anchor processing follows the applicable TAL processing rules
[RFC8630] and the RP's local trust anchor configuration.
After a trust anchor has been accepted in the current validation
cycle, it is treated as a special self-signed root CA for the purpose
of its publication point processing. The RP computes the
corresponding CA_ID for the accepted trust anchor certificate. If a
usable cache entry exists for this CA_ID, the trust anchor
publication point is processed as an existing CA publication point as
described in Section 4.3. Otherwise, it is processed as a new CA
publication point as described in Section 4.2.
Su, et al. Expires 7 January 2027 [Page 6]
Internet-Draft RPKI RP Incremental Validation July 2026
If a trust anchor is not accepted in the current validation cycle,
its subtree does not contribute to the current validated payload
output.
4.2. New CA Publication Point
A CA publication point is considered new when the CA_ID of the
current CA does not match any usable entry in the validation cache.
For a new CA publication point, the RP performs full validation for
that publication point according to the applicable RPKI
specifications, including resource certificate and CRL validation
[RFC6487] [RFC9829], signed object validation [RFC6488] [RFC9589],
manifest validation [RFC9286], and validation of supported payload-
carrying object types such as ROAs [RFC9582] and ASPA objects
[I-D.ietf-sidrops-aspa-profile]. In general, the RP may:
1. locate and validate the manifest and CRL associated with the
current CA;
2. check that the objects referenced by the manifest are present in
the current local repository snapshot and match the hashes
recorded in the manifest;
3. fully validate the objects referenced by the manifest, generate
validated payloads from valid payload-carrying objects, and
recursively process valid subordinate CAs;
4. record the resulting publication point state, including
ca_effective_resources and per-object state, in the validation
cache for later validation cycles.
This subsection does not redefine the validation rules for RPKI
objects. Certificate and CRL validation, manifest processing, signed
object validation, and payload extraction follow the applicable RPKI
specifications for the corresponding object types.
4.3. Existing CA Publication Point
A CA publication point is considered existing when the CA_ID of the
current CA matches a usable entry in the validation cache. A CA_ID
cache hit indicates that the CA certificate object itself has not
changed. It does not, by itself, indicate that the CA is reached
under the same resource context, or that all cached validation
results can be reused.
Su, et al. Expires 7 January 2027 [Page 7]
Internet-Draft RPKI RP Incremental Validation July 2026
4.3.1. CA Effective Resource Context Checking
The RP first compares the current effective resources
(effective_resources) of the CA certificate, as computed when
validating that CA certificate in its parent publication point, with
the cached ca_effective_resources of the CA's own publication point
cache.
If the two values differ, the RP does not reuse the cached
publication point state or cached object validation state for this CA
publication point. The publication point is processed by full
validation as described in Section 4.2 under the current
ca_effective_resources.
If the two values are equal, the RP processes the current manifest
and CRL as described in Section 4.3.2.
4.3.2. Manifest and CRL Processing
The RP locates the current manifest and CRL associated with the CA in
the current local repository snapshot and computes their object
hashes. If either the manifest or the CRL is missing, the RP may
fall back to the cached publication point state according to local
policy.
The RP then applies one of the following cases.
*Case 1: Manifest and CRL unchanged.*
If both the current manifest hash and the current CRL hash match the
cached manifest hash and cached CRL hash, the RP checks the cached
manifest thisUpdate and nextUpdate values and the cached CRL
thisUpdate and nextUpdate values against the current validation time.
If these checks succeed, the RP processes the publication point as
described in Section 4.3.3. If either the cached manifest or the
cached CRL is not valid at the current validation time, the
publication point is considered invalid for the current validation
cycle.
*Case 2: Manifest changed.*
If the current manifest hash differs from the cached manifest hash,
the RP validates the current manifest and current CRL according to
the applicable RPKI validation rules. The current CRL must be
referenced by the current manifest and must match the hash recorded
in the current manifest.
Su, et al. Expires 7 January 2027 [Page 8]
Internet-Draft RPKI RP Incremental Validation July 2026
If validation succeeds, the RP uses the object set defined by the
current manifest and processes the publication point as described in
Section 4.3.4. If the manifest or CRL validation fails, the RP may
fall back to the cached publication point state according to local
policy.
4.3.3. Publication-Point-Level Reuse
Publication-point-level reuse is used when the CA_ID,
ca_effective_resources, manifest hash, and CRL hash all match the
cached state.
In this case, the RP reuses the cached validation state for the
publication point, subject only to checks that depend on the current
validation time.
1. For each cached object that was valid in the cached state, the RP
checks whether the relevant certificate or signed object is valid
at the current validation time.
2. For each cached object that was invalid only because the
validation time was earlier than the relevant notBefore time, the
RP checks whether the relevant certificate or signed object is
within its validity interval at the current validation time. If
it is, the RP fully validates the object before treating it as
valid in the current validation cycle.
3. If an object is valid in the current validation cycle and is a
payload-carrying signed object, its derived_payload contributes
to the current validated payload output.
4. If an object is valid in the current validation cycle and is a
subordinate CA certificate, the RP recursively applies
ValidatePP(child CA) using the subordinate CA's
effective_resources.
Cached objects that are not valid in the current validation cycle do
not contribute to the current validated payload output.
4.3.4. Object-Level Reuse
Object-level reuse is used when the CA_ID and ca_effective_resources
match the cached state, but the current manifest hash differs from
the cached manifest hash.
The current manifest defines the object set of the current
publication point. Objects that are not referenced by the current
manifest do not contribute to the current validated payload output.
Su, et al. Expires 7 January 2027 [Page 9]
Internet-Draft RPKI RP Incremental Validation July 2026
1. For every object referenced by the current manifest, the RP
checks that the corresponding raw object exists in the current
local repository snapshot and that the object hash matches the
hash recorded in the current manifest. If any referenced object
is missing or has a mismatching hash, the RP may fall back to the
cached publication point state according to local policy.
2. For each object referenced by the current manifest, the RP looks
for cached object validation state using the object's filename
and hash.
3. If matching cached object validation state exists and the object
was valid in the cached state, the RP checks whether the relevant
certificate or signed object is valid at the current validation
time. If the current CRL hash differs from the cached CRL hash,
the RP also checks whether the relevant certificate serial number
is revoked by the current CRL. If these checks succeed, the
cached object validation result is reused.
4. If matching cached object validation state exists and the object
was invalid in the cached state, the RP uses the recorded
failure_reason to decide whether the object needs to be validated
again. The RP fully validates the object again only when one of
the following conditions is met:
* the previous failure was caused by the validation time being
earlier than the relevant notBefore time, and the relevant
certificate or signed object is within its validity interval
at the current validation time; or
* the previous failure was caused by CRL revocation, the current
CRL hash differs from the cached CRL hash, and the current CRL
no longer contains the relevant certificate serial number.
If neither condition is met, the object remains invalid in the
current validation cycle.
5. If no matching cached object validation state exists, the RP
fully validates the object according to the applicable RPKI
validation rules.
6. For each object that is valid in the current validation cycle,
the RP processes the object according to its type. If the object
is a payload-carrying signed object, its derived payload
contributes to the current validated payload output. If the
object is a subordinate CA certificate, the RP recursively
applies ValidatePP(child CA) using the subordinate CA's current
effective_resources.
Su, et al. Expires 7 January 2027 [Page 10]
Internet-Draft RPKI RP Incremental Validation July 2026
Objects that are not valid in the current validation cycle do not
contribute to the current validated payload output.
4.3.5. Updating the Publication Point Cache
After the existing CA publication point has been processed
successfully for the current validation cycle, the RP updates the
cache entry for the corresponding CA_ID.
The updated cache entry records the current ca_effective_resources,
current manifest state, current CRL state, and the validation state
of the objects in the current publication point. The previous cache
entry for the same CA_ID is replaced by the newly computed
publication point state.
Implementations may update the cache using any internal mechanism.
To avoid using partially updated validation state in later cycles, an
implementation can update the cache entry atomically after the
publication point has been processed.
5. Failure Handling and Fallback
If a new CA publication point cannot be validated, no previous
publication point state exists for the corresponding CA_ID. In this
case, the publication point is invalid for the current validation
cycle, and no valid cache entry is created for that CA_ID.
For an existing CA publication point, processing can fail if the
current manifest is invalid, the current CRL is invalid, the current
repository snapshot is inconsistent with the current manifest, or the
publication point has to be fully validated but full validation does
not succeed. In these cases, the RP may use the cached publication
point state for the same CA_ID as a fallback according to local
policy. This fallback represents the last successfully validated
state for that CA publication point.
Fallback to cached publication point state is a local policy behavior
and is outside the equivalence guarantee of this procedure. When
fallback is used, the RP still applies checks that depend on the
current validation time, such as validity-time checks for the cached
manifest, cached CRL, and cached objects. Objects that remain valid
after these checks may contribute to the current validated payload
output.
An implementation should not replace a previous valid cache entry
with partial or failed state. The cache entry for a CA_ID should be
updated only after the publication point has been successfully
processed in the current validation cycle.
Su, et al. Expires 7 January 2027 [Page 11]
Internet-Draft RPKI RP Incremental Validation July 2026
6. Correctness Considerations
The correctness of this procedure relies on the following properties:
1. Validation still proceeds top-down from the accepted trust
anchors, so only currently reachable objects can contribute to
the validated payload output.
2. The CA_ID binds cached state to a specific CA certificate object.
If the CA certificate changes, the cache entry is not reused and
the publication point is processed as new.
3. Publication-point-level reuse is used only when the CA_ID,
ca_effective_resources, manifest hash, and CRL hash all match the
cached state. Cached results are reused only after applying
checks that depend on the current validation time.
4. If the CA_ID matches but the current ca_effective_resources
differ from the cached ca_effective_resources, this procedure
does not reuse cached publication point state or cached object
validation results from that publication point.
5. During object-level reuse, the current manifest defines the
object set of the publication point. A cached object validation
result is reused only for an object that is referenced by the
current manifest and has the same filename and hash as the cached
object state.
6. A cache hit does not bypass checks that may change across
validation cycles. The current validation time is applied before
reuse. When object-level reuse is performed with a CRL that
differs from the cached CRL, the relevant certificate serial
number is checked against the current CRL before reuse.
Under these conditions, the incremental procedure preserves the
validation result of a complete top-down validation over the same
repository snapshot, trust anchor set, validation policy, and
validation time.
7. Security Considerations
This document does not change the syntax or validation semantics of
any RPKI object. The main security consideration is that cached
validation state MUST NOT be reused unless the cache reuse conditions
specified in this document are satisfied. In particular, an RP MUST
apply the current validation time, MUST apply the current CRL state
when required by this procedure, and MUST confirm that the current
effective resource context matches the cached state before reusing
Su, et al. Expires 7 January 2027 [Page 12]
Internet-Draft RPKI RP Incremental Validation July 2026
cached validation results.
Implementations should protect the integrity of the validation cache.
Corruption or unauthorized modification of cached validation state
could cause an RP to reuse incorrect validation results. If cache
state is missing, inconsistent, or cannot be trusted, the RP should
perform full validation for the affected publication point.
Fallback to cached publication point state is a local policy behavior
and is outside the equivalence guarantee of this procedure.
8. IANA Considerations
This document has no IANA requests.
Acknowledgements
Normative References
[RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,
August 2019, <https://www.rfc-editor.org/info/rfc8630>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>.
[RFC9829] Snijders, J., Maddison, B., and T. Buehler, "Handling of
Resource Public Key Infrastructure (RPKI) Certificate
Revocation List (CRL) Number Extensions", RFC 9829,
DOI 10.17487/RFC9829, July 2025,
<https://www.rfc-editor.org/info/rfc9829>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>.
[RFC9589] Snijders, J. and T. Harrison, "On the Use of the
Cryptographic Message Syntax (CMS) Signing-Time Attribute
in Resource Public Key Infrastructure (RPKI) Signed
Objects", RFC 9589, DOI 10.17487/RFC9589, May 2024,
<https://www.rfc-editor.org/info/rfc9589>.
Su, et al. Expires 7 January 2027 [Page 13]
Internet-Draft RPKI RP Incremental Validation July 2026
[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
<https://www.rfc-editor.org/info/rfc9286>.
[RFC9582] Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S.
Kent, "A Profile for Route Origin Authorizations (ROAs)",
RFC 9582, DOI 10.17487/RFC9582, May 2024,
<https://www.rfc-editor.org/info/rfc9582>.
[I-D.ietf-sidrops-aspa-profile]
Snijders, J., Azimov, A., Uskov, E., Bush, R., Housley,
R., and B. Maddison, "A Profile for Autonomous System
Provider Authorization", Work in Progress, Internet-Draft,
draft-ietf-sidrops-aspa-profile-27, 19 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-profile-27>.
[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>.
[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>.
Authors' Addresses
Yingying Su
Zhongguancun Laboratory
Beijing
China
Email: suyy@mail.zgclab.edu.cn
Lancheng Qin
Zhongguancun Laboratory
Beijing
China
Email: qinlc@mail.zgclab.edu.cn
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Su, et al. Expires 7 January 2027 [Page 14]