[sacm] Eric Rescorla's No Objection on draft-ietf-sacm-nea-swima-patnc-02: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-sacm-nea-swima-patnc-02: No Objection

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/



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

More detail in context at: https://mozphab-ietf.devsvcdev.mozaws.net/D3336

IMPORTANT
I consider the following comment important, though I have chosen to make
it a comment rather than a discuss.

   Software records on an endpoint are generally not considered to be
   sensitive, although there can be exceptions to this generalization as
   noted in the section on Privacy Considerations.  In general, an

I'm not sure where "generally" comes from. I consider it
sensitive and we know that people have been jailed for running certain
software.  Even the rest of this section provides strong evidence that
this is sensitive. So I think you should remove this claim and rewrite
this paragraph to acknowledge that this is sensitive information

MINOR
   The primary use of exchanging software inventory information over the
   PA-TNC interface is to enable a challenger (e.g.  NEA Server) to
   obtain inventory evidence about some system in a way that conforms to
Nit: e.g.,

   endpoint is providing false information, either through malice or
   error, but instead focuses on correctly and reliably providing the
   reported Software Inventory Evidence Collection to the NEA Server.
This seems like a pretty significant narrowing of the use cases. Can you
explain what use cases this is useful for if the machine can lie?

   A Record Identifier is a 4-byte integer generated by the SWIMA-PC
   that is uniquely associated with a specific record within the
In what byte order? Signed or unsigned? If it's actually an integer this is
important.

   that SWIMA-PV), the SWIMA-PC MUST assign that source a Source
   Identification Number, which is an 8-bit unsigned integer.  Each item
   reported includes the Source Identification Number that provided that
What happens if you have 256 sources? Must these be sequential?

   record that is no longer available, the SWIMA-PC SHOULD return a
   0-length record.
Is this different from what happens if you are requested to send something that
never existed? If so, is this a recipe for unlimited growth.

   An EID is a 4-byte unsigned integer that the SWIMA-PC assigns
   sequentially to each observed event (whether detected in real-time or
What byte order?

   very first recorded event in a SWIMA-PC's records within an EID Epoch
   MUST be assigned a value of 1 or greater.  Note that EID and EID
   Epoch values are assigned by the SWIMA-PC without regard to whether
Why "or greater" this is the only place you allow a gap.

   event records MUST only contain events with EIDs that all come from
   the current Epoch.
How does the SWIMA-PC garbage collect? It seems like the answer is it can just
change epochs?

   records.  This ensures that every partial list of event records is
   always complete within its indicated range.
Is the point here that the list must be consecutive?

   |              | (8)        | PA-TNC specification [RFC5792].       |
   +--------------+------------+---------------------------------------+
It's up to you, but isn't this table largely duplicative of S 5.2?

   |   Software Identifier Length  | Software Identifier (var len) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OK, I think I see what's going on here: you can have an arbitrary number of
instances of this block. Maybe you should show more than one in the diagram
with an indication that it's controlled by SWID Count? Or a .... or something?
This comment applies to the other PDUs in this document as well.

   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
I would not put lines between these timestamp fields because they are actually
one giant field