>>> Randy Turner <rturner@sharplabs.com> 04/26 11:33 PM >>>
>
>Let me attempt to clarify my position on this effort to provide another
>mechanism for accessing MIB data from IPP/SDP. Philosophically, I would
>like to see only SNMP used to access MIB data through OID mechanisms.
>Technically, I understand that we can also implement tunnels or "backdoors=
"
>in other protocols that attempt to "hack" into the MIB data stream and =
take
>advantage of the OID naming scopes that are used currently to expose
>existing MIB data.
SAI> I see SNMP being used to MANAGE the printer. I do not see using IPP
SAI> to MANAGE the printer. I see IPP as being a protocol that an end =
user
SAI> uses (or an application on behalf of an end user) to query the =
printer
SAI> for characteristics and capabilities that help in requesting options =
or
SAI> or formatting the job and then submitting the job and tracking and=20
SAI> simple management of that job (just query and cancel). As Harry L.
SAI> pointed out, I do not see MIB SETs in IPP, so I don't see a "hack"
SAI> or a "back door". I see a simple IPP front door (with a video
SAI> surveillance camera) just to see what the printer looks like. We
SAI> can only WIN of the IPP model of the Printer is the same as
SAI> SNMP Printer MIB model of the Printer!
>If we were to define another naming scope, say "attributes", that =
reflected
>object-for-object, the data objects that are in our MIBs, then I would be
>less opposed. To some degree we have already started doing this that in =
the
>existing IPP 1.0 printer object attribute set.
> The fact that we are switching naming scopes (printer-attributes over to
>SNMP OIDs) in midstream seems a little odd, and emphasizes the technical
>"shortcut" we are attempting, thus confusing the IPP model. I would much
>prefer us to extend IPP the way we originally intended, through the use =
of
>additional printer attributes.
SAI> I see both sides of this argument: we already picked named attributes
SAI> for IPP, but in this case we are moving to querying already named
SAI> MIB objects (the name is the OID) - so we are just stringifying that =
name.
SAI> Seems consistent.
> I think I will always have reservations about doing this, but if the PWG
> decides they want to do this anyway, then I would urge the PWG to =
include
> text in whatever document is generated that says something like "If =
this
> mechanism is implemented co-resident with an existing SNMP agent, then =
the
> mechanism must support, at a minimum, the minimum level of security that
> the SNMP agent provides for the same objects". This should be a =
mandatory
> compliance statement, and not just a strongly worded suggestion. This =
would
> give future network administrators at least some comfort that there =
printer
> MIB data cannot be "hacked".
SAI> I agree with this compliance statement.=20
SAI> If we allow access through two doors to view whats in=20
SAI> the shop, we should have the two security guards at each door working
SAI> off the same policy sheet that was passed out at the early morning =
staff
SAI> meeting (i.e., if the sheet says "Don't let Scott Isaacson in here =
anymore,=20
SAI> he causes problems" then neither guard should allow Scott in either =
door.)