The oid was only out for a few days. I think it would be much more
confusing to have a hole for something we took out of a draft, than to
simply move everything up after deleting the oid.
Mike Fenelon
Microsoft
________________________________
From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org] On Behalf Of Wijnen,
Bert (Bert)
Sent: Thursday, July 28, 2005 8:28 AM
To: McDonald, Ira; 'thrasher at lexmark.com'
Cc: 'pmp at pwg.org'
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18
Jul y 2005)
I have not followed detailed discussion on this... but
- SMI rules state that one a document with a MIB is published, you can
NEVER
re-use an OID for some other purpose. All you can do is obsolete the
old object and add a new one.
- In IETF, when we just have internet drafts, we allow people to re-use
an OID
(supposedly no-one has used the OID while at internet draft state,
besides.
such MIB modules normally have a
::= { mib-2 xxxx } -- xxxx to be assigned by IANA
so there is no definite complete OID, and people who want to do early
implementations
fill in a number under their enterprise prerelease branch or so.
the final xxxx gets assigned by IANA upon document approval (right
before RFC
publication) and so no OID changes are allowed anymore.
See the SMI documents for the rationale.
- But once published as RFC, we never re-use an OID, not even when a new
rev is
being published as a intrenet-draft.
Hope this helps,
Bert
-----Original Message-----
From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On Behalf Of
McDonald, Ira
Sent: Thursday, July 28, 2005 16:59
To: 'thrasher at lexmark.com'; McDonald, Ira
Cc: 'pmp at pwg.org'
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: imcdonald at sharplabs.com
-----Original Message-----
From: thrasher at lexmark.com [mailto:thrasher at lexmark.com]
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" <imcdonald at sharplabs.com>
07/23/2005 01:56 PM
To: "McDonald, Ira" <imcdonald at sharplabs.com>,
"'thrasher at lexmark.com'" <thrasher at lexmark.com>
cc: "'pmp at pwg.org'" <pmp at pwg.org>,
"'Ron.Bergman at rpsa.ricoh.com'" <Ron.Bergman at rpsa.ricoh.com>
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: imcdonald at sharplabs.com
-----Original Message-----
From: McDonald, Ira
Sent: Friday, July 22, 2005 1:37 PM
To: 'thrasher at lexmark.com'; McDonald, Ira
Cc: pmp at pwg.org; Ron.Bergman at rpsa.ricoh.com
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: imcdonald at sharplabs.com
-----Original Message-----
From: thrasher at lexmark.com [mailto:thrasher at lexmark.com]
Sent: Friday, July 22, 2005 1:28 PM
To: McDonald, Ira
Cc: pmp at pwg.org; Ron.Bergman at rpsa.ricoh.com
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" <imcdonald at sharplabs.com>
Sent by: pmp-owner at pwg.org
07/22/2005 12:13 PM
To: "'Bergman, Ron'"
<Ron.Bergman at rpsa.ricoh.com>, "McDonald,
Ira" <imcdonald at sharplabs.com>, "Wijnen, Bert (Bert)"
<bwijnen at lucent.com>,
pmp at pwg.org
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: imcdonald at sharplabs.com
> -----Original Message-----
> From: Bergman, Ron [mailto:Ron.Bergman at rpsa.ricoh.com]
> Sent: Thursday, July 21, 2005 8:24 PM
> To: McDonald, Ira; Wijnen, Bert (Bert); pmp at pwg.org
> 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:imcdonald at sharplabs.com]
> Sent: Wednesday, July 20, 2005 8:38 AM
> To: Bergman, Ron; McDonald, Ira; Wijnen, Bert (Bert);
pmp at pwg.org
> 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: imcdonald at sharplabs.com
>
> > -----Original Message-----
> > From: Bergman, Ron
[mailto:Ron.Bergman at rpsa.ricoh.com]
> > Sent: Tuesday, July 19, 2005 7:40 PM
> > To: McDonald, Ira; Wijnen, Bert (Bert); pmp at pwg.org
> > 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: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On
Behalf
> > Of McDonald,
> > Ira
> > Sent: Tuesday, July 19, 2005 9:46 AM
> > To: 'Wijnen, Bert (Bert)'; McDonald, Ira;
'pmp at pwg.org'
> > 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: imcdonald at sharplabs.com
> >
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert)
[mailto:bwijnen at lucent.com]
> > > Sent: Tuesday, July 19, 2005 9:08 AM
> > > To: McDonald, Ira; 'pmp at pwg.org'
> > > 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/pmp/attachments/20050728/d601647c/attachment-0001.html