Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y 2005)

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 28 Jul 2005 09:06:41 -0700

Hi Stuart
 
I _don't_ want to leave the hole.  As Mike Fenelon just said, it would be
confusing.
 
The ppmPortTable you listed indices for below is one table with six entries.
 
The need for ppmGeneralNumberOfPorts is to avoid 'walking off the end of the
table'
when a client browses the 'ppmPortTable' directly (without previously
reading every
entry in 'ppmPrinterTable' which gives the interior bounds).
 
It's just best practice to have scalar objects that avoid 'walking off the
end' (which
is often incorrectly reported to applications as an SNMP communications
error).
 
BOTH of these port counters are needed - because it's also important to
support
browsing the printer-specific list of ports.
 
Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked] 

-----Original Message-----
From: Stuart Rowley [mailto:[email-masked]]
Sent: Thursday, July 28, 2005 11:51 AM
To: McDonald, Ira
Cc: [email-masked]; [email-masked]
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y
2005)

Ira,

I am clear on the proposal now and I still don't see the need to maintain
the hole at this stage.

Can you clarify this for me...

If I have 2 attached printers each with the same 3 ports, they would be
indexed by the Printer and then the Port:

.1.1

.1.2

.1.3

.2.1

.2.2

.2.3

(I don't know if this is considered one table with 6 entries or 2 tables
with 3 entries each.)

So I don't understand the need for both

ppmGeneralNumberOfPorts

ppmPrinterNumberOfPorts

If I know the Printer index and number of printer ports, isn't this enough?

Thanks,

Stuart

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 28, 2005 8:24 AM
To: Stuart Rowley
Cc: [email-masked]
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y
2005)

Stuart, 

Sorry about the error in my request.  I was talking about ppmPrinterenabled,
not Portenabled. 

Jerry 

Stuart Rowley <[email-masked]> 
Sent by: [email-masked] 

07/28/2005 11:19 AM 

        To:        "[email-masked]'" <[email-masked]> 
        cc:        "McDonald, Ira" <[email-masked]> 
        Subject:        RE: PMP> [delete ppmPrinterEnabled] Restructured
Port MIB (18 Jul         y 2005)

Hi Ira,

I'm not clear on the proposal.

Your email said, "Let's delete ppmPrinterEnabled,..."

Then Jerry's reply said, "...where ppmPortEnabled "used" to be..."

So is the proposal to keep ppmPrinterEnabled and remove ppmPortEnabled?

I don't see the need to leave a hole for the removed object at this stage of
development.

Thanks,

Stuart

Stuart Rowley, Network Product Mgr.

[email-masked]      925 849-3306     925 849-3399 (fax)

Kyocera Technology Development Inc.

1855 Gateway Blvd. Suite 400

Concord, CA 94520

_____

From: [email-masked] [mailto:[email-masked]] On Behalf Of McDonald,
Ira
Sent: Thursday, July 28, 2005 7:59 AM
To: [email-masked]'; McDonald, Ira
Cc: [email-masked]'
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y
2005)

Hi Jerry,

There's no such thing as a reserved no-access object, but I'd be happy to
leave

the hole (so that the OIDs don't change for any other columnar objects).
Would

you prefer that?

Note that ALL of the columnar objects were cleaned up and reordered (and

renumbered) in this latest revision, so it would be hard for there to be too
many

implementations of the new OIDs already.

Others - shall I leave the hole and leave the other new OID assignments
stable?

Cheers,

- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 28, 2005 10:33 AM
To: McDonald, Ira
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y
2005)

Ira,

Are you just planning on creating a reserved no-access object where
ppmPortEnabled "used" to be, or are
you going to delete the entry and shift everything else in the table up.??

Jerry

"McDonald, Ira" <[email-masked]>

07/23/2005 01:56 PM

To:        "McDonald, Ira" <[email-masked]>,
"[email-masked]'" <[email-masked]> 
cc:        "[email-masked]'" <[email-masked]>,
"[email-masked]'" <[email-masked]> 
Subject:        RE: PMP> [delete ppmPrinterEnabled] Restructured
Port MIB (18 Jul        y 2005)

Hi,

Let's delete ppmPrinterEnabled, because the 'false' is redundant
with ppmPortEnabled of 'false' for all supported ports.  And
because otherwise, we must say "ignore ppmPortEnabled of 'true'
for installation if ppmPrinterEnabled is 'false'".  Which leads
me to agree that we should delete ppmPrinterEnabled.

When a Printer is permanently removed from an ENA interface,
the whole ppmPrinterTable row and all subordinate rows in
ppmPortTable can just be deleted.

For 'ppmPortProtocolType' using 'PrtChannelTypeTC', we're working
to get 'unknown(2)' registered quickly with IANA, so that we can
do the 'right thing' that Bert Wijnen pointed out.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]
-----Original Message-----
From: McDonald, Ira
Sent: Friday, July 22, 2005 1:37 PM
To: [email-masked]'; McDonald, Ira
Cc: [email-masked]; [email-masked]
Subject: RE: PMP> Restructured Port MIB (18 July 2005)

Hi Jerry,

I agree that feedback from the clients (Microsoft and Apple) on how they'd
like this to work would be helpful.

Remember, that a value of 'ppmPrinterIndex' must NEVER be reassigned
to a different instance of a Printer at a later date.  While the MIB may
grow and shrink, the base 'ppmPrinterIndex' should be immutably
associated with exactly one specific instance of a Printer.  This is both
correct MIB practice and required by the object definition in the current
MIB draft.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 22, 2005 1:28 PM
To: McDonald, Ira
Cc: [email-masked]; [email-masked]
Subject: RE: PMP> Restructured Port MIB (18 July 2005)

I would think that the usefullness of the ppmPrinterEnabled for an
ENA would only be for the "transcient" case of the plugging/unplugging
of the related printer.  However at some point (in the case that the printer

stays unplugged "permanently") the printer entry and associated protocol
tables would be removed such that the the MIB could grow and shrink
over time.....

For example, an ENA with a USB host interface that supports up to
128 attached printers, In my opinion, shouldn't need to have 128 printer
entries
in the MIB tables from first power on......only the entries that have
detected (valid 1284ID)
printers etc. attached.....otherwise you'd end up in most cases with 127
default printer entries
with associated port tables that don't actually go anywhere.

Of course this behaviour is different from the current TCPMON.ini file
which has static entries.......

I think maybe the clients should give guidance on how they want it to work.

Jerry Thrasher

"McDonald, Ira" <[email-masked]>
Sent by: [email-masked]
07/22/2005 12:13 PM

To:        "'Bergman, Ron'" <[email-masked]>, "McDonald,
Ira" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>,
[email-masked]
cc:
Subject:        RE: PMP> Restructured Port MIB (18 July 2005)

Hi Ron,

If the Printer entry is deleted when an ENA interface
is disconnected, then all the subordinate Port entries
MUST be deleted too (because they are indexed by the
object ppmPrinterIndex).  This is ugly if the local
printer is promptly plugged _back_ into the interface.

If the Printer entry is left in place but _not_ clearly
marked 'disabled', then ppmPrinterIEEE1284DeviceId,
ppmPrinterHrDeviceIndex and all the other Printer
columnar objects must be reset (to default values).

That's why the ppmPrinterEnabled object should be kept.

The WG concensus was strong that ppmPortEnabled was
required to keep the port list static (fixed number
of ports for an interface).  Therefore, I added the
ppmPrinterEnabled object.

If others want ppmPrinterEnabled removed, would they
please speak up soon?

Cheers,
- Ira

PS - Remember that this MIB is supposed to work for
Network Spoolers too, where the concept of 'the printer
is removed' is fuzzy.  The 'printer' is just some
configured downstream network printer that may well
be administratively disabled _without_ removing the
configuration at the Network Spooler.

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: Bergman, Ron [mailto:[email-masked]]
> Sent: Thursday, July 21, 2005 8:24 PM
> To: McDonald, Ira; Wijnen, Bert (Bert); [email-masked]
> Subject: RE: PMP> Restructured Port MIB (18 July 2005)
>
>
> Ira,
>
> Base on my experience with ENAs, they do not provide a feature to
> disable an output port unless the printer is removed.  Normally,
> this is to replace a worn-out unit or upgrade a printer.
> In this case the old printer is gone forever.  So how does your
> "STATIC entries" handle this situation?
>
>         Ron
>
> -----Original Message-----
> From: McDonald, Ira [mailto:[email-masked]]
> Sent: Wednesday, July 20, 2005 8:38 AM
> To: Bergman, Ron; McDonald, Ira; Wijnen, Bert (Bert); [email-masked]
> Subject: RE: PMP> Restructured Port MIB (18 July 2005)
>
>
> Hi Ron,
>
> Based on previous IPP experience, it will take MONTHS to add one
> new enum to the PrtChannelTypeTC with IANA - that would stop the
> Port Mon MIB dead in its tracks until it was accepted by IANA.
>
> About ppmPrinterEnabled - same rationale as ppmPortEnabled - keeps
> the number of Printer entries STATIC in an implementation - lets
> the user see that the one Printer (i.e., hardward output interface)
> on an External Network Adapter should presently be ignored.
>
> Remember that the Port Mon MIB MUST NOT depend on either Host
> Resources or Printer MIB, by common concensus - it may only
> AUGMENT them, if they are present.
>
> Cheers,
> - Ira
>
> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: [email-masked]
>
> > -----Original Message-----
> > From: Bergman, Ron [mailto:[email-masked]]
> > Sent: Tuesday, July 19, 2005 7:40 PM
> > To: McDonald, Ira; Wijnen, Bert (Bert); [email-masked]
> > Subject: RE: PMP> Restructured Port MIB (18 July 2005)
> >
> >
> > Ira,
> >
> > I am not sure what value ppmPrinterEnabled adds to the MIB.
> > This appears to be analogous to
> > On Line/Off Line.  If I want to create a driver for the
> > printer I don't care what the current
> > state is.  That information is only necessary when I am ready
> > to print and then this MIB is
> > not used.
> >
> > I believe that Bert has a valid point in using
> > ppmPortProtocolType.  It is not a major effort
> > to add unknown(2) to the IANA registrations.
> >
> > Otherwise, the changes are inline with our discussions
> > following the test.
> >
> >         Ron
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf
> > Of McDonald,
> > Ira
> > Sent: Tuesday, July 19, 2005 9:46 AM
> > To: 'Wijnen, Bert (Bert)'; McDonald, Ira; [email-masked]'
> > Subject: RE: PMP> Restructured Port MIB (18 July 2005)
> >
> >
> > Hi Bert,
> >
> > Thanks for your quick feedback.  My replies inline below.
> >
> > Cheers,
> > - Ira
> >
> >
> > Ira McDonald (Musician / Software Architect)
> > Blue Roof Music / High North Inc
> > PO Box 221  Grand Marais, MI  49839
> > phone: +1-906-494-2434
> > email: [email-masked]
> >
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > Sent: Tuesday, July 19, 2005 9:08 AM
> > > To: McDonald, Ira; [email-masked]'
> > > Subject: RE: PMP> Restructured Port MIB (18 July 2005)
> > >
> > >
> > > Only did a very very quick scan.
> > >
> > > Comments.
> > >
> > > - ppmPortProtocolTargetPort OBJECT-TYPE
> > >     SYNTAX      Integer32 (0..65535)
> > >   I propose that you use InetPortNumber TC from RFC4001
> > >
> >
> > Won't work, because this port is not limited to Internet Suite
> > protocols.  The 'service:' URI in ppmPortServiceNameOrURI may
> > also be for non-Internet suites (AppleTalk, NetWare, etc.).
> >
> > I'll correct the DESCRIPTION in the MIB and make clear that
> > (as with the Printer MIB) ports/channels may be from multiple
> > protocol suites.
> >
> >
> > > - ppmPortProtocolType OBJECT-TYPE
> > >     SYNTAX      Integer32 (0..2147483647)
> > >
> > >   WHy not use TC PrtChannelTypeTC as the SYNTAX?
> > >   I do see that you want to use zero (meaning not supported).
> > >   But maybe better is to use none(1) in that case, or maybe
> > >   adding an enumeration to the TC of notSupported(xx) ??
> > >   It is now an IANA-maintained TC, so it should not be that
> > >   difficult to get a label added.
> > >
> >
> > Won't work.  PrtChannelTypeTC currently only defines 'other(1)'
> > and (foolishly) does NOT define 'unknown(2)' (unlike every other
> > textual convention in the Printer MIB).  Because the Printer MIB
> > v2 still doesn't define DEFVAL clauses for most objects, this
> > oversight has not surfaced before.  We could register 'unknown(2)'
> > with IANA, but _not_ fast enough (because this MIB's going into OS
> > and printer vendor products right now).
> >
> >
> > > - ppmPortPrtChannelIndex has a reference to RFC1213, while I
> > >   think I would reather reference RFC2863 (the current IF-MIB)
> > >
> > > Bert
> > >
> >
> > Agreed.  My mistake from the old Printer MIB (RFC 1759).
> >
> > I'll correct the references in the MIB.
> > - Ira
> >
>