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

["Schmidt, Charles M." <[e-mail]>]

Hello,

Thank you very much for the feedback. Overall, I agree with your comments and am addressing them. I did have a couple questions/responses:

> 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.
>
<snip> 
>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.

I agree that spelling out the process better makes sense. However, I don't think the middle step you mention (convert to UTF-8) is necessary. RFC5198 (Network Unicode) already requires that all characters be in UTF-8. As such, my proposed text is:

A string containing the Software Locator value. This field value MUST be first normalized to Network Unicode format as described in Section 5.5 and then encoded as a URI.

Does this seem reasonable?

> 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.

Unfortunately, this convention was set out in the ISO SWID specification. While I agree that it is unfortunate, I think it is better to fit with the convention used in other SWID documents than to try to correct it here. I will add a note to the effect that this conforms to the conventions of the ISO SWID standard. I also updated the 2009 SWID specification reference as that uses "unknown" for the same purpose.

> 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.

I am open to this, but would like to get others' input as well. This is not an area with which I have much familiarity and worry about implementation impact if we impose requirements that might go beyond what is present in existing tools. My gut reaction is to leave the use of the standard unchanged unless there is an operational need to do otherwise, and I don't know that this is the case. I'll defer to others' opinions on this.

> 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.

I'm afraid I am not following your concern here. In 4.3, if the SWIMA-PV has no ability to support subscriptions then I don’t think we want to claim that it is SWIMA compliant. (We don’t want vendors selling “SWIMA-compliant” tools that cannot support subscriptions.) In 5.2, if the SWIMA-PV cannot send a SWIMA Request or receive the response that comes back, then it cannot participate in SWIMA at all. These requirements seem necessary to interoperability.

> 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.

I hear your concerns. Unfortunately, I do not have a good solution that won't add several pages to the specification. Are you aware of any existing standard that could be co-opted for this field?

Thanks,
Charles 

> -----Original Message-----
> From: Alexey Melnikov [mailto:[e-mail]]
> Sent: Thursday, February 22, 2018 6:21 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; Karen
> O'Donoghue <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Subject: Alexey Melnikov's Discuss on draft-ietf-sacm-nea-swima-patnc-02:
> (with DISCUSS and COMMENT)
> 
> 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.
>