Chris, thank you for the thorough report on RFC1759 status. Your efforts in
helping us get to Draft Standard are greatly appreciated. I would like to
comment on your approach to traps, however, and recommend an alternative which
I hope more directly addresses the problem:
>(1) Explain that traps are "implementation dependent", that in the absence
>of any standard way to do this in SNMP, each vendor did his own unique
>implementation. When trap mechanisms are standardized by the IETF for all
>MIBs, then the Printer MIB group will modify their implementations to be
>consistent.
Your point, here, is that traps are implementation dependent. This is
NOT TRUE and we desire to demonstrate exactly the opposite! SNMP, itself,
is deficient in terms of TRAP REGISTRATION, thus forcing implementation
dependent REGISTRATION, but RFC1759 defines STANDARD printer alerts and
attempts to define STANDARD printer trap PDU formats.
It is unfortunate that, due to the fixed definition of the v1 Trap PDU,
the Printer MIB is forced to use generic-trap = enterpriseSpecific(6)
(as opposed to generic-trap = printerAlert, for instance). This probably
results in some confusion, making RFC1759 traps appear "vendor specific".
They SHOULD NOT BE!
>(2) The RMON2 MIB included a trap mechanism and definition in their
>RFC2021. See http://ds.internic.net/rfc/rfc2021.txt There is a section
>called "Trap Destination Table" on pages 98-101. They have defined:
>
> trapDestIndex
> trapDestCommunity
> trapDestProtocol
> trapDestAddress
> trapDestOwner
> trapDestStatus
The portion of the RMON MIB which you reference relates to the way RMON has
tried to pin down registration as a trap recipient. The fact that SNMP does not
yet define a standard trap destination table is just SNMP business as usual and
should have no bearing on the status or progression of RFC1759! Therefore, I do
not believe option (2) buys us anything.
I think what we need to determine either via interop testing or by
comparing implementations are things like... given the RFC1759 trap
PDU definition... what exactly should the agent put in the following
fields:
1. ENTERPRISE
RFC1157 says "the type of object generating the trap - see
sysObjectID".
RFC1759 says "printerV1Alert" which is defined as "The value
of the enterprise-specific oid in an SNMPv1 trap..."
So... what goes here? sysObjectID, printerV1Alert? What have
all the implementations put here?
2. SPECIFIC-TRAP
RFC1157 says "specific code, present even if generic-trap is
not enterpriseSpecific" Pardon me for not sensing a great deal
of concrete direction here... does this mean the RFC1759 defined
AlertCode?
Again, what are the existing implementations?
3. VARIABLE-BINDINGS
RFC1157 says "interesting information". RFC1759 defines this
information. Is everyone sending Varbinds. Are they mandatory?
Do we all send the same stuff?
In summary, I don't think the trap host registration issue is where we
should be focusing when we talk about moving RFC1759 to draft standard and I
would like to see this topic removed from discussion. As you have pointed out
and Randy noted in Austin... Bob Stewart is addressing this for the future with
several drafts. I think, more important, do we have enough definition in the
RFC to guide implementations toward a standard and what have the existing
implementations done?
Harry Lewis - IBM Printing Systems