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