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

From: Randy Turner <[email-masked]>
Date: Sun, 26 Apr 1998 06:22:47 -0700

Just because you "can" do something doesn't necessarily mean you "should".

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.

If SDP is only going to be implemented over direct-attach, point-to-point
interfaces like RS232 or 1284, then I would relax my stance somewhat, but
not much.

Randy

At 02:00 AM 4/26/98 -0400, Harry Lewis wrote:
>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
>> >
>

---

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.

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.

Randy