[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RMON document advancement
> >>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.
> >>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.
> >
> >
> >>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! :-)
>
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.
Bert
> >Bert
> >
> >
> >>Andy
> >>
> >>
> >>
> >>
>
> Andy
>
> >
> >
> >
> >
>