Subject: RE: [Pwg-Announce] PWG Last call of HCD-NAP Binding

From: "Sukert, Alan" <[email-masked]>
Date: Wed, 9 Jan 2013 20:30:43 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Murdock, Joe
Sent: Monday, November 26, 2012 3:45 PM
To: [email-masked]
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
[email-masked]<mailto:[email-masked]>

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

_______________________________________________
pwg-announce mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/pwg-announce

---

From: "Sukert, Alan" <[email-masked]>
Date: Mon, 21 Jan 2013 20:25:46 +0000

The PWG Last call period for the HCD-NAP spec has been formally extended to Friday, Feb 1, 2013 at 10 pm US PST. If you have not reviewed this document yet and you are a PWG Voting member please review the spec so we can have the necessary quorum of members having reviewed the document.

Thanks.

Alan Sukert
Xerox Global Development Group Product Security Office
Xerox Certified Green Belt
[email-masked]|<mailto:[email-masked]%7C> tel 585.427.1413 or 8*707-1413
MS 0111-03A | 800 Phillips Road | Webster, NY 14580
"The right angle from which to approach a problem is a try-angle"

All,

HOW TO RESPOND

---

From: "Sukert, Alan" <[email-masked]>
Date: Mon, 28 Jan 2013 20:00:17 +0000

This note is just a reminder that the PWG Last Call period for the HCD-NAP spec has been formally extended to Friday, Feb 1, 2013 at 10 pm US PST. As of today we only have 5 responses and 8 are needed for a quorum to approve this spec.

Please respond by the deadline if you have not done so already.

Alan Sukert
Secretary, PWG IDS Working Group

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sukert, Alan
Sent: Monday, January 21, 2013 3:26 PM
To: Murdock, Joe; [email-masked]
Subject: RE: [Pwg-Announce] PWG Last call of HCD-NAP Binding

Thanks.

Alan Sukert

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Murdock, Joe
Sent: Monday, November 26, 2012 3:45 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Pwg-Announce] PWG Last call of HCD-NAP Binding

All,

HOW TO RESPOND

---

From: "Murdock, Joe" <[email-masked]>
Date: Thu, 31 Jan 2013 01:18:18 +0000

All,

We need two (2) more members to send in their notice that they have reviewed the HCD NAP specification, with or without comments, in order to advance this to PWG Formal Vote.
This Last Call has been extended until Feb 1, 2013, so there is still time to get your response in.

Thank you in advance for your review!

From: Sukert, Alan [mailto:[email-masked]]
Sent: Monday, January 21, 2013 12:26 PM
To: Murdock, Joe; [email-masked]
Subject: RE: [Pwg-Announce] PWG Last call of HCD-NAP Binding

Thanks.

Alan Sukert

All,

HOW TO RESPOND