OPSAWG meeting notes
IETF 75, Stockholm, July 29


1. Welcome and agenda bashing

Dan Romascanu: 
Scott cannot join physically to chair the session.
Dan and Ron sit in for Scott.
No requests for changing the agenda


2. WG status

Dan:
Documents in or after IETF last call:
  - mapping SNMP to Syslog
  - mapping Syslog to SNMP
  - SMI datatypes in XML
New revisions are needed for all of them.

Milestone review:

There is an open milestone on a template for generic management data models. There is no progress on this. It might be the right  idea to take it off the charter. 

David Harrington: 
There is a need for this document. because people are defining 
data models in several WGs. We have ideas what to write but did 
not yet find time for doing so. It is not much work to be done.

Dan: 
Do we have enough background in everything now that we can produce the document in the first place?

David Harrington: 
I believe so yes.  The document has most of the components that it needs now.  Many of the boiler plates just need updating to be "more generic".  Much of the document is very MIB-worded and could use some generic wording replacements.

Dan Romascanu: 
We have a lot of common and agreed-ed upon text about MIB modules, etc.  I'm not sure that agreement exists about common information models.

David Harrington: 
That's probably true.  It was decided to put the document templates on the tools page and the document should just point to the tools page.  That's probably what needs to be done for a generic management model as well in order to keep it current. Other WGs are possibly going to create various boiler plates (syslog, yang as EGs) and I do believe there is a lot of common text there.


Juergen Schoenwaelder:
I prefer to have separate documents for different cases in different working groups. The major issues are specific to the respective topic. Yang, syslog and IPFIX, for example, rather  need individual templates that need to be developed in the respective WGs.

David:
The document I am thinking of would point to individual templates. It would not be a one for all solution ,but would help people finding the right template zo use.

Dan:
We have the tools page for that purpose.

David:
People do not find it on the tools page.

Wes Hardaker:
This would be an RFC with almost nothing in. I'm not sure this is the right way to go. RFCs are not the index where anybody starts looking.

Ron Bonica:
I agree to Wes. We don't need the authority for the IETF for pointing
people to tools. The tools page is the right place for an index.

David:
When we wrote the charter, the tools page was much less used.

Dan:
We don't have consensus for removing the item from the charter.
I will try to draft an alternative and post it in the mailing list.

David:
If we do this, the result would need to go to the tools page.

Juergen Schoenwaelder:
You may ask for consensus if this should remain as a chartered item
with an RFC deliverable in this WG.
.
Dan: question: "do we want to continue the template for generic data model management as a chartered item in this working group"?

Dan:
Please show hands.
0 hands in favor
6 hands against

David: the other question to ask is whether anyone wants to work on the individual templates, or maybe each WG should do that
    
Dan: 
lets ask each WG first

David: people aren't asking questions about the MIB template, are they even being used or?

Dan: 
they're definitely being used but the questions are likely going to the ADs since we're getting questions about it.

Juergen: 
smidump is able to generate security considerations boilerplate tex from a MIB module and it is easy to extend this further to generate a whole document template from a MIB module; but all this is for me a tools issue.

3. Operations and management drafts
   (draft-ietf-opsawg-operations-and-management)
   (draft-ietf-opsawg-survey-management)
   
David Harrington (see slides):
There is a survey document on which the WG needs to decide what to
do with it. 

Juergen: 
this is an ever changing list of TCs and this is a dynamic list.  Why would this document need to be written.  I don't think we should cast constantly changing things as RFCs.

David: 
this document was also started long before the improved IETF tools pages.  I agree that it may be this is better as a wiki document

Dan: should we ask for a consensus call on this?

David: 
there are a number of MIBs that no one ever does anything with, should they be listed?  I don't think so.  People don't tell us when MIBs are being used.  There is a question about what the purpose of the document is.  The document also says COPS-PR is not recommended, but I'm aware of at least one
implementation exists so I'm not sure it's wise.

Ron Bonica: 
What is the intended status of the operations and management
document?

David:
BCP.

Ron:
This might be a problem because of the comments we received recently. We should rather consider making it informational.

discussion about BCP vs informational.  Summary: a BCP is more of a club and an informational is more of a guideline
 
Joel Yagely: 
there are places in BCP where we say things like "we don't like things but we're going to do it anyway".  We live in the real world.
 
David:
this document is designed to be a large piece of wood.  You could wield it as a club, but it's not designed to be a club.
 
Ron: 
by labeling it as a BCP it's wood and can be used as a club.  By labeling it as informational, it becomes a nerf weapon.

Dan:
This is an important question that needs to be clarified soon. Proposal to change of the intended status to informational. Revised I-D including some changes would follow if agreed.


4. Lock MIB
   (draft-meng-fan-lock-mib-01)

Washam Fan (see slides):
The purpose is monitoring locks.

Dan: 
Are there comments from people involved in Netconf.

Wes:
Locks are unfortunately necessary. 
It this seems to be good and useful work.
It will not be able to implement the locks easily. 

David Partain:
I'm not sure we should mention cops-pr because it isn't relevant any longer.

Juergen Schoenwaelder:
There are not just locks from COPS-PR and other IETF protocols. There are many other locks involved. Therefore, I have a problem with the use case. Developers will find it hard to check this MIB when observing a problem.

Balazs:
How do we indicate the scope of the locks?

Washam:
The scope is described in the respective standard defining the lock.

David Harrington:
Each protocol has different ways of defining the scope of a lock.
This needs to be shown in a different table outside of this MIB.

Dan: 
let me share a concern as an AD: when you tell me this is just monitoring what locks are on the device, I'm fine and understand the scope.  When we start dealing with extensibility and protocol information I start being more concerned.  If this is possible new work I'll probably ask for a minimal scope.

David Harrington:
The SNMP stack will not have much insight in what is going on
in the netconf stack. This would be very difficult to implelement,
because all stacks need to interact or all protocols need to be
consulted. I like to suggest a new work item for this WG. If people think that
COPS-PR is a dead protocol, then let's obsolete it.

Dan: 
Will you write an Internet draft on "COPS-PR is dead"?

David Partain:
Is that the way it is done?

Ron:
Yes.

David Partain:
I would support it.

David Harrington:
Then we should include SNMP-CONF.

Scott Bradner supporting this via Jabber.

Bert Wijnen:
This may be a waste of resources. It costs a lot of time in
the past to go this way for other documents.

Ron:
I like to give it a try for finding out it is still difficult.

Dan: 
Ron will sheperd the document :)

David Partain:
Having COPS-PR historic would also save time in the future,
because our documents would not anymore need to reference it.

Juergen Schoenwaelder:
COPS-PR is a target worth trying it. It has more relevance
than just a single MIB module.

Scott:
It will be a lot of work.

Dan:
As technical contributor, I would also support this effort.

Wes:
Even if we put COPS-PR to historic, we would still need to
refer to it in some documents, because it will still exist.

Bert:
We already stopped WGs doing PIB modules because they heavily
overlap with MIB modules.

Scott:
ITU-T anmd 3GPP are still using it.

Bert:
We went there and explained the situation. 3GPP guys are still writing PIB modules.

David Harrington:
One big problem with COPS-PR is that it has a global lock. This blocks even CLI. In such a case the LOCK MIB would be a  useful means for identifying the lock blocking other means.

Dan:
Who in the room is in favor of working on the LOCK MIB in the opsawg
4 hands in favor
0 hands against
We will take this to the list.

About cops-pr historic, whoever wants to do that should make a proposal document.



5. SNMP Lock
   (draft-fan-meng-snmp-lock-00)

Washam Fan (see slides):
We should extend the Lock MIB to manipulate SNMP locks.

Juergen Schoenwaelder:
What is being locked? What is the scope?

 Washam: 
The instrumentation itself

Juergen: 
The time it takes to process a set doesn't depend on the msg size.  the motivation section needs to be changed.

 Ron:
 How many believe this should be taken as an item?
 For: 3, against: 0
 Not many again, lets take it to the list.


6. OAM definition draft
   (draft-andersson-mpls-tp-oam-def)
   
Loa Anderson:
In MPLS-TP the term OAM is heavily used, but with probably different meanings. This is a document defining this term. It?s scope is beyond the MPLS-TP, wider-IETF

Ron:
How many think it should be a WG item?
3 in favor
0 against

Dan:
This has already been on the list for consensus. Another  week of mailing list comment chance, otherwise he can go ahead, and Loa can re-submit as draft-ietf-opsawg

Loa: 
There will be some other edits. 


7. Power Monitoring

Juergen Quittek (see slides):

Scott Bradner: 
Is the MIB read-only?

Juergen Quittek: 
No MIB by now, informational presentation, t's not the time to decide on that now

Scott: 
How does this relate to the smart grid work?

Juergen Quittek: 
It may be a component, but i think smart grid requires much more (like scheduling power production and consumption). I think it's slightly related but not strongly.

Dan Romascanu: 
Speaking as a contributor: there are a bunch of organizations working on this which is what makes it hard.  They may have MIBs as well and this might interfere. As an AD: I think we need to see an ID to see the scope of what is being suggested.

Juergen Quittek: 
This isn't a chartering request at this time; I just want to bring awareness and want to see who is interested in working on this?  Is this the right organization?

Scott Bradner: 
Smart-grid includes remote monitoring AND remote control

Juergen Quittek: 
I agree but I don't see that as the core issue.


David Harrington: 
I'm having a problem seeing what we could do in the opsawg about this.

Juergen Quittek: 
I'm not necessarily sure this is the right group to do it either.

Juergen Schoenwaleder: 
I reserved a 10 minute slot tomorrow in OPSAREA to discuss low-power stuff from 6lowpan.  They're considering using SNMP.
   
Ron Bonica: 
I could see a number of interesting MIBs written toward this goal.  Another thing worth monitoring might be the heat thrown off.


Juergen Schoenwaelder: 
The nice thing would be to know who would be implementing it.

David Harrington: 
There are certain types of things that should not be included in a MIB module. People are mentioning things like (was it standard deviations ?).  Values that can be derived from other values should not be included in a MIB module. The goal should be to keep the agent simple, and move any derivable calculations to the manager application.

Juergen Schoenwaleder: 
The MIB needs to be easy to implement.  State and duration is the easiest to implement.

Wes: 
As vendor I can confirm that the need is out there ? wee see demand.
 

   
8. Virtual Network Management Information Model
   (draft-okita-ops-vnetmodel-00)

Hideki Okita (see slides):
For virtual networks we need a data model for describing  relationships between virtual and physical networks and  for describing connections between virtual entities.

Juergen Quittek:
Is it for data centers only or applicable to general networks?

Hideki:
Also application to general networks should be possible.

Dan:
Who has read the draft?
(no hands showed up.)
It is too early to ask for WG adoption. Let's continue the discussion.


9. The Management Model of the Centralized Network Architecture
   (draft-richard-opsawg-cna-mib-00)

Richard Yang (see slides):
Suggest a generic management model.

Dan:
Please check everybody, if this is useful work for operators. Too early to talk about adoption by WG, needs to be continued on the list.