Subject: [OPS-AREA] OPSAREA - preliminary minutes of the Hiroshima session uploaded

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Dec 2009 14:18:38 +0100

I have uploaded the preliminary minutes of the OPSAREA open meeting in
Hiroshima. Please read and send me any correction or supplementary
information that I may have missed. 

http://www.ietf.org/proceedings/09nov/minutes/opsarea.txt

Thanks and Regards,

Dan

---

From: "David Harrington" <[email-masked]>
Date: Wed, 2 Dec 2009 13:23:38 -0500

Hi,

There are a few points I think did not get properly represented in the
minutes.
The audio archive recorded what was actually said.

Dave H. Why is OPSAREA needed? OAM is done in many several groups
forum. We have little real discussions.

more accurately: I think it might help if we tried to drive some
discussion in the OPS area. I am beginning to question what the OPS
area is doing in the IETF now. Operators don't come to the IETF
meetings very often. As we move to the multi-protocol NM model, lots
of OAM work is being done elsewhere in the IETF. If we don't do
operations, and management moves elsewhere, I am not sure what the O&M
area is for.

and ...
Dave H. There could be issue, OPSWG is where multi-protocol issues are
discussed without real plan/framework. We need to decide whether we
want to push YANG. We need to push this stuff. My company is looking
at it. 

more accurately: 
Dave H: The OPSAREA session could identify an issue that should be
discussed. For example, what does the community want to do about this
emerging multi-protocol management approach? We should get some debate
going. Right now, there is no discussion going on. 
Dan R: Discussion has been limited because we needed to get some
pieces into place. Now that we have RFC5706 Guidelines, and YANG and
the YANG architecture moving forward, we are in a better position to
discuss multi-protocol management. This type of discussion is value
that the OPS area can bring to the IETF. The OPSAWG WG has started to
work on these directions; we still have work to do.
Dave H: I think there are a few important issues we should be
discussing, probably in the OPS open area meeting. The OPSAWG WG is
defining how protocols should work together, such as syslog and SNMP.
But this work is being done piecemeal without any framework or real
plan about where we are going with this. YANG is about to be submitted
for standards track. I think we need a discussion of whether we want
to start encouraging other WGs to develop YANG models or not. I
haven't seen that discussion except in the Netconf and Netmod WGs,
where there is not surprisingly some bias on that question. We need to
have some of those discussions and they are not being driven in the
OPS area. My company is becoming concerned about the (lack of)
relevance of the work going on in the OPS area.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Wednesday, December 02, 2009 8:19 AM
> To: OPS Area (E-mail)
> Subject: [OPS-AREA] OPSAREA - preliminary minutes of the 
> Hiroshima sessionuploaded
> 
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Dec 2009 13:30:58 -0800

> Hi,

Sounds interesting.  Sorry I missed the meeting.
I thought the OPSAWG was just odds and ends that
would otherwise fall though the cracks and not get done.

Until YANG is published as an RFC, it is not really relevant
to other WGs besides NETMOD.  The challenge (perhaps for the OPSAWG)
is to create and execute a coherent development plan for a
standard framework (IF-MIB, ENTITY-MIB, etc.).

The NETCONF WG lost its operator focus, and therefore
lost its operator co-Chair.  The focus was supposed
to be on configuration, but the notification work
was done instead.

I am not convinced that the mere publication of YANG will
produce any standards-based configuration of
any real networking devices.  That is going to require
agreement on core YANG modules that build on existing
IETF standards, not the ad-hoc reinvention of every
SNMP or CLI data structure ever written.

IMO the IESG should have a 5 year plan for success, and it is not met,
then the IETF should officially give up on network configuration.
The lack of any real commitment by the IESG to either NETCONF or SNMP
(for this function) is not helping.

Andy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 2 Dec 2009 17:18:02 -0500

Hi Andy, 

> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Wednesday, December 02, 2009 4:31 PM
> To: David Harrington
> Cc: 'Romascanu, Dan (Dan)'; 'OPS Area (E-mail)'
> Subject: Re: [OPS-AREA] OPSAREA - preliminary minutes of the 

I believe that is accurate. 
I think the OPS area needs to drive the discussion of multi-protocol
management and whether YANG should be promoted by the area to other
areas of the IETF.
I don't have a problem with the OPS area deciding that the OPSAWG is a
good place to assign the deliverables for multi-protocol management.
I do have a problem with the odds and ends in OPSAWG driving the
direction of the OPS area.

> then the IETF should officially give up on network configuration.

I don't agree with that sentiment.
First I think the IAB should make a recommendation about architectural
directions for network management.
The 2002 workshop did that to a degree, and the result was to
implicitly endorse using multiple protocols.
I think the IETF (not just the IESG) needs to discuss a coherent plan
for moving to a multi-protocol framework.
I think the OPS area should help drive that discussion.

The 2002 workshop named certain specifics, and Netconf met the goal of
an XML-based configuration protocol.
Maybe it's time for IAB to hold another workshop and get feedback,
especially from operators, about where the IETF seems to be going and
whether operators think we are heading in the right direction by
expanding the nature of IETF OAM and moving significant portions of
the OAM work into other areas of the IETF.

Configuration is obviously a very dfficult problem, partly because we
have a moving target. 
The Internet keeps changing and we need to keep up with the changes
(albeit with some necessary delay).
The IETF already has over 100 RFCs that deal with "configuration".
I think the fact that "OAM" is being addressed in areas other than OPS
reflects that OPS has had a long tendency to have a singular view of
what OPS and management means, and that may not match the operations
perspective of the industry.

Tena Tsou recently published a draft about configuration. I don't
think the draft was very well written, but hidden in the draft was an
important point - many vendors in the telecomm industry are moving
toward an all-IP strategy. Telecom networks, such as LTE, will build
atop the Internet, and need some standardzied, automated configuration
management. 

The discussion about declaring COPS-PR Historic raised an interesting
point. Cable modems and other equipment will build atop the Internet,
and need configuration using some type of automated, policy-based
management. 

Do we really believe that Netconf and SNMP address those configuration
needs adequately? I don't see either being adequate to handle
automated policy-based configuration. Are we even working on that
problem in OPS?

> (for this function) is not helping.

I don't think IESG commitment is that important. I think market
commitment is important. I think addressing real market needs is
important. I think we need to start the discussion to understand what
the emerging needs are so we can begin to address them.

> >> I have uploaded the preliminary minutes of the OPSAREA open
meeting
> > in

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Dec 2009 15:12:07 -0800

David Harrington wrote:
...
> the emerging needs are so we can begin to address them.

Why would the market gravitate towards a standard
that is just standard operations on proprietary
data models?

That is what I meant by a 5 year plan.
Is there going to be any standard data models
(like ipfix-psamp.yang) actually deployed?
If so, is there some coherence to the collective
set of YANG modules published by the IETF?

If a domain-specific WG like IPFIX WG needs common
data modeling components (like an interfaces table),
then are they going to wait for that work, do it themselves,
invent some interim hack, or what?

Isn't it up to the IESG to make sure the protocols they
approve have some development plan, or at least a stated direction
wrt/ protocol work being deployed over a long period of time?

The market is already using SNMP and NETCONF for
proprietary data models.  Nobody needs YANG for that.
Now that the IETF is developing YANG, there is some
expectation that the IETF will do something with it.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 03 Dec 2009 10:44:25 +0100

Hello,
I agree that we need this debate. actually we have had a very similar 
debate internally within my company.

As I see it we are already live in a multi-protocol OAM world, that has 
been decided by the market.
IMHO there should be a set of recommended protocols that any WG/protocol 
developer in IETF should use for configuration/logging/performance 
management/ fault management.
All draft authors should have a good reason if they want to use 
something else.
An interesting point would be addressing/naming. As I see it 
configuration is heading for Netconf while fault management is using 
SNMP. These have very different naming systems.
I have the basic use case:  I get an alarm/trap about some resource in 
my node. I want to check the configuration/status of the resource, 
however I can't just copy the SNMP OID into a get/subtree-filter of a 
Netconf message. So what is the recommended way?

I fully agree with Andy, that to make YANG/NETCONF work we will need 
some basic stuff, like MIB2 system branch, interface tables, else? This 
would be work for the OPS area.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 3 Dec 2009 11:37:21 +0100

Thanks. I will make these corrections, and also try to find time to
listen to the audio feed to correct other misses. In the meantime any
other corrections based on audio or on personal memories of what was
said in the meeting are welcome. 

Regards,

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Wednesday, December 02, 2009 8:24 PM
> To: Romascanu, Dan (Dan); 'OPS Area (E-mail)'
> Subject: RE: [OPS-AREA] OPSAREA - preliminary minutes of the 
> There are a few points I think did not get properly 
> represented in the minutes.
> Dave H. Why is OPSAREA needed? OAM is done in many several 
> groups forum. We have little real discussions.
> 
> more accurately: I think it might help if we tried to drive 
> some discussion in the OPS area. I am beginning to question 
> what the OPS area is doing in the IETF now. Operators don't 
> come to the IETF meetings very often. As we move to the 
> multi-protocol NM model, lots of OAM work is being done 
> elsewhere in the IETF. If we don't do operations, and 
> management moves elsewhere, I am not sure what the O&M area is for.
> 
> and ...
> Dave H. There could be issue, OPSWG is where multi-protocol 
> issues are discussed without real plan/framework. We need to 
> decide whether we want to push YANG. We need to push this 
> stuff. My company is looking at it. 
> 
> more accurately: 
> Dave H: The OPSAREA session could identify an issue that 
> should be discussed. For example, what does the community 
> want to do about this emerging multi-protocol management 
> approach? We should get some debate going. Right now, there 
> is no discussion going on. 
> Dan R: Discussion has been limited because we needed to get 
> some pieces into place. Now that we have RFC5706 Guidelines, 
> and YANG and the YANG architecture moving forward, we are in 
> a better position to discuss multi-protocol management. This 
> type of discussion is value that the OPS area can bring to 
> the IETF. The OPSAWG WG has started to work on these 
> directions; we still have work to do.
> discussing, probably in the OPS open area meeting. The OPSAWG 
> WG is defining how protocols should work together, such as 
> syslog and SNMP.
> But this work is being done piecemeal without any framework 
> or real plan about where we are going with this. YANG is 
> about to be submitted for standards track. I think we need a 
> discussion of whether we want to start encouraging other WGs 
> to develop YANG models or not. I haven't seen that discussion 
> except in the Netconf and Netmod WGs, where there is not 
> surprisingly some bias on that question. We need to have some 
> of those discussions and they are not being driven in the OPS 
> area. My company is becoming concerned about the (lack of) 
> > Subject: [OPS-AREA] OPSAREA - preliminary minutes of the Hiroshima 
> > sessionuploaded
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Dec 2009 11:59:28 +0100

On Wed, Dec 02, 2009 at 11:18:02PM +0100, David Harrington wrote:
 
> I don't agree with that sentiment.  First I think the IAB should
> make a recommendation about architectural directions for network
> management.  The 2002 workshop did that to a degree, and the result
> was to implicitly endorse using multiple protocols.  I think the
> IETF (not just the IESG) needs to discuss a coherent plan for moving
> to a multi-protocol framework.  I think the OPS area should help
> drive that discussion.

Is there an operator here who knows an operational network that is
managed by _only_ a single protocol? It could be that operators left
because of a disconnect from the real world...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 3 Dec 2009 12:09:31 +0100

Thanks, Balazs for changing the subject line. I suggest that we continue
this very important discussion under this subject, and leave the minutes
comments only be discussed under the older one.

More in-line. 

Dan

> [mailto:[email-masked]] On Behalf Of Balazs Lengyel
> Sent: Thursday, December 03, 2009 11:44 AM
> To: Andy Bierman
> Cc: 'OPS Area (E-mail)'
> Subject: [OPS-AREA] OPSAREA strategy [was: Re: OPSAREA - 
> preliminary minutes of the Hiroshima sessionuploaded]
> 
> Hello,
> I agree that we need this debate. actually we have had a very 
> similar debate internally within my company.
> 
> As I see it we are already live in a multi-protocol OAM 
> world, that has been decided by the market.
> IMHO there should be a set of recommended protocols that any 
> WG/protocol developer in IETF should use for 
> configuration/logging/performance management/ fault management.
> All draft authors should have a good reason if they want to 
> use something else.

Until a few years ago the IESG was mandating that all WGs in the IETF
develop MIB modules for management. The results were mixed. A few WGs
developped MIB modules and they ended by being used. Other ignored the
IESG recommendation, or postponed writing the MIB modules, or did not
have enough MIB experts to write them and they were never written. Many
other WGs developped MIB modules (better or worse quality, smaller or
larger or huge) who were never used. The worst that happened in some
cases was that because of that directive some WGs did not think about
operational requirements and manageability, and did not bring the tools
used in real networks into the IETF standards track. Why do it if all
IESG was asking is writing a MIB module (actually a 'write a MIB module'
bullet in the WG charter)? 

Life was stronger than IESG directives and the IESG abandoned this
requirement a few years ago. The current requirement is that any
technology standardized in the IETF be managed, and that the
manageability considerations be documented and desirably standardized
using protocols and data modeling language from a standards toolkit.
This is documented to a certain extent in RFC 5706, but the IETF
community could not reach a consensus to make this a BCP, so it was
approved as Informational, at least at this phase. 

Operators will eventually use the tools that make sense for their
networks. The OPS area can make a great service to the community by
listening to operator needs and developing these tools and by
documenting what is available and how they are to be used. 

> configuration is heading for Netconf while fault management 
> is using SNMP. These have very different naming systems.
> I have the basic use case:  I get an alarm/trap about some 
> resource in my node. I want to check the configuration/status 
> of the resource, however I can't just copy the SNMP OID into 
> a get/subtree-filter of a Netconf message. So what is the 
> recommended way?
> 
> I fully agree with Andy, that to make YANG/NETCONF work we 
> will need some basic stuff, like MIB2 system branch, 
> interface tables, else? This would be work for the OPS area.
> 
> Balazs
> 
> 
> 
> > Why would the market gravitate towards a standard that is just 
> > standard operations on proprietary data models?
> >
> > Is there going to be any standard data models (like 
> ipfix-psamp.yang) 
> > actually deployed?
> > If so, is there some coherence to the collective set of 
> YANG modules 
> > published by the IETF?
> >
> > If a domain-specific WG like IPFIX WG needs common data modeling 
> > components (like an interfaces table), then are they going 
> to wait for 
> > that work, do it themselves, invent some interim hack, or what?
> >
> approve have 
> > some development plan, or at least a stated direction wrt/ protocol 
> > work being deployed over a long period of time?

It is first of all to the NETMOD WG to finish the YANG definition work
:-) Then to assist IPFIX as this is probably the first 'customer' in the
IETF planning to make serious use of YANG. There will be more. If these
efforts will be successful the IESG may be convinced to turn the usage
of NETCONF or YANG into a recommendation for specific cases, but
direction statements alone are not sufficient. We are the IETF - running
code is our supreme arbiter. 

> >
> > The market is already using SNMP and NETCONF for proprietary data 
> > models.  Nobody needs YANG for that.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 3 Dec 2009 12:04:03 -0500

Agreed.

Some operators told us there was a disconnect.
So we deliberately sought feedback from a wide range of operators and
found agreement there was a disconnect.
And we are moving to a multi-protocol approach because operators told
us there was a disconnect.
We also got some suggestions about how to proceed to close the gap
between operators' needs and IETF NM solutions.
But the operators haven't come home yet ...

The IETF is now faced with a problem. We now have multiple protocols,
and most defined their own information models, data modeling language
and data models, and we are not sure how to correlate information
available from different protocols. And while some in the IETF think
that is an important problem to resolve, and standardization is the
obvious answer, real world operators have been using multiple
protocols successfully without vendor-neutral standards for
cross-protocol correlation. 

Prior to the 2002 workshop, the OPS area led an effort to meet with
operators at operator forums, such as NANOG.
I recommend the OPS area drive an effort to get operator feedback
again.
Let's get some feedback on IETF NM work since 2002, get suggestions
from operator experience on whether and how to standardize information
across multiple NM protocols, be sure we understand operators' needs
in today's networks,
and get some suggestions for operators' emerging needs that the IETF
could better address over the next five to ten years.

Let's be sure we don't move down the disconnect road again.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, December 03, 2009 5:59 AM
> To: David Harrington
> Cc: 'Andy Bierman'; 'OPS Area (E-mail)'

---

From: Andy Bierman <[email-masked]>
Date: Thu, 03 Dec 2009 09:51:47 -0800

> Let's be sure we don't move down the disconnect road again.

I agree another workshop would be useful, but I think
many issues are being addressed by NETCONF and YANG.
I prefer to just get more work done that we know
needs to be done.

The NETMOD WG has been working with the IPFIX WG and
their development of the ipfix-psamp.yang data model
has been very helpful in determining requirements
for 'real-world' domain-specific models.  It will
be interesting to compare configuration of IPFIX
via CLI vs. SNMP vs. NETCONF/YANG and evaluate the
strengths and weaknesses of each one.

My original comment (as Balazs understood) is that
we do not have any YANG infrastructure in place so
domain-specific WGs like IPFIX have a reasonable
chance of success using NETCONF/YANG.  Hopefully,
this work will begin as soon as YANG is approved:
    * system group
    * interfaces group
    * entity group
    * access control model

It took many years to agree to each one of these bullets
for SNMP.  I am not patient enough to spend the
next 20 years reinventing what SNMP already standardized
over the last 25 years.  Others are looking forward
to starting from scratch.  That is why I think rough consensus
on a 5 year multi-protocol development plan would help.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 3 Dec 2009 19:05:07 +0100

> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Thursday, December 03, 2009 7:52 PM
> To: David Harrington
> Cc: 'OPS Area (E-mail)'
> Subject: Re: [OPS-AREA] OPSAREA strategy
> 
> David Harrington wrote:
> > Agreed.
> > 
> > in today's networks, and get some suggestions for 
> operators' emerging 
> > needs that the IETF could better address over the next five to ten 
> > years.
> > 
> I agree another workshop would be useful, but I think many 
> issues are being addressed by NETCONF and YANG.
> I prefer to just get more work done that we know needs to be done.
> 
> The NETMOD WG has been working with the IPFIX WG and their 
> development of the ipfix-psamp.yang data model has been very 
> helpful in determining requirements for 'real-world' 
> domain-specific models.  It will be interesting to compare 
> configuration of IPFIX via CLI vs. SNMP vs. NETCONF/YANG and 
> evaluate the strengths and weaknesses of each one.
> 
> My original comment (as Balazs understood) is that we do not 
> have any YANG infrastructure in place so domain-specific WGs 
> like IPFIX have a reasonable chance of success using 
> NETCONF/YANG.  Hopefully, this work will begin as soon as 
> YANG is approved:
>     * system group
>     * interfaces group
>     * entity group
>     * access control model
> 
> It took many years to agree to each one of these bullets for 
> SNMP.  I am not patient enough to spend the next 20 years 
> reinventing what SNMP already standardized over the last 25 
> years.  Others are looking forward to starting from scratch.  
> That is why I think rough consensus on a 5 year 
> multi-protocol development plan would help.
> 

Let us be a little bit more specific here. 

How would such a 5 year plan look like? What would it include? What is
the framework and the community it needs to get consensus from? 

Dan

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 03 Dec 2009 10:06:46 -0800

> cross-protocol correlation. 

Since the core reason for trying to have a single standard for a single function 
is to avoid the NxM combinatorial explosion problem, the obvious question is why 
operators haven't been enthusiastic about simplifying their data modeling world?

One possibility is that the real-world locus of control rests with the vendors 
of the different models.  Hence, the operators really cannot influence things. 
To some extent, getting a critical mass of operators to band together might be 
able to change the dynamic.

Another is that they have enough history making parallel specifications work 
that they are used to it.  This is where an extremely strong and pragmatic value 
proposition might make a difference.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Michael MacFaden <[email-masked]>
Date: Thu, 3 Dec 2009 10:29:22 -0800

>From: [email-masked] [[email-masked]] On Behalf Of Balazs Lengyel [[email-masked]]
>Sent: Thursday, December 03, 2009 1:44 AM
...
>SNMP. 

I agree with this observation.

>These have very different naming systems.

Indeed.

We have seen internet standard data model be extended to report names from
other data models -- case in point IF-MIB rfc 2863 section 3.1.5 on ifName.

In other cases what I have done for vendors is to update their enterprise mib modules
DESCRIPTIONS, to show how to poll for state using whatever the vendor would
prefer operators to use. 

Mike MacFaden
VMware Engineering, Palo Alto, CA

---

From: Michael MacFaden <[email-masked]>
Date: Thu, 3 Dec 2009 10:42:36 -0800

>From: [email-masked] [[email-masked]] On Behalf Of Dave CROCKER [[email-masked]]
>of the different models.  

Yes, vendors with market share.

>Hence, the operators really cannot influence things.

When management standards becomes a become a barrier to entry to the market vendors will comply.
Cable networks  like [Euro]DOCSIS  or US Gov't come to mind.

Till then we'll live with one or more vendors in various market segments making decisions.
Which by the way creates significant revenue for system integrators to hook up
management platform version Y to device/application version Z.

Having been involved with the enterprise server market/virtualization the past few years, 
was entertaining to see all the new proprietary management protocols built on top of standard 
transports and encoding schemes following very loosely from 'standard' data models from 
other non-IETF organizations.

Mike MacFaden

---

From: Andy Bierman <[email-masked]>
Date: Thu, 03 Dec 2009 11:03:17 -0800

> the framework and the community it needs to get consensus from? 

IMO, real coordination between the current data silos
is unrealistic, but if there is any real need then
spot solutions will crop up, like the Syslog over SNMP spec.

The issues important to me:
   - 5 year plan to publish all the infrastructure modules listed above
   - SYSLOG over NETCONF -- SYSLOG notification stream (is this needed?)
   - multi-protocol NETCONF database access and locking
   - YANG Doctors (pro-active training and early review)
   - YANG++ solutions planning (more OO features in YANG)
   - operator feedback and course correction

The plan would establish that there is rough consensus
on this approach, and there are people willing to do the work
needed to get the job done.  Currently, the market has no
idea what to expect from the IETF wrt/ network configuration.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 03 Dec 2009 12:20:25 -0800

Dave CROCKER wrote:
> Since the core reason for trying to have a single standard for a single
> function is to avoid the NxM combinatorial explosion problem, the
> obvious question is why operators haven't been enthusiastic about
> simplifying their data modeling world?
> 

job security.

The current approach (mostly CLI) is ad-hoc and not very
automation-friendly.  Operations automation is controlled
by Unix scripting wizards (and/or kiddies), and it's
probably in-house, poorly documented, and poorly maintained.
It is certainly proprietary, and probably too expensive.
That's the POV of the managers.  To the actual operators,
the current situation is just fine.

The costs related to moving away from this sort
of system (to anything else) are huge,
especially since the very people who need
to execute the transition do not think there is
any need for change.

The costs related to being locked in to such a system
are not as obvious, but people are starting to figure it out.

> One possibility is that the real-world locus of control rests with the
> vendors of the different models.  Hence, the operators really cannot
> influence things. To some extent, getting a critical mass of operators
> to band together might be able to change the dynamic.
> 
> Another is that they have enough history making parallel specifications
> work that they are used to it.  This is where an extremely strong and
> pragmatic value proposition might make a difference.
> 

Free software certainly influences what operators
use to do their job, and that aspect is very positive
and getting better all the time.  Operators use tools,
not standards.

Andy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 4 Dec 2009 19:30:53 +0100

Hi All,

I have a few questions which rack me a long time 
already. Since I have experience with and connections 
to different SDOs like 3GPP and TM Forum my main 
concern is interoperability and enabling the industry-
wide usage of IETF MIBs and YANG modules.

Here are some questions I find interesting to 
consider:

- Do we want to stay in our isolated management 
world or should we make our models available also
for SDOs, which use other modeling languages?
How does an inter-SDO model inter-operability 
looks like?

- What about getting our future modeling language 
(and models) aligned or easily mappable to other 
existing modeling languages (models)?

- Do we need to align our modeling language features 
with languages from other SDOs for easy mapping of 
the models or transforming from one format to the 
other?
- How about inheriting a class from an existing model
instead of defining every resource object ourselves
in a YANG modul?

- Which strategy should be followed if TM Forum wants 
or just starts incorporating the content of IETF 
MIBs or YANG modules into SID?
- Should this be developed in a joint team with TM Forum 
or are we against such an adoption of MIB or YAM 
contents into the TMF information model?
- If we allow this who does maintain such a information 
model in the future, TMF or IETF?

- Obviously TMF SID has an industry momentum currently
since it is "trying" to cover all network types and enables 
information exchange between them.
AFAIK operators want to have an e2e management view and 
exchange of management information even between a 3G mobile 
network and an ethernet network.

- So my main concern is that our management framework is 
not well prepared for management interoperability between 
networks.
- The feedback I get from people in other SDOs is that 
they don't understand ASN.1 and avoid reading it. They 
rather prefer using UML-based models and tools.

- I believe future YANG modules of IETF should be made 
available for the wide industry usage also for those,
who are working UML-based and translate everything into 
their own language first.

Cheers,
Mehmet

> [mailto:[email-masked]] On Behalf Of ext 
> Romascanu, Dan (Dan)
> Sent: Thursday, December 03, 2009 7:05 PM
> To: Andy Bierman; David Harrington
> Cc: OPS Area (E-mail)