Joe -
Below are the official Xerox comments to the PWG Last Call review of the HCD-NAP Spec (note that many of the comments relate to inconsistencies with the HCD-ATTR spec which may require changes in the HCD-ATTR spec to implement):
1. General Comment: This document uses a lot of acronyms but there is no List of Acronyms like there is in the HCD-ATTR spec. Such a list is definitely needed in the HCD-NAP spec. To help out generating the list, here are the acronyms I found (can't claim it is all of them) - PWG, HCD, PC, MAC, IP, NAP, SHA, SSoH, SoH, SoHR, SHV, DHCP, DNS, VLAN, ID, EAP, PEAP, RADIUS, PPP, IPsec, HCEP, HRA, PKCS, IDS, TCP, UDP, SCTP, SMI, IANA, TLV, WCCE, RNAP, WSH, TLS, CHAP and MS.
2. General Comment: I found several instances where there was no line between paragraphs. Be consistent - either include a line between paragraphs in all cases or do not do so.
3. Section 2, pg. 6, Line 240: The [IDS-ATTR] spec referenced here is not listed in Section 10.
4. Section 4.5.1, pg. 8, Line 334: section4.6. 4.3 -missing a space and not sure if you meant 4.6, 4.3 or 4.6.4.3 here.
5. Section 4.6.1, pg. 9, Line 352: The end of the sentence should read "....and gateway (0.0.0.0) settings."
6. Section 4.6.1, pg. 9, Line 353: [RFC3442] referenced here is not listed in Section 10.
7. This is more of a question than a comment. In Section 4.6.2, pg. 9, Line 369 the HCD-NAP spec provides a reference to a document that describes IEEE 802.1x. Since the HCD-ATTR spec also discusses 802.1x, shouldn't it also provide the same reference to a document that describes 802.1x?
8. Section 4.6.2, pg. 9, Line 376: The definition of PEAP in the text is incorrect; it should be Protected Extensible Authentication Protocol (Extensible was missing).
9. Section 4.7, pg. 10, Line 417: This line references Section 4.3 for discussion of NAP access protocols. Confirm that is the correct section to reference here because Section 4.3 talks about 'Protocol Transport'.
10. Section 4.7.4, pg. 11, Line 432: Grammatically, I think this sentence should read "...will be revoked and limit network access to a restricted network."
11. Section 5.1.1.2, pg. 12, Line 458: It is not clear what the 'HRESULT' value mentioned here refers to.
12. Section 5.1.1.4, pg. 12, Line 471: The description of the ForwardingEnabled attribute here ("...indicates whether the device is configured to forward data between interfaces") is inconsistent with the corresponding description of the ForwardingEnabled attribute ("...indicates whether any external-facing interface is being used as a bridge, route or proxy from any other external-facing interface including itself')) on pg. 13 of the HCD-ATTR spec. For example, the description in HCD-NAP doesn't address the aspect of the device interfacing with itself.
13. Section 5.1.1.4, pg. 13, Line 478: The HCD-ATTR spec and the HCD-ATTR spec are inconsistent on the size of the ForwardingEnabled attribute. The HCD-ATTR spec (see pg. 13) says that this attribute is a single-bit field but the HCD-NAP spec says that this attribute is represented in two bytes. Note that this exact same inconsistency between the HCD-NAP and HCD-ATTR specs applies to the following attributes: DefaultPasswordEnabled, PSTNFaxEnabled, UserApplicationEnabled and UserApplicationPersistenceEnabled.
14. Section 5.1.1.10, pg. 12, Line 471: The description of the VendorSMICode attribute here ("...indicates the name of the manufacturer of the HCD") is inconsistent with the corresponding description of the ForwardingEnabled attribute ("...contains a globally unique SMI Network Management Private Enterprise Code of the vendor...")) on pg. 14 of the HCD-ATTR spec.
15. Section 5.1.1.14, pg. 18, Line 606: The description of the FirmwarePatches ttribute here ("...all patches must be listed in the order in which they were applied, beginning with the first patch and ending with the last patch applied") is inconsistent with the corresponding description of the FirmwarePatches attribute ("...all patches must be listed in the order in which they were applied, beginning with the first patch and ending with the most current patch")) on pg. 13 of the HCD-ATTR spec. The issue is that the most current patch may not always be (nor does it have to be) the last patch applied. Note that this exact same inconsistency between the HCD-NAP and HCD-ATTR specs applies to the following attributes: UserApplicationPatches and ResidentApplicationPatches.
16. Section 5.1.1.15, pg. 18, Line 619: The description of the AttributesNaturalLanguage attribute here ("...indicates the local language used for the string attributes within this SOH") is inconsistent with the corresponding description of the AttributesNaturalLanguage attribute ("...indicates the local language used for all HCD string attribute values")) on pg. 14 of the HCD-ATTR spec.
17. Section 5.1.1.15, pg. 18, Line 619: The reference to 'rfc5646' should be '[RFC5646]'.
18. General Observation: The list of Mandatory, Conditionally Mandatory and Optional attributes in the HCD-NAP spec does not agree with the list of the list of Mandatory, Conditionally Mandatory and Optional attributes in Section 5 of the HCD-ATTR spec (e.g., UserApplicationEnabled is Conditionally Mandatory in the HCD-NAP spec but is Mandatory in the HCD-ATR spec).
19. Section 5.1.2.1, pg. 19, Line 637: The description of the UserApplicationEnabled attribute here ("...indicates whether the device is configured to allow execution of User Applications") is inconsistent with the corresponding description of the UserApplicationEnabled attribute ("...indicates whether the HCD supports (or currently has enabled) the ability to download or execute applications intended to dynamically downloaded by users and executed in the device")) on pg. 14 of the HCD-ATTR spec.
20. Section 5.1.2.2, pg. 19, Line 648: The description of the UserApplicationPersistenceEnabled attribute here ("...indicates whether the device is configured to allow User Applications to remain available in the system after use") is inconsistent with the corresponding description of the UserApplicationPersistenceEnabled attribute ("...indicates whether user-downloadable applications can persist outside the boundary of a single job")) on pg. 14 of the HCD-ATTR spec.
21. Section 5.1.2.3, pg. 20, Lines 661 and 670: To be consistent with what is in the HCD-ATTR spec for the UserApplicationName attribute I would suggest that the description on both these lines be changed to read "...identifies the name of a User Application that has been loaded..." Same comment applies to the ResidentApplicationName attribute in Section 5.1.2.7, pg. 22, Lines 722 & 732.
22. Section 5.1.2.8, pg. 23, Line 743: To be consistent with what is in the HCD-ATTR spec for the ResidentApplicationVersion attribute I would suggest that the description be changed to read "...uniquely identifies the current Resident Application version."
23. Section 5.1.3.1, pg. 25, Line 800: To be consistent with what is in the HCD-ATTR spec for the ConfigurationState attribute I would suggest that the description be changed to read "...uniquely identifies the state of any configuration settings that..."
24. Section 5.1.3.1, pg. 25, Line 808: The text here refers to "Imaging Device". Since this is the HCD-NAP spec, this reference should probably be to HCD instead. Same comment applies to Section 5.1.3.2, pg. 25, Line 820 and Section 6.4, pg. 26, Line 856.
25. Section 6.1, pg. 26, Line 831: The sentence was changed to refer to Section 5.1.1.6; I believe the reference here should be changed back to refer to Section 5.1.2.
26. Section 6.4, pg. 26, Line 856: This sentence refers to Section 4.6. Given the title of Section 4.6 the text should be changed to read "...at least one of the NAP Access protocols described in 4.6."
27. Section 6.5, pg. 27, Line 862: The following attributes are not mentioned as requiring revalidation either immediately or at the earliest opportunity - ResidentApplicationPatches, ForwardingEnabled, DefaultPasswordEnabled, MichanieTypeModel, PSTNFaxEnabled, UserApplicationEnabled, UserApplicationPersistenceEnabled, VendorName, VendorSMICode and AttributesNaturalLanguage. I just want to confirm whether these were left out deliberately or left out by mistake.
28. Section 7, pg. 27, Line 886: The title for the HCD-ATTR spec listed here is incorrect. It should be PWG Hardcopy Device Health Assessment Attributes.
29. Section 8, pg. 27, Line 890: The [ISO10646] document referenced here is not listed in Section 10.
30. Section 10.1, pg. 28, Line 906: The following documents listed as Normative References here are not referenced anywhere else in the spec - [IEEE2600], [RFC3748], [RFC4330] and [TLS-CIPHER].
I know there are a lot of comments; let me know if you have questions.
Alan
From: pwg-announce-bounces at pwg.org [mailto:pwg-announce-bounces at pwg.org] On Behalf Of Murdock, Joe
Sent: Monday, November 26, 2012 3:45 PM
To: pwg-announce at pwg.org
Subject: [Pwg-Announce] PWG Last call of HCD-NAP Binding
All,
[This PWG Last Call starts today Monday November 26, 2012 and ends Friday January 18, 2013 at 10pm US PST.]
This is the formal announcement of the PWG Last Call for the HCD-NAP Binding specification, located at:
ftp://ftp.pwg.org/pub/pwg/ids/wd/wd-ids-napsoh10-20121112.pdf
All required attributes and values defined in this document have been prototyped by a vendor. The IDS WG has completed extensive review of the various revisions of this document and an IDS WG last call.
The PWG Process/3.0 requires that a quorum (30%) of PWG voting members must acknowledge a PWG Last Call (with or without comments), before any document can progress to PWG Formal Vote. This PWG Last Call is NOT a Formal Vote but it DOES require your review acknowledgment.
HOW TO RESPOND
Send an email with *exactly* the following subject line format:
Subject: <Company Name> has reviewed the HCD-NAP specification and has [no] comments
WHERE TO SEND YOUR RESPONSE
Please send your response to *all* of the following email addresses (replacing "dot" with '.' and "at" with '@'):
"ids "at" pwg "dot" org (IDS WG mailing list - you must be subscribed!)
jmurdock "at" sharplabs "dot" com (Joe Murdock, IDS Chair and current HCD-NAP Binding Editor)
alan.sukert "at" xerox "dot" com (Alan Sukert, IDS WG Secretary)
Note that you must be subscribed to the IDS WG mailing list to send email there - otherwise your email will be silently discarded.
Please do NOT simply reply to this note on the PWG-Announce list.
Note: The PWG Definition of the Standards Development Process Version 3.0 is located at:
http://www.pwg.org/chair/membership_docs/pwg-process30.pdf
---------------------------------------
Joe Murdock
Principal Engineer and Researcher
Chair IEEE/ISTO Printer Working Group Imaging Device Security
Sharp Labs of America
5750 NW Pacific Rim Blvd
Camas, WA 98607
(360) 817-7542
jmurdock at sharplabs.com<mailto:jmurdock at sharplabs.com>
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/pwg-announce/attachments/20130109/ea88aeaf/attachment-0001.html>