Hi Ron,
Good questions.
I suggest that we assume that the IPP Client (subscriber)
using IPP 'Create-[Printer|Job]-Subscription' must know the
capabilities of the SNMP Agent at the IPP Printer (generator).
[Another good use for a general purpose IPP method for reading
elements from any MIB, not just Printer MIB, so that the usual
hierarchical tests could be done to discover SNMP protocol
versions and capabilities supported by the SNMP Agent.]
Since our proposed 'snmp-notify:' URL scheme should be usable
in other (non-IPP) contexts, I would suggest defining several
(optional) URL parameters:
'version' - SNMP version to be used by notification generator
(default of [SNMP] 'v1' or 'v1c' for community)
'pdutype' - Either Trap or Inform
(default of 'trap' - unacknowledged)
'comname' - Community name for SNMPv1c or SNMPv2c
(default of 'public')
There are probably a few others. Should I try to write up
some ABNF that follows RFC 2396 (URI Generic Syntax)? Or
would it be better to first post the question informally
to the IETF SNMPv3 WG list?
[You know, this isn't really as simple as it seems at first
glance, I'm realizing...]
Cheers,
- Ira McDonald (outside consultant at Sharp)
High North Inc
-----Original Message-----
From: Ron Bergman [mailto:rbergma at hitachi-hkis.com]
Sent: Tuesday, December 14, 1999 8:14 AM
To: McDonald, Ira
Cc: ipp at pwg.org
Subject: Re: IPP> Notifications Over SNMP Traps
Ira,
Yes, snmp-notify is much better. I will send a message to the
SNMP mail list early next week, after the PWG meeting and
to see if there are any other concerns.
One new issue:
I am now not sure how the subscriber and SNMP agent can
determine if an inform can be used instead of a trap. The trap
must be the default, but to use an inform it appears that the
subscriber must register using the Notification MIB. If using
IPP to register, the subscriber needs to know the capabilities
of the agent. But how can he tell the agent that an inform is
desired rather than a trap?
A similar problem occurs with a V1 vs V2 trap.
One method would be to define three URLs; snmp-v1-trap,
snmp-v2-trap, and snmp-inform. This is certainly not as
nice as one URL.
Another solution would be an IPP attribute. Also messy.
Ron Bergman
Hitachi Koki Imaging Solutions
"McDonald, Ira" wrote:
> Hi Ron,
>> I agree with your reasoning. The URL type 'ipp-snmp:' was just
> a placeholder.
>> Note that SNMP notifications (in SNMPv2 and SNMPv3) may be delivered
> either by a Trap (unacknowledged) or an Inform-Request (which should
> be acknowledged by the receiver with an Inform-Response). The choice
> of Trap versus Inform is up to the subscriber. I suggest that a better
> scheme name might be 'snmp-notify:' (since ASN.1 definitions in MIBs
> use the 'NOTIFICATION-TYPE' macro).
>> Assuming there is no other objection to beginning the inquiry
> and registration process from another IPP WG member, would you
> please initiate the inquiry to the SNMP mailing list? I'll be
> happy to work with you, Ron, on phrasing the background for our
> request.
>> Cheers,
> - Ira McDonald (outside consultant at Sharp)
> High North Inc
> 360-834-8744 (work at Sharp w/ voice mail)
>> -----Original Message-----
> From: Ron Bergman [mailto:rbergma at hitachi-hkis.com]
> Sent: Monday, December 13, 1999 8:25 AM
> To: Ira McDonald; ipp at pwg.org> Subject: IPP> Notifications Over SNMP Traps
>> Ira,
>> In the October meeting I suggested that the URL for SNMP notifications
> be something more generic, such as "snmp-trap:". I do not see any reason
>> for this URL to be specific to IPP Notifications.
>> In checking the IANA registry, there are no 'snmp-?' URLs registered.
> We probably will have to request this registration. We also should
> first
> send a message to the SNMP mail list to see if there is another working
> group that has this request in process or if there are any objections.
>> I will start this process unless there is anyone in the IPP group that
> has
> a concern regarding the URL name or my recommended procedure.
>> Ron Bergman
> Hitachi Koki Imaging Solutions