Subject: RE: IPP> ADM - Reminder about job openings and home work ass

From: [email-masked]
Date: Sun, 26 Apr 1998 14:55:56 -0400

Randy Turner said:

>What I would not like to hear from folks is..."well,SNMP has no security",
and
>"well, SNMP doesn't do traps reliably". If you read the minutes from the
last
>IETF Plenary in L.A, specifically the SNMPv3 WG minutes, SNMPv3
implementation
>and availability after 6 months at "proposed" is already past where v2 was
>after two years at "proposed". The point is, we're designing stuff that
probably
>won't be deployed until 1999, when in network management circles SNMPv3
will reach
>the dominant position, if kept at its current pace of implementation.
>
>SNMPv3 has some of the same security mechanisms at IPP, and you are going
>to have to reconcile these two models if you provide a backdoor to MIB
>data, whether you are reading, or writing these objects.

Gosh, let me count the number of printers that implement SNMPv3 ....

-- ZERO !!

Therefore if we allow access to the MIB Objects through IPP which includes
TLS, I contend there are no security problem. Accesssing MIB objects using
IPP would much, much more secure than accessing those same objects via the
currently popular SNMPv1 implementations.

**********************************************
* 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: Harry Lewis <[email-masked]>
Date: Sun, 26 Apr 1998 02:00:40 -0400

With the goal of "IPP SDP" to have one protocol for submission and management,
I see two paths.

1. Create an entirely redundant encoding of all the Printer MIB objects for
this new SDP protocol
2. Provide a  way for the SDP to access the current MIB OIDs.

Given that many (most?) of us already have the Printer MIB data representation
in our printers, I prefer (2).

I can see Randy's point if the desire was to keep print submission and
management separate, but I think, if you accept the premise of SDP in the first
place, you must abandon this approach.

As for security, this seems like an odd reasoning. Security was always one of
SNMP's weak points and something IPP has struggled to achieve. Besides, I don't
think Scott has recommended and SETs to the OIDs.

One of the highlights of SENSE I remember Jay telling us about was that, with
one query, he could get the whole Printer MIB. It didn't seem like a threat
then.

Harry Lewis - IBM Printing Systems

[email-masked] on 04/24/98 09:53:49 PM
Please respond to [email-masked]
To: [email-masked], [email-masked], [email-masked]
cc:
Subject: RE: IPP> ADM - Reminder about job openings and home work ass

I have some reservations about using the concept of using IPP to
encapsulate OID to access SNMP MIB objects. I think we should be very
careful about the scope and requirements for such a capability. The
biggest problem I guess I have with this is that we MUST make sure that
IPP is not used to circumvent or hack access to manageable objects which
might otherwise be secured by standard SNMP security methods. There are
other considerations such as the definition of request and response
attributes, and whether or not we have a rich enough value syntax to
describe current SMI data objects.
I could go on but its Friday night and I'm getting dirty looks...;)

Randy

> -----Original Message-----
> From: Kris Schoff [SMTP:[email-masked]]
> Sent: Friday, April 24, 1998 4:41 PM
> To: [email-masked]'; [email-masked]'
> Subject: RE: IPP> ADM - Reminder about job openings and home work
> assignme nts
>
> Scott,
>
> I would be very interested in tunneling SNMP OID's through IPP for
> printer management.  It seems like a very reasonable concept to do and
> it could allow for the enabling of millions of printers in existence
> today.  I'd like to see you continue your effort within IPP.
>
> I am still a proponent that IPP was intended to become a universal,
> catch-all printing protocol - which is why I am not on the SDP mailing
> list.  By definition of "Server-to-Device", it would seem as if the
> client is already being left out.  I could have sworn that some people
> within the IPP WG were trying to limit the number of protocols that
> needed to be implemented....
>
> Kris Schoff
>
>
>
>
> > -----Original Message-----
> > From: [email-masked] [SMTP:[email-masked]]
> > Sent: Wednesday, April 22, 1998 1:58 PM
> > To: [email-masked]
> > Subject: Re: IPP> ADM - Reminder about job openings and home work
> > assignments
> >
> > Message-Id: <[email-masked]>
> > Date: Wed, 22 Apr 1998 13:35:23 -0600
> > Subject:
> > Sender:
> >
> Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f#
> > com@hpbs1480
> > FROM:
> >
> Non-HP-SISAACSON/HP-Boise_mimegw7////////HPMEXT1/SISAACSON#a#novell#f#
> > com@hpbs1480
> > TO: [email-masked],
> >     [email-masked]
> > Encoding: 17 text
> >
> >
> > >>> Carl-Uno Manros <[email-masked]> 04/22 11:23 AM >>>
> > > (snip)
> > >HOME WORK ASSIGNMENTS
> > >
> > > (snip)
> > >
> > > 4) Revised draft on getting MIB info over IPP - Uncertain whether
> > this is
> > > still part of IPP or should be part of the SDP discussion? (Scott
> > I.)
> >
> > Unless this is still part of an IPP discussion, then I am not
> > interested in
> > participating.  I plan to rev the document and post and an I-D
> (non-WG
> > draft if necessary), but I would like for it to be a WG draft.
> >
> > Scott
> >