draft-coretta-oiddir-roadmap-01.txt

RADIR                                                         J. Coretta
Internet-Draft                                           August 27, 2024
Intended status: Experimental
Obsoletes: X660LDAP
Expires: February 23, 2025


                        The OID Directory:
                        A Technical Roadmap
                draft-coretta-oiddir-roadmap-01.txt

Abstract

   This I-D outlines a series of experimental standards documents which
   define the abstracts of the "OID Directory": a proposed philosophy
   and set of procedures used to facilitate the storage and management
   of the "OID tree" -- in part or in whole -- within an X.500/LDAP
   service implementation.

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 February 23, 2025.

Copyright Notice

   Copyright (c) 2024 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Coretta                Expires February 23, 2025                [Page 1]

Internet-Draft        The OID Directory: Roadmap             August 2024


Table of Contents

   1. Introduction ....................................................2
      1.1. Relation to draft-coretta-x660-ldap ........................2
      1.2. Conventions ................................................3
      1.3. Acronyms Used ..............................................4
      1.4. Intended Audience ..........................................4
      1.5. Alternatives ...............................................5
      1.6. Allocations ................................................5
      1.7. Key Citations and Generalizations ..........................5
      1.8. Common Operations and Concepts .............................7
         1.8.1. Read and Search .......................................7
         1.8.2. Modify ................................................9
         1.8.3. Add ...................................................9
         1.8.4. Delete ................................................9
         1.8.5. Modify DN ............................................10
   2. Supporting I-Ds ................................................10
      2.1. 'draft-coretta-oiddir-schema' .............................10
      2.2. 'draft-coretta-oiddir-radua' ..............................10
      2.3. 'draft-coretta-oiddir-radsa' ..............................11
      2.4. 'draft-coretta-oiddir-radit' ..............................11
   3. IANA Considerations ............................................11
   4. Security Considerations ........................................11
   5. References .....................................................11
      5.1. Normative References ......................................11
      5.2. Informative References ....................................11
   6. Ongoing Collaborative Resources ................................13
      6.1. The 'oid-directory' Repositories ..........................13
      6.2. The 'oid.directory' Internet Domain .......................13
   Author's Address ..................................................13

1.  Introduction

   This I-D series combines relevant components of ITU-T Recommendations
   [X.500], [X.660], [X.680], [RFC4510] and many others to define models
   and procedures of the "OID Directory" construct.

   The "OID Directory" is the X.500/LDAP facility for managing the "OID
   tree" -- in part or in whole -- in the context of OID Registration
   Authority operations, whether public or private.

   Additionally, unofficial components have been devised or appropriated
   specifically to aid adopters in overcoming various feasibility and
   logistical challenges that may arise during an implementation.

   This I-D series OBSOLETES all revisions of 'draft-coretta-x660-ldap'
   (X660LDAP).  See Section 1.1 for details.

   This I-D series -- as a whole -- is EXPERIMENTAL.  Implementations of
   any component set forth within this series SHOULD NOT manifest EXCEPT
   for any testing or proof-of-concept efforts.


Coretta                Expires February 23, 2025                [Page 2]

Internet-Draft        The OID Directory: Roadmap             August 2024


1.1.  Relation to 'draft-coretta-x660-ldap'

   This I-D was first published towards the end of 2020 under the formal
   name 'draft-coretta-x660-ldap' (X660LDAP) and had reached nine (9)
   revisions.  It originally held the title:

      "Lightweight Directory Access Protocol (LDAP) Procedures and
       Schema Definitions for the Storage of X.660 Registration
       Information"

   Subsequent community feedback -- although generally favorable --
   suggested that some of the proposed subject matter was external to
   the core precepts of ITU-T Rec. [X.660], which confused some readers.

   Eventually, it was decided this document should be re-submitted with
   a more generalized title. This single change satisfied nearly all
   instances of criticism while preserving the intended spirit of the
   I-D without misleading readers as it relates to the true scope of
   relevant standards.

   Furthermore, it was decided that, due to the overall breadth and
   complexity of the standards proposed, the I-D should be divided into
   multiple supporting I-Ds in a more focused manner.  This has the
   secondary effect of allowing potential extensions of this concept
   in the future to be set forth in a more modular manner.

   Aside from the correction of typographical and formatting errors
   previously identified, the following additional changes have been
   made to the new I-D(s):

     - Collective Attribute [RFC3671] support within this I-D series is
       now more well-defined.

     - Administrative procedures and considerations have been expanded
       throughout many areas of the I-D series.

     - The scope of potential candidates for adoption of the I-D series
       has been expanded in Section 1.4.

     - Added new schema definitions and optimized several existing
       definitions within the RASCHEMA I-D.

     - A short list of alternative solutions to this I-D series has been
       added in Section 1.5.

     - The status of the I-D is 'Experimental' (was 'Standards Track').

     - Citations and references now favor current editions of certain
       ITU-T Recommendations of relevance.

     - Author's physical address has reduced specificity.


Coretta                Expires February 23, 2025                [Page 3]

Internet-Draft        The OID Directory: Roadmap             August 2024


1.2.  Conventions

   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.

   The convention "I-D series" describes the entire suite of I-Ds which
   constitute the overall philosophy of the "OID Directory".  The term
   implies not only those I-Ds cited in Section 2, but also any future
   I-Ds that may be submitted as extensions by any author.

   The convention "OID tree" describes the hypothetical data structure
   that houses or represents all known public or private registrations
   that have ever been allocated.

1.3.  Acronyms Used

   The "OID Directory" I-D series makes reference to many acronyms, each
   of which are defined as follows:

      2FA    Two-Factor Authentication
      ABNF   Augmented Backus-Naur Form
      API    Application Programming Interface
      ASCII  American Standard Code for Information Interchange
      ASN.1  Abstract Syntax Notation one
      AVA    Attribute Value Assertion
      AXFR   (DNS) Authoritative Zone Transfer
      BE     Big-Endian
      DAP    Directory Access Protocol
      DIB    Directory Information Base
      DISP   Directory Information Shadowing Protocol
      DIT    Directory Information Tree
      DN     Distinguished Name
      DNS    Domain Name System
      DOP    Directory Operational Binding Management Protocol
      DSA    Directory System Agent
      DSE    DSA-Specific Entry
      DSP    Directory System Protocol
      DUA    Directory User Agent
      GUI    Graphical User Interface
      GUID   Globally Unique Identifier
      I-D    Internet-Draft (of this series)
      IPC    Interprocess Communication
      IRI    Internationalized Resource Identifier
      IXFR   (DNS) Incremental Zone Transfer
      LDAP   Lightweight Directory Access Protocol
      LDIF   LDAP Data Interchange Format
      OID    ASN.1 Object Identifier
      ORS    OID Resolution Service


Coretta                Expires February 23, 2025                [Page 4]

Internet-Draft        The OID Directory: Roadmap             August 2024


      OTP    One-Time Pass
      PEN    IANA Private Enterprise Number
      RA     Registration Authority
      RDN    Relative Distinguished Name
      SDK    Software Development Kit
      TLS    Transport Layer Security
      TTL    Time to Live
      TUI    Textual User Interface
      URI    Uniform Resource Identifier
      UUID   Universal Unique Identifier

1.4.  Intended Audience

   This I-D series will be most useful to an RA of any context, whether
   public or private.  This was, and shall always be, the primary goal
   of this effort.

   Other potential candidates include, but are not limited to:

     - Hardware manufacturers
     - Weather Services
     - Major internet technology companies
     - Internet Service Providers
     - Military/Allied directories
     - Healthcare service providers
     - Mainstream directory software product maintainers/vendors
     - ASN.1 professionals, particularly developers tasked with
       maintaining certain types of encoders and decoders

   Sufficed to say, any entity or individual that directly queries or
   uses ASN.1 object identifier information in frequent or critical
   fashion may be a candidate for this I-D series.

1.5.  Alternatives

   Alternatives to this I-D series include, but are not limited to:

     - Implementation of ORS, per ITU-T Rec. [X.672]
     - Use of proprietary end-user applications
     - Use of third party OID registration authority websites
     - Reference raw ASN.1 definitions or relevant standards
     - Implementation of a custom, in-house solution

1.6.  Allocations

   This I-D series has been allocated the following numeric OID prefix:

     - 1.3.6.1.4.1.56521.101

   Other I-Ds in this series extend this registration further.



Coretta                Expires February 23, 2025                [Page 5]

Internet-Draft        The OID Directory: Roadmap             August 2024


   Should this I-D series be elevated to RFC status, the aforementioned
   OID prefix shall be rendered obsolete in favor of an IANA-assigned
   OID, at which point this I-D series will be updated to reference the
   literal 'IANA-ASSIGNED-OID' placeholder prefix where appropriate.

1.7.  Key Citations and Generalizations

   Certain constructs and operations are cited frequently throughout
   this I-D series, each of which are covered below.

   Generalized phrasing is meaningful only within the bounds of this I-D
   series and only where specificity is not relevant in context.

   The DAP Modify Operation is defined in clause 12.3 of ITU-T Rec.
   [X.511].  The LDAP Modify Operation is defined in Section 4.6 of
   [RFC4511].  The term "Modify Operation" is used to describe either
   of these operations.

   The DAP Modify DN Operation is defined in clause 12.4 of ITU-T Rec.
   [X.511].  The LDAP Modify DN Operation is defined within Section 4.9
   of [RFC4511].  The term "Modify DN Operation" is used to describe
   either of these operations.

   The DAP Search Operation is defined in clause 11.2 of ITU-T Rec.
   [X.511].  The DAP List Operation, considered an alternative form of
   DAP Search, is defined in clause 11.1 of ITU-T Rec. [X.511].   The
   LDAP Search Operation is defined in Section 4.5 of [RFC4511].  The
   term "Search Operation" is used to describe either DAP or LDAP Search
   Operations.  Similarly, "List Operation" is the term used to describe
   either the DAP List Operation or an LDAP Search Operation using the
   singleLevel scope.

   The DAP Read Operation is defined within clause 10.1 of ITU-T Rec.
   [X.511].  The term "Read Operation" is used to describe either this
   operation or a baseObject-scoped LDAP Search Operation.

   The DAP Remove Entry Operation is defined in clause 12.2 of ITU-T
   Rec. [X.511].  The LDAP Delete Operation is defined in Section 4.8 of
   [RFC4511].  The term "Delete Operation" is used to describe either
   of these operations.

   The DAP Add Entry Operation is defined in clause 12.1 of ITU-T Rec.
   [X.511].  The LDAP Add Operation is defined within Section 4.7 of
   [RFC4511].  The term "Add Operation" is used to describe either
   of these operations.

   The DAP SearchArgumentData.subset parameter is defined in clause
   11.2.1 of ITU-T Rec. [X.511].  The LDAP SearchRequest.scope parameter
   is defined in Section 4.5.1 of [RFC4511].  The terms "scope" and
   "scoped" describe either of these components in the context of a
   "Search Operation".


Coretta                Expires February 23, 2025                [Page 6]

Internet-Draft        The OID Directory: Roadmap             August 2024


   The DAP EntryInformationSelection ASN.1 SET is defined in clause 7.6
   of ITU-T Rec. [X.511].  The LDAP SearchRequest.attributeSelector is
   defined in Section 4.5.1.8 in [RFC4511].  The terms "selection" and
   "selector" describe either of these components in the context of
   refining the presentation of attribute types derived from entries
   obtained by way of the Search or Read Operations.

   The DAP EntryInformationSelection.infoTypes.attributeTypesOnly
   parameter is defined within clause 7.6 of ITU-T Rec. [X.511].  The
   equivalent LDAP SearchRequest.typesOnly parameter is defined in
   Section 4.5.1 of [RFC4511].  The term 'typesOnly' refers to either
   of these constructs in the context of occluding values during the
   presentation of entries retrieved using Read or Search Operations.

   The concepts of DIT Content Rules, DIT Structure Rules and Name Forms
   are defined throughout Section 6 of ITU-T Rec. [X.501] and in Section
   4.1 of [RFC4512].

   The term "Write Operation" is an informal term used within this I-D
   series.  In context, it can be used to refer to any of "Modify DN",
   "Modify", "Add" and "Delete" operation generalizations defined above
   wherever specificity is not required.

   The root DSE is discussed in Section 5 of [RFC4512] and within clause
   23.4.2 of ITU-T Rec. [X.501].

   The 'subschemaSubentry' is defined in Section 4.2 of [RFC4512].

   Collective attributes, including associated subtree and subentry
   mechanics -- including the 'subtreeSpecification' attribute type --
   are defined throughout [RFC3671], [RFC3672] and ITU-T Rec. [X.501].

1.8.  Common Operations and Concepts

   The following subsections describe where the standard DAP and LDAP
   Operations itemized in Section 1.7 apply within this I-D series, and
   in what manner.

   Not all Operations will necessarily have a direct correlation to any
   specific procedures set forth within this I-D series.  For instance,
   none of the procedures have any specific associations with Extended,
   Bind or Unbind Operations defined within both ITU-T Rec. [X.511] and
   [RFC4511].

1.8.1.  Read and Search

   The Search and Read Operations are the most critical used within this
   I-D series, regardless of the nature of implementation.





Coretta                Expires February 23, 2025                [Page 7]

Internet-Draft        The OID Directory: Roadmap             August 2024


   The Read Operation is used to retrieve or "call" specific individual
   entries from the RA DIT.  This requires foreknowledge of the target
   DN, but is RECOMMENDED as standard procedure in the intended spirit
   of this I-D series.  This operation should ONLY return either one (1)
   entry or none.

   The Search Operation is used to retrieve multiple entries within a
   request, typically in the context of a directory subtree.  Specific
   foreknowledge of the desired entries is not required, however input
   of SearchRequest (LDAP) or SearchArgumentData (DAP) will require
   added specificity in terms of the scope (LDAP) or subset (DAP) in
   use, the filter supplied, and other parameters such as a selector.

   The Search Operation is usually discouraged for use by end users
   unless baseObject-scoped.  Use in administratively-focused RA DUA
   implementations is acceptable.

   The following subsections cover relevant parameters extended by the
   SearchRequest and SearchArgumentData constructs.

1.8.1.1.  baseObject

   The baseObject parameter defined within the SearchRequest (LDAP) and
   SearchArgumentData constructs defines the Name of the targeted entry
   as a DN.

   There is no default value within the context of this I-D series, as
   this will be influenced based on the activities of the RA DUA.

1.8.1.2.  scope and subset

   The scope of a Search Operation defines the depth of the intended
   operation in terms of 'baseObject' (0), 'singleLevel' (1) and
   'wholeSubtree' (2).

   The default scope or subset for the RA DUA SHOULD be 'baseObject'.
   This is analogous to the Read Operation.  The RA DUA MAY allow user
   override of this parameter when appropriate.

1.8.1.3.  typesOnly and attributeTypesOnly

   During the presentation of a retrieved entry, the specification of
   (LDAP) typesOnly or (DAP) attributeTypesOnly parameters results in
   the discarding of values.

   This is often desirable in cases where the presence of entries alone
   is the focus -- not their content.

1.8.1.4.  filter

   Use of a filter adds conditions to the successful matching of entries
   to be retrieved by way of the Read or Search Operations.

Coretta                Expires February 23, 2025                [Page 8]

Internet-Draft        The OID Directory: Roadmap             August 2024


   Although generally not required of the user, certain procedures set
   forth in this I-D require use of a filter, for example during a range
   check to be conducted prior to allocation of an OID.  Generally the
   RA DUA is expected to manage such activities.

   The RA DUA may allow user-defined statements to be used for routine
   or administrative operation, if appropriate.

1.8.1.5.  attribute selection

   The attribute selection parameters may be used to specify desired
   attribute types to be retrieved, if defined, as a result of a Read
   or Search Operation upon an entry.

   Use of a selector by the RA DUA in virtually all cases is STRONGLY
   RECOMMENDED.

   The RA DUA MAY allow user-defined overrides, such as '+', '*', '1.1'
   or explicit attribute type descriptions if appropriate in context.

1.8.2.  Modify

   The Modify Operation is usually among the lesser-used operations in
   the terms of this I-D series.

   Aside from unusual or extraordinary circumstances, 'registration'
   entries themselves are not typically edited.

   'registrant' entries, however, may be prone to updates, as they will
   contain contact information -- such as email addresses and telephone
   numbers -- for the respective authority.

   The nature of this I-D series does not impose any particular practice
   or recommended procedure relating to the Modify Operation itself.

   Modification operations, in general, SHOULD be limited to authorized
   personnel or the respective "owners" of certain 'registration' and/or
   'registrant' entries as deemed appropriate.

1.8.3.  Add

   The Add Operation is used for the creation of new 'registration' or
   'registrant' entries.

   Generally this operation would be conducted by either the owner of
   the respective allocation, or the RA administrative personnel in the
   event the RA DSA supports this operation.

   The addition of new 'registration' entries MUST ONLY occur below the
   appropriate 'rARegistrationBase' value.  Similarly, the addition of
   new 'registrant' entries MUST ONLY occur below the appropriate
   'rARegistrantBase' value.

Coretta                Expires February 23, 2025                [Page 9]

Internet-Draft        The OID Directory: Roadmap             August 2024


   RA DUAs MUST observe the MAY and MUST clauses of the object class
   definitions within Section 2.5 of the RASCHEMA I-D.  These provide
   a rough inventory of the absolute minimum requirements for entry
   composition, as well as the OPTIONAL types available for use.

   The RA DUA MUST be prepared to observe additional restrictions or
   extensions that may be imposed through the use of DIT Content Rules,
   DIT Structure Rules and Name Forms held by the RA DSA.  This will
   influence the content of entries as well as the entry's DN structure.

1.8.4.  Delete

   The Delete Operation is among the least-used operations within the
   terms of this I-D series.

   'registration' entries themselves are generally not deleted outright,
   especially when public-facing.  Any given 'registration' entry SHOULD
   be labeled as OBSOLETE, DEALLOCATED or some other such designation of
   non-operation and left intact indefinitely.  The act of deleting a
   'registration' entry directly is often discouraged outside of unusual
   or extraordinary circumstances, and may have disastrous consequences
   if executed in cavalier fashion.

   The same point may or may not apply to 'registrant' entries.  Given
   the costs associated with modern storage options, RAs may not deem it
   worthwhile to preserve so-called orphaned 'registrant' entries -- in
   other words, 'registrant' entries not currently serving in authority
   for any registrations.  Use of the Delete Operation may be indicated.

   This I-D series makes no recommendation on the proper usage of the
   Delete Operation by appropriate personnel in the event of unusual or
   extraordinary circumstances.  Beyond purely administrative concerns,
   RA DUA adopters are STRONGLY ADVISED to consider the specifics of
   how and when deletion support should or should not be supported.

1.8.5.  Modify DN

   The Modify DN Operation is likely the least-used operation within the
   terms of this I-D series.

   Aside from unrelated administrative uses of this operation, such as
   an effort to "move" entries from "ou=OIDs,o=rA" into a newly created
   context "ou=Registrations,o=rA", or for the correction of a bogus DN,
   the Modify DN operation is not indicated within the I-D series.

2. Supporting I-Ds

   The following subsections each identify and describe various I-Ds
   that comprise and support this proposed standard as a whole.

   If any of these I-Ds are updated or revised in any way, the highest
   revision number supersedes any previous revision.

Coretta                Expires February 23, 2025               [Page 10]

Internet-Draft        The OID Directory: Roadmap             August 2024


2.1.  'draft-coretta-oiddir-schema'

   The 'draft-coretta-oiddir-schema' I-D contains many useful schema
   definitions that comprise the supporting schema for the so-called RA
   DIT.

   This I-D is hereafter cited and referenced as RASCHEMA.

2.2.  'draft-coretta-oiddir-radua'

   The 'draft-coretta-oiddir-radua' I-D describes the RA client within
   the traditional client/server model in terms of high-level concepts
   and procedures for proper interaction with the RA DSA.

   This I-D is hereafter cited and referenced as RADUA.

2.3.  'draft-coretta-oiddir-radsa'

   The 'draft-coretta-oiddir-radsa' I-D describes the RA server within
   the traditional client/server model in terms of high-level concepts
   and procedures for managing activities related to the RA DUA and RA
   DIT.

   This I-D is hereafter cited and referenced as RADSA.

2.4.  'draft-coretta-oiddir-radit'

   The 'draft-coretta-oiddir-radit' I-D defines guidelines and official
   procedures relating to the so-called RA DIT in terms of applicable
   design considerations, content models, storage and operating states,
   et al.

   This I-D is hereafter cited and referenced as RADIT.

3.  IANA Considerations

   There are no requests to IANA in this document at this time.

4.  Security Considerations

   See the RADUA, RADSA and RADIT I-Ds for security considerations.

5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", RFC 8174, May 2017.


Coretta                Expires February 23, 2025               [Page 11]

Internet-Draft        The OID Directory: Roadmap             August 2024


5.2.  Informative References

   RADIT      Coretta, J., "The OID Directory: The RA DIT",
              draft-coretta-oiddir-radit, February 2024.

   RADSA      Coretta, J., "The OID Directory: The RA DSA",
              draft-coretta-oiddir-radsa, February 2024.

   RADUA      Coretta, J., "The OID Directory: The RA DUA",
              draft-coretta-oiddir-radua, February 2024.

   RASCHEMA   Coretta, J., "The OID Directory: The Schema",
              draft-coretta-oiddir-schema, February 2024.

   [RFC3671]  Zeilenga, K., "Collective Attributes in the Lightweight
              Directory Access Protocol (LDAP)", RFC 3671, December
              2003.

   [RFC3672]  Zeilenga, K., "Subentries in the Lightweight Directory
              Access Protocol (LDAP)", RFC 3672, December 2003.

   [RFC4510]  Zeilenga, K. "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC 4510, June
              2006.

   [RFC4511]  J. Sermersheim, Ed. "Lightweight Directory Access Protocol
              (LDAP): The Protocol", RFC 4511, June 2006.

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

   [X.500]    International Telecommunication Union - Telecommunication
              Standardization Sector, "The Directory: Overview of
              concepts, models and services", ITU-T X.500, October 2019.

   [X.501]    International Telecommunication Union - Telecommunication
              Standardization Sector, "The Directory: Models", ITU-T
              X.501, October 2019.

   [X.511]    International Telecommunication Union - Telecommunication
              Standardization Sector, "The Directory: Abstract service
              definition", ITU-T X.511, October 2019.

   [X.660]    International Telecommunication Union - Telecommunication
              Standardization Sector, "General procedures and top arcs
              of the international object identifier tree", ITU-T X.660,
              July 2011.





Coretta                Expires February 23, 2025               [Page 12]

Internet-Draft        The OID Directory: Roadmap             August 2024


   [X.672]    International Telecommunication Union - Telecommunication
              Standardization Sector, "OID resolution system: Problems,
              requirements and potential solutions", ITU-T X.672, March
              2020.

   [X.680]    International Telecommunication Union - Telecommunication
              Standardization Sector, "Abstract Syntax Notation One
              (ASN.1): Specification of basic notation", ITU-T X.680,
              July 2002.

6.  Ongoing Collaborative Resources

   This section contains information regarding resources, repositories
   and websites related to ongoing collaboration and participation for
   community members and experts alike with respect to this I-D series.

6.1.  The 'oid-directory' Repositories

   The following URL refers to a GitHub repository dedicated solely for
   management of each I-D in the (immediate) series:

     https://github.com/oid-directory/id

   The following URL refers to a GitHub repository dedicated for content
   relating to the RASCHEMA I-D:

     https://github.com/oid-directory/definitions

   Individuals or other parties interested in participating in this I-D
   series are encouraged to visit any or all of these repositories.

6.2.  The 'oid.directory' Internet Domain

   The public internet domain 'oid.directory' has been reserved for any
   relevant endeavors related to the I-D series in the future.

   Should the I-D be accepted and elevated to the status of RFC, this
   domain may be turned over to an appropriate entity or working group.

Author's Address

   Jesse Coretta
   California, United States

   Email: jesse.coretta@icloud.com









Coretta                Expires February 23, 2025               [Page 13]