IPP> Notifications Over SNMP Traps

IPP> Notifications Over SNMP Traps

IPP> Notifications Over SNMP Traps

McDonald, Ira imcdonald at sharplabs.com
Tue Dec 14 19:38:33 EST 1999


Hi Ron,

Okay, I'll watch for your mail later this week.  I won't
see mail after Thursday until the following Monday, so 
don't wait on me for wording if I'm the holdup.

I subscribed to the IETF SNMPv3 WG mailing list earlier
today, so that I could watch the traffic.

Cheers,
- Ira

-----Original Message-----
From: Ron Bergman [mailto:rbergma at hitachi-hkis.com]
Sent: Tuesday, December 14, 1999 4:50 PM
To: McDonald, Ira
Cc: ipp at pwg.org
Subject: Re: IPP> Notifications Over SNMP Traps


Ira,

Your proposed URL parameters would solve the problem
without add too much muck to the scheme.  At least for the
v1 trap case, which is most likely the most common, no
parameters are necessary.  I don't think that any ABNF is
necessary until a good review is completed.

I will bring this subject up in the IPP meeting and see if anyone
else has an input.  Then I will post our conclusion to the SNMP
mail list.  I will have you and the group review the text before
sending.

    Ron Bergman
    Hitachi Koki Imaging Solutions

"McDonald, Ira" wrote:

> 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



More information about the Ipp mailing list