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

From: "McDonald, Ira" <[email-masked]>
Date: Sat, 23 Jul 2005 10:56:30 -0700

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

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 28 Jul 2005 07:59:08 -0700

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

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

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,

Cheers,
- Ira

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

Cheers,
- Ira

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

Jerry Thrasher

Hi Ron,

Cheers,
- Ira

---

From: Stuart Rowley <[email-masked]>
Date: Thu, 28 Jul 2005 08:19:09 -0700

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,

you prefer that?

Cheers,

- Ira

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

Jerry 

07/23/2005 01:56 PM 

Hi,

Cheers,
- Ira

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

Cheers,
- Ira

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

Jerry Thrasher

Hi Ron,

Cheers,
- Ira

---

From: [email-masked]
Date: Thu, 28 Jul 2005 11:23:44 -0400

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 don't see the need to leave a hole for the removed object at this stage 
of
development.

Thanks,

Stuart

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,

you prefer that?

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

Cheers,

- Ira

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

Jerry

07/23/2005 01:56 PM

Hi,

Cheers,
- Ira

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

Cheers,
- Ira

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

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

Jerry Thrasher

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,

Cheers,
- Ira

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 28 Jul 2005 17:28:29 +0200

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: [email-masked] [mailto:[email-masked]]On Behalf Of McDonald, Ira
Sent: Thursday, July 28, 2005 16:59
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

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

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,

Cheers,
- Ira

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

Cheers,
- Ira

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

Jerry Thrasher

Hi Ron,

Cheers,
- Ira

---

From: "Mike Fenelon" <[email-masked]>
Date: Thu, 28 Jul 2005 08:43:56 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Wijnen,
Bert (Bert)
Sent: Thursday, July 28, 2005 8:28 AM
To: McDonald, Ira; [email-masked]'
Cc: [email-masked]'
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18
Jul y 2005)

- 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 

  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: [email-masked] [mailto:[email-masked]]On Behalf Of
McDonald, Ira
	Sent: Thursday, July 28, 2005 16:59
	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
	 
		-----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 

        

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

		
		
		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,

		

		
		Cheers,
		- Ira

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 28 Jul 2005 08:49:38 -0700

Hi Bert,

It does help, yes.  We have been prototyping against the equivalent
of Internet-Drafts (PWG Working Drafts).  After a very successful
initial interoperability test two weeks ago, we realized that
restructuring (from two object groups to three object groups)
was necessary.  I posted an ASN.1-only sketch of the restructuring.

Of necessity, the OIDs changed (because the columnar objects moved
from one table to the other).

Jerry Thrasher's team at Lexmark was so quick that they've already
prototyped the new sketch.

Probably we should close the hole.  That's what I just asked for
feedback about on this mailing list.  Both Client (SNMP Command 
Generator) and Agent (SNMP Command Receiver) applications have been 
prototyped by OS and printer vendors.

Cheers,
- Ira

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

- In IETF, when we just have internet drafts, we allow people to re-use an
OID

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

Hi Jerry,

Cheers,
- Ira

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

Jerry 

Hi,

Cheers,
- Ira

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

Cheers,
- Ira

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

Jerry Thrasher

Hi Ron,

Cheers,
- Ira

---

From: Stuart Rowley <[email-masked]>
Date: Thu, 28 Jul 2005 08:50:32 -0700

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 

07/28/2005 11:19 AM 

Hi Ira,

Thanks,

Stuart

Concord, CA 94520

_____

Hi Jerry,

you prefer that?

Cheers,

- Ira

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

Jerry

07/23/2005 01:56 PM

Hi,

Cheers,
- Ira

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

Cheers,
- Ira

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

Jerry Thrasher

Hi Ron,

Cheers,
- Ira

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 28 Jul 2005 20:20:28 +0200

It does not matter how long the OID has been out.
What matters is if it was formally assigned (by whoever controls assignments in
    enterprises pwg(2699) mibs(1)
and it seems (from the doc/mic that was posted) that ppmMIB did get and OID
assigned, namely
     enterprises pwg(2699) mibs(1) ppmMIB(2)
 
And so I claim it has been published and so in my view you would not re-order OIDs.
There are sound technical reasons why that is the case, read RFC2579-2580 for that.
 
If you had like an experimental tree somewhere under pwg, then you could do it
there if you made VERY CLEAR statements that those are all for experimental
and/or pre-release testing and so no-one should assume that OIDs in there are
ever going to be permanent. You would still (in my view) re-root under some other
branch at the top level of the ppmMIB module if you started reordering OIDs.
 
Just trying to explain and help.
 
 Bert
 
-----Original Message-----
From: Mike Fenelon [mailto:[email-masked]]
Sent: Thursday, July 28, 2005 17:44
To: Wijnen, Bert (Bert); McDonald, Ira; [email-masked]
Cc: [email-masked]
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y 2005)

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: [email-masked] [mailto:[email-masked]] On Behalf Of Wijnen, Bert (Bert)
Sent: Thursday, July 28, 2005 8:28 AM
To: McDonald, Ira; [email-masked]'
Cc: [email-masked]'
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y 2005)

 

 
 
Hope this helps,
 
Bert
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of McDonald, Ira
Sent: Thursday, July 28, 2005 16:59
To: [email-masked]'; McDonald, Ira
Cc: [email-masked]'
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y 2005)
Hi Jerry,

 
 
Cheers,
- Ira
 
-----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, 

Jerry 

        

Hi,

Cheers,
- Ira

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

Cheers,
- Ira

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

Jerry Thrasher

Hi Ron,

Cheers,
- Ira

---

From: "Mike Fenelon" <[email-masked]>
Date: Thu, 28 Jul 2005 16:54:53 -0700

So what does that mean to us?? It is ridiculous to have an obsolete OID
in the MIB because we changed our mind during development. 
 
Mike Fenelon
Microsoft

From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Thursday, July 28, 2005 11:20 AM
To: Mike Fenelon; McDonald, Ira; [email-masked]
Cc: [email-masked]
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18
Jul y 2005)
 
It does not matter how long the OID has been out.
What matters is if it was formally assigned (by whoever controls
assignments in
    enterprises pwg(2699) mibs(1)
and it seems (from the doc/mic that was posted) that ppmMIB did get and
OID
assigned, namely
     enterprises pwg(2699) mibs(1) ppmMIB(2)
 
And so I claim it has been published and so in my view you would not
re-order OIDs.
There are sound technical reasons why that is the case, read
RFC2579-2580 for that.
 
If you had like an experimental tree somewhere under pwg, then you could
do it
there if you made VERY CLEAR statements that those are all for
experimental
and/or pre-release testing and so no-one should assume that OIDs in
there are
ever going to be permanent. You would still (in my view) re-root under
some other
branch at the top level of the ppmMIB module if you started reordering
OIDs.

 Bert
 
	-----Original Message-----
	From: Mike Fenelon [mailto:[email-masked]]
	Sent: Thursday, July 28, 2005 17:44
	To: Wijnen, Bert (Bert); McDonald, Ira; [email-masked]
	Cc: [email-masked]
	Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port
MIB (18 Jul y 2005)
	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: [email-masked] [mailto:[email-masked]] On Behalf Of
Wijnen, Bert (Bert)
	Sent: Thursday, July 28, 2005 8:28 AM
	To: McDonald, Ira; [email-masked]'
	Cc: [email-masked]'
	Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port
MIB (18 Jul y 2005)

	- 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 

	  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: [email-masked] [mailto:[email-masked]]On
Behalf Of McDonald, Ira
		 
		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
		 
			-----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 

        

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

			
			
			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.

			> -----Original Message-----
[mailto:[email-masked]]

---

From: "Bergman, Ron" <[email-masked]>
Date: Thu, 28 Jul 2005 17:02:56 -0700

I vote to eliminate the hole.  We know only 6 companies impemented the previous draft, so I doubt
if more than 6 have implemented this update in the last several days.  I also don't believe this draft
has been formally accepted to even be published as a draft.  
 
Has anyone implemented this version and is objecting to removing the deleted object?
 
    Ron
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Mike Fenelon
Sent: Thursday, July 28, 2005 4:55 PM
To: Wijnen, Bert (Bert); McDonald, Ira; [email-masked]
Cc: [email-masked]
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y 2005)

So what does that mean to us?? It is ridiculous to have an obsolete OID in the MIB because we changed our mind during development. 
 
Mike Fenelon
Microsoft

  _____  

 

 
 Bert
 
-----Original Message-----
From: Mike Fenelon [mailto:[email-masked]]
Sent: Thursday, July 28, 2005 17:44
To: Wijnen, Bert (Bert); McDonald, Ira; [email-masked]
Cc: [email-masked]
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y 2005)
 
Mike Fenelon
Microsoft

  _____  

 

 

Hope this helps,
 
Bert
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of McDonald, Ira
Sent: Thursday, July 28, 2005 16:59
To: [email-masked]'; McDonald, Ira
Cc: [email-masked]'
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y 2005)
Hi Jerry,

 
 
Cheers,
- Ira
 
-----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, 

Jerry 

        

Hi,

Cheers,
- Ira

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

Cheers,
- Ira

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

Jerry Thrasher

Hi Ron,

Cheers,
- Ira

---

From: [email-masked]
Date: Thu, 28 Jul 2005 20:16:52 -0400

Ron,

I'm not aware of any company that's already implemented the restructured
MIB that's going
to lie down in the road and object to removing the object and moving the
other objects up in
the table.....:).....just grumble a bit.....

Jerry

                      "Bergman, Ron"                                                                                            
                      <Ron.Bergman@rpsa        To:       "Mike Fenelon" <[email-masked]>, "Wijnen, Bert         
                      .ricoh.com>               \(Bert\)" <[email-masked]>, "McDonald, Ira" <[email-masked]>,      
                                                <[email-masked]>                                                          
                      07/28/2005 08:02         cc:       <[email-masked]>                                                          
                      PM                       Subject:  RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y    
                                                2005)                                                                           

I vote to eliminate the hole.  We know only 6 companies impemented the
previous draft, so I doubt
if more than 6 have implemented this update in the last several days.  I
also don't believe this draft
has been formally accepted to even be published as a draft.

Has anyone implemented this version and is objecting to removing the
deleted object?

    Ron
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Mike Fenelon
Sent: Thursday, July 28, 2005 4:55 PM
To: Wijnen, Bert (Bert); McDonald, Ira; [email-masked]
Cc: [email-masked]
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul
y 2005)

So what does that mean to us?? It is ridiculous to have an obsolete OID in
the MIB because we changed our mind during development.

Mike Fenelon
Microsoft

  _____

y 2005)

And so I claim it has been published and so in my view you would not
re-order OIDs.
There are sound technical reasons why that is the case, read RFC2579-2580
for that.

If you had like an experimental tree somewhere under pwg, then you could do
it
there if you made VERY CLEAR statements that those are all for experimental
and/or pre-release testing and so no-one should assume that OIDs in there
are
ever going to be permanent. You would still (in my view) re-root under some
other
branch at the top level of the ppmMIB module if you started reordering
OIDs.

 Bert

-----Original Message-----
From: Mike Fenelon [mailto:[email-masked]]
Sent: Thursday, July 28, 2005 17:44
To: Wijnen, Bert (Bert); McDonald, Ira; [email-masked]
Cc: [email-masked]
Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul
y 2005)

Mike Fenelon
Microsoft

  _____

y 2005)

Hope this helps,

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

too many

Cheers,
- Ira

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

Jerry

Hi,

Cheers,
- Ira

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

Cheers,
- Ira

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

Jerry Thrasher

Hi Ron,

Cheers,
- Ira

> > I'll correct the references in the MIB.
(See attached file: C.htm)

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 28 Jul 2005 17:44:21 -0700

Hi,

We're going to eliminate the hole!  Nobody really wants to keep it.

Bert said that IETF WGs sometimes moved around OIDs in Internet-Drafts
(working documents).  We've already moved around the OIDs at LEAST
three times in our working documents and we're going to do it once
more and quit, because we agree that we've got all the necessary
objects.

Bert - none of these working documents has EVER been approved or
promised ANY stability of OIDs.

Cheers,
- Ira

PS - As I promised Jerry Thrasher earlier today, new ASN.1 by
end-of-day tomorrow (Friday) or sooner if I can.

PPS - Jerry or Mike still needs to incorporate the rewritten
Requirements section into the right place in the boilerplate.

PPPS - And I need to write edits for Internationalization and
Security sections, because we moved some elements up (logically)
from the previous ppmPortTable to the new ppmPrinterTable.

> [email-masked]
> Sent: Thursday, July 28, 2005 8:17 PM
> To: Bergman, Ron
> Cc: [email-masked]
>                       <Ron.Bergman@rpsa        To:       
> "Mike Fenelon" <[email-masked]>, "Wijnen, 
> Bert         
>                       .ricoh.com>               \(Bert\)" 
> <[email-masked]>, "McDonald, Ira" <[email-masked]>,      
>                                                 
> <[email-masked]>                                        
>                   
>                       07/28/2005 08:02         cc:       
> <[email-masked]>                                                 
>          
>                       PM                       Subject:  RE: 
> PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y    
>                                                 2005)         
>                                                                   
>                                                               
>                                                                   
> 
> 
> 
> 
> Of Mike Fenelon
> Port MIB (18 Jul
> Port MIB (18 Jul
> RFC2579-2580
> Port MIB (18 Jul
> Port MIB (18 Jul
> (right before
> when a new
> Port MIB (18 Jul
> columnar objects).
> there to be
> assignments
> Port MIB (18 Jul

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 31 Jul 2005 08:44:52 +0200

Ira, I cannot stop you. I just want to help you realize 
what it means. W.r.t. 

> (working documents).

In principle only when the module itself does not have an OID assigned
yet. And so there is no real OID registered. They all are not
fixed untill the MIB module itself gets an OID assigned.

>  We've already moved around the OIDs at LEAST
not smart in my view. But who is me?

> promised ANY stability of OIDs.
Maybe not approved. But you had documents that DID have complete OIDs
defined, and so one never knows who has used them. Changing them 
in my view is against the base proinciples of the OID assignment
process/concenpts.

But I won't loose sleep of that is what PWG/PMP wants to do.
It is their name that is on the block, not mine.

Bert
> Sent: Friday, July 29, 2005 02:44
> To: [email-masked]'; Bergman, Ron
> Cc: [email-masked]
> Port MIB (18

---

From: "McDonald, Ira" <[email-masked]>
Date: Sun, 31 Jul 2005 10:42:01 -0700

Hi Bert,

You're right of course.  We haven't before wrestled with OID
assignment by the PWG for MIBs.  In fact only the IEEE-ISTO PWG
Secretary (currently Jerry Thrasher of Lexmark) has the authority
to assign/approve the base MIB arc when the Candidate Standard
is published.

In the future, we'll adopt the 'nnnn -- to be assigned by PWG'
approach.  Of course, when we have a prototyping interop test,
we'll have to choose _something_ for an experimental number
(for documents still in working drafts stage).

What do the IETF chartered working groups do during development?
Do they very use 'experimental' for this?

Cheers,
- Ira

> Sent: Sunday, July 31, 2005 2:45 AM
> To: McDonald, Ira; [email-masked]'; Bergman, Ron
> Cc: [email-masked]
> case that the