Subject: [sacm] Edits to SWIMA

From: "Schmidt, Charles M." <[email-masked]>
Date: Thu, 1 Jun 2017 21:00:40 +0000

Hi all,

I have received some feedback on the latest SWIMA specification offline. I am summarizing those comments here for the benefit of the list.

- Section 3.6 (page 23, 1st full paragraph): The text provides guidance on detecting change events. The text states, "The SW-PC MUST assign a time to each detected change in the endpoint's Software Inventory Evidence Collection.  These timestamps correspond to the SW-PC's best understanding as to when the detected change occurred.  These timestamps MUST be as accurate as possible."

The commenter felt that the last sentence was superfluous and should be deleted.

- Section 3.6 (page 23, 2nd full paragraph) : The text talks about retention of deleted software records for reporting purposes. The text states, "With regard to deletions of records, the SW-PC needs to detect the deletion and MUST retain a copy of the full deleted record along with the associated Record Identifier and Software Locator so that the record and associated information can be provided to the SW-PV upon request.  This copy of the record MUST be retained for a reasonable amount of time.  Vendors and administrators determine what "reasonable" means, but a copy of the record SHOULD be retained for as long as the event recording the deletion of the record remains in the SW-PC's event log (as described in Section 3.7)."

The commenter noted that this leaves open a question as to what to do if a record is deleted while still named in the event log. They suggested we add the following sentence: "In the case that a SW-PC is called upon to report a deleted record that is no longer available, the SW-PC SHOULD return a 0-length record."

- Section 3.7.1 (page 25, 2nd full paragraph): The text talks about the EID Epoch value and its use. It states, "EID Epoch values SHOULD be generated randomly and in such a way that it is unlikely that the same EID Epoch is generated twice, even if the SW-PC reverted to an earlier state (e.g., resetting it to factory defaults)."

The reviewer felt that the normative text focused on the means, rather than the end. They suggested replacing this sentence with the following: "EID Epoch values MUST be generated in such a way that it is unlikely that the same EID Epoch is generated twice, even if the SW-PC reverts to an earlier state (e.g., resetting to factory defaults). For this reason, sequential EID Epochs are discouraged, since loss of state could result in repeated use of a value."

- Section 3.7.6 (page 31, 2nd full paragraph): The text talks about handling evidence that the SW-PC and SW-PV have fallen out of sync with regard to EIDs. It states: "The SW-PV will normally never receive an attribute indicating that the latest EID is less than the latest EID reported in a previous attribute within the same EID Epoch.  If this occurs, the SW-PC has suffered an error of some kind, possibly indicative of at least partial corruption of its event log.  In this case, the SW-PV SHOULD treat the situation as if there was a change in Epoch and treat any local copy of the endpoint's Software Inventory Evidence Collection as out-of-sync until a full inventory can be reported by the SW-PC. In this case, the SW-PV SHOULD flag the occurrence so the SW-PC can be examined to ensure it is now operating properly."

The reviewer noted that failure to abide by the first SHOULD would result in ongoing inaccuracy in in the SW-PV's understanding of endpoint state. As such, they suggested changing this to a MUST.

The reviewer also suggested that, in the final sentence, "flag" should be replaced with the more specific "log".

- Section 3.9 (page 39, final paragraph): The text states "Both SW-PCs and SW-PVs SHOULD log errors so that administrators can trace the causes of errors.  Log entries SHOULD include the type of the error, the time it was detected, and additional descriptive information to aid in understanding the nature and cause of the error."

The reviewer recommended adding the following sentence: "Logs are an important debugging tool and implementers are strongly advised to include comprehensive logging capabilities in their products."

These suggestions seem reasonable to me. Are there any other thoughts on these suggestions?

Thanks,
Charles

---

From: Adam Montville <[email-masked]>
Date: Fri, 02 Jun 2017 11:27:01 +0000

They also seem reasonable to me. Curious, were these offline comments based
on experience with an implementation attempt?

Kind regards,

Adam

On Thu, Jun 1, 2017 at 4:00 PM Schmidt, Charles M. <[email-masked]>
wrote:

> Hi all,
>
> I have received some feedback on the latest SWIMA specification offline. I
> am summarizing those comments here for the benefit of the list.
>
> - Section 3.6 (page 23, 1st full paragraph): The text provides guidance on
> detecting change events. The text states, "The SW-PC MUST assign a time to
> each detected change in the endpoint's Software Inventory Evidence
> Collection.  These timestamps correspond to the SW-PC's best understanding
> as to when the detected change occurred.  These timestamps MUST be as
> accurate as possible."
>
> - Section 3.6 (page 23, 2nd full paragraph) : The text talks about
> retention of deleted software records for reporting purposes. The text
> states, "With regard to deletions of records, the SW-PC needs to detect the
> deletion and MUST retain a copy of the full deleted record along with the
> associated Record Identifier and Software Locator so that the record and
> associated information can be provided to the SW-PV upon request.  This
> copy of the record MUST be retained for a reasonable amount of time.
> Vendors and administrators determine what "reasonable" means, but a copy of
> the record SHOULD be retained for as long as the event recording the
> deletion of the record remains in the SW-PC's event log (as described in
> Section 3.7)."
>
> The commenter noted that this leaves open a question as to what to do if a
> record is deleted while still named in the event log. They suggested we add
> the following sentence: "In the case that a SW-PC is called upon to report
> a deleted record that is no longer available, the SW-PC SHOULD return a
> 0-length record."
>
> - Section 3.7.1 (page 25, 2nd full paragraph): The text talks about the
> EID Epoch value and its use. It states, "EID Epoch values SHOULD be
> generated randomly and in such a way that it is unlikely that the same EID
> Epoch is generated twice, even if the SW-PC reverted to an earlier state
> (e.g., resetting it to factory defaults)."
>
> The reviewer felt that the normative text focused on the means, rather
> than the end. They suggested replacing this sentence with the following:
> "EID Epoch values MUST be generated in such a way that it is unlikely that
> the same EID Epoch is generated twice, even if the SW-PC reverts to an
> earlier state (e.g., resetting to factory defaults). For this reason,
> sequential EID Epochs are discouraged, since loss of state could result in
> repeated use of a value."
>
> - Section 3.7.6 (page 31, 2nd full paragraph): The text talks about
> handling evidence that the SW-PC and SW-PV have fallen out of sync with
> regard to EIDs. It states: "The SW-PV will normally never receive an
> attribute indicating that the latest EID is less than the latest EID
> reported in a previous attribute within the same EID Epoch.  If this
> occurs, the SW-PC has suffered an error of some kind, possibly indicative
> of at least partial corruption of its event log.  In this case, the SW-PV
> SHOULD treat the situation as if there was a change in Epoch and treat any
> local copy of the endpoint's Software Inventory Evidence Collection as
> out-of-sync until a full inventory can be reported by the SW-PC. In this
> case, the SW-PV SHOULD flag the occurrence so the SW-PC can be examined to
> ensure it is now operating properly."
>
> The reviewer noted that failure to abide by the first SHOULD would result
> in ongoing inaccuracy in in the SW-PV's understanding of endpoint state. As
> such, they suggested changing this to a MUST.
>
> - Section 3.9 (page 39, final paragraph): The text states "Both SW-PCs and
> SW-PVs SHOULD log errors so that administrators can trace the causes of
> errors.  Log entries SHOULD include the type of the error, the time it was
> detected, and additional descriptive information to aid in understanding
> the nature and cause of the error."
>
> The reviewer recommended adding the following sentence: "Logs are an
> important debugging tool and implementers are strongly advised to include
> comprehensive logging capabilities in their products."
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 2 Jun 2017 13:24:55 +0000

Hi Adam,

These were not based on implementation (although I'm aware of a couple teams working on that so hopefully they will have comments). These comments were based on extracting all the normative guidance from the document and doing a review just of that.

Charles

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
> Sent: Friday, June 02, 2017 6:27 AM
> To: Schmidt, Charles M. <[email-masked]>; <[email-masked]>
> <[email-masked]>
> Subject: Re: [sacm] Edits to SWIMA
> 
> They also seem reasonable to me. Curious, were these offline comments
> based on experience with an implementation attempt?
> 
> Kind regards,
> 
> Adam
> 
> On Thu, Jun 1, 2017 at 4:00 PM Schmidt, Charles M. <[email-masked]
> <mailto:[email-masked]> > wrote:
> 
> 
> 	Hi all,
> 
> 	I have received some feedback on the latest SWIMA specification
> offline. I am summarizing those comments here for the benefit of the list.
> 
> 	- Section 3.6 (page 23, 1st full paragraph): The text provides guidance
> on detecting change events. The text states, "The SW-PC MUST assign a time
> to each detected change in the endpoint's Software Inventory Evidence
> Vendors and administrators determine what "reasonable" means, but a copy
> of the record SHOULD be retained for as long as the event recording the
> 	The commenter noted that this leaves open a question as to what to
> do if a record is deleted while still named in the event log. They suggested
> we add the following sentence: "In the case that a SW-PC is called upon to
> report a deleted record that is no longer available, the SW-PC SHOULD return
> a 0-length record."
> 
> 	The reviewer felt that the normative text focused on the means,
> rather than the end. They suggested replacing this sentence with the
> following: "EID Epoch values MUST be generated in such a way that it is
> unlikely that the same EID Epoch is generated twice, even if the SW-PC
> reverts to an earlier state (e.g., resetting to factory defaults). For this reason,
> regard to EIDs. It states: "The SW-PV will normally never receive an attribute
> indicating that the latest EID is less than the latest EID reported in a previous
> attribute within the same EID Epoch.  If this occurs, the SW-PC has suffered
> an error of some kind, possibly indicative of at least partial corruption of its
> event log.  In this case, the SW-PV SHOULD treat the situation as if there was
> a change in Epoch and treat any local copy of the endpoint's Software
> Inventory Evidence Collection as out-of-sync until a full inventory can be
> reported by the SW-PC. In this case, the SW-PV SHOULD flag the occurrence
> so the SW-PC can be examined to ensure it is now operating properly."
> 
> 	The reviewer noted that failure to abide by the first SHOULD would
> result in ongoing inaccuracy in in the SW-PV's understanding of endpoint
> state. As such, they suggested changing this to a MUST.
> 
> 	The reviewer also suggested that, in the final sentence, "flag" should
> be replaced with the more specific "log".
> 
> 	- Section 3.9 (page 39, final paragraph): The text states "Both SW-PCs
> and SW-PVs SHOULD log errors so that administrators can trace the causes of
> detected, and additional descriptive information to aid in understanding the
> nature and cause of the error."
> 
> 	The reviewer recommended adding the following sentence: "Logs
> are an important debugging tool and implementers are strongly advised to
> include comprehensive logging capabilities in their products."
> 
> 
> 	[email-masked] <mailto:[email-masked]>

---

From: Adam Montville <[email-masked]>
Date: Fri, 02 Jun 2017 13:38:17 +0000

Thank you! I was hopeful. It would be great to get implementers comments.

Adam

On Fri, Jun 2, 2017 at 8:25 AM Schmidt, Charles M. <[email-masked]>
wrote:

> Hi Adam,
>
> These were not based on implementation (although I'm aware of a couple
> teams working on that so hopefully they will have comments). These comments
> were based on extracting all the normative guidance from the document and
> doing a review just of that.
>
> Charles
>
> attribute