[sacm] Alexey Melnikov's Discuss on draft-ietf-sacm-nea-swima-patnc-02: (with DISCUSS and COMMENT)

[Alexey Melnikov <[e-mail]>]

Alexey Melnikov has entered the following ballot position for
draft-ietf-sacm-nea-swima-patnc-02: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is generally a well written document, despite certain repetition of text.
It was a pleasure to read.

I have a couple of issues that I would like to discuss. I believe they would be
easy to resolve:

1) In Section 5.8, in the table (I believe this is repeated at least 3 more
times elsewhere in the document):

 Software Locator:

   A string containing the Software Locator value.
   This is expressed as a URI. This field value
   MUST be normalized to Network Unicode format as
   described in Section 3.4.4.

At minimum this text is misleading (or can be misread) and at maximum it is
wrong. I think what you are trying to say is that the location value is first
normalized to Network Unicode format as described in Section 3.4.4, then it is
converted in UTF-8 and then it is encoded as a URI. (As opposed to doing
something else, e.g. convert to URI first and then trying to normalize it). If
this is correct, I suggest:

   A string containing the Software Locator value.
   This is expressed as a URI [RFC3986]. This field value
   MUST be first normalized to Network Unicode format as
   described in Section 3.4.4, then converted to UTF-8 [RFC3629]
   (if not already in UTF-8), then encoded as a URI.

2) SWID registry is using "http://invalid.unavailable" Tag Creator RegID value.

invalid.unavailable is not a valid domain name and "unavailable" is not
registered in the special-use domain registry
<https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml>

I am not entirely sure how big of a problem this is, but use of something which
can be interpreted as a URI in a non existing non special-use domain seems like
a bad idea.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Minor:

1) Please add a Normative Reference to [RFC3629] when mentioning UTF-8.

2) When referencing RFC 5198 (Network Unicode format), I personally prefer a
stricter version that disallows control characters (other than CR LF). In RFC
5198, use of control characters is only "SHOULD NOT". So you might want to make
a stronger statement on this.

3) In Section 3.4.4.  Software Locators

   The location is expressed as a URI string consisting of a scheme and
   path.  [RFC3986] The location URI does not include an authority part.

The last sentence: is this just a fact for file: URIs or is it absolute
prohibition for all other schemes that can be used here?

4) In Section 3.8.1.  Establishing Subscriptions

   A SWIMA-PC MUST have the ability to record and support multiple
   simultaneous subscriptions from a single party and from multiple
   parties.  A SWIMA-PV MUST have the ability to record and support
   multiple simultaneous subscriptions to a single party and
   subscriptions to multiple parties.

In order to improve interoperability it might be useful to specify a minimal
limit on the number of multiple subscriptions per PV.

5) In Section 4.3.  Required Exchanges

   All SWIMA-PVs and SWIMA-PCs MUST support both types of exchanges.

I question the value in requiring SWIMA-PVs in supporting both types of
exchanges. For example, if a SWIMA-PV never uses subscriptions, it doesn't seem
to need to handle subscription responses.

Similar text in 5.2:

   All SWIMA-PVs MUST be capable of sending SWIMA Request attributes and
   be capable of receiving and processing all SWIMA Response attributes
   as well as PA-TNC Error attributes.

6) Use of fields which can contain both human readable and possibly machine
readable information - I think this is rather handwavy and I wish you would be
more specific. Also consider issues raised in BCP 18 (RFC 2277), in particular
language tagging of human readable text.

7) IANA Considerations Sections 10.2 and 10.3 contain:

  Software Inventory Message
  and Attributes for PA-TNC

as the reference. This is not actually useful, because these tables are going
to be extracted and copied to the www.iana.org website. You should add
"[RFCXXXX]" to them, so that RFC Editor knows to replace it with the RFC number
of this document once it is published.

Nit:

8) 3.4.  Core Software Reporting Information

   Different parameters in the SWIMA Request can influence what
   information is returned in the SWIMA Response.  However, while each
   SWIMA Response provides different additional information about this
   installed software, they all share a common set of fields that
   support reliable software identification on an endpoint.  These
   fields include: Software Identifiers, the Data Model Type, Record
   Identifiers, Software Locators, and Source Identifiers.  These fields
   are present for each reported piece of software in each type of SWIMA
   Response.  The following sections examine these three types of

five types as per the previous sentence?

   information in more detail.