diff --git a/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-schema.adoc b/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-schema.adoc
index bcf1fb8278..685523ffc6 100644
--- a/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-schema.adoc
+++ b/opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-schema.adoc
@@ -760,16 +760,18 @@ When introducing DIT structure rules to an established (preexisting) DIT, it is
 [#dsr-subentries-schema]
 
 ==== Considerations For Collective Attribute Subentries
-DIT structure rules apply not only to standard entries as demonstrated in the previous section, but also to subentries -- entries that bear the `subentry` STRUCTURAL class defined in http://tools.ietf.org/html/rfc3672#section-2.4[Section 2.4 of RFC 3672, window=_blank].
 
-In cases where a directory server employs DIT structure rules in addition to collective attributes, it is necessary to implement a new `dITStructureRules` definition: one that enforces a suitable RDN attribute type (such as `cn`) for subentries, while taking into account the superior structure rule(s) involved.
+Currently, as of version 4.8.0, DIT structure rules are wrongly applied not only to standard entries as demonstrated in the previous section, but also to subentries -- entries that bear the `subentry` STRUCTURAL class defined in http://tools.ietf.org/html/rfc3672#section-2.4[Section 2.4 of RFC 3672, window=_blank]. This is in violation of https://www.itu.int/rec/T-REC-X.501[ITU-T Rec. X.501, window=_blank] and https://datatracker.ietf.org/doc/html/rfc3672[RFC 3672, window=_blank]. At the time of this writing, is not known whether this issue will be resolved.
 
-To begin, as was done in the previous section, a nameForms definition is required first.
+In the interim, in cases where a directory server employs DIT structure rules in addition to collective attributes, it is necessary to implement a new `dITStructureRules` definition: one that enforces a suitable RDN attribute type (such as `cn`) for subentries, while taking into account the superior structure rule(s) involved.
+
+To begin, as was done in the previous section, a name form definition is required. For this, we'll extract the appropriate definition directly from https://www.itu.int/rec/T-REC-X.501[clause 14.2.2 of ITU-T Rec. X.501, window=_blank], as this represents the ONLY valid name form for such use cases.
 
 [source]
 ----
-      nameForms: ( 1.3.6.1.4.1.56521.999.2.7.5
-         NAME 'subentryForm'
+      nameForms: ( 2.5.15.16
+         NAME 'subentryNameForm'
+         DESC 'X.501, cl. 14.2.2: the Subentry name form'
          OC subentry
          MUST cn )
 ----
@@ -786,7 +788,7 @@ This leaves `domain` (20) and `organizationalUnit` (21) entries. Thus:
 ----
       dITStructureRules: ( 24
          NAME 'subentryStructure'
-         FORM subentryForm
+         FORM subentryNameForm
          SUP ( 20 21 ) )
 ----
 
@@ -794,6 +796,8 @@ Because subentries themselves do not allow for subordinate entries, we need not
 
 When implemented (and with respect to the parameters of the previous subsection), the definitions defined in this subsection will correctly allow for the addition of entries bearing the `subentry` STRUCTURAL class, thus allowing use of dependent constructs, such as collective attributes, to be used unfettered.
 
+If and when this issue is resolved, the above schema DIT structure rule and name form definitions will become unnecessary and should be removed.
+
 [#aci-vs-dsr-schema]
 
 ==== ACIs Vs. DIT Structure Rules