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

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

Hello Eric,

Thank you very much for the comments. I have only two follow-up questions:

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

Section 5.3 (Message Diagram Syntax) states that "Multi-octet fields representing numeric values MUST be sent in network (big-endian) byte order." I have tweaked this to simply say "All fields representing numeric values MUST be sent in network (big-endian) byte order". Is this sufficient or do feel that this should be reiterated in the individual field descriptions? (I did go through and make sure that every integer is explicitly "unsigned", per your other comment.)

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

You are correct. The second paragraph of section 3.7.1 (Event Identifiers) states that "In the case where a SWIMA-PC needs to reset its EID counter, either because it has exhausted all available EID values or because the SWIMA-PC's event log becomes corrupted, then a new EID Epoch MUST be selected." Apart from that passing mention, I don't believe the document makes any comment. Do you feel additional emphasis on this topic is necessary?

Finally, an aesthetic check on repeated fields. I have attempted the following:
--------------
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Flags        |                Event Count                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request ID Copy / Subscription ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       EID Epoch                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Last EID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Last Consulted EID                              |
   =================================================================
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          EID                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Record Identifier                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Data Model Type PEN                 |Data Model Type|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source Id Num |  Action       |   Software Identifier Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Software Identifier (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Software Locator Length     |Software Locator (variable len)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 8: Software Identifier Events Attribute

   Everything after the line of double bars (======) is repeated a
   number of times equal to Event Count.
-------------

Do you feel that this clarifies the repeated fields in the diagram? The alternative would be to do something like:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Flags        |                Event Count                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Request ID Copy / Subscription ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       EID Epoch                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Last EID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Last Consulted EID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               						|
   |    SUB-BLOCK (Event Count times)			|
   |							|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure n: Main message

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          EID                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Record Identifier                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Data Model Type PEN                 |Data Model Type|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source Id Num |  Action       |   Software Identifier Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Software Identifier (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Software Locator Length     |Software Locator (variable len)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure M: Sub-block

I'm interested in your thoughts as to which of these better clarifies the nature of the repeated fields.

Thanks again for your help.

Charles

> -----Original Message-----
> From: Eric Rescorla [mailto:[e-mail]]
> Sent: Monday, February 19, 2018 10:55 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; Karen
> O'Donoghue <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Subject: Eric Rescorla's No Objection on draft-ietf-sacm-nea-swima-patnc-02:
> (with COMMENT)
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-sacm-nea-swima-patnc-02: No Objection
> 
> ----------------------------------------------------------------------
> 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
> 
>