PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)
draft-ietf-nea-pa-tnc-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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-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 |