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

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

Hi Eric,

Thanks for the clarifications. I'll make the updates you suggest.

Thanks for the help.

Charles

> -----Original Message-----
> From: Eric Rescorla [mailto:[e-mail]]
> Sent: Tuesday, February 20, 2018 8:56 AM
> To: Schmidt, Charles M. <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Eric Rescorla's No Objection on draft-ietf-sacm-nea-swima-
> patnc-02: (with COMMENT)
> 
> 
> 
> On Tue, Feb 20, 2018 at 6:21 AM, Schmidt, Charles M. <[e-mail]
> <mailto:[e-mail]> > wrote:
> 
> 
> 	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.)
> 
> 
> 
> 
> Yeah, I make notes as I go and then left this one because I think that might
> be confusing as people read in order.
> 
> I'm not sure what the best approach is, TBH. Maybe say it up front too?
> 
> 
> 
> 	>    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?
> 
> 
> 
> It confused me a bit. Perhaps you might say "or has exhausted the space
> allowed for event storage"
> 
> 
> 
> 
> 
> 	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.
> 
> 
> 
> I think the second is better, but as you say it's aesthetic.
> 
> FWIW, I usually do these big blockaf (e.g., timestamp) s by eliding the
> horizontal bars rather than the vertical ones, but again, it's taste.
> 
> Best,
> -Ekr
> 
> 
> 
> 
> 	Thanks again for your help.
> 
> 	Charles
> 
> 	> -----Original Message-----
> 	> From: Eric Rescorla [mailto:[e-mail] <mailto:[e-mail]>
> ]
> 	> Sent: Monday, February 19, 2018 10:55 AM
> 	> To: The IESG <[e-mail] <mailto:[e-mail]> >
> 	> Cc: [e-mail] <mailto:draft-ietf-
> [e-mail]> ; [e-mail] <mailto:[e-mail]> ;
> Karen
> 	> O'Donoghue <[e-mail] <mailto:[e-mail]>
> >; [e-mail] <mailto:[e-mail]> ;
> 	> [e-mail] <mailto:[e-mail]> ;
> [e-mail] <mailto:[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
> <http://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
> 	>
> 	>
> 
> 
>