[Nea] Request for guidance on PA-subtypes for Multi-function hardcopy devices
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nea] Request for guidance on PA-subtypes for Multi-function hardcopy devices



Hello NEA List,

The Printer Working Group is finalizing a set of attributes to be used exclusively with imaging devices, and these attributes will be rooted under the PWG's private enterprise SMI number.

The PWG has utilized the extensibility mechanism provided by the PA- TNC document to create SMI-specific attributes.

The specific question I had was regarding attribute request "routing".

Attribute requests within the NEA/TNC protocols are routed to logical components within a device based on PA-subtype.

Like the attribute extensibility feature, PA-subtypes seem to allow the same type of SMI-specific extensibility.

Currently, the PWG has NOT created any new PA-subtypes specific to imaging/hardcopy devices.

The absence of any new PWG-specific PA-subtypes implies the PWG would have to route PWG-specific attributes using existing "standard" NEA PA- subtypes. For example, one of:

Testing
Operating System
Anti-Virus
Anti-Spyware
Anti-Malware
Firewall
IDPS
VPN
NEA Client

Many imaging (especially high-end multifunction devices) have started using Linux as their OS platform. In these cases, it's possible that the proposed NEA standard PA-subtypes would be appropriate. Even when the OS platform is a traditional embedded operating system such as VxWorks, it's possible that these devices could use a subset of the same NEA proposed standard PA-subtypes.

Given all the "level-setting" information I have described above, I was curious about a very common product architectural scenario that is prevalent in the marketplace for high-end multi-function imaging devices that provide multiple "hardware" services to the network, typically:

1. Printing
2. Scanning
3. Faxing (both traditional analog fax, as well as fax over VoIP)
4. Copying (a logical service consisting of scanning+printing in digital copier/printers)

It is quite normal in this industry to have separate "computers" to provide each of these functions. By "computers", I mean a separate CPU and separate memory space (really a separate board). These separate computers have their own firmware/software version and patch information that might need to be assessed for security posture.

The Multifunction product only has one network interface over which it communicates. And in some cases (like HP's products), even this network device is one of the "separate computing devices" within the overall product, and has a separate firmware and operating system "version".

In the absence of PWG-specific PA-subtypes, I'm curious how a validator could request software version & patch information from each of these separate computing spaces? For example, if I have 3 separate "computers" in my multifunction product, and I want to retrieve the OS version of each separate OS running on each "computer", how would I target my requests?

I can think of ways to "overload attribute values" or "cheat" using the current model, but it seems to me like a PA-subtype of "Fax Subsystem" (as an example) might be a better way to really represent what I'm trying to do.

When I proposed creating new PA-subtypes like this to the PWG, they noticed that none of the existing NEA proposed PA-subtypes represent "hardware" subsystems, and that my proposal might violate some NEA design guideline. As an example, they posed the question "Why didn't the NEA (or TNC group) provide a PA-subtype for "BIOS", since this subsystem is versioned and remediated independently of the "Operating System", and is a standard component within desktop PCs? I didn't have an answer for this question since I'm not a TCG member and wasn't present when these subtypes were possibly discussed.

Comments or Suggestions as to how we might proceed are greatly appreciated! My own personal opinion at the moment is that we probably need PA-subtypes defined under the PWG SMI.

Thanks
Randy




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.