Subject: Re: IPP> Using OID access with IPP/SDP

From: [email-masked]
Date: Mon, 27 Apr 1998 12:48:23 -0400

Randy Turner said

>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.

Randy, I can't believe you said this.  Is this security by obscurity?  OK,
rather than call them OIDs will pick random series of numbers separated
by periods (that happen to match the MIB) to identify the attributes we
want and call them PORN - "Printer Object Random Numbers"

Anyone object?
**********************************************
* Don Wright                 [email-masked] *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 27 Apr 1998 10:02:15 -0700

Pick whatever naming scope you wish, just pick ONE.

We already have printer attributes, why not stick with em'.

Randy

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Monday, April 27, 1998 9:48 AM
	To:	[email-masked]
	Cc:	[email-masked]
	Subject:	Re: IPP> Using OID access with IPP/SDP

	Randy Turner said

	reflected
	the
	>existing IPP 1.0 printer object attribute set.

	Randy, I can't believe you said this.  Is this security by
obscurity?  OK,
	rather than call them OIDs will pick random series of numbers
separated
	by periods (that happen to match the MIB) to identify the
attributes we
	want and call them PORN - "Printer Object Random Numbers"

	Anyone object?

---

From: Harry Lewis <[email-masked]>
Date: Mon, 27 Apr 1998 13:54:07 -0400

Randy said...

 >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 in the

The main concern I have with using string named attributes rather than the
distinguishing part of the Printer MIB OID is the
processing required to differentiate strings vs. the (relatively short) OID
stubs.

Harry Lewis - IBM Printing Systems

---

From: "Scott Isaacson" <[email-masked]>
Date: Mon, 27 Apr 1998 12:47:25 -0600

My comments preceded by SAI>

>>> Randy Turner <[email-masked]> 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 
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
>less opposed. To some degree we have already started doing this that in the

> 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. 
SAI> If we allow access through two doors to view whats in 
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, 
SAI> he causes problems" then neither guard should allow Scott in either door.)