[mile] Review of rfc5070bis and schema

["Waltermire, David A." <[e-mail]>]

Please find below comments based on my review of the rfc5070bis and the associated schema. Please let me know if you have any questions.

 

Sincerely,

Dave

 

------------

Section 2.4:

The following text is diffecult to parse. Consider rephrasing:

This relationship between multiple
classes being translated instances of the same text is indicated by a
common identifier set in the translation-id attribute.

Section 2.12:

Isn't this implemented as the PostalAddressType in the schema not xs:string?

Section 2.16:

There is a cross reference for the text "Section 3.3.8" that looks like it is incorrect.


General schema Comments:
- The schema is missing an XML declaration at the beginning.
- Some type names are inconsistant with the overall type naming scheme (e.g., systemimpact-type-type)
- The type "yes-no-type" is not referenced in the schema.
- The outline numbering has many singular subsections (e.g., 3.13.1). This issue may get raised by the RFC editor and should probably get fixed/clarified before then.
- Schema types for the REAL i/d type vary between float and double. Is there a reason for this (e.g., Counter -> xs:double)? If so, it may make sense to have specific types in the i/d to reflect the distinction.
- The prefixes used in section 3 and subsections (e.g., ds, xml) should be documented at the beginning of section 3 for clarity.

Section 3.2:

- The cardinality of IndicatorData in the schema is 0..1 while in the i/d it is 0..*
- The observable-id attribute is marked as the STRING type, but is an xs:ID type in the schema. All instances of xs:ID are required to be unique in an XML instance. For this reason it should be marked as an ID type in the i/d. This means we need a datatype for ID in section 2.
- The definition for status -> ext-value uses the terminology "An escape value used to extend this attribute". I recommend against using the term "escape" here to avoid confusion with escaping. Perhaps it would be better to use "A value used to indicate that this attribute is extended and the actual value is provided using the ext-status attribute."

Section 3.3:
- The colors values in the restriction class provide mappings to other provided values, but they do not define the meaning of the colors. They seem to relate to TLP. Perhaps we should reference the related UK TLP work?

Section 3.6:
- The cardinality of IncidentId, URL, ThreatActor, and Campaign in the schema are 1..*. In the i/d this matches in the UML text, but not in the diagrams where they are 0..*. The cardinality on the parent choice (1..*) should allow the individual elements to be 1..1. Let me know if you have any questions on this.

Section 3.7:
- ThreatActor -> ThreatActorId is inconsistant in the schema (1..1), diagram (0..1), and text (1..*).
- ThreatActor -> Description is inconsistant in the schema and diagram (0..*), and text (1..*).

Section 3.8
- Campaign -> CampaignID and Description are inconsistant in the schema and diagram (0..1), and text (1..*).

Section 3.9
- The schema is missing the ext-dtype attribute documented in the i/d.

Section 3.10
- Is there a reason that Fax is limited to 0..1? I would guess some organizations may have more than one Fax #.

Section 3.10.2
- The attribute 'translation-id' is missing in the i/d diagram and text.

Section 3.12.1
- The requirement for at least one of Description or DetectionConfiguration can be modeled a xs:choice with 1..* cardinality in the schema. Other classes can probably be improved in the same way.

Section 3.13:
- The element 'enum:Reference' in the i/d is not in the enum namespace in the schema.

Section 3.13.1:
- The element 'ReferenceName' should be 'enum:ReferenceName' in the i/d text.
- The text starting with "At least one of these classes MUST be present." appears to be improperly nested in the i/d.

Section 3.14:
- The text:

A least one instance of the possible three impact classes (i.e.,
Impact, TimeImpact, or MonetaryImpact) MUST be present.

Should read as:

A least one instance of the possible five impact classes (i.e.,
SystemImpact, BusinessImpact, TimeImpact, MonetaryImpact, or
IntendedImpact) MUST be present.

- The IntendedImpact class doesn't appear to be documented in this section. The text is confusing on this:

Identically defined as Section 3.14.2 but describes intent rather
      than the realized impact.

Should be:

Identical to the BusinessImpact class defined in Section 3.14.2, but describes the intent rather
      than the realized impact.


Section 3.14.1:
- The attribute 'type' does not have the 'unknown' default value defined in the schema. 'unknown' is not a valid enum value.
- The attribute 'type' allow the enum value admin in the schema. This value is not documented in the i/d.

Section 3.14.3:
- The schema is missing the 'ext-metrics' and 'ext-duration' attributes defined in the i/d.

Section 3.14.5:

The 'Confidence' class is defined in the schme as:

  <xs:element name="Confidence">
    <xs:complexType mixed="true">
      <xs:attribute name="rating" use="required" type="confidence-rating-type"/>
    </xs:complexType>
  </xs:element>

To match the i/d it should be defined in the schema as:

  <xs:element name="Confidence">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="iodef:PositiveFloatType">
          <xs:attribute name="rating" use="required" type="confidence-rating-type"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>


Section 3.15:
- The cardinality for 'HistoryItem' is "One or many." This is different than the use of "One or more." in the rest of the document. This should be made consistant with the rest of the draft. Also, check for other cases of this.

Section 3.19:
- The schema allows Node to be 1..* while the i/d diagram and text is 1..1.

Section 3.20:
- The schema defines a NodeRole element that is not documented in the i/d.
- The i/d defines a DateTime element that is not defined in the schema.

Section 3.20.1:
- The base type of this class is xs:string in the schema. The i/d diagram does not reflect this.
- Should the default for category be ipv6-addr given the emphasis on transition?

Section 3.20.2:
- The base type of this class is MLString in the schema. The i/d diagram does not reflect this.
- The i/d diagram and text is also missing the attribute translation-id.
- NodeRole -> Category is inconsistant where the schema has 'c2-server' and the i/d has 'c2'.

Section 3.20.3:
- The schema is missing the ext-unit attribute.

Section 3.21.1:
- The values for 'record-type' are not documented in the i/d. There is a "TODO" placeholder in the i/d.

Section 3.21.3:
- The 'SameDomainContact' element is 1..1 in the schema and 0..1 in the i/d diagram and text.

Section 3.22:
- The choice between 'Port' and 'Portlist' should be changed to be 1..1 in the schema to reflect the requirement for one of the two to be used in the i/d.

Section 3.22.1:
- The 'IANAService' element is 1..1 in the schema and 0..1 in the i/d diagram and text,

Section 3.22.2:
- The attribute 'proto-name' is an xs:integer in the schema and xs:string in the i/d. It looks like the schema needs to be changed based on the i/d text.
- The attribute 'ext-dtype' is missing in the schema.
- the attribute 'dtype' is missing values "portlist" and "path" in the schema.

Section 3.22.4:
- The attribute has the name 'ext-dtype' in the schema and 'enum-dtype' in the i/d diagram.
- SoftwareReference -> spec-name -> swid entry needs to have the actual reference provided. Look for "fix me."

Section 3.24:
- The cardnalities of EmailHeaderField, HashData, and SignatureData are 0..* in the i/d diagram and 0..1 in the schema and i/d text.

Section 3.25.1:
- The 'RecordItem' element is 1..* in the schema and 0..* in the i/d diagram and text.

Section 3.26.1:
- The attribute 'observable-id' is missing in the schema.

Section 3.27.1:
- The element 'ds: X509Data' has a space in the i/d diagram that should be removed.

Section 3.28.1:
- The element 'FileType' has the type xs:integer in the schema and xs:string in the i/d. The schema should be changed to xs:string based on the i/d text.
- The elements 'SignatureData' and 'AssociatedSoftware' in the i/d are named differently in the schema.

Section 3.29:
- The attribute 'ext-scope', which is defined in the schema, is missing in the i/d diagram.

Section 3.29.1:
- The element 'ds:CannonicalizationMethod' is 0..1 in the i/d and 1..1 in the schema.

Section 3.29.2:
- The element AdditionalData is 0..* in the i/d and 1..1 in the schema.

Section 3.32:
- The element 'AlternativeIndicatorID' is 0..* in the schema and 0..1 in the i/d.
- The element 'AdditionalData' is missing in the schema.

Section 3.32.3:
- The attributes 'restriction' and 'ext-restriction' are defined in the schema and are missing in the i/d.
- The element 'Service' is missing in the schema.
- The element 'AdditionalData' is 0..1 in the schema and 0..* in the i/d.
- A choice should be used to model the "extactly one" requirement.

Section 3.32.3.1:
- The element 'BulkObservableList' is 0..1 in the schema and 1..1 in the i/d.
- The element 'AdditionalData' is 0..1 in the schema and 0..* in the i/d.

Section 3.32.4:
- The cardinality of the elements do not match in the schema and i/d.

Section 3.32.6:
- It is not clear what the type "EMPTY" means here.
- I don't recall if the "IDREF" data type was defined in section 2.

Section 3.32.7:
- It is not clear what the type "EMPTY" means here.
- I don't recall if the "IDREF" data type was defined in section 2.