Software Inventory Message and Attributes (SWIMA) for PA-TNC
draft-ietf-sacm-nea-swima-patnc-05

Received changes through RFC Editor sync (created alias RFC 8412, changed abstract to 'This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209).', changed pages to 101, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-07-05, changed IESG state to RFC Published)

[Ballot comment]
Thank you for addressing my DISCUSS and many of my comments. Remaining comments listed below (plus see updated point #7)

Minor:

(Points not mentioned below were addressed).

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.

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) (downgraded from DISCUSS): SWID registry is using "http://invalid.unavailable" Tag Creator RegID value in Section 6.1.1.

invalid.unavailable is not a valid domain name and "unavailable" is not registered in the special-use domain registry


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.
Note, if you can change the value to "http://unavailable.invalid", that would address my concern.

[Ballot comment]
Minor:

(Points not mentioned below were addressed).

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.

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) (downgraded from DISCUSS): SWID registry is using "http://invalid.unavailable" Tag Creator RegID value in Section 6.1.1.

invalid.unavailable is not a valid domain name and "unavailable" is not registered in the special-use domain registry


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.
Note, if you can change the value to "http://unavailable.invalid", that would address my concern.

[Ballot comment]
The shepherd write-up says: "This document is being requested for publication as an Internet Standard RFC." I issued my ballot position under the assumption that document is published as Proposed Standard as indicated in the datatracker.

[Ballot 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


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.

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

[Ballot comment]
Thanks for everyone's work on this document. I support Ben's DISCUSS, his
concerns regarding the treatment of privacy in §8, and EKR's concerns
regarding the phrasing "not generally considered to be sensitive."

I also have a few very important comments about this document's
handling of URIs.

§3.4.4:
>  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 URI schema describes the context of the described location.  For
>  example, in most cases the location of the installed software product
>  will be expressed in terms of its path in the filesystem.  For such
>  locations, the location URI scheme MUST be "file" or the URI MUST
>  appear without a scheme.  (I.e., "file" is default scheme.)  It is
>  possible that other schemes could be used to represent other location
>  contexts.  Apart from reserving the "file" scheme, this specification
>  does not reserve schemes.  When representing software products in
>  other location contexts, tools MUST be consistent in their use of
>  schemes, but the exact string used in those schemes is not
>  normatively defined here.

Please cite RFC 8098 in this paragraph.

Saying that a URI can appear without a scheme is at least confusing and probably
ambiguous. For example, I can't tell which of the following syntaxes are
expected and/or allowed:

1. :///Applications/TurnipTwaddler
2. ///Applications/TurnipTwaddler
3. /Applications/TurnipTwaddler

Read literally, the quoted paragraph describes the first. It probably means to
describe the second (maybe?), but I suspect some implementors will interpret
it as the third.

This becomes even more problematic for Windows, where it might be interpreted
to mean any of *four* things (where the final one is clearly wrong due to
potential confusion between drive letters and URI schemes -- but which I'm
sure will be implemented if not clearly spelled out):

1. :///C:/Program%20Files/TurnipTwaddler
2. ///C:/Program%20Files/TurnipTwaddler
3. /C:/Program%20Files/TurnipTwaddler
4. C:/Program%20Files/TurnipTwaddler

To be clear, whatever you define in this document cannot allow the omission of a
scheme to result in Form #4 above, as this is syntactically ambiguous.

It also probably bears reiterating that omitting the "file" scheme from a URI
doesn't exempt it from encoding according to RFC 8089 section 4 (e.g.,
including an unescaped space, as in "Program Files", would be syntactically
invalid).

Finally, I question the assertion that "The location URI does not include an
authority part." It's been a while since I used Windows on a regular basis, but
my recollection is that files -- including applications -- can be accessed from
a CIFS filesystem without associating a local mount point with them. It would be
impossible to describe the location of such applications if the authority is
required to be omitted. It is easy to anticipate that future iterations of,
e.g., Linux may have similar properties. (Popular desktops already allow
userland access of files on unmounted access using full URIs, which necessarily
include authority components; it is not far-fetched to imagine that this
functionality might be incorporated into the kernel at some point).

---------------------------------------------------------------------------

The following appears in several places:

>  | Software      | A string containing the Software Locator value.  |
>  | Locator        | This is expressed as a URI. This field value    |
>  |                | MUST be normalized to Network Unicode format as  |
>  |                | described in Section 3.4.4. This string MUST NOT |
>  |                | be NULL terminated.                              |

Section 3.4.4 doesn't describe the use of Network Unicode format, so this text
is confusing. I'll note that file URIs are generally going to be percent
encoded, so they shouldn't contain any non-ASCII characters. Section 4 of RFC
8089 deals with encoding considerations for file URIs. Other URIs have their own
encoding considerations, and it would be somewhat ambitious for this document to
take on any encoding specification above and beyond what is already defined for
each scheme.

[Ballot discuss]
(This is related to one of Ekr's comments, but I don't think it's quite the same.)

In the first paragraph of §7.2, the conclusions seem to be based on the following sentence:

"This is generally not considered to be problematic, as
  those with access to the endpoint can usually learn of everything
  disclosed by that endpoint’s records simply by inspecting other parts
  of the endpoint."

This doesn’t seem like a reasonable assumption. Multiuser endpoints may well have access controls that prevent a given user from seeing all software packages installed on the system. This leads to the conclusion that the records on the endpoint are not sensitive. I do not think this document should draw that conclusion. Even if this were provably true for all existing systems, such an assumption could be problematic for future systems.

[Ballot comment]
Substantive Comments:

§2.4: This seems to assume there is never a need to hide information from intermediaries. Is that the intent? (Or maybe there aren't any intermediaries?)

§3.4.3,
-- first paragraph: What is the expected scope of uniqueness for record identifiers?
-- In the sentence "The Record Identifier SHOULD remain unchanged if that record is modified.", why is the SHOULD not a MUST? What would happen if the identifier did change?

§3.4.4:

-- "However, if that directory is shared by other software products, the "location" SHOULD be the location of the primary executable
  associated with the software product."
I'm confused by the the condition, since sharing a directory with other products doesn't seem to introduce the ambiguity that the rest of the sentence assumes. Perhaps this was meant to be about situations where a software package is installed across multiple directories?

-- "Even a probable location for a software product is preferable to using a zero-length locator."
This could use elaboration; do you expect the collector to guess?

§7.1: " Some tools might not be designed to update records in the Software Inventory Evidence Collection in real time,..."
Wasn't there a normative requirement that they be capable of this?

§8,
-- 2nd paragraph: It’s worth mentioning that in some contexts this sort of information could expose the user to severe personal risk, including the risk of death.
-- Last paragraph: "For this reason, privacy safeguards might be necessary for collected inventory information."
Can this be stated more strongly than "might be necessary"?



Editorial Comments and Nits:

§3.8.5, first paragraph: "As noted in Section 3.6 SWIMA-PCs MUST ..."
Please reserve 2119 keywords for the authoritative statement of a requirement; that is, please do not use them to refer to requirements defined elsewhere. (Note that this pattern occurs multiple times in the draft.)

§9: Nit: is there are reasons to violate the convention that IANA, security, and privacy considerations are the last substantive sections in in the body of an RFC?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-sacm-nea-swima-patnc-01. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the PA Subtypes registry on the Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) Parameters regsitry page located at:

https://www.iana.org/assignments/pb-tnc-parameters/

the following registration is to be added:

PEN: 0
Integer: 9
Name: SWIMA Attributes
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the PA-TNC Attribute Types registry on the Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) Parameters registry page located at:

https://www.iana.org/assignments/pa-tnc-parameters/

the following registrations will be added to the registry:

+-----+---------+-------------------+-------------------------------+
| PEN | Integer | Name | Defining Specification |
+-----+---------+-------------------+-------------------------------+
| 0 | 17 | SWIMA Request | [ RFC-to-be ] |
| | | | |
| 0 | 18 | Software | [ RFC-to-be ] |
| | | Identifier | |
| | | Inventory | |
| | | | |
| 0 | 19 | Software | [ RFC-to-be ] |
| | | Identifier Events | |
| | | | |
| 0 | 20 | Software | [ RFC-to-be ] |
| | | Inventory | |
| | | | |
| 0 | 21 | Software Events | [ RFC-to-be ] |
| | | | |
| 0 | 22 | Subscription | [ RFC-to-be ] |
| | | Status Request | |
| | | | |
| 0 | 23 | Subscription | [ RFC-to-be ] |
| | | Status Response | |
| | | | |
| 0 | 24 | Source Metadata | [ RFC-to-be ] |
| | | Request | |
| | | | |
| 0 | 25 | Source Metadata | [ RFC-to-be ] |
| | | Response | |
| | | | |
| 0 | 26 - 31 | Reserved for | [ RFC-to-be ] |
| | | future use | |
+-----+---------+-------------------+-------------------------------+

IANA Question --> are Integer values 13 - 16 defined in another document, or is there a reason these values are not used?

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the PA-TNC Error Codes registry on the Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) Parameters registry page located at:

https://www.iana.org/assignments/pa-tnc-parameters/

the following registrations will be added to the registry:

+-----+---------+--------------------------------------+---------------+
| PEN | Integer | Name | Reference |
+-----+---------+--------------------------------------+---------------+
| 0 | 32 | SWIMA_ERROR | [ RFC-to-be ] |
| 0 | 33 | SWIMA_SUBSCRIPTION_DENIED_ERROR | [ RFC-to-be ] |
| 0 | 34 | SWIMA_RESPONSE_TOO_LARGE_ERROR | [ RFC-to-be ] |
| 0 | 35 | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR | [ RFC-to-be ] |
| 0 | 36 | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR | [ RFC-to-be ] |
| 0 | 37-47 | Reserved for future use | [ RFC-to-be ] |
+-----+---------+--------------------------------------+---------------+

IANA Question --> are Integer values 4 - 31 defined in another document, or is there a reason these values are not used?

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, a new registry is to be created called the Software Data Models registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? Is it to be on the Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) Parameters registry page located at:

https://www.iana.org/assignments/pa-tnc-parameters/ ?

The new registry is to be managed via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+-----+---------+----------------------------+----------------------+
| PEN | Integer | Name | Reference |
+-----+---------+----------------------------+----------------------+
| 0 | 1 | ISO 2015 SWID Tags using | [ RFC-to-be ] |
| | | XML | |
| 0 | 2 | ISO 2009 SWID Tags using | [ RFC-to-be ] |
| | | XML | |
| 0 | 192-255 | Reserved for local | N/A |
| | | enterprise use | |
+-----+---------+----------------------------+----------------------+

IANA Question --> Is PEN 0, Integer Value 0 reserved or unassigned?

IANA Question --> Are PEN 0, Integer Values 3-191 unassigned?

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

[Ballot 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

[Ballot comment]
The authors have queued up some clarifying text from section 10.4 to make it more clear that this section is requesting the addition of a new registry.  My ballot also makes that point clear int he request to IANA.

[Ballot comment]
The authors have queued up some clarifying text fro section 10.4 to make it more clear that this section is requesting the addition of a new registry.  My ballot also makes that point clear int he request to IANA.

The following Last Call announcement was sent out (ends 2018-02-21):

From: The IESG
To: IETF-Announce
CC: sacm-chairs@ietf.org, sacm@ietf.org, odonoghue@isoc.org, Karen O'Donoghue , Kathleen.Moriarty.ietf@gmail.com, draft-ietf-sacm-nea-swima-patnc@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Software Inventory Message and Attributes (SWIMA) for PA-TNC) to Proposed Standard


The IESG has received a request from the Security Automation and Continuous
Monitoring WG (sacm) to consider the following document: - 'Software
Inventory Message and Attributes (SWIMA) for PA-TNC'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document extends the PA-TNC specification [RFC5792] by providing
  specific attributes and message exchanges to allow endpoints to
  report their installed software inventory information to a NEA server
  (as described in [RFC5209]).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5209: Network Endpoint Assessment (NEA): Overview and Requirements (Informational - IETF stream)

draft-ietf-sacm-nea-swid-patnc shepherd write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is being requested for publication as an Internet Standard RFC. It provides normative requirements surrounding an extension to the IETF NEA specifications (RFC 5209) with the goal of using the NEA protocols to deliver endpoint software inventory information. The intended status is shown on the title page.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:

This document defines normative requirements for an extension to IETF NEA (RFC 5209) for the collection and delivery of software inventory information from an endpoint to a NEA server.

Working Group Summary:
The document has working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item.

Document Quality:
This document has been reviewed and revised many times. It is well written and clear. There were no specific external expert reviews conducted.

Personnel:
Karen O'Donoghue is acting as the Document Shepherd.  Kathleen is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed the final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that were performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document does not require any special reviews beyond those planned during the IESG review process.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Document Shepherd is comfortable with this document as a set of requirements to drive the SACM working group efforts in the future. The documents represent the consensus of the working group.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors have confirmed that they have dealt with all appropriate IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Parts of the workgroup are interested in different subsections of the SACM architecture. Within the portion of SACM that is focusing on collecting data from endpoints, there is strong consensus behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

###There are ID nits that need to be fixed, but we'll make sure they are done once Kathleen has done her review.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no formal review criteria for this document.

(13) Have all references within this document been identified as either normative or informative?

All references are tagged as normative or informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are to published documents.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No references are made to documents at a lower maturity level.
There are normative references to ISO/IEC 19770-2-2009 and ISO/IEC 19770-2-2015, both of which are behind a paywall.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document will not change the status of any existing RFC. This document extends NEA along standard extension points built into that specification and requires no changes to any NEA specification.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

(###Need to finish in parallel with Kathleen's review)

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

A new entry is added to the existing “PA Subtype” registry defined in RFC 5792. This addition requires expert review as defined in section 7.1 in that specification.
10 new entries are added to the existing “PA-TNC Attribute Types” registry defined in RFC 5792. This addition requires expert review as defined in section 7.1 in that specification.

6 new entries are added to the existing “PA-TNC Error Codes” registry defined in RFC 5792. This addition requires expert review as defined in section 7.1 in that specification.

The specification defines a new registry named “Software Data Model Types”. Addition of further entries to this registry will require expert review.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language sections in this document.