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

RE: RMON document advancement



I am in favor of a MIB Doctors meeting at IETF65. At first reading, I
like the two-steps proposal by Bert, but it's only the first reading. I
plan to come at IETF65. Regards, Dan


 
 

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert)
> Sent: Friday, December 23, 2005 6:15 PM
> To: Andy Bierman
> Cc: MIB Doctors
> Subject: RE: RMON document advancement
> 
> Thinking about it somewhat and meeting at IETF65 to discuss 
> it might be a good idea.
> 
> In fact, it might be good to schedule a MIB doctors meeting at
> IETF65 anyways, together with the new AD and to then evaluate 
> what we as MIB doctors have done in the past and how we want 
> to proceed in the future and how we can help the new AD.
> 
> Can I get a confirmation of all those who plan or not plan to 
> come to IETF65? Private email is best and I can keep a list 
> of those who plan to attend.
> 
> Bert
> 
> > -----Original Message-----
> > From: Andy Bierman [mailto:ietf@andybierman.com]
> > Sent: Friday, December 23, 2005 17:10
> > To: Wijnen, Bert (Bert)
> > Cc: C. M. Heard; MIB Doctors
> > Subject: Re: RMON document advancement
> > 
> > 
> > Hi Bert,
> > 
> > I agree with you, and there are basically 2 choices:
> >   1) silent option: don't ask, don't advance
> >   2) nuclear option: document all the ways multi-phase MIB 
> standards 
> > level
> >       has hampered, influenced, and even damaged IETF NM standards 
> > quality
> > 
> > I refuse to be the only author on the nuclear option draft.
> > It might set into motion a series of events I don't have 
> enough time 
> > for.
> > Can we use "MIB Doctors" as the author? ;-)  I suggest we 
> think about 
> > it for awhile, and have a meeting at IETF65 to decide.
> > 
> > IMO, Juergen brought up one of the most important points (again).
> > Many times we have ignored coupling and cohesion principles to get 
> > around standards advancement problems.  We have good 
> reason, after 16 
> > or so years of operational experience, to change the advancement 
> > process for MIB modules.
> > 
> > Andy
> > 
> > 
> > 
> > 
> > 
> > 
> > >Inline
> > >
> > >  
> > >
> > >>-----Original Message-----
> > >>From: owner-mreview@ops.ietf.org
> > [mailto:owner-mreview@ops.ietf.org]On
> > >>Behalf Of C. M. Heard
> > >>Sent: Friday, December 23, 2005 02:48
> > >>To: MIB Doctors
> > >>Subject: Re: RMON document advancement
> > >>
> > >>
> > >>On Thu, 22 Dec 2005, Andy Bierman wrote:
> > >>    
> > >>
> > >>>Do we really need a draft to declare that we're just not 
> going to 
> > >>>try to advance any MIBs past Proposed anymore?
> > >>>      
> > >>>
> > >>It would probably be sufficient if the OPS AD for NM put a policy 
> > >>statement on the OPS web site stating that WGs would no longer be 
> > >>required to do that.
> > >>    
> > >>
> > >
> > >Tough to do if there is no good (IETF) consensus on that.
> > >I am pretty sure I would get a lot of pushback.
> > >If I do it silently, then it works, if we want to make it a policy 
> > >statement... I suspect lots of pushback if we do not have a good 
> > >document explaining why we do it. And once we have the 
> document, I'd 
> > >try to get IETF consensus/agreement/no-objection.
> > >
> > >  
> > >
> > >>However, before that is done, it would probably be a good idea to 
> > >>make a haeds up announcement on the ietf-mibs mailing 
> list and the 
> > >>relevant WG mailing lists.
> > >>
> > >>    
> > >>
> > >
> > >And the best way to do that is to point to a document 
> (does not need 
> > >to be more than a couple of pages I guess) which explains
> > the rationale.
> > >
> > >  
> > >
> > >>Having said that, I still would like to see a draft 
> announcing that 
> > >>policy ... if for no other reason than that it might have 
> the effect 
> > >>of prodding newtrk into doing something.
> > >>
> > >>    
> > >>
> > >
> > >That too. But that would be a side-effect I would think.
> > >
> > >Bert
> > >  
> > >
> > >>//cmh
> > >>
> > >>
> > >>    
> > >>
> > >
> > >
> > >
> > >  
> > >
> > 
> 
>