If I follow Larry's message correctly, he is suggesting that "policy"
regarding the use of imaging devices be included in the Model effort. I
think that we can all agree that:
1. Some method of setting policy for service use (perhaps conditional
upon User identification, Authentication an authorization [IAA]) is
necessary
2. This is a administrative/management function (note that, by
established definition, administrators and managers are a class of Users, so
to the term Users should not be taken as being limited to potential job
originators
3. SNMP is not an appropriate mechanism
I think there may be less agreement (but a need to reach consensus one way
or the other) that:
1. Policy setting should be part of the current model that we are
defining
2. Policy setting for Cloud use of imaging services involves (perhaps
in addition 'standard' cloud IAA actions) administrative access to the Cloud
Imaging Server, and (perhaps in addition to Cloud based IAA actions
controlling access to a specific Cloud Imaging Server) the Cloud Imaging
Servers enforce policy
3. Management of the hardcopy device itself, including configuration,
should not be normally considered a Cloud based function; if there is a need
for defining remote device management via the cloud, this is a separate
project perhaps more appropriate for the WIMS WG rather than the Cloud
group.
Another thing that the Cloud WG should consider:
There is some suggestion (and Larry has started some work) on the Cloud
Imaging model. One observation is that one is liable to miss some important
aspects in going from the subset to the more general. Should be refocus our
activity in Cloud Imaging rather than limiting current efforts to Cloud
Printing?
Please post your thoughts!
Thanks,
Bill Wagner
From: larryupthegrove [mailto:larryupthegrove at comcast.net]
Sent: Thursday, February 07, 2013 5:24 PM
To: 'Randy Turner'; William Wagner; cloud at pwg.org
Subject: RE: [Cloud] new actors summary
The placement of all the administrative functions in the "user" role I
believe is only appropriate in a simple case of a single unit, or in a
single domain. In a cloud environment, it is not typical that the network
user ID's and passwords can be used to authenticate with external domains.
This gets even more complex with scanning to the cloud, where the device may
act as the client as well. I think it is easier with multiple actors to
show the flow or requirements, a statement can be added that a single person
can perform multiple actor roles. One of the issues that I would like to
avoid are the instances already occurring where an Enterprise bans the use
of cloud apps or services because there is not any way to set policies.
Cloud based control of imaging devices is currently becoming more of an
issue with service providers, as the current SNMP methods are probably not
the best choice. I can see a transition where the service states are used
to alert a service provider. There are enterprises that are willing to give
a service provider secure access to a device, but would prefer not to use
network applications or other vendor devices residing on the networks. I
have first-hand experience with this from moving print operations to a
cloud.
I'll wait for some additional comments or ideas.
Larry
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Randy Turner
Sent: Thursday, February 07, 2013 12:49 PM
To: cloud at pwg.org
Subject: Re: [Cloud] new actors summary
Not sure if the following statements are exactly relevant to this email
thread.but the thread touched on some things I've been thinking about.
It's a bit risky to define a complete "cloud" printing model without having
an over-arching "imaging" model first -- we might take liberties with the
printing model that are too "printing" specific and are not generic enough
to be applied to an imaging model -- so I like the idea of making sure that
a higher-order set of actors and model objects map with a generic imaging
cloud model.
I think the model document should "recognize" that there is authentication
and authorization (most likely) in any cloud design that is actually
implemented and deployed. However, we don't have to address specifics of
AAA in the near term. We would just include AAA components in the model
illustrations (the pictures) just to show that we know these would probably
exist. But that's it for now.
The IDS group may want to tackle these AAA model "abstractions" and put some
meat behind them about how this might work.
By the way, is there anyone still working on a XACML proposal for imaging
services ? I think someone was looking into this last year.
I agree with Bill that we shouldn't be talking about device management,
except for the transient "setup and configuration" that is implied by any
job ticket information that requires a particular (temporary) setup of the
rendering device.
R.
On Feb 7, 2013, at 12:29 PM, William A Wagner wrote:
Larry,
I was presenting an argument, not necessarily specifying a solution. I would
like to have your thinking on why these actors/actions are needed in the
model. And I still have the question on whether conditional accesses
(service functions accessible depending on time, quantity etc) can
reasonably be fully handled by the cloud environment outside for the PWG
model. Perhaps user authorization not only limits client access to
appropriate Cloud Print Servers, but allows access with some conditional
restriction code that is enforced in the client (or in the Cloud Print
Server?)
I agree that we want the print model to phase well into the general model,
but I also would like to understand in what way these actions would apply
more to a scan service (or any other imaging service) than to a print
service. With respect to administrative/device controls, I think device
controls (that is, changing end device configuration) are completely out of
scope (unless we want to define a model for Cloud based management of a
imaging device.) What constitute Administrative controls is squishy, but I
think we need to decide whether administering any of the model components,
or providing administrative data from any of the components, is reasonably
an objective of the printing, scanning, etc model. Again, I pose this as a
question, not a conclusion.
Thoughts from the list please!
Thanks,
Bill W.
From: larryupthegrove [mailto:larryupthegrove at comcast.net]
Sent: Thursday, February 07, 2013 11:53 AM
To: 'William A Wagner'; cloud at pwg.org
Subject: RE: [Cloud] new actors summary
Bill,
I appreciate your comments. I am trying to think longer term, to include
scan operations and administrative/device controls.
My concerns about not identifying these tasks and/or owners deals with the
acceptance of this standard in the marketplace. In the legacy network
environments, imaging tasks are mostly controlled by the operating system
vendor and the printer manufacturer. The OS vendor may publish a
compatibility document, indicating approval.
I am ok with adding these type requirements back into the functional
requirements, and adding the exclusions into the design requirements. I
think the sale of these cloud imaging solutions may not be enhanced by the
fact that only a part of solution is covered by the standards.
Larry
From: William A Wagner [mailto:wamwagner at comcast.net]
Sent: Wednesday, February 06, 2013 3:32 PM
To: 'larryupthegrove'; cloud at pwg.org
Subject: RE: [Cloud] new actors summary
Many thanks for these suggestions and the discussion. I think, considering
Glen's argument, that it might be better to start with considering what
actors are responsible for these actions rather than defining new actors.
For example:
User access to device and features: Joe suggests that we have already
considered this as out of scope for the print model, with questions of user
identification and authorization implemented by other aspects of the Cloud
Environment. Presumably, by the PWG Cloud Imaging model, the client
connection with the Cloud Service establishes what Cloud Print Servers the
user can access, and what end services he can use. Therefore, although it
may be any one of several actors that is responsible for defining access
rights, none of the components of the PWG Model should be defined as
responsible for enforcing them; rather it becomes part of the Cloud
Environment requirements (functional requirements) and must be clearly
stated in those requirements. If this is agreed to, the question to be
considered here is conditional access rights.access limited to certain
functions, quantities, or times.
I would say that authorization or selection of:
cloud services or connections
Administrator access to device, logs, and other user controls
Accounting functions
Are probably appropriate actions for the administrator of the Print
Manager.or maybe someone else. But I don't think that these are part of the
Cloud Printing model. These too are part of the environment and should be
included in Functional requirements but I don't think that we need to define
the actor.
For the Cloud Service administrator, again I suggest that these
configuration operation are all out of scope for the model, although they
should be identified in the Function requirements section. And as such, it
is not necessary to identify a Cloud Service Administrator actor .
Having indicated that I do not think that these actors need be identified, I
would ask Larry if he added them since he needed them for the sequence
diagrams or other parts of section 4.
Thanks,
Bill W.
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
larryupthegrove
Sent: Wednesday, February 06, 2013 12:46 PM
To: cloud at pwg.org
Subject: [Cloud] new actors summary
ftp://ftp.pwg.org/pub/pwg/cloud/white/New Actors.pdf
ftp://ftp.pwg.org/pub/pwg/cloud/white/New Actors.docx
New Actors
Device Owner - the person(s) or entity responsible for the authorization or
selection of:
1. Any cloud services or connections (apply to IPP)
2. User access to device and features
3. Administrator access to device, logs, and other user controls
4. Accounting functions
Cloud Service Administrator - on behalf of the Device Owner, performs
operations to:
1. Configures device access controls for use by Cloud Service -
should be with
2. Configures device for Cloud Print Service access
3. Can start, stop , or modify all queues at the cloud service
4. Can retrieve any logs from the cloud service
5. Accounting configurations
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean. _______________________________________________
cloud mailing list
cloud at pwg.orghttps://www.pwg.org/mailman/listinfo/cloud
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, 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/cloud/attachments/20130208/7bfabc46/attachment-0002.html>