Understood and agreed. Many thanks.
Bill Wagner
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Friday, January 07, 2005 1:03 PM
To: Wagner,William; McDonald, Ira; wims at pwg.org
Subject: RE: WIMS> Definitions for all WIMS Objects
Hi Bill,
PLEASE do not move these definitions of the object types into
terminology (before the model). These definitions will also
(presumably) eventually make reference to their Normative XML
schema definitions (as we agreed).
If you want to prune the definitions (of their references
and each second sentence that says how these objects are
transferred or accessed) and include them earlier in the
terminology, that seems fine.
On reflection, the only Normative reference in these objects
is 'Subunit' which says "imports the definition and semantics"
(not merely "extension and generalization of"). All the others
are Informative references. OK?
(It's important that 'Subunit' says "imports", because we
are folding the Printer MIB device model elements into the
PWG Semantic Model here.)
We already have a fine definition of 'WIMS Proxy' in the
terminology section. Let's leave it there. All of the new
ones are first-class objects in the formal sense of the PWG
Semantic Model.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Thursday, January 06, 2005 8:31 PM
To: McDonald, Ira; wims at pwg.org
Subject: RE: WIMS> Definitions for all WIMS Objects
Ira,
Many thanks for these additions. I was just working on the draft. We
already have (less rigorous) definitions for many of these terms under
Terminology. Because these are the components of the model being
defined, I understand why they may be in the Model section. But I think
readers would expect all definitions, including new terms, in one place.
Do you have a strong feeling about these being in section 4 rather than
under terminology? Some of these terms are used in Chapter 3.
And, granted that a formal definition of WIMS Proxy is not needed for
the model, I do think a working definition of the term should be
included someplace.
And I wonder a bit about the references being normative rather than
informative, since we define the terms as we are using them in this
document and do not rely upon the references for definition.
Bill Wagner
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Thursday, January 06, 2005 7:00 PM
To: 'wims at pwg.org'
Subject: WIMS> Definitions for all WIMS Objects
Hi Bill, Thursday (6 January 2005)
Below is a new section 4.1 'WIMS Objects' for addition to the WIMS spec.
Every definition has normative source document references.
Please note that a WIMS 'Proxy' object is NOT defined. A WIMS Proxy is
simply a network host system with a WIMS Agent controlling a subordinate
WIMS Manager (for operation and action forwarding), as shown in the
current diagrams in section 4 of the WIMS spec.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
------------------------------------------------------------------------
4.1 WIMS Objects
WIMS adds the following objects to the PWG Semantic Model:
Agent: An abstract object that represents a software component of a
network host system that supports management of one or more Services
or Devices. An Agent object always supports the WIMS Agent Interface as
a request generator and may support the WIMS Management Interface as a
response generator.
Note: This document defines the Agent object as an extension and
generalization of the SNMP Agent defined in the IETF Architecture
for Describing SNMP Management Frameworks [RFC3411].
Alert: An abstract object that represents the set of information
associated with a normal event (e.g., ServiceConfigChanged) or exception
event (e.g., ServiceStopped) on a managed entity. An Alert may be
transferred to a Manager via a SendAlerts operation.
Note: This document defines the Alert object as an extension and
generalization of the Alert element defined in the IETF Printer MIB
[RFC1759] [RFC3805].
Device: An abstract object that represents a hardware component of a
network host system that supports one imaging function (e.g., copy) and
may be associated with one or more upstream Service objects. A Device
object exposes for monitoring and management every associated Subunit
(e.g., Marker) on that network host system.
Note: This document defines the Device object as an extension and
generalization of the Printer element defined in the IETF Printer
MIB [RFC1759] [RFC3805].
Manager: An abstract object that represents a software component of a
network host system that supports management of one or more managed
entities via their associated Agents. A Manager object always supports
the WIMS Agent Interface as a response generator and may support the
WIMS Management Interface as a request generator.
Note: This document defines the Manager object as an extension and
generalization of the SNMP Manager defined in the IETF Architecture
for Describing SNMP Management Frameworks [RFC3411].
Report: An abstract object that represents the set of information
associated with the performance of a scheduled or immediate action
(e.g., GetElements). A Report may be transferred to a Manager via a
SendReports operation.
Note: This document defines the Report object as an extension and
generalization of the Get-Printer-Attributes response defined in the
IETF Internet Printing Protocol (IPP) Model and Semantics [RFC2566]
[RFC2911].
Resource: An abstract object that represents a software component of a
network host system that is necessary for the operation of one or more
Services or Devices (e.g., fonts or firmware).
Note: This document defines the Resource object as an extension and
generalization of the Resource object defined in the ISO Document
Processing Application (DPA) [ISO10175].
Schedule: An abstract object that represents a set of planned actions
and their timetables on a network host system. A Schedule object may be
transferred to an Agent via a SetSchedule operation request (WIMS
Management Interface) or a GetSchedule or RegisterForManagement
operation response (WIMS Agent Interface).
Note: This document defines the Schedule object as an extension and
generalization of the Schedule element defined in the IETF Schedule
MIB [RFC3231].
Service: An abstract object that represents a software component of a
network host system that supports one or more imaging functions (e.g.,
copy, print, and scan) and may be associated with one or more downstream
Device objects. A Service object exposes for monitoring and management
every associated Subunit (e.g., Channel) on that network host system.
Note: This document defines the Service object as an extension and
generalization of the Printer object defined in the IETF Internet
Printing Protocol (IPP) Model and Semantics [RFC2566] [RFC2911].
Subscription: An abstract object that represents a set of events to be
monitored on a network host system and a recipient for notifications
associated with those events (delivered via WIMS Alerts, SNMP traps,
etc.). A Subscription may be transferred to an Agent via a
SubscribeForAlerts action in a Schedule.
Note: This document defines the Subscription object as an extension
and generalization of the SNMP Subscription defined in the IETF
SNMP Applications [RFC3413].
Subunit: An abstract object that represents a hardware or software
component of a network host system that is accessible for monitoring and
management but _cannot_ be rebooted independently of the owner System,
Service, or Device object.
Note: This document imports the definition and semantics of a
Subunit from the IETF Printer MIB [RFC1759] [RFC3805], including all
of the following standard Subunit types: Channel, Console, Cover,
InputTray, Interface, Interpreter, Marker, MediaPath, and OutputBin.
System: An abstract object that represents a network host system and
may support one or more configured Services or Devices on that network
host system. A System object exposes for monitoring and management
every configured Subunit (e.g., Console) on that network host system.
Note: This document defines the System object as an extension and
generalization of the System group in IETF MIB-II (RFC 1213) and the
System group in IETF Host Resources MIB [RFC1514] [RFC2790].