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

Re: RMON document advancement

Wijnen, Bert (Bert) wrote:
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. 



The latter is what I had in mind.



okay



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. 
That is why I suggested that you as WG chair propose on the RMONMIB
list that we will close down after RAQMON is finished.
We can then see if there is objection to that.


agreed






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. 


oops -- mean pass the tests for Full Standard, not Draft Standard
If a Proposed Standard MIB module is not advanced in 4 years, then 
     it is moved to Historic status.

Throw your darts!  :-)



Mmm... I was more thinking of describing why having MIB document
just at PS and recycle at PS if updates/changes are needed.
I would not want to suggest to dive into the NEWTRK pool. You probably will get depressed. 
I was just thinking that if we document why we (MIB people) think
that one level (PS) and recycling at that if changes/updates are
needed, then we can see if NM and MIB people support that, and
we could even try to get that adopted for MIB documents as the
acceptable process. As a side effect it may (or may not) help NEWTRK, but I would not 
see that as a primary goal.



okay -- I really don't want to get involved in newtrk now!

That option would of needed to be accounted for anyway,
i.e., starting a new 4 year timer each time an RFC cycled at Proposed.
I like your idea even better -- the 1 Phase MIB Advancement Process!


Bert


Andy


Bert



Andy



Andy