Extension Registry for the Extensible Provisioning Protocol
draft-ietf-regext-ext-registry-epp-08

Network Working Group                                      S. Hollenbeck
Internet-Draft                                             Verisign Labs
Obsoletes: 7451 (if approved)                                8 June 2026
Intended status: Standards Track                                        
Expires: 10 December 2026

      Extension Registry for the Extensible Provisioning Protocol
                 draft-ietf-regext-ext-registry-epp-08

Abstract

   The Extensible Provisioning Protocol (EPP) includes features to add
   functionality by extending the protocol.  It does not, however,
   describe how those extensions are maintained.  This document
   describes a procedure for the registration and management of
   extensions to EPP, and it specifies a format for an IANA registry to
   record those extensions.  If approved, this document obsoletes RFC
   7451.

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 10 December 2026.

Copyright Notice

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

Hollenbeck              Expires 10 December 2026                [Page 1]
Internet-Draft           EPP Extension Registry                June 2026

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Changes Since RFC 7451  . . . . . . . . . . . . . . . . .   3
     1.2.  Conventions Used in This Document . . . . . . . . . . . .   4
   2.  Extension Specification and Registration Procedure  . . . . .   4
     2.1.  Extension Specification . . . . . . . . . . . . . . . . .   4
       2.1.1.  Designated Expert Evaluation Criteria . . . . . . . .   4
     2.2.  Registration Procedure  . . . . . . . . . . . . . . . . .   6
       2.2.1.  Required Information  . . . . . . . . . . . . . . . .   6
       2.2.2.  Registration Form . . . . . . . . . . . . . . . . . .   7
       2.2.3.  Registration Processing . . . . . . . . . . . . . . .   8
       2.2.4.  Updating Registry Entries . . . . . . . . . . . . . .   9
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .  10
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Domain name registries implement a variety of operational and
   business models.  The differences in these models make it impossible
   to develop a "one size fits all" provisioning protocol; the
   Extensible Provisioning Protocol [STD69] was designed to focus on a
   minimal set of common functionality with built-in extension
   capabilities that allow new features to be specified on an "as
   needed" basis.  Guidelines for extending EPP are documented in RFC
   3735 [RFC3735] (or its future replacement).

Hollenbeck              Expires 10 December 2026                [Page 2]
Internet-Draft           EPP Extension Registry                June 2026

   Standard 69 [STD69] and RFC 3735 [RFC3735] do not describe how
   extension development can be managed and coordinated.  This has led
   to a situation in which server operators can develop different
   extensions to address similar needs, such as the provisioning of
   Value Added Tax (VAT) information.  Clients then need to support
   multiple extensions that serve similar purposes, and interoperability
   suffers as a result.

   RFC 7451 [RFC7451] filled that gap by defining the Extensions for the
   Extensible Provisioning Protocol (EPP) IANA registry [IANA-REG] to
   help manage and coordinate the development of EPP extensions.

   This update was written to address issues that were identified with
   RFC 7451 [RFC7451] over time.  Refer to Section 1.1 for more details.

1.1.  Changes Since RFC 7451

   *  The intended status has been changed from Informational to
      Standards Track.

   *  The name of the mailing list used to review and discuss
      registration requests was changed from "eppext" to "regext"
      throughout the document.

   *  Section 2.1 has been updated to note that Internet-Draft documents
      are not acceptable specifications for this registry.

   *  Section 2.1.1 has been updated to describe Designated Expert
      responsibility to confirm correctness of URIs used in extension
      registration requests, and that IETF namespaces MUST be reserved
      for specifications published in the IETF Stream.

   *  Section 2.2.1 has been updated by adding "Other" to the set of
      document status values for the registry to avoid confusion with
      "Informational" RFCs and removing use of "Informational" for
      proprietary extensions.  This document includes instructions for
      IANA to update existing registry entries appropriately.

   *  Section 2.2.2 has been updated by changing "<registrant name>,
      <email address>" to "<name>, <address>" to meet right margin
      constraints.

   *  Section 2.2.3 has been updated to note that registry entries can
      be removed with IESG approval.

   *  Section 5 (Operational Considerations) has been added.

Hollenbeck              Expires 10 December 2026                [Page 3]
Internet-Draft           EPP Extension Registry                June 2026

1.2.  Conventions Used in This Document

   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.  Extension Specification and Registration Procedure

   This section describes the format of the Extensions for the
   Extensible Provisioning Protocol (EPP) IANA registry [IANA-REG] and
   the procedures used to populate and manage registry entries.

2.1.  Extension Specification

   This registry uses the "Specification Required" policy described in
   RFC 8126 [RFC8126].  Note that Section 2.1 of RFC 3735 [RFC3735] (or
   its future replacement) provides specific guidelines for documenting
   EPP extensions.

   The "Specification Required" policy requires review by a designated
   expert.  Section 5 of [RFC8126] describes the role of designated
   experts and the function they perform.  For this registry, acceptable
   specifications include RFC documents and proprietary specifications
   that meet the "permanent and readily available" requirement described
   in Section 4.6 of [RFC8126].  An English language version of the
   extension specification MUST be referenced from the registry, though
   non-English versions of the specification may also be provided.
   Internet-Draft documents are not acceptable specifications for future
   registrations.  Early allocations [RFC7120] do not apply to the
   Extensions for the EPP IANA registry [IANA-REG].

2.1.1.  Designated Expert Evaluation Criteria

   A high-level description of the role of the designated expert is
   described in Section 5.2 of RFC 8126 [RFC8126].  Specific guidelines
   for the appointment of designated experts and the evaluation of EPP
   extensions are provided here.

   The IESG should appoint a primary designated expert and a small
   number of individuals (perhaps 3 - 5) to serve as backup designated
   experts as described in Section 5.2 of [RFC8126].  The primary
   designated expert is responsible for conducting all reviews requested
   by IANA.  The secondary designated experts are responsible for
   conducting reviews as a simple majority, consensus-based group if the
   primary designated expert is unavailable.  In cases where a
   registration decision could be perceived as creating a conflict of

Hollenbeck              Expires 10 December 2026                [Page 4]
Internet-Draft           EPP Extension Registry                June 2026

   interest for a particular Designated Expert, that Expert MUST defer
   to the judgment of the other Experts.  The designated experts MUST
   use the existing regext mailing list (regext@ietf.org) or its
   successor for public discussion of registration requests.

   Extensions should be evaluated for architectural soundness using the
   guidelines described in RFC 3735 [RFC3735] (or its future
   replacement), including the Security Considerations section of that
   document.  Expert evaluation should explicitly include consideration
   of the privacy consequences of proposed extensions, and, at a
   minimum, ensure that any privacy considerations are fully documented
   in the relevant specification(s).

   URIs proposed in extensions (XML namespace and schema registration
   requests are commonly found in EPP extensions) should be evaluated
   for both syntactic and semantic correctness.  XML schemas, XML schema
   URIs, and XML namespace URIs defined in the extension specification
   MUST be registered in the IETF XML Registry using the procedures
   described in RFC 3688 [RFC3688].  IETF namespaces MUST be reserved
   for specifications published in the IETF Stream.  Non-IETF namespaces
   MUST be used for non-IETF specifications (which includes RFC
   documents published using the Independent Submission stream); the
   designated experts may need to work with a registrant to identify
   URIs that can be added to the IETF XML Registry.  Extensions and any
   normative reference necessary to implement the extension MUST NOT be
   denoted with "work in-progress" or any similar description.  Issues
   discovered during the evaluation MUST be shared with, and can be
   corrected by, the registrant until the designated experts explicitly
   decide to accept or reject the registration request.

   Designated experts should be permissive in their evaluation of
   requests to register extensions that have been implemented and
   deployed by at least one registry/registrar or server/client pair.
   This implies that it may indeed be possible to register multiple
   extensions that provide the same functionality.  Requests to register
   extensions that have not been deployed should be evaluated with a
   goal of reducing functional duplication.  A potential registrant who
   submits a request to register a new, un-deployed extension that
   includes similar functionality to an existing, registered extension
   should be made aware of the existing extension.  The registrant
   should be asked to reconsider their request given the existence of a
   similar extension.  Should they decline to do so, perceived
   similarity SHOULD NOT be a sufficient reason for rejection as long as
   all other requirements are met.

Hollenbeck              Expires 10 December 2026                [Page 5]
Internet-Draft           EPP Extension Registry                June 2026

2.2.  Registration Procedure

   The registry contains information describing each registered
   extension.  Registry entries are created and managed by sending forms
   to IANA that describe the extension and the operation to be performed
   on the registry entry.

2.2.1.  Required Information

   Name of Extension: A case-insensitive, ASCII text string that
   contains the name of the extension specification and does not overlap
   with an existing registered extension.  Non-ASCII representations of
   the extension name can be included in the "Notes" described below.

   Document Status: The document status of the specification document.
   For RFC documents, the possible set of values includes "Standards
   Track", "Informational", "Experimental", "Historic", and "BCP" as
   described in Sections 4 and 5 of RFC 2026 [RFC2026].  For documents
   that are not RFCs, this will always be "Other".

   Reference: A permanent, publicly available reference to the
   specification of this extension as described in Section 2.1.1.

   Registrant Name and Email Address: The name and email address of the
   entity that is responsible for managing the registry entry.  If the
   extension is registered by an IETF stream RFC, this can simply be
   listed as "IETF, <iesg@ietf.org>".

   TLDs: A text string containing the top-level domain name (or domain
   names), including the preceding ".", for which the extension has been
   specified (e.g., ".org").  If there are multiple TLDs, they are given
   as a list of domain names separated by commas, (e.g. ".com", ".net").
   Internationalized Domain Name (IDN) TLDs MUST be specified in A-label
   [RFC5890] format.  If the extension is not associated with a specific
   top-level domain, the case-insensitive text string "Any" can be used
   to indicate that.  If the extension is not associated with domain
   name processing, the case-insensitive text string "N/A" (Not
   Applicable) can be used to indicate that.

   IPR Disclosure: A pointer to any Intellectual Property Rights (IPR)
   disclosure document(s) related to this extension, or "None" may be
   used if there are no such disclosures.  This can be an IPR disclosure
   filed with the IETF in accordance with BCP 79 [BCP79] if the
   extension is part of an IETF Contribution, or it can be other IPR
   disclosure documents identifying the claimed intellectual property
   rights and terms of use for extensions that are not part of an IETF
   Contribution.

Hollenbeck              Expires 10 December 2026                [Page 6]
Internet-Draft           EPP Extension Registry                June 2026

   Status: Either "Active" or "Inactive".  The "Active" status is used
   for extensions that are currently implemented and in use.  The
   "Inactive" status is used for extensions that are not implemented or
   are otherwise not being used.  "Inactive" can also be used for
   extensions for which a reference specification becomes unavailable as
   described in Section 2.2.4.

   Notes: Either "None" or other text that describes optional notes to
   be included with the registered extension.  If the Status value is
   being changed, text MUST be included to describe the rationale for
   the status change.

2.2.2.  Registration Form

   The required information MUST be provided using the following
   registration form.  Form field names and values MAY appear on the
   same line.

    -----BEGIN FORM-----
    Name of Extension: <text string> (quotes are optional)

    Document Status: <document status>

    Reference: <RFC number, URL, etc.>

    Registrant Name and Email Address: <name>, <address>

    TLDs: "Any"|"N/A"|<one or more TLD text strings separated by commas>

    IPR Disclosure: "None"|<URL>

    Status: "Active"|"Inactive"

    Notes: "None"|<optional text>
    -----END FORM-----

   Example form with RFC specification:

    -----BEGIN FORM-----
    Name of Extension:
    "An Extension RFC for the Extensible Provisioning Protocol (EPP)"

    Document Status:  Standards Track

    Reference:  RFC XXXX

    Registrant Name and Email Address:  IETF, <iesg@ietf.org>

Hollenbeck              Expires 10 December 2026                [Page 7]
Internet-Draft           EPP Extension Registry                June 2026

    TLDs: Any

    IPR Disclosure: None

    Status: Active

    Notes: None
    -----END FORM-----

   Example form with non-RFC specification:

    -----BEGIN FORM-----
    Name of Extension:
    "An Example Extension for the .example Top-Level Domain"

    Document Status: Other

    Reference:
    https://www.example.com/html/example-epp-ext.txt

    Registrant Name and Email Address: John Doe, jdoe@example.com

    TLDs: .example

    IPR Disclosure:
    https://www.example.com/ipr/example-epp-ext-ipr.html

    Status: Active

    Notes: None
    -----END FORM-----

2.2.3.  Registration Processing

   Registrants should send each registration form to IANA with a single
   record for incorporation into the registry.  Send the form via email
   to <iana@iana.org> or complete the online form found on the IANA web
   site.  The subject line MUST indicate whether the enclosed form
   represents an insertion of a new record (indicated by the word
   "INSERT" in the subject line), replacement of an existing record
   (indicated by the word "MODIFY" in the subject line), deactivation of
   an existing record (indicated by the word "DEACTIVATE" in the subject
   line), or removal of an existing record (indicated by the word
   "REMOVE" in the subject line).

   Removal of registrations created through IETF consensus MUST be
   approved by the IESG using the IESG Approval process described in
   Section 4.10 of [RFC8126].  Registrations not created through IETF

Hollenbeck              Expires 10 December 2026                [Page 8]
Internet-Draft           EPP Extension Registry                June 2026

   consensus can be removed or deactivated with the approval of the
   IESG, or at the request of the original registrant, in consultation
   with or at the request of the Designated Experts.

   On receipt of a registration request, IANA will initiate review by
   the designated expert(s), who will evaluate the request using the
   criteria in Section 2.1.1 in consultation with the current working
   group mailing list focused on the development of EPP extensions if
   such working group exists.

2.2.4.  Updating Registry Entries

   When submitting changes to existing registry entries, include text in
   the "Notes" field of the registration form describing the change.
   Under normal circumstances, registry entries are only to be updated
   by the registrant.  If the registrant becomes unavailable or
   otherwise unresponsive, a designated expert can submit a registration
   form to IANA to update the registrant information.  Entries can
   change state from "Active" to "Inactive" and back again as long as
   state-change requests conform to the processing requirements
   identified in this document.  In addition to entries that become
   "Inactive" due to a lack of implementation, entries for which a
   specification becomes consistently unavailable over time should be
   marked "Inactive" by the designated expert until the specification
   again becomes reliably available.

3.  IANA Considerations

   Section 2 provides IANA registration considerations.  These
   considerations are not repeated here.

   IANA has created the "Extensions for the Extensible Provisioning
   Protocol (EPP)" registry [IANA-REG] to manage EPP extensions,
   described in Section 2.  This document requests IANA to replace the
   reference of the EPP registry from RFC 7451 to the RFC number to be
   assigned to this document.  This document also requests IANA to
   update "Document Status" of all non-RFC documents from
   "Informational" to "Other", and to add a note to the registry to
   explain that RFC 7120 early allocations do not apply to this
   registry.

4.  Security Considerations

   This document introduces no new security considerations to EPP.
   However, extensions should be evaluated according to the Security
   Considerations of RFC 3735 [RFC3735] (or its future replacement) and
   STD 69 [STD69].

Hollenbeck              Expires 10 December 2026                [Page 9]
Internet-Draft           EPP Extension Registry                June 2026

5.  Operational Considerations

   The updates defined in this document are meant to enhance the
   guidance for reviewing EPP extensions (e.g., avoid non-IETF
   specifications squatting on IETF XML namespaces) and thus allows for
   better interoperability.

   Section 2 includes provisions for modifying and deleting existing
   registration entries by registrants.  Such requests may have
   operational implication on other entities that deploy that extension.
   Note that the registry does not include a history mechanism and there
   is no way to track deleted entries once they have been removed.

   Section 3 updates the content of "Document Status" to be compliant
   with the guidance in Section 2.  That update does not impact the
   extension itself.  No operational issues are induced by that update.

6.  Normative References

   [BCP79]    Best Current Practice 79,
              <https://www.rfc-editor.org/info/bcp79>.
              At the time of writing, this BCP comprises the following:

              Bradner, S. and J. Contreras, "Intellectual Property
              Rights in IETF Technology", BCP 79, RFC 8179,
              DOI 10.17487/RFC8179, May 2017,
              <https://www.rfc-editor.org/info/rfc8179>.

   [STD69]    Internet Standard 69,
              <https://www.rfc-editor.org/info/std69>.
              At the time of writing, this STD comprises the following:

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
              <https://www.rfc-editor.org/info/rfc5730>.

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Domain Name Mapping", STD 69, RFC 5731,
              DOI 10.17487/RFC5731, August 2009,
              <https://www.rfc-editor.org/info/rfc5731>.

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
              August 2009, <https://www.rfc-editor.org/info/rfc5732>.

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
              August 2009, <https://www.rfc-editor.org/info/rfc5733>.

Hollenbeck              Expires 10 December 2026               [Page 10]
Internet-Draft           EPP Extension Registry                June 2026

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Transport over TCP", STD 69, RFC 5734,
              DOI 10.17487/RFC5734, August 2009,
              <https://www.rfc-editor.org/info/rfc5734>.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/info/rfc2026>.

   [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>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC3735]  Hollenbeck, S., "Guidelines for Extending the Extensible
              Provisioning Protocol (EPP)", RFC 3735,
              DOI 10.17487/RFC3735, March 2004,
              <https://www.rfc-editor.org/info/rfc3735>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [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>.

7.  Informative References

   [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
              Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
              2014, <https://www.rfc-editor.org/info/rfc7120>.

   [RFC7451]  Hollenbeck, S., "Extension Registry for the Extensible
              Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
              February 2015, <https://www.rfc-editor.org/info/rfc7451>.

Hollenbeck              Expires 10 December 2026               [Page 11]
Internet-Draft           EPP Extension Registry                June 2026

   [IANA-REG] Internet Assigned Numbers Authority, "Extensions for the
              Extensible Provisioning Protocol (EPP)",
              <https://www.iana.org/assignments/epp-extensions/epp-
              extensions.xhtml>.

Acknowledgements

   The information described in the registry is based on a suggestion
   posted to the provreg mailing list by Jay Daley in August 2013.  The
   need to update RFC 7451 was first proposed by Gavin Brown.
   Additional feedback for the update was provided by the following
   people: Gavin Brown, James Galvin, James Gould, Pawel Kowalik, Andrew
   Newton, Jasdip Singh.

Change Log

   This section is to be removed before publishing as an RFC.

   -00:  Initial WG version.

   -01:  WG last call edits: added reference to RFC 2026 to clarify the
      status of Internet-Draft documents as extension specifications.
      "IESG approval" -> "IESG Approval" in Section 2.2.3.  Added
      DEACTIVATE and REMOVE request processing to Section 2.2.3.
      Clarified use of IETF namespaces and "work in progress"
      specifications in Section 2.2.1.  Clarified status values in
      Section 2.2.1.  Updated acknowledgements.

   -02:  Changed intended status from Informational to BCP.  Added text
      to address Independent Submission stream RFCs to Section 2.1.
      Noted that the value of the TLDs field (Section 2.2.1) can be "N/
      A".  Added text to Section 2.2.1 to ensure that it's consistent
      with Section 2.2.4.  Updated examples to use "https" instead of
      "http".  Updated acknowledgements.

   -03:  Updated to use BCP 14 keywords.  Updated Section 2.1 and
      Section 2.1.1 to clarify ISE RFC use as a reference specification
      for an extension.

   -04:  Second WG last call edits: Updated "XML schemas, XML schema
      URIs, and XML namespace URIs" wording in Section 2.2.1.  Noted
      that the value of "TLDs" can be "N/A" in Section 2.2.2.  Updated
      "removed or deactivated" wording in Section 2.2.3.  Changed RFC
      3735 from an informative reference to a normative reference.
      Changed "IESG" to "IETF" in the "Registrant Name and Email
      Address" description in Section 2.2.1 and the example registration
      template in Section 2.2.2.  Updated obsolete normative references
      to RFCs 3979 and 4879 (obsoleted by RFC 8179/BCP 79).

Hollenbeck              Expires 10 December 2026               [Page 12]
Internet-Draft           EPP Extension Registry                June 2026

   -05:  Post-WG last call edits: changed "should not" to "SHOULD NOT"
      in the last sentence of Section 2.1.1.  Changed "RFC 5730" to "STD
      69" in Section 1 and added "STD 69" to Section 4.

   -06:  Shepherd write-up edit: Added "If approved" sentence to the
      Abstract.

   -07:  AD review edits.

   -08:  IESG evaluation edits.

Author's Address

   Scott Hollenbeck
   Verisign Labs
   12061 Bluemont Way
   Reston, VA 20190
   United States of America
   Email: sah@sahollenbeck.com, shollenbeck@verisign.com
   URI:   https://www.verisignlabs.com/

Hollenbeck              Expires 10 December 2026               [Page 13]