Skip to main content

PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)
RFC 5792

Revision differences

Document history

Date Rev. By Action
2020-01-21
06 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
06 (System) Notify list changed from nea-chairs@ietf.org, draft-ietf-nea-pa-tnc@ietf.org to (None)
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Ralph Droms
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2010-03-10
06 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2010-03-10
06 Cindy Morgan [Note]: 'RFC 5792' added by Cindy Morgan
2010-03-09
06 (System) RFC published
2010-01-13
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-01-11
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-01-11
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-01-06
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-01-06
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-11-16
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-11-09
06 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-11-09
06 (System) IANA Action state changed to In Progress
2009-11-07
06 Cindy Morgan IESG state changed to Approved-announcement sent
2009-11-07
06 Cindy Morgan IESG has approved the document
2009-11-07
06 Cindy Morgan Closed "Approve" ballot
2009-10-25
06 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov
2009-10-25
06 Alexey Melnikov [Ballot comment]
Who is going to be the Designated Expert for the registries created by the document?
2009-10-25
06 Alexey Melnikov [Ballot discuss]
2009-10-23
06 (System) New version available: draft-ietf-nea-pa-tnc-06.txt
2009-09-17
06 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss by Ralph Droms
2009-09-17
06 Ralph Droms
[Ballot comment]
In the last paragraph of section 3.1, a reference to section 4.5 of the PB spec would be helpful, as section 3.4 of …
[Ballot comment]
In the last paragraph of section 3.1, a reference to section 4.5 of the PB spec would be helpful, as section 3.4 of the PB spec really describes very little of the PB-PA header.

Similarly, a reference to section 4.5 of the PB spec in section 3.3 would be helpful.
2009-09-17
06 Ralph Droms
[Ballot discuss]
+1 for Alexey's comments on the quality and readability of this
document.

Expanding on Alexey's comments about the definition of the TimeString
Field …
[Ballot discuss]
+1 for Alexey's comments on the quality and readability of this
document.

Expanding on Alexey's comments about the definition of the TimeString
Field Type, it seems the Field Types defined in section 3.6 are not
used throughout the rest of the document.  In the example Alexey
mentioned, I would have expected that the TimeString Field Type have
the expanded definition suggested by Alexey, with a simple reference
to that Field Type in the definition of the Last Use field of the
Operational Status Attribute.

In my opinion, there are several other Attribute fields that could be
defined in terms of Field Types. 

In the case of the Numeric Version Attribute Type, I would expect the
Major/Minor Version Number and Service Pack Major/Minor fields to be
encoded as a VersionNum Field Type. 

What is the "PA-PB header"?  There are only a couple of references, in
sections 3.1 and 3.3.

Glancing at draft-ietf-nea-pb-tnc-04 (which I haven't read in detail,
yet), there is a PB-PA header; it would clarify
draft-ietf-nea-pa-tnc-04 to include a reference to the definition of
the PB-PA header (if I've got the association right).

The definition of the Posture Collector Identifier is unclear.  From
the definition in draft-ietf-nea-pb-tnc-04 - here, too, a reference to
section 4.5 of draft-ietf-nea-pb-tnc-04 would help - I understand the
Posture Collector Identifier to be associated with a specific Posture
Collector.  But, this text from section 3.3 of  gives a somewhat
different understanding:

    For example, a single Posture Collector might report attributes 
    on two installed VPN implementations on the endpoint.  Because 
    the individual attributes do not include an indication of which 
    VPN product they are describing, the recipient needs something 
    to perform this correlation.  Therefore, for this example, the 
    VPN Posture Collector would need to obtain two Posture Collector 
    Identifiers from the Posture Broker Client and consistently use 
    one with each of the implementations during an assessment.

Also, section 4.5 of draft-ietf-nea-pb-tnc-04 defines the Posture
Collector Identifier as being assigned by the Posture Broker Client
without intervention on the part of the Posture Collector,
while the text quoted above indicates that the Posture Collector
obtains Posture Collector Identifiers from the Posture Broker Client
and then supplies the Posture Collector Identifier with the associated
attributes to the Posture Broker Client.

Section 3.1, para 3: Each Posture Collector or Posture Validator 
    may send several PA-TNC messages in succession before indicating 
    that it has completed its response to the Posture Broker Client 
    or Posture Broker Server respectively.  As necessary, the 
    Posture Broker Client and Posture Broker Server will batch these 
    messages prior to sending them over the network.

"its response" seems overly restrictive.  What about transactions
initiated by the Posture Collector or Posture Validator?
s/response/batch of messages/ ?

Section 3.1:  However, this publish/subscribe model has some possible negative 
    side effects.  When a Posture Collector or Posture Validator 
    initially sends a PA-TNC message, it does not know whether it 
    will receive many, one, or no PA-TNC messages from the other 
    side.  For many types of assessments, this is acceptable, but in 
    some cases a more direct channel binding between a particular 
    Posture Collector and Posture Validator pair is necessary.  For 
    example, a Posture Validator may wish to provide remediation 
    instructions to a particular Posture Collector that it knows is 
    capable of remediating a non-compliant component.  This can be 
    accomplished using the exclusive delivery PB-TNC capability to 
    limit distribution of a message to a single Posture Collector by 
    including the target Posture Collector Identifier in the PA-PB 
    header.

(This question may be more appropriate in a review of
draft-ietf-nea-pb-tnc.)  Suppose the Posture Validator field is set
but the EXCL is not set in a message sent from a Posture Collector
through a Posture Broker Client.  Does the Posture Broker Server
deliver the message to all Posture Validators registered for the
message sub-type or just the Posture Validator identified in the
Posture Validator field?

Section 3.2:      The PA Subtype identifies the message type more specifically 
    within the set of message types defined by that vendor.  This 
    specification defines several IETF Standard PA Subtypes to be 
    used with a PA Message Vendor ID of zero (0).  Within this 
    specification, the PA Subtype field is used to indicate the type 
    of component (e.g. firewall) involved with the message's 
    attributes.

Vendors may define other message types that are not components?

Section 4.1:
    PA-TNC Attribute Length 

        [...]

        Implementations that do not support the specified PA-TNC 
        Attribute Type can use this length to skip over this 
        attribute to the next attribute.  Note that while this field 
        is 4 octets the maximum usable attribute length is likely to 
        be less than 2^32-1 due to limitations of the underlying 
        protocol stack specifically PB-TNC's length field includes 32 
        bytes of other headers which reduce the maximum size 
        available to PA-TNC since they both use 4 octet length 
        fields. 

I can't parse last sentence in this paragraph.
2009-08-28
06 Alexey Melnikov [Ballot comment]
Who is going to be the Designated Expert for the registries created by the document?
2009-08-28
06 Alexey Melnikov
[Ballot discuss]
Updated as per version -05.

This is a well written document, it was a pleasure to read (despite the length). However I have …
[Ballot discuss]
Updated as per version -05.

This is a well written document, it was a pleasure to read (despite the length). However I have some blocking comments, which are relatively minor. I would be happy for them to be resolved using RFC Editor notes:

1). The document is referencing PA-TNC security protocol.
draft-sangster-nea-pa-tnc-security-00 is an example of such protocol.
This is not being worked on by the WG, as far as I can tell, and the individual draft has expired. What is the status of this?
2009-08-28
06 Alexey Melnikov [Ballot comment]
Who is going to be the Designated Expert for the registries created by the document?
2009-08-28
06 Alexey Melnikov
[Ballot discuss]
I've updated the DISCUSS portion after reading responses from Paul Sangster and seeing a comment from Robert Sparks.

This is a well written …
[Ballot discuss]
I've updated the DISCUSS portion after reading responses from Paul Sangster and seeing a comment from Robert Sparks.

This is a well written document, it was a pleasure to read (despite the length). However I have some blocking comments, which are relatively minor. I would be happy for them to be resolved using RFC Editor notes:

1). The document is referencing PA-TNC security protocol.
draft-sangster-nea-pa-tnc-security-00 is an example of such protocol.
This is not being worked on by the WG, as far as I can tell, and the individual draft has expired. What is the status of this?
2009-08-26
06 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2009-08-26
06 Russ Housley State Changes to IESG Evaluation::AD Followup from IESG Evaluation - Defer::AD Followup by Russ Housley
2009-08-26
06 Russ Housley Note field has been cleared by Russ Housley
2009-08-25
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-08-25
05 (System) New version available: draft-ietf-nea-pa-tnc-05.txt
2009-08-13
06 Cindy Morgan State Changes to IESG Evaluation - Defer::Revised ID Needed from IESG Evaluation - Defer by Cindy Morgan
2009-08-13
06 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2009-08-13
06 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-08-11
06 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2009-08-10
06 Russ Housley
[Ballot discuss]
The document says:
  >
  > Consistent with IETF's requirements for standards track 
  > documents, the TCG has authorized the editors …
[Ballot discuss]
The document says:
  >
  > Consistent with IETF's requirements for standards track 
  > documents, the TCG has authorized the editors of this document 
  > to offer the specification to the IETF without restriction.  As 
  > with other Internet-Drafts, the IETF Trust owns the copyright to 
  > this document.  The IETF may modify this document, ignore it, 
  > publish it as an RFC, or take any other action.  If the IETF 
  > decides to adopt a version of this document as an RFC, the TCG 
  > plans to publish a specification for an equivalent TNC protocol 
  > to ensure continued compatibility.
  >
  While this seems fine for an Internet-Draft, the wording does not
  seem right for an Standards Track RFC.    The copyright statements
  here are redundant, and the RFC copyright shoudl speak for itself.
  I suggest:
  >
  > The TCG has transferred change control of this specification to
  > the IETF without restriction.  The TCG plans to publish a
  > specification for an equivalent TNC protocol to ensure
  > continued compatibility.
2009-08-07
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Larry Zhu
2009-08-07
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Larry Zhu
2009-08-07
06 Samuel Weiler Assignment of request for Last Call review by SECDIR to Tobias Gondrom was rejected
2009-07-17
06 (System) Removed from agenda for telechat - 2009-07-16
2009-07-16
06 Alexey Melnikov
[Ballot comment]
Some comments. I would appreciate a response.

1). In Section 3.6:

      TimeString  An RFC 3339 [4] compliant ASCII string expressed  …
[Ballot comment]
Some comments. I would appreciate a response.

1). In Section 3.6:

      TimeString  An RFC 3339 [4] compliant ASCII string expressed 
                  in Coordinated Universal Time (UTC) time.

Definition in section 4.2.5 is more precise, in particular it says that fractional seconds are not used, that 't' and 'z' are capitalized.
I suggest you copy text from section 4.2.5 here.

2). In Section 4.2.1:

    All Posture Collectors that implement any of the IETF Standard 
    PA Subtypes defined in this specification SHOULD support 

This text needs to be clarified that Posture Collectors must either support this attribute, or send an error that they don't. Silently ignoring it shouldn't be allowed.

    receiving and processing this attribute type for at least those 
    PA subtypes.

3). In Section 4.2.4:

    Config. Len 

        This field defines the number of octets in the Configuration 
        Version Number field.  If the product version number is 
        unavailable or unknown, this field MUST be set to 0 and the 
        Product Version Number field will be zero length (effectively 
        not present). 

I think you meant "configuration version" everywhere in this paragraph.

4). In Section 4.2.5:

        Leap seconds are permitted and Posture Validators MUST 
        support them. The last use string MUST NOT be NUL terminated 
        or padded in any way.  If the last use time is not known, not 
        applicable, or cannot be represented in this format, the 
        Posture Collector MUST set this field to the value "0000-00-
        00T00:00:00Z" (allowing this field to be fixed length). Not 

Typo: Note

        that this particular reserved value is NOT a valid RFC 3339 
        date and time and MUST NOT be used for any other purpose in 
        this field. 

5). In Section 4.2.6:

    Protocol 

        This field contains the protocol number being blocked or 
        allowed. The values used in this field are the same ones used 
        in the IPv4 Protocol and IPv6 Next Header fields.  The IANA 
        already maintains a registry of these values.

I think you need to add the name of the registry here.

    Port Number 

        This field contains the port number being blocked or allowed. 
        The values used in this field are specific to the protocol 
        identified by the Protocol field.  The IANA maintains 
        registries for TCP and UDP port numbers. 

In both paragraphs: clarify that you are talking about *transport* protocols.

6). In Section 5:

    This section discusses the major types of potential security 
    threats relevant to the PA-TNC message protocol and summarizes 
    the expected security protections that should be offered by PA-
    TNC security protocols.  PA-TNC security protocols are described 
    in separate specifications which layer upon the base PA-TNC 
    protocol described in this specification.


I think an informative reference to [8] would be useful here.

7). In Section 4.2.5:

    Last Use 

        This field contains the date and time of the last use of the 
        component.  The Last Use date and time MUST be represented as 
        an RFC 3339 [4] compliant ASCII string in Coordinated 
        Universal Time (UTC) time with the additional restrictions 
        that the 't' delimiter and the 'z' suffix MUST be capitalized 
        and fractional seconds (time-secfrac) MUST NOT be included.

The document needs to say that this field conforms to date-time
ABNF production from section 5.6 of RFC 3339.
(RFC 3339 also has Appendix A, which might confuse readers.)

8). Who is going to be the Designated Expert for the registries created by the document?
2009-07-16
06 Alexey Melnikov
[Ballot discuss]
I've updated the DISCUSS portion after reading responses from Paul Sangster and seeing a comment from Robert Sparks.

This is a well written …
[Ballot discuss]
I've updated the DISCUSS portion after reading responses from Paul Sangster and seeing a comment from Robert Sparks.

This is a well written document, it was a pleasure to read (despite the length). However I have some blocking comments, which are relatively minor. I would be happy for them to be resolved using RFC Editor notes:

1). The document is referencing PA-TNC security protocol.
draft-sangster-nea-pa-tnc-security-00 is an example of such protocol.
This is not being worked on by the WG, as far as I can tell, and the individual draft has expired. What is the status of this?

2). In Section 4.2.10.1:

    Remediation-String 

        The Remediation Parameters field in the Remediation 
        Instructions attribute MUST contain a UTF-8 encoded string. 
        This string should contain human-readable instructions for 
        remediation that MAY be displayed to the user by the Posture 
        Collector.  The Remediation String SHOULD be localized in the 
        user's preferred language when known and supported by the NEA 
        Server. 

BCP 18 (RFC 2277), section 4.2 says:

  Protocols that transfer text MUST provide for carrying information
  about the language of that text.

[...]

  Note that this does NOT mean that such information must always be
  present; the requirement is that if the sender of information wishes
  to send information about the language of a text, the protocol
  provides a well-defined way to carry this information.

So the document would need to have a normative reference to RFC 4646 and some text about use of language tags. I can advise separately on how to address this issue.

3).
    [9]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 
          Resource Identifier (URI): Generic Syntax", RFC 3986
          January 2005. 

This reference should be Normative.

4). After seeing comment from Robert, I am upgrading this to DISCUSS.

In Section 4.2.10.1:

        The Remediation Parameters field in the Remediation 
        Instructions attribute MUST contain a URI, as described in 
        RFC 3986 [9].  This URI SHOULD contain instructions to update 
        a particular component so that it might result in the 
        component being compliant with the policies in future 
        assessments. 

The Security consideration should specifically talk about the danger of automatic downloading and execution of content specified by such URIs.
2009-07-16
06 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to Undefined from No Objection by Magnus Westerlund
2009-07-16
06 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-07-16
06 Cullen Jennings State Changes to IESG Evaluation - Defer from IESG Evaluation by Cullen Jennings
2009-07-16
06 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-07-16
06 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-07-16
06 Alexey Melnikov
[Ballot comment]
Some comments. I would appreciate a response.

1). In Section 3.6:

      TimeString  An RFC 3339 [4] compliant ASCII string expressed  …
[Ballot comment]
Some comments. I would appreciate a response.

1). In Section 3.6:

      TimeString  An RFC 3339 [4] compliant ASCII string expressed 
                  in Coordinated Universal Time (UTC) time.

Definition in section 4.2.5 is more precise, in particular it says that fractional seconds are not used, that 't' and 'z' are capitalized.
I suggest you copy text from section 4.2.5 here.

2). In Section 4.2.1:

    All Posture Collectors that implement any of the IETF Standard 
    PA Subtypes defined in this specification SHOULD support 

This text needs to be clarified that Posture Collectors must either support this attribute, or send an error that they don't. Silently ignoring it shouldn't be allowed.

    receiving and processing this attribute type for at least those 
    PA subtypes.

3). In Section 4.2.4:

    Config. Len 

        This field defines the number of octets in the Configuration 
        Version Number field.  If the product version number is 
        unavailable or unknown, this field MUST be set to 0 and the 
        Product Version Number field will be zero length (effectively 
        not present). 

I think you meant "configuration version" everywhere in this paragraph.

4). In Section 4.2.5:

        Leap seconds are permitted and Posture Validators MUST 
        support them. The last use string MUST NOT be NUL terminated 
        or padded in any way.  If the last use time is not known, not 
        applicable, or cannot be represented in this format, the 
        Posture Collector MUST set this field to the value "0000-00-
        00T00:00:00Z" (allowing this field to be fixed length). Not 

Typo: Note

        that this particular reserved value is NOT a valid RFC 3339 
        date and time and MUST NOT be used for any other purpose in 
        this field. 

5). In Section 4.2.6:

    Protocol 

        This field contains the protocol number being blocked or 
        allowed. The values used in this field are the same ones used 
        in the IPv4 Protocol and IPv6 Next Header fields.  The IANA 
        already maintains a registry of these values.

I think you need to add the name of the registry here.

    Port Number 

        This field contains the port number being blocked or allowed. 
        The values used in this field are specific to the protocol 
        identified by the Protocol field.  The IANA maintains 
        registries for TCP and UDP port numbers. 

In both paragraphs: clarify that you are talking about *transport* protocols.

6). In Section 5:

    This section discusses the major types of potential security 
    threats relevant to the PA-TNC message protocol and summarizes 
    the expected security protections that should be offered by PA-
    TNC security protocols.  PA-TNC security protocols are described 
    in separate specifications which layer upon the base PA-TNC 
    protocol described in this specification.

I think an informative reference to [8] would be useful here.

7). In Section 4.2.5:

    Last Use 

        This field contains the date and time of the last use of the 
        component.  The Last Use date and time MUST be represented as 
        an RFC 3339 [4] compliant ASCII string in Coordinated 
        Universal Time (UTC) time with the additional restrictions 
        that the 't' delimiter and the 'z' suffix MUST be capitalized 
        and fractional seconds (time-secfrac) MUST NOT be included.

The document needs to say that this field conforms to date-time
ABNF production from section 5.6 of RFC 3339.
(RFC 3339 also has Appendix A, which might confuse readers.)

8). Who is going to be the Designated Expert for the registries created by the document?
2009-07-16
06 Alexey Melnikov
[Ballot discuss]
I've updated the DISCUSS portion after reading responses from Paul Sangster and seeing a comment from Robert Sparks.

This is a well written …
[Ballot discuss]
I've updated the DISCUSS portion after reading responses from Paul Sangster and seeing a comment from Robert Sparks.

This is a well written document, it was a pleasure to read (despite the length). However I have some blocking comments, which are relatively minor. I would be happy for them to be resolved using RFC Editor notes:

0). DISCUSS DISCUSS:

The document is referencing PA-TNC security protocol. draft-sangster-nea-pa-tnc-security-00 is an example of such protocol.
This is not being worked on by the WG, as far as I can tell, and the individual draft has expired. What is the status of this?

1). IANA has raised some issues and I agree with the majority of them.
They are summarized below:

The following attribute types are missing from the registry in section 7.3:

    4.2.9. Assessment Result...................................45 
    4.2.10. Remediation Instructions...........................46 
    4.2.11. Forwarding Enabled.................................49 
    4.2.12. Factory Default Password Enabled...................50 

>*************************
>Section 4.1 reserves the 0xffffffff value for PA-TNC Attribute Types
>which is not listed in section 7.3. Should IANA also register this value?
>0 0xffffffff Reserved RFC-nea-pa-tnc-04
>*************************

IANA should register PA-TNC Attribute Type value 0xffffffff as
Reserved. We will update Section 7.3 to reflect this.

>*************************
>Section 4.2.8 also defines the 0 value for PA-TNC Error Codes, which is
>not listed in section 7.4. Should IANA register this value?
>0 0 Reserved RFC-nea-pa-tnc-04
>*************************

IANA should register PA-TNC Error Code value 0 as Reserved. We
will update Section 7.3 to reflect this.

>*************************
>Section 4.2.10 and 7.5 define the Remediation Parameters Types
>subregistry. The 0 value is not registered. As with other subregistries
>in this specification, should IANA reserve it?
>*************************

IANA should register the Remediation Parameters Type value 0. This will ensure consistency with other sub-registries in this specification.


2). In Section 4.2.10.1:

    Remediation-String 

        The Remediation Parameters field in the Remediation 
        Instructions attribute MUST contain a UTF-8 encoded string. 
        This string should contain human-readable instructions for 
        remediation that MAY be displayed to the user by the Posture 
        Collector.  The Remediation String SHOULD be localized in the 
        user's preferred language when known and supported by the NEA 
        Server. 

BCP 18 (RFC 2277), section 4.2 says:

  Protocols that transfer text MUST provide for carrying information
  about the language of that text.

[...]

  Note that this does NOT mean that such information must always be
  present; the requirement is that if the sender of information wishes
  to send information about the language of a text, the protocol
  provides a well-defined way to carry this information.

So the document would need to have a normative reference to RFC 4646 and some text about use of language tags. I can advise separately on how to address this issue.

3).
    [9]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 
          Resource Identifier (URI): Generic Syntax", RFC 3986
          January 2005. 

This reference should be Normative.

4). After seeing comment from Robert, I am upgrading this to DISCUSS.

In Section 4.2.10.1:

        The Remediation Parameters field in the Remediation 
        Instructions attribute MUST contain a URI, as described in 
        RFC 3986 [9].  This URI SHOULD contain instructions to update 
        a particular component so that it might result in the 
        component being compliant with the policies in future 
        assessments. 

The Security consideration should specifically talk about the danger of automatic downloading and execution of content specified by such URIs.
2009-07-16
06 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2009-07-15
06 Robert Sparks
[Ballot comment]
I strongly agree with Alexey's comment suggesting more discussion of the
danger of automatic processing of the content of Remediation instructions.

Should the …
[Ballot comment]
I strongly agree with Alexey's comment suggesting more discussion of the
danger of automatic processing of the content of Remediation instructions.

Should the document provide some guidance on what to do if a message contains both a numeric version and a string version (4.2.3, 4.2.4 respectively)

draft-sangster-nea-pa-tnc-security-00 is expired. What is the nea wg's current plan for it?
2009-07-15
06 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-07-15
06 Alexey Melnikov
[Ballot comment]
Some comments. I would appreciate a response.

1). In Section 3.6:

      TimeString  An RFC 3339 [4] compliant ASCII string expressed  …
[Ballot comment]
Some comments. I would appreciate a response.

1). In Section 3.6:

      TimeString  An RFC 3339 [4] compliant ASCII string expressed 
                  in Coordinated Universal Time (UTC) time.

Definition in section 4.2.5 is more precise, in particular it says that fractional seconds are not used, that 't' and 'z' are capitalized.
I suggest you copy text from section 4.2.5 here.

2). In Section 4.2.1:

    All Posture Collectors that implement any of the IETF Standard 
    PA Subtypes defined in this specification SHOULD support 

Why this is just a SHOULD?

    receiving and processing this attribute type for at least those 
    PA subtypes.  Posture Collectors that receive and process this 
    attribute MAY choose to send all, a subset or none of the 
    requested attributes but MUST NOT send attributes that were not 

This MUST NOT is quite pointless, considering the first SHOULD.
How does the sender know if the other end complies with the SHOULD?

    requested (except error attributes).

3). In Section 4.2.4:

    Config. Len 

        This field defines the number of octets in the Configuration 
        Version Number field.  If the product version number is 
        unavailable or unknown, this field MUST be set to 0 and the 
        Product Version Number field will be zero length (effectively 
        not present). 

I think you meant "configuration version" everywhere in this paragraph.

4). In Section 4.2.5:

        Leap seconds are permitted and Posture Validators MUST 
        support them. The last use string MUST NOT be NUL terminated 
        or padded in any way.  If the last use time is not known, not 
        applicable, or cannot be represented in this format, the 
        Posture Collector MUST set this field to the value "0000-00-
        00T00:00:00Z" (allowing this field to be fixed length). Not 

Typo: Note

        that this particular reserved value is NOT a valid RFC 3339 
        date and time and MUST NOT be used for any other purpose in 
        this field. 

5). In Section 4.2.6:

    Protocol 

        This field contains the protocol number being blocked or 
        allowed. The values used in this field are the same ones used 
        in the IPv4 Protocol and IPv6 Next Header fields.  The IANA 
        already maintains a registry of these values.

I think you need to add the name of the registry here.

    Port Number 

        This field contains the port number being blocked or allowed. 
        The values used in this field are specific to the protocol 
        identified by the Protocol field.  The IANA maintains 
        registries for TCP and UDP port numbers. 

In both paragraphs: clarify that you are talking about *transport* protocols.

6). In Section 4.2.10.1:

        The Remediation Parameters field in the Remediation 
        Instructions attribute MUST contain a URI, as described in 
        RFC 3986 [9].  This URI SHOULD contain instructions to update 
        a particular component so that it might result in the 
        component being compliant with the policies in future 
        assessments. 

I think the Security consideration should specifically talk about the danger of automatic downloading and execution of content specified by such URIs.

7). In Section 5:

    This section discusses the major types of potential security 
    threats relevant to the PA-TNC message protocol and summarizes 
    the expected security protections that should be offered by PA-
    TNC security protocols.  PA-TNC security protocols are described 
    in separate specifications which layer upon the base PA-TNC 
    protocol described in this specification.

I think an informative reference to [8] would be useful here.

8). Who is going to be the Designated Expert for the registries created by the document?
2009-07-15
06 Alexey Melnikov
[Ballot discuss]
I've updated the DISCUSS portion after reading responses from Paul Sangster. The COMMENT part hasn't changed, but there is no way to exclude …
[Ballot discuss]
I've updated the DISCUSS portion after reading responses from Paul Sangster. The COMMENT part hasn't changed, but there is no way to exclude it from the email message generated by the IDTracker.

This is a well written document, it was a pleasure to read (despite the length). However I have some blocking comments, which are relatively minor. I would be happy for them to be resolved using RFC Editor notes:

0). DISCUSS DISCUSS:

The document is referencing PA-TNC security protocol. This is not being worked on by the WG, as far as I can tell, and the individual draft has expired. What is the status of this?

1). IANA has raised some issues and I agree with the majority of them.
In particular:

The following attribute types are missing from the registry in section 7.3:

    4.2.9. Assessment Result...................................45 
    4.2.10. Remediation Instructions...........................46 
    4.2.11. Forwarding Enabled.................................49 
    4.2.12. Factory Default Password Enabled...................50 

2). In Section 4.2.10.1:

    Remediation-String 

        The Remediation Parameters field in the Remediation 
        Instructions attribute MUST contain a UTF-8 encoded string. 
        This string should contain human-readable instructions for 
        remediation that MAY be displayed to the user by the Posture 
        Collector.  The Remediation String SHOULD be localized in the 
        user's preferred language when known and supported by the NEA 
        Server. 

BCP 18 (RFC 2277), section 4.2 says:

  Protocols that transfer text MUST provide for carrying information
  about the language of that text.

[...]

  Note that this does NOT mean that such information must always be
  present; the requirement is that if the sender of information wishes
  to send information about the language of a text, the protocol
  provides a well-defined way to carry this information.

So the document would need to have a normative reference to RFC 4646 and some text about use of language tags. I can advise separately on how to address this issue.

3).
    [9]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 
          Resource Identifier (URI): Generic Syntax", RFC 3986
          January 2005. 

This reference should be Normative.

4). In Section 4.2.5:

    Last Use 

        This field contains the date and time of the last use of the 
        component.  The Last Use date and time MUST be represented as 
        an RFC 3339 [4] compliant ASCII string in Coordinated 
        Universal Time (UTC) time with the additional restrictions 
        that the 't' delimiter and the 'z' suffix MUST be capitalized 
        and fractional seconds (time-secfrac) MUST NOT be included.

The document needs to say that this field conforms to date-time
ABNF production from section 5.6 of RFC 3339.
(RFC 3339 also has Appendix A, which might confuse readers.)
2009-07-15
06 Alexey Melnikov
[Ballot comment]
Some comments. I would appreciate a response.

1). In Section 3.6:

      TimeString  An RFC 3339 [4] compliant ASCII string expressed  …
[Ballot comment]
Some comments. I would appreciate a response.

1). In Section 3.6:

      TimeString  An RFC 3339 [4] compliant ASCII string expressed 
                  in Coordinated Universal Time (UTC) time.

Definition in section 4.2.5 is more precise, in particular it says that fractional seconds are not used, that 't' and 'z' are capitalized.
I suggest you copy text from section 4.2.5 here.

2). In Section 4.2.1:

    All Posture Collectors that implement any of the IETF Standard 
    PA Subtypes defined in this specification SHOULD support 

Why this is just a SHOULD?

    receiving and processing this attribute type for at least those 
    PA subtypes.  Posture Collectors that receive and process this 
    attribute MAY choose to send all, a subset or none of the 
    requested attributes but MUST NOT send attributes that were not 

This MUST NOT is quite pointless, considering the first SHOULD.
How does the sender know if the other end complies with the SHOULD?

    requested (except error attributes).

3). In Section 4.2.4:

    Config. Len 

        This field defines the number of octets in the Configuration 
        Version Number field.  If the product version number is 
        unavailable or unknown, this field MUST be set to 0 and the 
        Product Version Number field will be zero length (effectively 
        not present). 

I think you meant "configuration version" everywhere in this paragraph.

4). In Section 4.2.5:

        Leap seconds are permitted and Posture Validators MUST 
        support them. The last use string MUST NOT be NUL terminated 
        or padded in any way.  If the last use time is not known, not 
        applicable, or cannot be represented in this format, the 
        Posture Collector MUST set this field to the value "0000-00-
        00T00:00:00Z" (allowing this field to be fixed length). Not 

Typo: Note

        that this particular reserved value is NOT a valid RFC 3339 
        date and time and MUST NOT be used for any other purpose in 
        this field. 

5). In Section 4.2.6:

    Protocol 

        This field contains the protocol number being blocked or 
        allowed. The values used in this field are the same ones used 
        in the IPv4 Protocol and IPv6 Next Header fields.  The IANA 
        already maintains a registry of these values.

I think you need to add the name of the registry here.

    Port Number 

        This field contains the port number being blocked or allowed. 
        The values used in this field are specific to the protocol 
        identified by the Protocol field.  The IANA maintains 
        registries for TCP and UDP port numbers. 

In both paragraphs: clarify that you are talking about *transport* protocols.

6). In Section 4.2.10.1:

        The Remediation Parameters field in the Remediation 
        Instructions attribute MUST contain a URI, as described in 
        RFC 3986 [9].  This URI SHOULD contain instructions to update 
        a particular component so that it might result in the 
        component being compliant with the policies in future 
        assessments. 

I think the Security consideration should specifically talk about the danger of automatic downloading and execution of content specified by such URIs.

7). In Section 5:

    This section discusses the major types of potential security 
    threats relevant to the PA-TNC message protocol and summarizes 
    the expected security protections that should be offered by PA-
    TNC security protocols.  PA-TNC security protocols are described 
    in separate specifications which layer upon the base PA-TNC 
    protocol described in this specification.

I think an informative reference to [8] would be useful here.

8). Who is going to be the Designated Expert for the registries created by the document?
2009-07-15
06 Alexey Melnikov
[Ballot discuss]
This is a well written document, it was a pleasure to read (despite the length). However I have some blocking comments, which are …
[Ballot discuss]
This is a well written document, it was a pleasure to read (despite the length). However I have some blocking comments, which are relatively minor. I would be happy for them to be resolved using RFC Editor notes:

0). DISCUSS DISCUSS:

The document is referencing PA-TNC security protocol. This is not being worked on by the WG, as far as I can tell, and the individual draft has expired. What is the status of this?

1). IANA has raised some issues and I agree with the majority of them.
In particular:

The following attribute types are missing from the registry in section 7.3:

    4.2.9. Assessment Result...................................45 
    4.2.10. Remediation Instructions...........................46 
    4.2.11. Forwarding Enabled.................................49 
    4.2.12. Factory Default Password Enabled...................50 

2). In Section 4.2.10.1:

    Remediation-String 

        The Remediation Parameters field in the Remediation 
        Instructions attribute MUST contain a UTF-8 encoded string. 
        This string should contain human-readable instructions for 
        remediation that MAY be displayed to the user by the Posture 
        Collector.  The Remediation String SHOULD be localized in the 
        user's preferred language when known and supported by the NEA 
        Server. 

BCP 18 (RFC 2277), section 4.2 says:

  Protocols that transfer text MUST provide for carrying information
  about the language of that text.

[...]

  Note that this does NOT mean that such information must always be
  present; the requirement is that if the sender of information wishes
  to send information about the language of a text, the protocol
  provides a well-defined way to carry this information.

So the document would need to have a normative reference to RFC 4646 and some text about use of language tags. I can advise separately on how to address this issue.

3).
    [9]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 
          Resource Identifier (URI): Generic Syntax", RFC 3986
          January 2005. 

This reference should be Normative.

4). In Section 4.2.5:

    Last Use 

        This field contains the date and time of the last use of the 
        component.  The Last Use date and time MUST be represented as 
        an RFC 3339 [4] compliant ASCII string in Coordinated 
        Universal Time (UTC) time with the additional restrictions 
        that the 't' delimiter and the 'z' suffix MUST be capitalized 
        and fractional seconds (time-secfrac) MUST NOT be included.

The document needs to say that this field conforms to date-time
ABNF production from section 5.6 of RFC 3339.
(RFC 3339 also has Appendix A, which might confuse readers.)
2009-07-14
06 Ralph Droms
[Ballot comment]
As long as there is an example of version number (Service Pack)
encoded as a 16-bit integer, why not define the VersionNum Field …
[Ballot comment]
As long as there is an example of version number (Service Pack)
encoded as a 16-bit integer, why not define the VersionNum Field Type
as a pair of 16 bit integers, for use as in all Attributes?

You might consider adding some text about the use of Field Types in
the definition of future Attributes to simplify implementation.

Page 35:  The IANA 
        already maintains a registry of these values.

explicit pointers to those registries?

page 35: The IANA maintains 
        registries for TCP and UDP port numbers.

How is the IANA registry for TCP and UDP port numbers relevant?
2009-07-14
06 Ralph Droms
[Ballot discuss]
+1 for Alexey's comments on the quality and readability of this
document.

Expanding on Alexey's comments about the definition of the TimeString
Field …
[Ballot discuss]
+1 for Alexey's comments on the quality and readability of this
document.

Expanding on Alexey's comments about the definition of the TimeString
Field Type, it seems the Field Types defined in section 3.6 are not
used throughout the rest of the document.  In the example Alexey
mentioned, I would have expected that the TimeString Field Type have
the expanded definition suggested by Alexey, with a simple reference
to that Field Type in the definition of the Last Use field of the
Operational Status Attribute.

In my opinion, there are several other Attribute fields that could be
defined in terms of Field Types. 

In the case of the Numeric Version Attribute Type, I would expect the
Major/Minor Version Number and Service Pack Major/Minor fields to be
encoded as a VersionNum Field Type. 

What is the "PA-PB header"?  There are only a couple of references, in
sections 3.1 and 3.3.

Glancing at draft-ietf-nea-pb-tnc-04 (which I haven't read in detail,
yet), there is a PB-PA header; it would clarify
draft-ietf-nea-pa-tnc-04 to include a reference to the definition of
the PB-PA header (if I've got the association right).

The definition of the Posture Collector Identifier is unclear.  From
the definition in draft-ietf-nea-pb-tnc-04 - here, too, a reference to
section 4.5 of draft-ietf-nea-pb-tnc-04 would help - I understand the
Posture Collector Identifier to be associated with a specific Posture
Collector.  But, this text from section 3.3 of  gives a somewhat
different understanding:

    For example, a single Posture Collector might report attributes 
    on two installed VPN implementations on the endpoint.  Because 
    the individual attributes do not include an indication of which 
    VPN product they are describing, the recipient needs something 
    to perform this correlation.  Therefore, for this example, the 
    VPN Posture Collector would need to obtain two Posture Collector 
    Identifiers from the Posture Broker Client and consistently use 
    one with each of the implementations during an assessment.

Also, section 4.5 of draft-ietf-nea-pb-tnc-04 defines the Posture
Collector Identifier as being assigned by the Posture Broker Client
without intervention on the part of the Posture Collector,
while the text quoted above indicates that the Posture Collector
obtains Posture Collector Identifiers from the Posture Broker Client
and then supplies the Posture Collector Identifier with the associated
attributes to the Posture Broker Client.

Section 3.1, para 3: Each Posture Collector or Posture Validator 
    may send several PA-TNC messages in succession before indicating 
    that it has completed its response to the Posture Broker Client 
    or Posture Broker Server respectively.  As necessary, the 
    Posture Broker Client and Posture Broker Server will batch these 
    messages prior to sending them over the network.

"its response" seems overly restrictive.  What about transactions
initiated by the Posture Collector or Posture Validator?
s/response/batch of messages/ ?

Section 3.1:  However, this publish/subscribe model has some possible negative 
    side effects.  When a Posture Collector or Posture Validator 
    initially sends a PA-TNC message, it does not know whether it 
    will receive many, one, or no PA-TNC messages from the other 
    side.  For many types of assessments, this is acceptable, but in 
    some cases a more direct channel binding between a particular 
    Posture Collector and Posture Validator pair is necessary.  For 
    example, a Posture Validator may wish to provide remediation 
    instructions to a particular Posture Collector that it knows is 
    capable of remediating a non-compliant component.  This can be 
    accomplished using the exclusive delivery PB-TNC capability to 
    limit distribution of a message to a single Posture Collector by 
    including the target Posture Collector Identifier in the PA-PB 
    header.

(This question may be more appropriate in a review of
draft-ietf-nea-pb-tnc.)  Suppose the Posture Validator field is set
but the EXCL is not set in a message sent from a Posture Collector
through a Posture Broker Client.  Does the Posture Broker Server
deliver the message to all Posture Validators registered for the
message sub-type or just the Posture Validator identified in the
Posture Validator field?

Section 3.2:      The PA Subtype identifies the message type more specifically 
    within the set of message types defined by that vendor.  This 
    specification defines several IETF Standard PA Subtypes to be 
    used with a PA Message Vendor ID of zero (0).  Within this 
    specification, the PA Subtype field is used to indicate the type 
    of component (e.g. firewall) involved with the message's 
    attributes.

Vendors may define other message types that are not components?

Section 4.1:
    PA-TNC Attribute Length 

        [...]

        Implementations that do not support the specified PA-TNC 
        Attribute Type can use this length to skip over this 
        attribute to the next attribute.  Note that while this field 
        is 4 octets the maximum usable attribute length is likely to 
        be less than 2^32-1 due to limitations of the underlying 
        protocol stack specifically PB-TNC's length field includes 32 
        bytes of other headers which reduce the maximum size 
        available to PA-TNC since they both use 4 octet length 
        fields. 

I can't parse last sentence in this paragraph.
2009-07-14
06 Ralph Droms [Ballot Position Update] New position, Discuss, has been recorded by Ralph Droms
2009-07-13
06 Russ Housley
[Ballot discuss]
The informal coordination process is described in the following text:

    Starting in 2004, the Trusted Computing Group (TCG) has defined 
  …
[Ballot discuss]
The informal coordination process is described in the following text:

    Starting in 2004, the Trusted Computing Group (TCG) has defined 
    and published the Trusted Network Connect (TNC) architecture and 
    standards for network access control.  These standards enable 
    multi-vendor interoperability throughout the TNC architecture 
    and have been widely adopted and deployed.  In order to avoid 
    the development of multiple incompatible standards in this area, 
    the TCG offered several of its TNC standards to the IETF as 
    candidates for standardization in the IETF also.  This document 
    is one of those standards, known in the IETF as PA-TNC and in 
    the TCG as IF-M 1.0.  PA-TNC and IF-M 1.0 are equivalent. 

    Consistent with IETF's requirements for standards track 
    documents, the TCG has authorized the editors of this document 
    to offer the specification to the IETF without restriction.  As 
    with other Internet-Drafts, the IETF Trust owns the copyright to 
    this document.  The IETF may modify this document, ignore it, 
    publish it as an RFC, or take any other action.  If the IETF 
    decides to adopt a version of this document as an RFC, the TCG 
    plans to publish a specification for an equivalent TNC protocol 
    to ensure continued compatibility. 

  The IETF has no agreement or liaison relationship with TCG.  Change
  control for the protocol rests with the IETF.  This discussion of
  Internet-Drafts should not be included in the final document.

  I suggest rewriting these paragraph to make is clear what really
  happened in the NEA WG ad that the IETF has authority over changes.
2009-07-13
06 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2009-07-12
06 Alexey Melnikov
[Ballot comment]
Some comments. I would appreciate a response.

1). In Section 3.6:

      TimeString  An RFC 3339 [4] compliant ASCII string expressed  …
[Ballot comment]
Some comments. I would appreciate a response.

1). In Section 3.6:

      TimeString  An RFC 3339 [4] compliant ASCII string expressed 
                  in Coordinated Universal Time (UTC) time.

Definition in section 4.2.5 is more precise, in particular it says that fractional seconds are not used, that 't' and 'z' are capitalized.
I suggest you copy text from section 4.2.5 here.

2). In Section 4.2.1:

    All Posture Collectors that implement any of the IETF Standard 
    PA Subtypes defined in this specification SHOULD support 

Why this is just a SHOULD?

    receiving and processing this attribute type for at least those 
    PA subtypes.  Posture Collectors that receive and process this 
    attribute MAY choose to send all, a subset or none of the 
    requested attributes but MUST NOT send attributes that were not 

This MUST NOT is quite pointless, considering the first SHOULD.
How does the sender know if the other end complies with the SHOULD?

    requested (except error attributes).

3). In Section 4.2.4:

    Config. Len 

        This field defines the number of octets in the Configuration 
        Version Number field.  If the product version number is 
        unavailable or unknown, this field MUST be set to 0 and the 
        Product Version Number field will be zero length (effectively 
        not present). 

I think you meant "configuration version" everywhere in this paragraph.

4). In Section 4.2.5:

        Leap seconds are permitted and Posture Validators MUST 
        support them. The last use string MUST NOT be NUL terminated 
        or padded in any way.  If the last use time is not known, not 
        applicable, or cannot be represented in this format, the 
        Posture Collector MUST set this field to the value "0000-00-
        00T00:00:00Z" (allowing this field to be fixed length). Not 

Typo: Note

        that this particular reserved value is NOT a valid RFC 3339 
        date and time and MUST NOT be used for any other purpose in 
        this field. 

5). In Section 4.2.6:

    Protocol 

        This field contains the protocol number being blocked or 
        allowed. The values used in this field are the same ones used 
        in the IPv4 Protocol and IPv6 Next Header fields.  The IANA 
        already maintains a registry of these values.

I think you need to add the name of the registry here.

    Port Number 

        This field contains the port number being blocked or allowed. 
        The values used in this field are specific to the protocol 
        identified by the Protocol field.  The IANA maintains 
        registries for TCP and UDP port numbers. 

In both paragraphs: clarify that you are talking about *transport* protocols.

6). In Section 4.2.10.1:

        The Remediation Parameters field in the Remediation 
        Instructions attribute MUST contain a URI, as described in 
        RFC 3986 [9].  This URI SHOULD contain instructions to update 
        a particular component so that it might result in the 
        component being compliant with the policies in future 
        assessments. 

I think the Security consideration should specifically talk about the danger of automatic downloading and execution of content specified by such URIs.

7). In Section 5:

    This section discusses the major types of potential security 
    threats relevant to the PA-TNC message protocol and summarizes 
    the expected security protections that should be offered by PA-
    TNC security protocols.  PA-TNC security protocols are described 
    in separate specifications which layer upon the base PA-TNC 
    protocol described in this specification.

I think an informative reference to [8] would be useful here.

8). Who is going to be the Designated Expert for the registries created by the document?
2009-07-12
06 Alexey Melnikov
[Ballot discuss]
This is a well written document, it was a pleasure to read (despite the length). However I have some blocking comments, which are …
[Ballot discuss]
This is a well written document, it was a pleasure to read (despite the length). However I have some blocking comments, which are relatively minor. I would be happy for them to be resolved using RFC Editor notes:

1). IANA has raised some issues and I agree with the majority of them.
In particular:

The following attribute types are missing from the registry in section 7.3:

    4.2.9. Assessment Result...................................45 
    4.2.10. Remediation Instructions...........................46 
    4.2.11. Forwarding Enabled.................................49 
    4.2.12. Factory Default Password Enabled...................50 

2). In Section 4.2.10.1:

    Remediation-String 

        The Remediation Parameters field in the Remediation 
        Instructions attribute MUST contain a UTF-8 encoded string. 
        This string should contain human-readable instructions for 
        remediation that MAY be displayed to the user by the Posture 
        Collector.  The Remediation String SHOULD be localized in the 
        user's preferred language when known and supported by the NEA 
        Server. 

BCP 18 (RFC 2277), section 4.2 says:

  Protocols that transfer text MUST provide for carrying information
  about the language of that text.

[...]

  Note that this does NOT mean that such information must always be
  present; the requirement is that if the sender of information wishes
  to send information about the language of a text, the protocol
  provides a well-defined way to carry this information.

So the document would need to have a normative reference to RFC 4646 and some text about use of language tags. I can advise separately on how to address this issue.

3).
    [9]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 
          Resource Identifier (URI): Generic Syntax", RFC 3986
          January 2005. 

I think this reference is Normative.

4). In Section 4.2.5:

    Last Use 

        This field contains the date and time of the last use of the 
        component.  The Last Use date and time MUST be represented as 
        an RFC 3339 [4] compliant ASCII string in Coordinated 
        Universal Time (UTC) time with the additional restrictions 
        that the 't' delimiter and the 'z' suffix MUST be capitalized 
        and fractional seconds (time-secfrac) MUST NOT be included.

I need to think more about this, but I think you need to specify which ABNF production from RFC 3339 you mean here. It looks like RFC 3339 allows for many fields to be optional.
[Note this issue might just go away, I will update the description before next Thursday.]
2009-07-12
06 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2009-07-09
06 Tim Polk State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Tim Polk
2009-07-09
06 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2009-07-09
06 Tim Polk Ballot has been issued by Tim Polk
2009-07-09
06 Tim Polk Created "Approve" ballot
2009-07-07
06 Tim Polk Placed on agenda for telechat - 2009-07-16 by Tim Polk
2009-06-23
06 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-06-22
06 Michelle Cotton
Correction to IANA Last Call comments:

*************************
Section 7.1 says: "The vendor MUST supply a copy to the IANA and
authorize the IANA to archive …
Correction to IANA Last Call comments:

*************************
Section 7.1 says: "The vendor MUST supply a copy to the IANA and
authorize the IANA to archive this copy and make it freely available to
all if at some point the document becomes no longer freely available to
all through other channels."
*************************

IANA can archive the document.  We do this for another existing registry.
2009-06-22
06 Michelle Cotton
IANA Last Call comments:

Upon approval of this document, the IANA will create the following
registry "PA-TNC" located at http://www.iana.org/assignments/TBD. The
registry will initially …
IANA Last Call comments:

Upon approval of this document, the IANA will create the following
registry "PA-TNC" located at http://www.iana.org/assignments/TBD. The
registry will initially contains 4 subregistries as shown below.
Subregistries are separated by "==========="

IANA have questions to the authors below. The questions are between
"*********" at the end.


==================
==================
PA-TNC Registry
Contains the following sub-registries:
PA Subtypes
PA-TNC Attribute Types
PA-TNC Error Codes
PA-TNC Remediation Parameters Types

==================
PA Subtypes
Registration Procedures:
Expert Review with Specification Required

Field lengths:
PEN field is 24 bits, type unsigned integer
Number field is 32 bits, type unsigned integer
Name field is unlimited, type string.

PEN Number Name Refererence
--- ------ ---- ----------------------
0 0 Testing RFC-nea-pa-tnc-04
0 1 Operating System RFC-nea-pa-tnc-04
0 2 Anti-Virus RFC-nea-pa-tnc-04
0 3 Anti-Spyware RFC-nea-pa-tnc-04
0 4 Anti-Malware RFC-nea-pa-tnc-04
0 5 Firewall RFC-nea-pa-tnc-04
0 6 IDPS RFC-nea-pa-tnc-04
0 7 VPN RFC-nea-pa-tnc-04
0 8 NEA Client RFC-nea-pa-tnc-04

==================
PA-TNC Attribute Types
Registration Procedures:
Expert Review with Specification Required

Field lengths:
PEN field is 24 bits; unsigned integer
Value field is 32 bits; unsigned integer
Name field is unlimited; string.

PEN Value Name Reference
--- ----- ---- ----------------------
0 0 Testing RFC-nea-pa-tnc-04
0 1 Attribute Request RFC-nea-pa-tnc-04
0 2 Product Information RFC-nea-pa-tnc-04
0 3 Numeric Version RFC-nea-pa-tnc-04
0 4 String Version RFC-nea-pa-tnc-04
0 5 Operational Status RFC-nea-pa-tnc-04
0 6 Port Filter RFC-nea-pa-tnc-04
0 7 Installed Packages RFC-nea-pa-tnc-04
0 8 PA-TNC Error RFC-nea-pa-tnc-04

*************************
Section 4.2 have the following additional values for PA-TNC Attribute
Types which are not listed in section 7.3. Should IANA also register
those values?
0 9 Assessment Result RFC-nea-pa-tnc-04
0 10 Remediation Instructions RFC-nea-pa-tnc-04
0 11 Forwarding Enabled RFC-nea-pa-tnc-04
0 12 Factory Default Password RFC-nea-pa-tnc-04
*************************


*************************
Section 4.1 reserves the 0xffffffff value for PA-TNC Attribute Types
which is not listed in section 7.3. Should IANA also register this value?
0 0xffffffff Reserved RFC-nea-pa-tnc-04
*************************

==================
PA-TNC Error Codes

Registration Procedures:
Expert Review with Specification Required

Field lengths:
PEN field is 24 bits; unsigned integer
Value field is 32 bits; unsigned integer
Name field is unlimited; string.

PEN Value Name Reference
--- ----- ---- ----------------------
0 1 Invalid Parameter RFC-nea-pa-tnc-04
0 2 Version Not Supported RFC-nea-pa-tnc-04
0 3 Attribute Type Not Supported RFC-nea-pa-tnc-04

*************************
Section 4.2.8 also defines the 0 value for PA-TNC Error Codes, which is
not listed in section 7.4. Should IANA register this value?
0 0 Reserved RFC-nea-pa-tnc-04
*************************


==================
PA-TNC Remediation Parameters Types

Registration Procedures:
Expert Review with Specification Required

Field lengths:
PEN field is 24 bits; unsigned integer
Value field is 32 bits; unsigned integer
Name field is unlimited; string.

PEN Value Name Reference
--- ----- ---- ----------------------
0 1 URI RFC-nea-pa-tnc-04
0 2 Remediation String RFC-nea-pa-tnc-04


==================
==================
ADDITIONAL IANA QUESTIONS or CONFIRMATIONS

*************************
Section 7.1 says: "The vendor MUST supply a copy to the IANA and
authorize the IANA to archive this copy and make it freely available to
all if at some point the document becomes no longer freely available to
all through other channels." . IANA currently have no such archive
mechanism
for documents.
*************************

*************************
Section 4.2.10 and 7.5 define the Remediation Parameters Types
subregistry. The 0 value is not registered. As with other subregistries
in this specification, should IANA reserve it?
*************************

*************************
Section 4.2.5 defines specific values for the Status and Result fields
in tables. However, there is no request for IANA action. Therefore, IANA
will not create registries for these values.
*************************

*************************
Section 4.2.9 defines specific values for the Assessment Result field in
a table. However, there is no request for IANA action. Therefore, IANA
will not create registries for these values.
*************************

*************************
Section 4.2.11 defines specific values for the Forwarding Enabled field
in a table. However, there is no request for IANA action. Therefore,
IANA will not create registries for these values.
*************************

*************************
Section 4.2.12 defines specific values for the Factory Default Password
Enabled field in a table. However, there is no request for IANA action.
Therefore, IANA will not create registries for these values.
*************************
2009-06-16
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2009-06-16
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2009-06-09
06 Amy Vezza Last call sent
2009-06-09
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-06-09
06 Tim Polk State Changes to Last Call Requested from Publication Requested by Tim Polk
2009-06-09
06 Tim Polk Last Call was requested by Tim Polk
2009-06-09
06 (System) Ballot writeup text was added
2009-06-09
06 (System) Last call text was added
2009-06-09
06 (System) Ballot approval text was added
2009-05-12
06 Tim Polk
Susan Thomson (NEA co-chair) is the document shepherd.

Doc shepherd write-up for: draft-ietf-nea-pa-tnc-04.txt


(1.a) Who is the Document Shepherd for this document? Has the
  …
Susan Thomson (NEA co-chair) is the document shepherd.

Doc shepherd write-up for: draft-ietf-nea-pa-tnc-04.txt


(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

Susan Thomson (sethomso@cisco.com) is document shepherd.
I have reviewed this document and believe this version is ready for
forwarding to the IESG.

(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

The document has had adequate review.

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
      issues 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. Has an IPR disclosure related to this document
      been filed? If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

No concerns or IPR disclosures related to this document. Please see WG
Summary below for additional information.


(1.e) 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?

WG consensus is solid for this document. Please see WG Summary below
for additional information.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/). Boilerplate checks are
      not enough; this check needs to be thorough. Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
      informative? 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
      strategy for their completion? Are there normative references
      that are downward references, as described in [RFC3967]? If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

The document has split its references into normative and
informative. There are no downward references or references to
documents that are in an unclear state.

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document? If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries? Are the IANA registries clearly identified? If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations? Does it suggest a
      reasonable name for the new registry? See [RFC5226]. If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

Yes.

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

No formal language is used.

(1.k) 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 the PA-TNC protocol. PA-TNC is a Posture
Attribute protocol that carries posture attributes between a
Posture Collector on a NEA client and a Posture Validator on a NEA
server. The PA-TNC protocol is designed to run over the PB-TNC
protocol. PA-TNC is equivalent to the Trusted Computing
Group's IF-M 1.0 protocol. It addresses the PA protocol requirements
defined in the NEA requirements specification.

Working Group Summary

The WG solicited proposals for the PA protocol based on the
NEA reference model and requirements specified in RFC 5209. The TCG
submitted a specification to the NEA WG in response to the call for
proposals. There was broad support in the WG to adopt the submission as
a WG document. Subsequent WG updates to the document have not been
contentious.

The protocol document specifies a base protocol and is extensible.
The WG has discussed the potential for certain optimizations and
extensions to the above specifications (e.g. additional standard
posture attributes). The proposed extensions did not share the same
level of consensus as the base document and represented significant
additional work. The WG decided to defer potential extensions to
supplemental documents in the interests of making progress on the base
documents.

Document Quality 

Several vendors have indicated their intention in public or private to
implement the specification.

Personnel

Susan Thomson is the document shepherd. Tim Polk is the responsible
Area Director.
2009-05-12
06 Tim Polk Draft Added by Tim Polk in state Publication Requested
2009-04-17
04 (System) New version available: draft-ietf-nea-pa-tnc-04.txt
2009-03-06
03 (System) New version available: draft-ietf-nea-pa-tnc-03.txt
2008-10-09
02 (System) New version available: draft-ietf-nea-pa-tnc-02.txt
2008-07-15
01 (System) New version available: draft-ietf-nea-pa-tnc-01.txt
2008-04-11
00 (System) New version available: draft-ietf-nea-pa-tnc-00.txt