Section 3.12.5 says as follows:
"The content of the class is of type REAL and specifies a numerical
assessment in the confidence of the data when the value of the rating
attribute is "numeric". Otherwise, this element MUST be empty."

The current schema does not allow the confidence class to have the content (REAL type), thus the correction (note the addition of "<xs:extension base="xs:float">") is proposed.

"DomainData
Zero or more. The domain (DNS) information associated with this
node. If an Address is not provided, at least one DomainData MUST
be specified. See Section 3.19.

Address
Zero or more. The hardware, network, or application address of
the node. If a DomainData is not provided, at least one Address
MUST be specified. See Section 3.18.1."

To comply with the above definition, "minOccurs" attribute for both DomainData and Address elements need to be removed. (Current schema allows to omit both of the elements, but the RFC says that at least one of them need to be presented.)

The attributes of the iodef:ExtensionType type are:
name
Optional. STRING. A free-form name of the field or data element.
dtype
Required. ENUM. The data type of the element content. The
default value is "string". These values are maintained in the
"ExtensionType-dtype" IANA registry per Section 10.2.
1. boolean. The element content is of type BOOLEAN.
2. byte. The element content is of type BYTE.
3. bytes. The element content is of type HEXBIN.
4. character. The element content is of type CHARACTER.
5. date-time. The element content is of type DATETIME.
6. ntpstamp. Same as date-time.
7. integer. The element content is of type INTEGER.
8. portlist. The element content is of type PORTLIST.
9. real. The element content is of type REAL.
10. string. The element content is of type STRING.
11. file. The element content is a base64-encoded binary file
encoded as a BYTE[] type.
12. path. The element content is a file-system path encoded as a
STRING type.
13. frame. The element content is a Layer 2 frame encoded as a
HEXBIN type.
14. packet. The element content is a Layer 3 packet encoded as a
HEXBIN type.
15. ipv4-packet. The element content is an IPv4 packet encoded
as a HEXBIN type.
16. ipv6-packet. The element content is an IPv6 packet encoded
as a HEXBIN type.
17. url. The element content is of type URL.
18. csv. The element content is a comma-separated value (CSV)
list per Section 2 of [RFC4180] encoded as a STRING type.
19. winreg. The element content is a Microsoft Windows registry
key encoded as a STRING type.
20. xml. The element content is XML. See Section 5.2.
21. ext-value. A value used to indicate that this attribute is
extended and the actual value is provided using the
corresponding ext-* attribute. See Section 5.1.1.

It should say:

The attributes of the iodef:ExtensionType type are:
name
Optional. STRING. A free-form name of the field or data element.
dtype
Required. ENUM. The data type of the element content. The
default value is "string". These values are maintained in the
"ExtensionType-dtype" IANA registry per Section 10.2.
1. boolean. The element content is of type BOOLEAN.
2. byte. The element content is of type BYTE.
3. bytes. The element content is of type HEXBIN[].
4. character. The element content is of type CHARACTER.
5. date-time. The element content is of type DATETIME.
6. ntpstamp. Same as date-time.
7. integer. The element content is of type INTEGER.
8. portlist. The element content is of type PORTLIST.
9. real. The element content is of type REAL.
10. string. The element content is of type STRING.
11. file. The element content is a base64-encoded binary file
encoded as a BYTE[] type.
12. path. The element content is a file-system path encoded as a
STRING type.
13. frame. The element content is a Layer 2 frame encoded as a
HEXBIN[] type.
14. packet. The element content is a Layer 3 packet encoded as a
HEXBIN[] type.
15. ipv4-packet. The element content is an IPv4 packet encoded
as a HEXBIN[] type.
16. ipv6-packet. The element content is an IPv6 packet encoded
as a HEXBIN[] type.
17. url. The element content is of type URL.
18. csv. The element content is a comma-separated value (CSV)
list per Section 2 of [RFC4180] encoded as a STRING type.
19. winreg. The element content is a Microsoft Windows registry
key encoded as a STRING type.
20. xml. The element content is XML. See Section 5.2.
21. ext-value. A value used to indicate that this attribute is
extended and the actual value is provided using the
corresponding ext-* attribute. See Section 5.1.1.

Notes:

Section 2.5.2 (explanation of HEXBIN and HEXBIN[] types) says:
" A binary octet encoded as a character tuple consistent of two
hexadecimal digits is represented in the information model by the
HEXBIN data type. A sequence of these octets is of the HEXBIN[] data
type.
The HEXBIN and HEXBIN[] data types are implemented in the data model
as an "xs:hexBinary" type per Section 3.2.15 of [W3C.SCHEMA.DTYPES]."

If I am reading that section correctly, HEXBIN is for hex-encoded things that decode to exactly one byte, while HEXBIN[] is for hex-encoded things that decode to one or more bytes. Thus, things that may decode to multiple bytes should be HEXBIN[], not HEXBIN.

The extension types in Section 2.16 that are currently HEXBIN should probably be HEXBIN[]. The name "bytes" implies decoding to multiple bytes (so it should be HEXBIN[]). Frames and packets (regardless of layer) tend to be multiple bytes long (so they should be HEXBIN[] as well).

Change: Update Section 3.29.1 to show that AlternativeIndicatorID contains IndicatorIDs, not IndicatorReferences.

From the notations part of the introduction (Section 1.2), the UML diagrams in Section 3 are non-normative, and the "IODEF Data Model (XML Schema)" in Section 8 is normative.
If my understanding of the text is correct, this means that if the UML diagrams conflict with the schema in Section 8, the schema in Section 8 is correct, and the UML diagrams must be changed to align with the schema in Section 8.

Page 153 of the document contains the (normative) AlternativeIndicatorID schema from Section 8:

From the above schema, the AlternativeIndicatorID is a sequence of IndicatorID, not the sequence of IndicatorReference implied by Section 3.29.2 (Figure 61 and the accompanying text). Thus, if I understand the document correctly, Section 3.29.2 must be changed to something more like the "Corrected Text" in this report.

In section 3.9, the body text says that the role attribute can take the value "vendor-support," but the schema says that the role can take the value "vendor-services." This inconsistency needs to be solved.

The Node class identifies a system, asset, or network and its
location.
+---------------+
| Node |
+---------------+
| |<>--{0..*}--[ DomainData ]
| |<>--{0..*}--[ Address ]
| |<>--{0..1}--[ PostalAddress ]
| |<>--{0..*}--[ Location ]
| |<>--{0..*}--[ Counter ]
+---------------+
Figure 34: The Node Class
The aggregate classes of the Node class are:
DomainData
Zero or more. The domain (DNS) information associated with this
node. If an Address is not provided, at least one DomainData MUST
be specified. See Section 3.19.
Address
Zero or more. The hardware, network, or application address of
the node. If a DomainData is not provided, at least one Address
MUST be specified. See Section 3.18.1.
PostalAddress
Zero or one. POSTAL. The postal address of the node.
Location
Zero or more. ML_STRING. A free-form text description of the
physical location of the node. This description may provide a
more detailed description of where at the address specified by the
PostalAddress class this node is found (e.g., room number, rack
number, or slot number in a chassis).

It should say:

The Node class identifies a system, asset, or network and its
location.
+---------------+
| Node |
+---------------+
| |<>--{0..*}--[ DomainData ]
| |<>--{0..*}--[ Address ]
| |<>--{0..1}--[ PostalAddress ]
| |<>--{0..*}--[ Location ]
| |<>--{0..*}--[ Counter ]
+---------------+
Figure 34: The Node Class
The aggregate classes of the Node class are:
DomainData
Zero or more. The domain (DNS) information associated with this
node. If an Address is not provided, at least one DomainData MUST
be specified. See Section 3.19.
Address
Zero or more. The hardware, network, or application address of
the node. If a DomainData is not provided, at least one Address
MUST be specified. See Section 3.18.1.
PostalAddress
Zero or one. The postal address of the node. See Section 3.9.2.
Location
Zero or more. ML_STRING. A free-form text description of the
physical location of the node. This description may provide a
more detailed description of where at the address specified by the
PostalAddress class this node is found (e.g., room number, rack
number, or slot number in a chassis).

Note that the schema is referring to the PostalAddress class (iodef:PostalAddress) instead of the "PAddress" (POSTAL) member of the PostalAddress class. Also, the UML diagram (Figure 34) and other parts of Section 3.18 refer to the PostalAddress class instead of the "PAddress" (POSTAL) member of the PostalAddress class. Thus, the "PostalAddress" field of the Node class is most likely an instance of the PostalAddress class, and not the POSTAL type stated in the text.

The corrected text ("The aggregate classes of the Node class are... PostalAddress") includes a reference to the PostalAddress class ("See Section 3.9.2") instead of the "POSTAL." type.