RE: What about the OAM in OAM&P

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Some of us believe that notifications are a huge part of
configuration management. 

On Wed, 5 Jul 2006, Hare, Michael wrote:
> Thanks Andy.
> 
> The Notifications is what I think was confusing some of us into
> believing NETCONF was to be a complete OAMP solution since
> notification have little to do with network configuration.
> 
> >From what I gather from your response NETCONF is just for 
> >the configuration of the network with a bit of notification
> >thrown in.
> 
> Maybe there's a need for other WGs to define NETMAN, NETOP and
> NETADM to cover the rest. Not your problem, I understand, but I
> have to convience the folks here that things like software
> upgrades, loopbacks and such are not part of NETCONF. We will
> need to write proprietary RPCs for all that.
I'm crying now. Andy and you are talking at different levels
without true understanding nor communication.

Michael - why do you use the term OAM&P?

Regards,
/david t. perkins

> 
> Thanks,
> 
> - m
> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com]
> Sent: Monday, July 03, 2006 11:29 AM
> To: Hare, Michael
> Cc: Netconf Mailing List (E-mail)
> Subject: Re: What about the OAM in OAM&P
> 
> 
> Hare, Michael wrote:
> > Hi,
> > 
> > Please forgive me if this was covered.
> > 
> > Netconf is doing a good job of covereing the 'P' and maybe some of the 
> > 'A' and 'M', but what about the 'O'?
> > 
> > Things like:
> > 
> > Software Download (not really a <copy-config>, maybe just <copy>?)
> > Operating and Releasing Loopbacks/Test Signals (not really editing the 
> > configuration, new verb-set?)
> > Initializing PM Registers (again, not really editing the configuration)
> > Protection Switching
> > 
> > 
> > This may be outside the Netconf charter, but it seems the rpc framework 
> > being used for netconf could be re-used to the other parts of network 
> > management.
> 
> My position on NETCONF extensions is clear:
> 
> Vendors should develop extensions on their own, in running code,
> and get some operators to use them.  When you have some
> deployment experience with the extension, then propose it
> as a standard.  In my experience, if a "feature" is important
> enough, vendors will provide it to customers, regardless of any standard.
> 
> <config-rant>
> 
> Notifications got grandfathered in because they were in the original charter.
> After that, we will be working on standards based configuration
> or nothing at all.
> 
> Our focus is standards based configuration, a subject some
> vendors seem to want to leave as "TBD".  Anybody who understands
> embedded agent design knows why --  it is a non-trivial matter
> to support multiple incompatible configuration APIs
> (e.g., proprietary and standard), unlike multiple incompatible
> monitoring APIs.  The problem is not "special RPC" vs. "data model" at all.
> 
> 
> Unfortunately, the current process and mindset for IETF data models (MIBs)
> is never going to work for configuration.  Somebody is
> going to have to figure out how to remove 1 of the 2 adjectives
> ('multiple' or 'incompatible').  Maybe this is a topic for the NMRG.
> 
> </config-rant>
> 
> 
> > 
> > 
> > ---------------------------------
> > Michael Hare
> > NMI Engineering
> 
> Andy
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>