[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RMON document advancement

Wijnen, Bert (Bert) wrote:


Inline


-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Friday, December 16, 2005 17:49
To: Bert Wijnen
Cc: MIB Doctors
Subject: RMON document advancement


Hi Bert,

I hope you had a good vacation.


Yes I did. The bad news is always when you come back and find
a hopeless stack of emails in yiour inbox. Oh well.


I know you are busy, and you have a lot
of things to do before March.


Yes, I do want to try and clean my plate as much as I can so that
my successor can start fresh and with as clean a plate as possible.


That's why I think we should drop the rfc2613 (SMON-MIB) advancement.
It is in state "waiting for writeup:external party". 

So, from what I see, we did do an IETF Last Call,
We do have an implementation report (Dec 2002)
And this was just waiting till 2021 was davanced to DS,
which we just completed a month or so ago.

So if we really wanted to, it would be a matter of:
- simple WG Last Call to ask if anyone objects to the report
 from Dec 2004 and to move forward now that the pre-req
 (2021 to DS) has been completed.
- I would re-issue an IETF Last Call, but state that we basically
 had no objections back in 2002 and that the recent approval
 of RMON2 to DS unlocked this doc.
- Put it on IESG agenda and be done with it.
I'd say that if anyone at any point raises or suggests we start editing (for boilerplate and up-to-date security considerations 
and such), then we decide to give up and NOT move forward.

But... I am not wedded to this. We can also decide to remove
the work item from the WG charter. More below.



If you and Dan want to do the work, then fine.
I don't really have any time to spend on updating RMON RFC boilerplate.
If most of the work is already done, and you just re-designate RFC 2613,
then I guess it's worth finishing.


There are 5 other RMON MIBs that could advance to Draft (or not)
as well, after SMON-MIB.

But what's the point?  Nobody cares.
OK, so then I suggest that you wriet a msg to the RMONMIB list stating so and that you plan to suggest to the AD to close the 
WG once we get past approval of the RAQMOB documents.
If we get vehement objections we can see, otherwise we go ahead as you advise. 

Okay.
I don't foresee any new work in the RMONMIB WG.
I don't really know if any of these other new MIBs are even implemented
by multiple vendors. 
Nobody ever wants to respond to the implementation surveys.
Margaret and I did a ton of work on Entity MIB advancement,
deprecated objects, begged repeatedly for implementation reports,
republished repeatedly -- and in the end a couple people came
out of the shadows and said "we implement those objects so you
can't deprecate them!" 
Did they ever respond to the implementation survey? No.
Because nobody cares about a MIB advancing from Proposed to Draft.
We did a bunch of work, only to cause harm to the standards
community by attempting to deprecate objects actually in use!

I cc:ed MIB Doctors to see if I could rile anyone
into defending the MIB Standards Advancement Process.
IMO, the whole process should be suspended until the NEWTRK
work is done.  (Which might be never ;-)



I have seen the comments by Mike, Dave (DBH) too.
Would it make sense to write a document that explains why we would want to stop advancing MIB documents? Would that mean we want to be a bit more strict in screening 
MIB I-Ds that want to go PS, since it seems the final doc.
Or would we actively encourage to do new revs based on
experience and recycle at PS.

If we have a good write-up (preferably as an I-D), we may actually
be able to get traction and help the discussion in NEWTRK (which is now just stalled I think). 

I have been tempted to do so, but I have successfully avoided most
involvement with IETF procedural issues so far ;-). 
If the MIB Doctors come to consensus on a reasonable outline, I will
volunteer to write up the I-D.  I suppose the proposal below could
apply to any protocol, not just SNMP MIB modules.

My starting target to throw darts at:

 - 2 step advancement process

  1) Proposed Standard

     Make it hard to become a proposed standard by being more
     selective in the work that gets done, polling potential implementors
and operators for their real opinions, investigating actual implementations (e.g., the NMRG's SNMP survey). Use whatever resources at your disposal to help you decide in advance that the proposed work will be successful. Don't be afraid to use Experimental status instead of Proposed Standard. 

  2) Full Standard

     After 1 year, and before 4 years after initial RFC Publication,
     some WG must advance the MIB module from Proposed to Full Standard
     by passing the tests we have now for advancement to Draft Standard.

     If a Proposed Standard MIB module is not advanced in 4 years, then
     it is moved to Historic status.

Throw your darts!  :-)


Bert

Andy




Andy