Draft: draft-ietf-sacm-coswid

Commentary: Flagged firmware resource colletion appendix for revision Made use of terminology more consistent Better defined use of extension points in the CDDL Added definitions for indexed values Added IANA registry for  use indexed values
Paragraph (version A):
Software Inventory Management, a part of the Software Asset
Management SAM process, which requires an accurate list of
discernible deployed software components.
Paragraph (version B):
Software Inventory Management, a part of a Software Asset
Management SAM process, which requires an accurate list of
discernible deployed software components.
Paragraph (version A):
which maps human-readable labels of that content to more concise
integer labels (indices).  The use of CBOR to express SWID
information in CoSWID tags allows both CoSWID and SWID tags to be
part of an enterprise security solution for a wider range of
endpoints and environments.
Paragraph (version B):
which maps the human-readable labels of SWID data to more concise
integer labels (indices).  The use of CBOR to express SWID
information in CoSWID tags allows both CoSWID and SWID tags to be
part of an enterprise security solution for a wider range of
endpoints and environments.
Paragraph (version A):
In addition to defining the format of a SWID tag record, ISO/IEC
19770-2:2015 defines requirements concerning the SWID tag lifecycle.
Specifically, when a software component is installed on an endpoint,
that product's SWID tag is also installed.  Likewise, when the
product is uninstalled or replaced, the SWID tag is deleted or
replaced, as appropriate.  As a result, ISO/IEC 19770-2:2015
describes a system wherein there is a correspondence between the set
of installed software components on an endpoint, and the presence of
the correspondingsponding SWID tags for these components on that
endpoint.  CoSWIDs share the same lifecycle requirements as a SWID
tag.
Paragraph (version A):
The following is an excerpt (with some modifications and reordering)
from NIST Interagency Report (NISTIR) 8060: Guidelines for the
Creation of Interoperable SWID Tags SWID-GUIDANCE, which describes
the tag types used within the lifecycle defined in ISO-19770-2:2015.
Paragraph (version A):
Primary Tag - A SWID or CoSWID tag that identifies and describes a
software component is installed on a computing device.
Paragraph (version A):
Patch Tag - A SWID or CoSWID tag that identifies and describes an
installed patch which has made incremental changes to a software
component installed on a computing device.
Paragraph (version B):
In addition to defining the format of a SWID tag record, ISO/IEC
19770-2:2015 defines requirements concerning the SWID tag lifecycle.
Specifically, when a software component is installed on an endpoint,
that software component's SWID tag is also installed.  Likewise, when
the software component is uninstalled or replaced, the SWID tag is
deleted or replaced, as appropriate.  As a result, ISO/IEC
19770-2:2015 describes a system wherein there is a correspondence
between the set of installed software components on an endpoint, and
the presence of the corresponding SWID tags for these components on
that endpoint.  CoSWIDs share the same lifecycle requirements as a
SWID tag.
Paragraph (version B):
The following is an excerpt (with some modifications and reordering)
from NIST Interagency Report (NISTIR) 8060: Guidelines for the
Creation of Interoperable SWID Tags SWID-GUIDANCE, which describes
the tag types used within the lifecycle defined in ISO-19770-2:2015.
This information is included here to provide a concise reference for
the use of CoSWIDs in the software lifecycle.
Paragraph (version B):
Primary Tag - A SWID or CoSWID tag that identifies and describes a
software component is installed on a computing device.  A primary
tag is intended to be installed on an endpoint along with the
corresponding software component.
Paragraph (version B):
Patch Tag - A SWID or CoSWID tag that identifies and describes an
installed patch which has made incremental changes to a software
component installed on an endpoint.  A patch tag is intended to be
installed on an endpoint along with the corresponding software
component patch.
Paragraph (version B):
Note: The type of a tag is determined by specific data elements,
which is discussed in model-tag-type.
Paragraph (version A):
This document defines the CoSWID format, a more concise
representation of SWID information in the Concise Binary Object
Representation (CBOR) RFC7049.  This is described via the Concise
Data Definition Language (CDDL) I-D.ietf-cbor-cddl.  The resulting
CoSWID data definition is interoperable with the XML schema
definition of ISO-19770-2:2015 SWID.  The vocabulary, i.e., the CDDL
names of the types and members used in the CoSWID data definition,
are mapped to more concise labels represented as small integer
values.  The names used in the CDDL data definition and the mapping
to the CBOR representation using integer labels is based on the
vocabulary of the XML attribute and element names defined in ISO/IEC
19770-2:2015.
Paragraph (version B):
This document defines the CoSWID format, a more concise
representation of SWID information in the Concise Binary Object
Representation (CBOR) RFC7049.  The structure of a CoSWID is
described via the Concise Data Definition Language (CDDL) I-D.ietf-
cbor-cddl.  The resulting CoSWID data definition is aligned in the
information able to be expressed with the XML schema definition of
ISO-19770-2:2015 SWID.  The vocabulary, i.e., the CDDL names of the
types and members used in the CoSWID data definition, are mapped to
more concise labels represented as small integer values.  The names
used in the CDDL data definition and the mapping to the CBOR
representation using integer labels is based on the vocabulary of the
XML attribute and element names defined in ISO/IEC 19770-2:2015.
Paragraph (version A):
The inclusion of extension points in the CoSWID data definition
that allow for additional uses of CoSWID tags that go beyond the
original scope of ISO-19770-2:2015 tags.  These are covered in
model-payload and model-evidence.
Paragraph (version B):
CoSWID Extension - Used to add new information structures to a
CoSWID (defined in model-concise-software-identity).
Paragraph (version B):
Entity Extension - Used to add new new information structures
to an entity (defined in model-entity).
Paragraph (version B):
Payload Extension - Used to add new new information structures
to a payload, such as new payload resource types (defined in
model-payload).
Paragraph (version B):
Evidence Extension - Used to add new new information structures
to an evidence, such as new evidence resource types (defined in
model-evidence).
Paragraph (version A):
The following is a CDDL representation for a CoSWID tag.  This CDDL
represetation is intended to be parallel to the XML schema definition
in the ISO/IEC 19770-2:2015 SWID specification, allowing both SWID
and CoSWID tags to represent a common set of SWID information and to
support all SWID tag use cases.  To achieve this end, the CDDL
representation includes every SWID tag field and attribute.  The
CamelCase notation used in the XML schema definition is changed to a
hyphen-separated notation (e.g.  ResourceCollection is named
resource-collection in the CoSWID data definition).  This deviation
from the original notation used in the XML representation reduces
ambiguity when referencing certain attributes in corresponding
textual descriptions.  An attribute referred by its name in CamelCase
notation explicitly relates to XML SWID tags, an attribute referred
by its name in hyphen-separated notation explicitly relates to CoSWID
tags.  This approach simplifies the composition of further work that
reference both XML SWID and CoSWID documents.
Paragraph (version B):
The following is a CDDL representation for a CoSWID tag.  This CDDL
representation is intended to be parallel to the XML schema
definition in the ISO/IEC 19770-2:2015 SWID specification, allowing
both SWID and CoSWID tags to represent a common set of SWID
information and to support all SWID tag use cases.  To achieve this
end, the CDDL representation includes every SWID tag field and
attribute.  The CamelCase notation used in the XML schema definition
is changed to a hyphen-separated notation (e.g.  ResourceCollection
is named resource-collection) in the CoSWID data definition.  This
deviation from the original notation used in the XML representation
reduces ambiguity when referencing certain attributes in
corresponding textual descriptions.  An attribute referred by its
name in CamelCase notation explicitly relates to XML SWID tags, an
attribute referred by its name in hyphen-separated notation
explicitly relates to CoSWID tags.  This approach simplifies the
composition of further work that reference both XML SWID and CoSWID
documents.
Paragraph (version A):
The CDDL above allows for a more effecient CBOR encoding of the data
when a single value is used by avoiding the need to first encode the
array.  An array is used for two or more values.  This modeling
pattern is used frequently in the CoSWID CDDL data definition in such
cases.
Paragraph (version B):
The CDDL above allows for a more efficient CBOR encoding of the data
when a single value is used by avoiding the need to first encode the
array.  An array is used for two or more values.  This modeling
pattern is used frequently in the CoSWID CDDL data definition in such
cases.
Paragraph (version A):
tag-id (label 0): An textual identifier uniquely referencing a
(composite) software component.  The tag identifier MUST be
globally unique.  There are no strict guidelines on how this
identifier is structured, but examples include a 16 byte GUID
(e.g.  class 4 UUID) RFC4122.
Paragraph (version B):
tag-id (label 0): An textual identifier uniquely referencing a
(composite) software component.  The tag identifier MUST be
globally unique.  There are no strict guidelines on how this
identifier is structured, but examples include a 16 byte GUID
(e.g.  class 4 UUID) RFC4122, or a text string appended to a DNS
domain name to ensure uniqueness across organizations.
Paragraph (version A):
incremented to indicate that the data is updated.
Paragraph (version B):
incremented to indicate that the data has been updated.
Paragraph (version A):
supplemental (label 11): A boolean value that indicates if the tag
is providing additional information to be associated with another
referenced SWID or CoSWID tag.  Tags using this item help to
ensure that primary and patch tags provided by a software provider
are not modified by software management tools, while allowing
these tools to provide their own software metadata for a software
component.  If a CoSWID tag is a supplemntal tag, it MUST contain
the supplemental item and its value MUST be set to "true".  If not
provided the default value MUST be considered "false".
Paragraph (version B):
supplemental (label 11): A boolean value that indicates if the tag
is providing additional information to be associated with another
referenced SWID or CoSWID tag.  Tags using this item help to
ensure that primary and patch tags provided by a software provider
are not modified by software management tools, while allowing
these tools to provide their own software metadata for a software
component.  If a CoSWID tag is a supplemental tag, it MUST contain
the supplemental item and its value MUST be set to "true".  If not
provided the default value MUST be considered "false".
Paragraph (version A):
media (label 10): This text value is a hint to the tag consumer to
understand what this tag applies to.  This item represents a query
as defined by the W3C Media Queries Recommendation (see
http://www.w3.org/TR/css3-mediaqueries/).  A hint to the consumer
of the link to what the target item is applicable for.
Paragraph (version A):
software-meta-entry (label 5): An open-ended collection of key/
value data related to this CoSWID.  A number of predefined
attributes can be used within this item providing for common usage
and semantics across the industry.  The data definition of this
entry allows for any additional attribute to be included, though
it is recommended that industry norms for new attributes are
defined and followed to the degree possible.  Described in model-
software-meta.
Paragraph (version A):
entity-entry (label 2): Specifies the organizations related to the
software component referenced by this CoSWID tag.  Described in
model-entity.
Paragraph (version A):
link-entry (label 4): Provides a means to establish a relationship
arc between the tag and another item.  A link can be used to
establish relationships between tags and to reference other
resources that are related to the CoSWID tag, e.g.  vulnerability
database associations, ROLIE feeds, MUD files, software download
location, etc).  This is modeled after the HTML "link" element.
Described in model-link.
Paragraph (version A):
payload-entry (label 6): The items that may be installed on a
system entity when the software component is installed.  Note that
payload may be a superset of the items installed and - depending
on optimization mechanisms in respect to that system entity - may
or may not include every item that could be created or executed on
the corresponding system entitiy when software components are
installed.  In general, payload will be used to indicate the files
that may be installed with a software component.  Therefore
payload will often be a superset of those files (i.e. if a
particular optional sub-component is not installed, the files
associated with that software component may be included in
payload, but not installed in the system entity).  Described in
model-payload.
Paragraph (version A):
evidence-entry (label 3): This item is used to provide results
from a scan of a system where software that does not have a CoSWID
tag is discovered.  This information is not provided by the
software-creator, and is instead created when a system is being
scanned and the evidence for why software is believed to be
installed on the device is provided in the evidence item.
Described in model-evidence.
Paragraph (version B):
media (label 10): This text value is a hint to the tag consumer to
understand what this tag applies to.  This item represents a query
as defined by the W3C Media Queries Recommendation (see
http://www.w3.org/TR/css3-mediaqueries/).  A hint to the consumer
of the link to what the target item is applicable for.  Described
in model-media.
Paragraph (version B):
software-meta-entry (label 5): An open-ended map of key/value data
pairs.  A number of predefined keys can be used within this item
providing for common usage and semantics across the industry.  The
data definition of this entry allows for any additional attribute
to be included, though it is recommended that industry norms for
new attributes are defined and followed to the degree possible.
Described in model-software-meta.
Paragraph (version B):
entity-entry (label 2): Provides information about one or more
organizations related to the software component referenced by this
CoSWID tag.  Described in model-entity.
Paragraph (version B):
link-entry (label 4): Provides a means to establish relationship
arcs between the tag and another items.  A given link can be used
to establish the relationship between tags or to reference another
resource that is related to the CoSWID tag, e.g.  vulnerability
database association, ROLIE feed , MUD resource , software
download location, etc).  This is modeled after the HTML "link"
element.  Described in model-link.
Paragraph (version B):
payload-entry (label 6): This item represents the software
artifacts that may be installed on an endpoint when the software
component is installed.  Note that the payload may represent a
superset of the software artifacts installed.  Based on user
selections at install time, an installation may not include every
artifact that could be created or executed on the endpoint when
the software component is installed (i.e. if a particular optional
sub-component is not installed, the files associated with that
software component may be included in payload, but not installed
in the system entity).  Described in model-payload.
Paragraph (version B):
evidence-entry (label 3): This item is used to provide results
from a scan of a system where software that does not have a CoSWID
tag is discovered.  In such a case, a CoSWID tag may be created by
the discovery process when the endpoint is scanned.  This item
represents evidence for why software is believed to be installed
on the endpoint.  Described in model-evidence.
Paragraph (version A):
The operational model for SWID and CoSWID tags introduced in intro-
lifecycle.  The following rules can be used to determine the type of
a CoSWID tag.
Paragraph (version B):
The operational model for SWID and CoSWID tags was introduced in
intro-lifecycle.  The following rules can be used to determine the
type of a CoSWID tag.
Paragraph (version A):
Only one of the corpus, patch, and supplemental items MUST be set
to "true", or all of the corpus, patch, and supplemental items
MUST be set to "false" or be omitted.
Paragraph (version A):
If the patch item is set to "true", the the tag SHOULD contain at
least one link with the rel(ation) item value of "patches" and an
href item specifying an association with the software that was
patched.
Paragraph (version A):
If the supplemental item is set to "true", the the tag SHOULD
contain at least one link with the rel(ation) item value of
"supplements" and an href item specifying an association with the
software that is supplemented.
Paragraph (version B):
Only one of the patch and supplemental items MUST be set to
"true", or the patch and supplemental items MUST be set to "false"
or be omitted.
Paragraph (version B):
If the patch item is set to "true", the tag SHOULD contain at
least one link with the rel(ation) item value of "patches" and an
href item specifying an association with the software that was
patched.
Paragraph (version B):
If the supplemental item is set to "true", the tag SHOULD contain
at least one link with the rel(ation) item value of "supplements"
and an href item specifying an association with the software that
is supplemented.
Paragraph (version A):
lang (index 15): A language tag or corresponding IANA index
integer that conforms with IANA Language Subtag Registry RFC5646.
Paragraph (version B):
lang (index 15): A textual language tag that conforms with IANA
Language Subtag Registry RFC5646.
Paragraph (version A):
global-attributes: The global-attributes group described in model-
global-attributes.
Paragraph (version A):
reg-id (index 32): The registration id is intended to uniquely
identify a naming authority in a given scope (e.g. global,
organization, vendor, customer, administrative domain, etc.) that
is implied by the referenced naming authority.  The value of an
registration ID MUST be a RFC 3986 URI.  The scope SHOULD be the
scope of an organization.  In a given scope, the registration id
MUST be used consistently.
Paragraph (version A):
role (index 33): The relationship(s) between this organization and
this tag.  The role of tag creator is required for every CoSWID
tag.  The role of an entity may include any role value, but the
pre-defined roles include: "aggregator", "distributor",
"licensor", "software-creator", and "tag-creator".  These pre-
defined role index and text values are defined in indexed-entity-
role.  Use of index values instead of text for these pre-defined
roles allows a CoSWID to be more concise.
Paragraph (version A):
thumbprint (index 34): The value of the thmbprint item provides an
integer-based hash algorithm identifier (hash-alg-id) and a byte
string string value (hash-value) that contains the corresponding
hash value (i.e. the thumbprint) of the signing entities
certificate(s).  If the hash-alg-id is not known, then the integer
value "0" MUST be used.  This ensures parity between the SWID tag
specification SWID, which does not allow an algorithm to be
identified for this field.  See model-hash-entry for more details
on the use of the hash-entry data structure.
Paragraph (version B):
reg-id (index 32): The registration id is intended to uniquely
identify a naming authority in a given scope (e.g. global,
organization, vendor, customer, administrative domain, etc.) for
the referenced naming authority.  The value of an registration ID
MUST be a RFC 3986 URI.  The scope SHOULD be the scope of an
organization.  In a given scope, the registration id MUST be used
consistently.
Paragraph (version B):
role (index 33): The relationship(s) between this organization and
this tag.  The role of an entity MAY include any role value, but
the pre-defined roles include: "aggregator", "distributor",
"licensor", "software-creator", and "tag-creator".  These pre-
defined role index and text values are defined in indexed-entity-
role.  Use of index values instead of text for these pre-defined
roles allows a CoSWID to be more concise.
Paragraph (version B):
An entity item MUST be provided with the role of "tag-creator" for
every CoSWID tag.  This indicates the organization that created
the CoSWID tag.
Paragraph (version B):
thumbprint (index 34): The value of the thumbprint item provides
an integer-based hash algorithm identifier (hash-alg-id) and a
byte string value (hash-value) that contains the corresponding
hash value (i.e. the thumbprint) of the signing entities
certificate(s).  If the hash-alg-id is not known, then the integer
value "0" MUST be used.  This ensures parity between the SWID tag
specification SWID, which does not allow an algorithm to be
identified for this field.  See model-hash-entry for more details
on the use of the hash-entry data structure.
Paragraph (version A):
extended-data (index 30): An open-ended collection of elements
that can be used to attach arbitrary metadata to an entity item.
Paragraph (version A):
a URI with "coswid:" as the scheme, which refers to another
CoSWID by tag-id.  This URI would need to be resolved in the
context of the system by software that can lookup other CoSWID
tags.  For example, "coswid:2df9de35-0aff-
4a86-ace6-f7dddd1ade4c" references the tag with the tag-id
value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c".
Paragraph (version B):
a URI with "coswid:" as the scheme, which refers to another
CoSWID by tag-id.  This URI would need to be resolved in the
context of the endpoint by software that can lookup other
CoSWID tags.  For example, "coswid:2df9de35-0aff-
4a86-ace6-f7dddd1ade4c" references the tag with the tag-id
value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c".
Paragraph (version A):
media (index 10): See media defined in model-concise-software-
identity.
Paragraph (version B):
media (index 10): See media defined in model-media.
Paragraph (version A):
media-type (index 41): The IANA MediaType for the target file;
this provides the consumer with intelligence of what to expect.
See http://www.iana.org/assignments/media-types/media-types.xhtml
for more details on link type.
Paragraph (version A):
use (index 42): Determines if the target software is a hard
requirement or not.  Valid enumerations are: required,
recommended, optional.
Paragraph (version B):
media-type (index 41): The IANA MediaType for the target resource;
this provides the consumer with a hint of what type of resource to
expect.  See http://www.iana.org/assignments/media-types/media-
types.xhtml for more details.
Paragraph (version B):
use (index 42): Determines if the target software is a hard
requirement or not to be installed before installing the tagged
software component.  Valid enumerations are: required,
recommended, optional, which are defined in indexed-link-use.
Paragraph (version A):
colloquial-version (index 45): The informal or colloquial version
of the product (i.e. 2013).  Note that this version may be the
same through multiple releases of a software component where the
version specified in entity is much more specific and will change
for each software release.  Note that this representation of
version is typically used to identify a group of specific software
releases that are part of the same release/support infrastructure
(i.e.  Fabrikam Office 2013).  This version is used for string
comparisons only and is not compared to be an earlier or later
release (that is done via the entity version).
Paragraph (version B):
colloquial-version (index 45): The informal or colloquial version
of the product (i.e. 2013).  Note that this version may be the
same through multiple releases of a software component where the
version specified in entity is much more specific and will change
for each software release.
Paragraph (version B):
Note that this representation of version is typically used to
identify a group of specific software releases that are part of
the same release/support infrastructure (i.e.  Fabrikam Office
2013).  This version is used for string comparisons only and is
not compared to be an earlier or later release (that is done via
the entity version).
Paragraph (version A):
edition (index 47): The variation of the product (Extended,
Enterprise, Professional, Standard etc).
Paragraph (version B):
edition (index 47): The variation of the product (Extended,
Enterprise, Professional, Standard, etc).
Paragraph (version A):
generator (index 50): The name of the software tool that created a
CoSWID tag.  This item is typically used if tags are created on
the fly or via a catalog-based analysis for data found on a
computing device.
Paragraph (version A):
product (index 52): The base name of the product (e.g. ).
Paragraph (version A):
product-family (index 53): The overall product family this
software belongs to.  Product family is not used to identify that
a product is part of a suite, but is instead used when a set of
products that are all related may be installed on multiple
different devices.  For example, an enterprise backup system may
consist of a backup services, multiple different backup services
that support mail services, databases and ERP systems, as well as
individual software components that backup client system entities.
In such an usage scenario, all software components that are part
of the backup system would have the same product-family name so
they can be grouped together in respect to reporting systems.
Paragraph (version B):
generator (index 50): The name of the software tool that created a
CoSWID tag.  This item is typically used if tags are created on
the fly or via a catalog-based analysis for data found on an
endpoint.
Paragraph (version B):
product (index 52): The base name of the product.
Paragraph (version B):
product-family (index 53): The overall product family this
software belongs to.  Product family is not used to identify that
a product is part of a suite, but is instead used when a set of
products that are all related may be installed on multiple
different endpoints.  For example, an enterprise backup system may
consist of a backup services, multiple different backup services
that support mail services, databases and ERP systems, as well as
individual software components that backup client system entities.
In such an usage scenario, all software components that are part
of the backup system would have the same product-family name so
they can be grouped together in respect to reporting systems.
Paragraph (version A):
revision (index 54): The informal or colloquial representation of
the sub-version of the given product (ie, SP1, R2, RC1, Beta 2,
etc).  Note that the version will provide very exact version
details, the revision is intended for use in environments where
reporting on the informal or colloquial representation of the
software is important (for example, if for a certain business
process, an organization recognizes that it must have, for example
"ServicePack 1" or later of a specific product installed on all
devices, they can use the revision data value to quickly identify
any devices that do not meet this requirement).  Depending on how
a software organizations distributes revisions, this value could
be specified in a primary (if distributed as an upgrade) or
supplemental (if distributed as a patch) CoSWID tag.
Paragraph (version B):
revision (index 54): The informal or colloquial representation of
the sub-version of the given product (ie, SP1, R2, RC1, Beta 2,
etc).  Note that the version item will provide very exact version
details, while the revision is intended for use in environments
where reporting on the informal or colloquial representation of
the software is important (for example, if for a certain business
process, an organization recognizes that it must have, for example
"ServicePack 1" or later of a specific product installed on all
devices, they can use the revision data value to quickly identify
any devices that do not meet this requirement).
Paragraph (version B):
Depending on how a software organizations distributes revisions,
this value could be specified in a primary (if distributed as an
upgrade) or supplemental (if distributed as a patch) CoSWID tag.
Paragraph (version A):
The following are an initial set of values for use in the version-
scheme item for the version schemes defined in the ISO/IEC
19770-2:2015 SWID specification.  Index value in parens indicates the
index value to use in the version-scheme item.
Paragraph (version A):
The values above are registered in the "SWID/CoSWID Version Schema
Values" registry defined in section iana-version-scheme.  Additional
valid values will likely be registered over time in this registry.
Paragraph (version A):
The values above are registered in the "SWID/CoSWID Entity Role
Values" registry defined in section iana-entity-role.  Additional
valid values will likely be registered over time.  Additionally, the
index values 226 through 255 have been reserved for private use.
Paragraph (version B):
The following table contains an initial set of values for use in the
version-scheme item for the version schemes defined in the ISO/IEC
19770-2:2015 SWID specification.  Index value in parens indicates the
index value to use in the version-scheme item.
Paragraph (version B):
The values above are registered in the "SWID/CoSWID Version Schema
Values" registry defined in section iana-version-scheme.  Additional
valid values will likely be registered over time in this registry.
Additionally, the index values 32768 through 65535 have been reserved
for private use.
Paragraph (version B):
The values above are registered in the "SWID/CoSWID Entity Role
Values" registry defined in section iana-entity-role.  Additional
valid values will likely be registered over time.  Additionally, the
index values 128 through 255 have been reserved for private use.
Paragraph (version B):
The following table indicates the index value to use for the link use
item (see model-link), which is also defined in the ISO/IEC
19770-2:2015 SWID specification.
Paragraph (version B):
The values above are registered in the "SWID/CoSWID Link Use Values"
registry defined in section iana-link-use.  Additional valid values
will likely be registered over time.  Additionally, the index values
128 through 255 have been reserved for private use.
Paragraph (version B):
This document uses unsigned 8-bit index values to represent link-use
values.  The initial set of Link use values are derived from the
textual names defined in the ISO/IEC 19770-2:2015 specification SWID.
Paragraph (version B):
Initial registrations for the SWID/CoSWID Entity Role Values registry
are provided below.
Paragraph (version A):
Clarified language around SWID and CoSWID to make more consistant
use of these terms.
Paragraph (version A):
Fixed a number of gramatical, spelling, and wording issues.
Paragraph (version B):
Clarified language around SWID and CoSWID to make more consistent
use of these terms.
Paragraph (version B):
Fixed a number of grammatical, spelling, and wording issues.