Subject: [nmrg] Minutes of the OPS Area open meetings in Prague - draft 2
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "IETF MIBs" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Thu, 29 Mar 2007 14:19:54 +0200
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

I have included notes taken by Dave Harrington at the first meeting. 

I would welcome more comments and corrections before we turn these into the official version. 

Dan

-------------------------------------------------------------------------------

Meeting 1 - Monday March 19, 2007 15:20 to 17:20 

1. Meeting Administrivia

2. Introduction of new Area Director - Ron Bonica 

Dan - thanking David Kessens for his years of service as Area Director

3. Mini-BOF A: - Manageability and Operational Guidelines - David Harrington 

http://www3.ietf.org/proceedings/07mar/slides/opsarea-1.ppt

Discussions about the structure of the document - should the protocol evaluation be part of the document? 

4. Mini-BOF B: COPS push mode policy configuration - Tom Taylor and Tina Tsou  

http://www3.ietf.org/proceedings/07mar/slides/opsarea-3.ppt

Sharon Chisholm: why COPS? because COPS is (apparently) going away 
Unidentified : working at the ITU-T, still some interest 
Kevin Johnson: in the draft, not quite clear if a new message was used.
Tom: draft proposes a new message but could also use a flag, which is the less violent solution. Discussion of the collision of handles
Dbh: there are two questions to answer.
question 1: is COPS going away? Worth it? Little update in the industry. Should this be part of the manageability work (his mini-BOF)? Should we move COPS to experimental or not recommended? question 2: technical decision whether change is the right one?
Scott Bradner: Answer Dave's first question. some enthusiasm for COPS at the  beginning, then faded away. Interest in ITU. The ITU-T is using a few protocols including DIAMETER and COPS from the IETF that require some extensions. If another non-IETF group wants to use COPS, why stand in their way?
Dave: "I can agree with that; somebody once said that the IETF doesn't produce standards, but technologies; other organizations produce standards"
Dan (to Tom): what is your preferred solution? 
Tom: A standard document with the COPS update . ITU and IETF would progress this in parallel (approve in ITU-T as an annex), and then have IETF (tweak and) approve it, and then update ITU-T to reference the RFC.
Scott: This parallel approach has been problematic in the past. It should either be done in ITU or in IETF, but not both.
Tina: I think this can be done
Dan: another approach is that the ITU-T can publish an Informational document. I do not want to take a position at this point. ITU should also consider what happens
Dave Partain: I think there will be little energy to do this in the IETF, so it should be done in ITU.
Bert: I do not know if COPS-PR is being used or not; I know I do not want to spend time working on COPS-PR. Is anybody interested in working on it (including review any work done by ITU?)
Tom: Does anybody work for an organization that uses COPS-PR? 
One person raised their hands (Tina Tsou from Huawei)
Tom: Is there any interest in working on COPS-PR extensions? 
Dan: these questions should be asked on the OPS lists and ITU lists.
Should it be standards track? - the authors would like it so. 
Action item - Tom to address the ops-area list with query to determine status of implementation and deployment of COPS and COPS-PR and level of interest in participating in such a work

5. Mini-BOF C: Best Current Practices in Operations and Management - David Harrington  

http://www3.ietf.org/proceedings/07mar/slides/opsarea-2.ppt

Proposal to create operation capabilities working group, modeled on the experience of opsec WG
Would bring in operators experience
Framework document and operational guidelines as principal output
Is opsec a success story? 
Straw poll indicates interest - continue discussion after the next item

6. Improved Efficiency of the OPS Area - proposal for the formation of a OPS Area WG - ADs 

David and Dan - create structure for OPS area, similar to the one existing in TSV and Routing
Should it be merged with OPS and management capabilities WG as suggested by David H.? 
TSV chair - success in Transport due to multiple small items, no dominant item
Straw poll indicates interest - nobody believes it's a bad idea, continue discussions in net meeting

7. Open Microphone 

Meeting 2 - Wednesday March 21, 2007 - 13:00 to 16:10 

1. Meeting Administrivia ADs (total: 5 min) 

2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling - Michael Alexander 

http://www3.ietf.org/proceedings/07mar/slides/opsarea-4.ppt

Scott Bradner - very complex, IETF not good history in this type of thing
Pekka - benefit would go to NMS vendors?
response - benefit to equipment vendors to get devices into NMSs
Pekka - simpler version may be helpful, clean terminology would be helpful potential but current scope too big, maybe more fit to the IRTF
Margret Wassermann - interesting, but what gets standardized?
response - focus on meta models only
xx - sim  (info model) underway for 4 years - achieved meta view, now time to distribute to groups to use
response - this proposal is much simpler than sim

Chair: suggest create list & discuss issues raised in meeting, only one opposed

3. MIB-Doctor-sponsored MIB-document-writing template: David Harrington 

http://www3.ietf.org/proceedings/07mar/slides/opsarea-8.ppt

No discussions

4. Mini-BOF E: MIB module editing in XML : Emile Stephan  

http://www3.ietf.org/proceedings/07mar/slides/opsarea-5.ppt

Sharon - do you actually have tools to translate XML to MIBs?
response - I'm proposing to edit the MIB in XML and use XSL transformation.
Sharon - do you do SMI verification?
Emile: Shows that the tool captures mistakes.
Bill Fenner - wrong way to model MIB in XML - better to have element that is syntax or XML schema for writing a MIB
response - I'm using XML in a very loose way, but this is better than nothing. Please make better proposal.
Juergen - The opening argument in the beginning you wanted to move to data model. The main issue is not syntactic problem to get there.
response -  I asked for a BOF in order to discuss and have proposals of how to move forward

chair - does not feel that it's a standards problem at this time but maybe should be discussed with tools people

5. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima 

http://www3.ietf.org/proceedings/07mar/slides/opsarea-6.ppt

- proposed goal for NGO
Sharon - why select VLANs?
response - well used technology in enterprise space
chair - MIB modules are used for VLAN config in enterprises - good to see comparison between SNMP & netconf 

chair - In Chicago we will have one or two BOFs for data modeling. This contribution belongs to this space. Encourage to continue the work, update the I-D and bring proposals to the NGO work.

6. Mini-BOF G: OWL techniques for MIB to XML documents and schema translation - Bob Natale 

http://www3.ietf.org/proceedings/07mar/slides/opsarea-7.ppt

Andy Bierman - there are issues beyond mere translations - suggests that experts in a protocol would need to be involved in determining if conversion can even be done
Scott Bradner - how fill in holes (beyond what MIB covers)
bob - would need to have collaborative process for each MIB
	
chair - good to invite WS-CIM folk to join discussion
Sharon xx - may be mismatch between MIBs and service-orientated interface - also may be too high a data bandwidth generated for SOA/WS  management stations
Bob - yes an issue
Sharon - how much interest in WS community
Bob - much need among user & developer communities 
Dan Romascanu (from floor) - not sure that this fits the base role of the IETF - make net work better
Bob - this will help the operators run the network better
Eugene - spent years in WS area - high level seems to be good - but WS seems to rely on different fundamental information needs than what is in MIBs - also some groups in this area do not like each  other (OAIS & DMTF for example).  The other is political. Are the two standard bodies can really work together in the long term?
xx - good idea & he is optimistic that this would be useful - but there are valid concerns about level of impact on the other communities

chair - open list for discussion, consensus in the room

7. Late Submission - requirements to tunneling protocols OAM - KIKUCHI Yutaka 

Pekka - why is this tunnel specific? Only reordering is
response - Our main objective is to measure tunnel quality.
Chair - Maybe the next version of the draft you may need to better clarify what is tunnel quality, to emphasis the difference between interface and tunnel interface
Scott Bradner - if you prepend seq # you change packet size you may have to fragment
Response - I used GRE sequence number (32 bits). Good, if you prepend sequence number you may get into segmentation situation.

chair -We'll continue to discuss this on the list, gauge interest and answer the questions. I forwarded this to IPPM and benchmarking WG.

Tries to sense the interest in the room: 4-5 hands. Is this not relevant? None

8. Open microphone  

Margaret: The topics today were interesting. But interesting is not good enough. We have really bad history of trying to standardize management approaches that were not really needed by service providers. We much work only on what users really need.
Dan: We split the OPS session to two days. Today's is more the 'new'
issues. We need more feedback from operators. Work in the past lead to NETCONF etc.
Dave K.: We haven't allowed BOFs for the last few IETF being strict to ensure that ideas that are not really required will not go forward.
However we felt that we may miss some good ideas from going forward.
Bob: To answer Margaret. I wanted to stress in my presentation that there are operators and users that need the data models. What do you want that shows this need.
Margaret: I want them to be here and participate. If we don' t have multiple sources of input.
David Partain: I'd like to address Margaret point. There has been a lot of discussions on data modeling. This is a real problem, since everyone wants to use NETCOM but there is not any data models. Our users want NETCONF. I think this is fair to characterizing it as real need.
Margeret: Are you the customer of the data model
David: Me and my customer.
Ron B.: Maybe we should go to the operators and ask what are the most critical problems and start from that, i.e. solve this first. When he was a operator he would not have seen the issue as a lack of a data model - rather why does pager go off - should keep doing this kind of thing but should try to get closer to userâ€™s actual perceived needs
Andy: I don't believe it is possible to have a protocol independent data model. We don't have the expertise in web verbs etc. You should do the work. I agree with Scott that we don't have a way to fill in the holes.
Dave H: Addressing Margaret point. I'm going to have a workgroup meeting to understand their needs. Are there any operators  in the rooms? ~ 5 hands. on Monday he proposed an ops nm WG to get operators involved - looking for volunteers to help ops area better understand operator needs, also - operations & managements guidelines doc - also ooking for volunteers for that
Bob: We might have minimum basic requirements for conversion of MIBs. But most MIBs should be map-able.
Dave K.: Is the experiment with the mini-BOF useful? Around 30 hands
Who thinks this is not useful? None
Dan: Regarding Dave H suggestion for two working groups, I suggest that we unite it into one working group.
Dave H: I think these are two different problems and should be done by two different contributor groups. Protocol designers and Operators.
Dan: I agree, but work generates feedback and input generates work. My concern that split of resources and that there will not be enough interest if we split it to two.
Dave K: From the operator part we don't want to be too lonely… The important thing is to have a good charter for the working group.
Ron B: New WG chair. Applause to Dave K. I work for Juniper. I was an operator in the VBNS network. Looking forward to work with you all.

Date: Thu, 29 Mar 2007 08:58:02 +0200
From: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
Organization: IBR, TU Braunschweig
To: Frank Strau? <[email-masked]>, [email-masked]
Subject: Re: [nmrg] draft prague meeting minutes

Juergen Schoenwaelder wrote:
> On Tue, Mar 27, 2007 at 10:31:30AM +0200, Frank Strau? wrote:
>  
>> My general thinking is to keep the schema homogeneous from the
>> perspective of the consumer of XML rendered traces. This should not
>> be guided by the origin format (SNMP), at least not primarily, but
>> by the semantics of the represented data. In this sense: yes, I
>> really do think it would be a good idea to render real error causes
>> as something like NMTOKENs from an enumeration list and
>> max-repetitions as numbers, of course.
> 
> Our goal is to represent fields of protocol messages and the protocol
> in question carries a number in this particular field - with semantics
> depending on the protocol operation. Such overloading happens in real
> protocols; you seem to take a fundamental position that this
> overloading is bad and hence we should not expose it in other formats;
> the ultimate solution would then actually to introduce different
> fields, at least in the XML representation.

There are protocols in which such an overloading makes sense, e.g., to
achieve a more compact representation. But in case of XML, I think,
splitting different semantics in seperate fields is a good approach.
But...

> While I in general agree with your principle (avoid overloading), I am
> not sure it is worth to adhere to it in this case since following your
> principle requires changes to several programs and ultimately the CSV
> and XML formats, which I like to minimize as long as things are not
> really broken. (An example for what I consider "broken" is our
> unfortunate decision to turn Counter32s into Unsigned32 and thus
> loosing information.)

Of course, it's not "broken", if you keep the combined field as it is
in SNMP. I had no clue how large the set of existing code already is.
I understand this point. Hence, I'm fine, if you tend to keep it the
way it is. I thought it would be easier to get things in a *slightly*
cleaner shape before this document becomes an RFC.

Date: Wed, 28 Mar 2007 20:29:22 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Frank Strau? <[email-masked]>
Subject: Re: [nmrg] draft prague meeting minutes
Mail-Followup-To: Frank Strau? <[email-masked]>, [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]

On Tue, Mar 27, 2007 at 10:31:30AM +0200, Frank Strau? wrote:
 
> My general thinking is to keep the schema homogeneous from the
> perspective of the consumer of XML rendered traces. This should not
> be guided by the origin format (SNMP), at least not primarily, but
> by the semantics of the represented data. In this sense: yes, I
> really do think it would be a good idea to render real error causes
> as something like NMTOKENs from an enumeration list and
> max-repetitions as numbers, of course.

Our goal is to represent fields of protocol messages and the protocol
in question carries a number in this particular field - with semantics
depending on the protocol operation. Such overloading happens in real
protocols; you seem to take a fundamental position that this
overloading is bad and hence we should not expose it in other formats;
the ultimate solution would then actually to introduce different
fields, at least in the XML representation.

While I in general agree with your principle (avoid overloading), I am
not sure it is worth to adhere to it in this case since following your
principle requires changes to several programs and ultimately the CSV
and XML formats, which I like to minimize as long as things are not
really broken. (An example for what I consider "broken" is our
unfortunate decision to turn Counter32s into Unsigned32 and thus
loosing information.)

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

content-class: urn:content-classes:message
Date: Tue, 27 Mar 2007 15:02:21 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "IETF MIBs" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: [nmrg] Minutes of the OPS Area open meetings in Prague - draft 1

Please find below a draft of the OPS area open meeting. I am still missing notes from the 3/19 session, so corrections and additions are welcome, including your own comments if you were at mic.  

Dan

Meeting 1 - Monday March 19, 2007 15:20 to 17:20 

1. Meeting Administrivia

2. Introduction of new Area Director - Ron Bonica 

Dan - thanking David Kessens for his years of service as Area Director

3. Mini-BOF A: - Manageability and Operational Guidelines - David Harrington 

http://www3.ietf.org/proceedings/07mar/slides/opsarea-1.ppt

Discussions about the structure of the document - should the protocol evaluation be part of the document? 

4. Mini-BOF B: COPS push mode policy configuration - Tom Taylor and Tina Tsou  

http://www3.ietf.org/proceedings/07mar/slides/opsarea-3.ppt

Bert Wijnen - to what extent is COPS used in the industry today? 
straw poll if interest - who would be interested in this work - a few
Should it be standards track? - the authors would like it so. The ITU-T is using a few protocols including DIAMETER and COPS from the IETF that require some extensions. 
Action item - Tom to address the ops-area list with query to determine status of implementation and deployment of COPS and COPS-PR and level of interest in participating in such a work

5. Mini-BOF C: Best Current Practices in Operations and Management - David Harrington  

http://www3.ietf.org/proceedings/07mar/slides/opsarea-2.ppt

Proposal to create operation capabilities working group, modeled on the experience of opsec WG
Would bring in operators experience
Framework document and operational guidelines as principal output
Is opsec a success story? 
Straw poll indicates interest - continue discussion after the next item

6. Improved Efficiency of the OPS Area - proposal for the formation of a OPS Area WG - ADs 

David and Dan - create structure for OPS area, similar to the one existing in TSV and Routing
Should it be merged with OPS and management capabilities WG as suggested by David H.? 
TSV chair - success in Transport due to multiple small items, no dominant item
Straw poll indicates interest - nobody believes it's a bad idea, continue discussions in net meeting

7. Open Microphone 

Meeting 2 - Wednesday March 21, 2007 - 13:00 to 16:10 

1. Meeting Administrivia ADs (total: 5 min) 

2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling - Michael Alexander 

http://www3.ietf.org/proceedings/07mar/slides/opsarea-4.ppt

Scott Bradner - very complex, IETF not good history in this type of thing
Pekka - benefit would go to NMS vendors?
response - benefit to equipment vendors to get devices into NMSs
Pekka - simpler version may be helpful, clean terminology would be helpful potential but current scope too big, maybe more fit to the IRTF
Margret Wassermann - interesting, but what gets standardized?
response - focus on meta models only
xx - sim  (info model) underway for 4 years - achieved meta view, now time to distribute to groups to use
response - this proposal is much simpler than sim

Chair: suggest create list & discuss issues raised in meeting, only one opposed

3. MIB-Doctor-sponsored MIB-document-writing template: David Harrington 

http://www3.ietf.org/proceedings/07mar/slides/opsarea-8.ppt

No discussions

4. Mini-BOF E: MIB module editing in XML : Emile Stephan  

http://www3.ietf.org/proceedings/07mar/slides/opsarea-5.ppt

Sharon - do you actually have tools to translate XML to MIBs?
response - I'm proposing to edit the MIB in XML and use XSL transformation.
Sharon - do you do SMI verification?
Emile: Shows that the tool captures mistakes.
Bill Fenner - wrong way to model MIB in XML - better to have element that is syntax or XML schema for writing a MIB
response - I'm using XML in a very loose way, but this is better than nothing. Please make better proposal.
Juergen - The opening argument in the beginning you wanted to move to data model. The main issue is not syntactic problem to get there.
response -  I asked for a BOF in order to discuss and have proposals of how to move forward

chair - does not feel that it's a standards problem at this time but maybe should be discussed with tools people

5. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima 

http://www3.ietf.org/proceedings/07mar/slides/opsarea-6.ppt

- proposed goal for NGO
Sharon - why select VLANs?
response - well used technology in enterprise space
chair - MIB modules are used for VLAN config in enterprises - good to see comparison between SNMP & netconf 

chair - In Chicago we will have one or two BOFs for data modeling. This contribution belongs to this space. Encourage to continue the work, update the I-D and bring proposals to the NGO work.

6. Mini-BOF G: OWL techniques for MIB to XML documents and schema translation - Bob Natale 

http://www3.ietf.org/proceedings/07mar/slides/opsarea-7.ppt

Andy Bierman - there are issues beyond mere translations - suggests that experts in a protocol would need to be involved in determining if conversion can even be done
Scott Bradner - how fill in holes (beyond what MIB covers)
bob - would need to have collaborative process for each MIB
	
chair - good to invite WS-CIM folk to join discussion
Sharon xx - may be mismatch between MIBs and service-orientated interface - also may be too high a data bandwidth generated for SOA/WS  management stations
Bob - yes an issue
Sharon - how much interest in WS community
Bob - much need among user & developer communities 
Dan Romascanu (from floor) - not sure that this fits the base role of the IETF - make net work better
Bob - this will help the operators run the network better
Eugene - spent years in WS area - high level seems to be good - but WS seems to rely on different fundamental information needs than what is in MIBs - also some groups in this area do not like each  other (OAIS & DMTF for example).  The other is political. Are the two standard bodies can really work together in the long term?
xx - good idea & he is optimistic that this would be useful - but there are valid concerns about level of impact on the other communities

chair - open list for discussion, consensus in the room

7. Late Submission - requirements to tunneling protocols OAM - KIKUCHI Yutaka 

Pekka - why is this tunnel specific? Only reordering is
response - Our main objective is to measure tunnel quality.
Chair - Maybe the next version of the draft you may need to better clarify what is tunnel quality, to emphasis the difference between interface and tunnel interface
Scott Bradner - if you prepend seq # you change packet size you may have to fragment
Response - I used GRE sequence number (32 bits). Good, if you prepend sequence number you may get into segmentation situation.

chair -We'll continue to discuss this on the list, gauge interest and answer the questions. I forwarded this to IPPM and benchmarking WG.

Tries to sense the interest in the room: 4-5 hands. Is this not relevant? None

8. Open microphone  

Margaret: The topics today were interesting. But interesting is not good enough. We have really bad history of trying to standardize management approaches that were not really needed by service providers. We much work only on what users really need.
Dan: We split the OPS session to two days. Today's is more the 'new'
issues. We need more feedback from operators. Work in the past lead to NETCONF etc.
Dave K.: We haven't allowed BOFs for the last few IETF being strict to ensure that ideas that are not really required will not go forward.
However we felt that we may miss some good ideas from going forward.
Bob: To answer Margaret. I wanted to stress in my presentation that there are operators and users that need the data models. What do you want that shows this need.
Margaret: I want them to be here and participate. If we don' t have multiple sources of input.
David Partain: I'd like to address Margaret point. There has been a lot of discussions on data modeling. This is a real problem, since everyone wants to use NETCOM but there is not any data models. Our users want NETCONF. I think this is fair to characterizing it as real need.
Margeret: Are you the customer of the data model
David: Me and my customer.
Ron B.: Maybe we should go to the operators and ask what are the most critical problems and start from that, i.e. solve this first. When he was a operator he would not have seen the issue as a lack of a data model - rather why does pager go off - should keep doing this kind of thing but should try to get closer to userâ€™s actual perceived needs
Andy: I don't believe it is possible to have a protocol independent data model. We don't have the expertise in web verbs etc. You should do the work. I agree with Scott that we don't have a way to fill in the holes.
Dave H: Addressing Margaret point. I'm going to have a workgroup meeting to understand their needs. Are there any operators  in the rooms? ~ 5 hands. on Monday he proposed an ops nm WG to get operators involved - looking for volunteers to help ops area better understand operator needs, also - operations & managements guidelines doc - also ooking for volunteers for that
Bob: We might have minimum basic requirements for conversion of MIBs. But most MIBs should be map-able.
Dave K.: Is the experiment with the mini-BOF useful? Around 30 hands
Who thinks this is not useful? None
Dan: Regarding Dave H suggestion for two working groups, I suggest that we unite it into one working group.
Dave H: I think these are two different problems and should be done by two different contributor groups. Protocol designers and Operators.
Dan: I agree, but work generates feedback and input generates work. My concern that split of resources and that there will not be enough interest if we split it to two.
Dave K: From the operator part we don't want to be too lonely… The important thing is to have a good charter for the working group.
Ron B: New WG chair. Applause to Dave K. I work for Juniper. I was an operator in the VBNS network. Looking forward to work with you all.

Date: Tue, 27 Mar 2007 10:31:30 +0200
From: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
Organization: IBR, TU Braunschweig
To: [email-masked]
Subject: Re: [nmrg] draft prague meeting minutes

Juergen Schoenwaelder wrote:

>>>>>  - The main reason to use names for protocol operations is that they
>>>>>    are frequently read by humans for debugging and analysis while
>>>>>    the error-status value is usually of secondary importance (as is
>>>>>    the version number).
>>>>>
>>>>>    [Ed: the more I think about it, it may actually be useful to use
>>>>>    strings rather than numbers]
>>>> I like your later thoughts. :-)
>>> Well, no, later on I changed my mind again. There are two fields that
>>> can be rendered - the version number and the error status. For the
>>> version number, rendering might make sense (or not - depends on your
>>> taste). For the error-status, the situation is a bit more complex
>>> since GetBulk uses this field to convey the max-repetitions; so
>>> rendering would have to take into account the PDU type (and since the
>>> field is actually not used for requests other than GetBulk, rendering
>>> probably only makes sense for responses) and I am not really sure this
>>> leads to simplification, especially for scripts that have to process
>>> this data.
>> So, what about "the main reason to use names for protocol operations is
>> that they are frequently read by humans for debugging and analysis ..."
>> Why do you think the error-status is of minor importance? *If* errors
>> occur, it could be interesting to get statistics or debugging info on
>> their causes and the argument for human readability is true as well, in
>> my opinion.
> 
> The error-status field was included with the intention that it is
> possible to get statistics - no doubt about that. However, when you
> look for something in the traces, our observation was that the first
> thing you almost always do is to understand which type of protocol
> messages is involved. This is not true for the error-status as far as
> I can tell from my experience so far. Furthermore, the error-status
> field carries different information as I explained above. So you
> really believe we should render the protocol field value depending on
> the PDU type?
> 
> Note that we have analysis code which simply counts the different
> values in this field on a per PDU type which gives you the error
> status distribution for responses, the max-repetitions distribution
> for GetBulks, and an idea whether there are surprises for the other
> messages (means value != 0). If we follow your approach, this will get
> a bit more complex to do and the same is true for our converters
> written in languages where numbers and strings are treated quite
> different.

First of all, please note that I do *not* have any experience with
such traces and their analysis. So, if you think you know better what's 
the best approach, you are most probably right. :-) I just want to give 
my impression from a certain distance and from what I have learned
in the past few years about good and bad XML schema design independent
from the application domain.

My general thinking is to keep the schema homogeneous from the 
perspective of the consumer of XML rendered traces. This should not be 
guided by the origin format (SNMP), at least not primarily, but by the 
semantics of the represented data. In this sense: yes, I really do think 
it would be a good idea to render real error causes as something like 
NMTOKENs from an enumeration list and max-repetitions as numbers, of course.

I think the schema should not be guided by any specific programming 
languages.

Date: Tue, 27 Mar 2007 08:43:32 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Frank Strau? <[email-masked]>
Subject: Re: [nmrg] draft prague meeting minutes
Mail-Followup-To: Frank Strau? <[email-masked]>, [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]

On Mon, Mar 26, 2007 at 01:35:48PM +0200, Frank Strau? wrote:
> Juergen Schoenwaelder wrote:
> >
> >The problem is that there is not just one solution. Some operators
> >give away pcap files, others XML or CSV files, some with filtering
> >some with anonymization, and yet others don't give any files away but
> >are willing to run scripts on behalf of researchers. So this figure
> >simply can't be drawn.
> 
> I see. So, could you please spend a short paragraph on this diversity,
> quite like the one above? Maybe, I could have read the draft more
> carefully, but the way I read it, such a paragraph would have helped me.

I can try to make this clearer.
 
> >>>  - The main reason to use names for protocol operations is that they
> >>>    are frequently read by humans for debugging and analysis while
> >>>    the error-status value is usually of secondary importance (as is
> >>>    the version number).
> >>>
> >>>    [Ed: the more I think about it, it may actually be useful to use
> >>>    strings rather than numbers]
> >>I like your later thoughts. :-)
> >
> >Well, no, later on I changed my mind again. There are two fields that
> >can be rendered - the version number and the error status. For the
> >version number, rendering might make sense (or not - depends on your
> >taste). For the error-status, the situation is a bit more complex
> >since GetBulk uses this field to convey the max-repetitions; so
> >rendering would have to take into account the PDU type (and since the
> >field is actually not used for requests other than GetBulk, rendering
> >probably only makes sense for responses) and I am not really sure this
> >leads to simplification, especially for scripts that have to process
> >this data.
> 
> So, what about "the main reason to use names for protocol operations is
> that they are frequently read by humans for debugging and analysis ..."
> Why do you think the error-status is of minor importance? *If* errors
> occur, it could be interesting to get statistics or debugging info on
> their causes and the argument for human readability is true as well, in
> my opinion.

The error-status field was included with the intention that it is
possible to get statistics - no doubt about that. However, when you
look for something in the traces, our observation was that the first
thing you almost always do is to understand which type of protocol
messages is involved. This is not true for the error-status as far as
I can tell from my experience so far. Furthermore, the error-status
field carries different information as I explained above. So you
really believe we should render the protocol field value depending on
the PDU type?

Note that we have analysis code which simply counts the different
values in this field on a per PDU type which gives you the error
status distribution for responses, the max-repetitions distribution
for GetBulks, and an idea whether there are surprises for the other
messages (means value != 0). If we follow your approach, this will get
a bit more complex to do and the same is true for our converters
written in languages where numbers and strings are treated quite
different.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

From: "David B Harrington" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Mon, 26 Mar 2007 10:54:34 -0400
Subject: [nmrg] comparing management standards (was Comments Question about draft-xu-cops-push-00.txt)

Hi David,

(I changed the subject line since this is not about the cops-pr
proposal anymore)

(I reduced the CC's to the ops-area and the nmrg mailing lists, hoping
that will reduce duplicate mailings, I BCC'd the other addresses, to
alert them they should join the ops-area list or the nmrg list for
this discussion.) 

So far we have not done a very good job of comparing and contrasting
IETF NM standards, and providing guidelines of how they might operate
together in a system. 

I am editing an OPS area "Guidelines for Operability and
Manageability" draft that currently includes sections for describing
the applicability of IETF NM protocols and IETF NM data models.
This document may be similar to what you are describing, but to avoid
the "boiling the ocean" problem, we are focusing on comparing and
contrasting IETF standards for NM, before we consider expanding it to
include NM-related standards of other SDOs. 

As we develop the operability and manageability guidelines draft, we
may split these sections into  a second draft specifically for
comparing and contrasting available technologies. We plan to use a
bottom-up approach of understanding and documenting how IETF NM
protocols are **actually deployed** to manage real IP-based networks
today, so we can understand current practices better. It would be
helpful if other SDOs provided similar documentation of how their
NM-related standards are actually deployed to manage real IP-based
networks today. 

Such a focused approach does have its potential pitfalls, of course;
by focusing only on the IETF NM standards, in a bottom-up approach, we
might miss the bigger picture espoused by other SDOs that prefer a
top-down approach.

We are faced with a lack of quantitative research into how NM
protocols (standard or not) are used today in real networks, so it
will be hard to compare and contrast based on quantitative measures.
We will probably need to base the document we are producing on
anecdotal reports and empirical data from small research networks
until the research community can get enough cooperation from
commercial interests to be able to study patterns in commercial
enterprise and service provider networks. 

The current work being done by the NMRG and others to generate
quantitative data, and to address the concerns of commercial interests
about the sharing of data (such as anonymization), hopefully will lead
to better information in the future.

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

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Durham, David
> Sent: Saturday, March 17, 2007 7:23 PM
> To: [email-masked]; xuheyuan
> Cc: [email-masked]; [email-masked]; 
> Romascanu,Dan (Dan); Hexian Huang; Tom-PT Taylor; 
> [email-masked]; [email-masked]; Tina Tsou
> Subject: RE: [nmrg] Re: Comments Question about 
> draft-xu-cops-push-00.txt
> 
> If the goal is to use XML, then why reinvent the wheel on
webservices
> for management outside of the W3C and DMTF? 
> SNMP, COPS, DIAMETER, NETCONF... Where does it end?
> 
> Is there an RFC that does a thorough analysis of the alternatives
> (IETF's and other standards bodies' included) in terms of 
> capabilities,
> latency, bandwidth, complexity, backward compatibility and other
such
> quantitative metrics? If not, this might be a helpful activity as
the
> mailing list discussions quickly become crystal ball gazing and
> philosophical in nature. Then folks can figure out if their 
> requirements
> make a better fit for one protocol over another. 
> 
> -Dave
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Juergen Schoenwaelder
> > Sent: Thursday, March 15, 2007 7:47 AM
> > To: xuheyuan
> > Cc: Tina Tsou; [email-masked]; [email-masked]; 
> Romascanu,
> Dan
> > (Dan); Hexian Huang; Tom-PT Taylor; [email-masked]; ops-
> > [email-masked]
> > Subject: [nmrg] Re: Comments Question about 
> draft-xu-cops-push-00.txt
> > 
> > On Thu, Mar 15, 2007 at 10:19:18PM +0800, xuheyuan wrote:
> > 
> > > At that time the Re reference point, merged into Rw 
> reference point
> > > later, controlled the IP edge, actually an IP-IP gateway. In the
> > > current network, most existing IP-IP gateways are routers, which
> > > support COPS already. In reality, using COPS is the 
> quickest way to
> > > do that as described in approach 2 in this draft.
> > 
> > I have routers that support NETCONF in my lab and no routers
> > supporting COPS-PR or COPS.  Perhaps this is why our views of the
> > world are somewhat different.
> > 
> > > COPS-PR by nature does policy control, Rw interface mainly does
> > > policy control dynamically, not just push configuration
> > > information. Besides, in 2005,NETCONF was a pretty new 
> protocol, and
> > > few existing routers supported NETCONF.
> > 
> > I never understood the distinction between configuration and
policy
> > information when it comes to the device interface. The PDP is the
> > policy engine and what comes out of this engine as provisioning
> > information is for me not really distinct from configuration data
> > coming out of other systems (e.g. customer provisioning systems).
> > 
> > I agree that NETCONF was pretty new in 2005 and it still is in
2007.
> > COPS-PR is older but as far as I can tell not too widely
implemented
> > and the number of people within the IETF who do understand COPS-PR
> > well is like to be somewhat smaller than the number of people
within
> > the IETF who understand NETCONF and my impression was that COPS-PR
> > awareness declines.
> > 
> > > As RACF supports both fix and mobile, push and pull modes, in
the
> > > real networking, PD-FE may possibly support both modes, 
> and in pull
> > > modes, COPS is very effective, so, in push mode, if 
> approach 2 COPS
> > > could be adopted, it will simplify the implementation.
> > 
> > The implementation simplification is a relative thing (if you have
> > COPS, using COPS is simple, if you have NETCONF, using NETCONF is
> > simple). Not sure how to make a decision on this.
> > 
> > Again, I like to see the discussion raised to the technical level
to
> > first understand if NETCONF could do what you need it to do
equally
> > well or whether there is any technical feature that really
> > distinguishes COPS-PR from NETCONF.
> > 
> > /js
> > 
> > --
> > Juergen Schoenwaelder		 Jacobs University Bremen
> > <http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725
Bremen,
> > Germany
> > --
> > !! This message is brought to you via the `nmrg' mailing list.
> > !! Please do not reply to this message to unsubscribe. To 
> unsubscribe
> or
> > adjust
> > !! your settings, send a mail message to
> <[email-masked]>
> > !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 
> -- 
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust
> !! your settings, send a mail message to 
> <[email-masked]>
> !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

Date: Mon, 26 Mar 2007 13:35:48 +0200
From: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
Organization: IBR, TU Braunschweig
To: [email-masked]
Subject: Re: [nmrg] draft prague meeting minutes

Juergen Schoenwaelder wrote:
> On Mon, Mar 26, 2007 at 12:53:39PM +0200, Frank Strau? wrote:
>> Juergen Schoenwaelder wrote in the posted Prague Minutes:
>>
>>> 3. Last call review draft-irtf-nmrg-snmp-measure-01.txt (JS)
>>>
>>>   This document was last called and 15 reviews were submitted. Bert
>>>   Wijnen acts as the shepherd for this document. JS went through all
>>>   reviews, discussing those issues he felt worth bringing up (i.e.,
>>>   the edits may not be fully understood); see the issues list in the
>>>   proceedings. Below are the actions agreed on during the meeting:
>>>   - JS to contact Frank - he wants to see a figure but it is unclear
>>>     what the figure should show
>> Sorry for being unclear. The figure I had in mind, would show the
>> general archicture, containing
>>
>> - the entities that process the five steps shown in Section 2,
>>   along with their potential locations,
>>
>> - the kind of data transfered between these entities (raw, converted,
>>   filtered, anonymized).
>>
>> The figure should make clear, who controls which entities, so that the
>> reader could easily see that no raw or unfiltered data leaves his
>> domain, if this is required by his policies.
> 
> The problem is that there is not just one solution. Some operators
> give away pcap files, others XML or CSV files, some with filtering
> some with anonymization, and yet others don't give any files away but
> are willing to run scripts on behalf of researchers. So this figure
> simply can't be drawn.

I see. So, could you please spend a short paragraph on this diversity,
quite like the one above? Maybe, I could have read the draft more
carefully, but the way I read it, such a paragraph would have helped me.

>>>   - The main reason to use names for protocol operations is that they
>>>     are frequently read by humans for debugging and analysis while
>>>     the error-status value is usually of secondary importance (as is
>>>     the version number).
>>>
>>>     [Ed: the more I think about it, it may actually be useful to use
>>>     strings rather than numbers]
>> I like your later thoughts. :-)
> 
> Well, no, later on I changed my mind again. There are two fields that
> can be rendered - the version number and the error status. For the
> version number, rendering might make sense (or not - depends on your
> taste). For the error-status, the situation is a bit more complex
> since GetBulk uses this field to convey the max-repetitions; so
> rendering would have to take into account the PDU type (and since the
> field is actually not used for requests other than GetBulk, rendering
> probably only makes sense for responses) and I am not really sure this
> leads to simplification, especially for scripts that have to process
> this data.

So, what about "the main reason to use names for protocol operations is
that they are frequently read by humans for debugging and analysis ..."
Why do you think the error-status is of minor importance? *If* errors
occur, it could be interesting to get statistics or debugging info on
their causes and the argument for human readability is true as well, in
my opinion.

Date: Mon, 26 Mar 2007 13:18:03 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Frank Strau? <[email-masked]>
Subject: Re: [nmrg] draft prague meeting minutes
Mail-Followup-To: Frank Strau? <[email-masked]>, [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]

On Mon, Mar 26, 2007 at 12:53:39PM +0200, Frank Strau? wrote:
> Juergen Schoenwaelder wrote in the posted Prague Minutes:
> 
> >3. Last call review draft-irtf-nmrg-snmp-measure-01.txt (JS)
> >
> >   This document was last called and 15 reviews were submitted. Bert
> >   Wijnen acts as the shepherd for this document. JS went through all
> >   reviews, discussing those issues he felt worth bringing up (i.e.,
> >   the edits may not be fully understood); see the issues list in the
> >   proceedings. Below are the actions agreed on during the meeting:
> 
> >   - JS to contact Frank - he wants to see a figure but it is unclear
> >     what the figure should show
> 
> Sorry for being unclear. The figure I had in mind, would show the
> general archicture, containing
> 
> - the entities that process the five steps shown in Section 2,
>   along with their potential locations,
> 
> - the kind of data transfered between these entities (raw, converted,
>   filtered, anonymized).
> 
> The figure should make clear, who controls which entities, so that the
> reader could easily see that no raw or unfiltered data leaves his
> domain, if this is required by his policies.

The problem is that there is not just one solution. Some operators
give away pcap files, others XML or CSV files, some with filtering
some with anonymization, and yet others don't give any files away but
are willing to run scripts on behalf of researchers. So this figure
simply can't be drawn.
 
> >   - The main reason to use names for protocol operations is that they
> >     are frequently read by humans for debugging and analysis while
> >     the error-status value is usually of secondary importance (as is
> >     the version number).
> >
> >     [Ed: the more I think about it, it may actually be useful to use
> >     strings rather than numbers]
> 
> I like your later thoughts. :-)

Well, no, later on I changed my mind again. There are two fields that
can be rendered - the version number and the error status. For the
version number, rendering might make sense (or not - depends on your
taste). For the error-status, the situation is a bit more complex
since GetBulk uses this field to convey the max-repetitions; so
rendering would have to take into account the PDU type (and since the
field is actually not used for requests other than GetBulk, rendering
probably only makes sense for responses) and I am not really sure this
leads to simplification, especially for scripts that have to process
this data.

> >   - Clarify that the IPv6 address type is just there to capture src
> >     and dst addresses (do we have to add MAC addresses?)
> 
> Have there been any arguments for or against MAC addresses? At this
> point, I think they are not needed, and what's really not needed should
> not show up in the traces.

MAC addresses would only be needed for SNMP over IEEE 802 (but then we
have not seen such packets in our traces; but the same holds for IPv6
packets).

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

Date: Mon, 26 Mar 2007 12:53:39 +0200
From: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
Organization: IBR, TU Braunschweig
To: [email-masked], Juergen Schoenwaelder <[email-masked]>
Subject: Re: [nmrg] draft prague meeting minutes

Juergen Schoenwaelder wrote in the posted Prague Minutes:

> 3. Last call review draft-irtf-nmrg-snmp-measure-01.txt (JS)
> 
>    This document was last called and 15 reviews were submitted. Bert
>    Wijnen acts as the shepherd for this document. JS went through all
>    reviews, discussing those issues he felt worth bringing up (i.e.,
>    the edits may not be fully understood); see the issues list in the
>    proceedings. Below are the actions agreed on during the meeting:

>    - JS to contact Frank - he wants to see a figure but it is unclear
>      what the figure should show

Sorry for being unclear. The figure I had in mind, would show the
general archicture, containing

- the entities that process the five steps shown in Section 2,
   along with their potential locations,

- the kind of data transfered between these entities (raw, converted,
   filtered, anonymized).

The figure should make clear, who controls which entities, so that the
reader could easily see that no raw or unfiltered data leaves his
domain, if this is required by his policies.

I know that the compexity that can be placed in IETF documents' figures
is very limited. Hence, please regard this just as a proposal. I feel
no strong need about it.

>    - The main reason to use names for protocol operations is that they
>      are frequently read by humans for debugging and analysis while
>      the error-status value is usually of secondary importance (as is
>      the version number).
> 
>      [Ed: the more I think about it, it may actually be useful to use
>      strings rather than numbers]

I like your later thoughts. :-)

>    - Clarify that the IPv6 address type is just there to capture src
>      and dst addresses (do we have to add MAC addresses?)

Have there been any arguments for or against MAC addresses? At this
point, I think they are not needed, and what's really not needed should
not show up in the traces.

Date: Sun, 25 Mar 2007 22:33:42 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] draft prague meeting minutes
Reply-To: [email-masked]

--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

attached please find the draft minutes from our meeting in Prague.
Please let me know by the end of the week if there is something that
needs to be changed.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="nmrg.txt"

Minutes of the 22nd NMRG meeting
IETF 68, Prague, Czech Republic
23 March 2007
Minutes: Vladislav Marinov, Juergen Schoenwaelder

Participants:

The meeting was attended by about 40 people. The names were recorded
on the rooster which went to the IETF secretariat.

Agenda:

09:00 Agenda bashing and administrivia
      Juergen Schoenwaelder (Chair)
09:10 Report from the NMRG workshop in Utrecht
      Aiko Pras
09:30 Last call review draft-irtf-nmrg-snmp-measure-01.txt
      Juergen Schoenwaelder
10:00 SNMP Traffic Analysis Update
      Juergen Schoenwaelder
10:30 Distributed monitoring algorithms
      Alberto Gonzalez Prieto
11:00 Discussion
      Everybody
11:20 Wrapup
      Juergen Schoenwaelder (Chair)

Abbreviations:

JS: Juergen Schoenwaelder
AP: Aiko Pras
BW: Bert Wijnen 
DP: David Perkins
RB: Randy Bush
LD: Luca Deri
DH: David Harrington
SL: Simon Leinen
DR: Dan Romascanu
AG: Alberto Gonzalez Prieto
AB: Andy Bierman
PD: Petre Dini

1. Introduction to NMRG (JS)

   The agenda was updated since the NETCONF RBAC people from France
   could not make it to Prague meeting. The relevant I-D is 
   draft-cridlig-netconf-rbac-00.txt.

2. EMANICS / NMRG Workshop Report (AP)

   AP reviewed the EMANICS/NMRG workshop in October 2006 on future
   research directions. See his slides for details. About 25% of the
   attendees were at the IAB plenary the night before the NMRG
   meeting; so AP decided to go over all slides (and not just the ones
   not presented at the plenary).

   C: Your bullet that "Network management is risk management" was
      very interesting. There is always risk in uncertainty, we are
      not sure what happens in the network.
 
   Q: About the economic slides - is there work in the area? 

   A: Yes, one of the EMANICS work packages is economic management;
      but work is still focusing on SLAs and legal issues. I want to
      see answers of this question myself in the future.

3. Last call review draft-irtf-nmrg-snmp-measure-01.txt (JS)

   This document was last called and 15 reviews were submitted. Bert
   Wijnen acts as the shepherd for this document. JS went through all
   reviews, discussing those issues he felt worth bringing up (i.e.,
   the edits may not be fully understood); see the issues list in the
   proceedings. Below are the actions agreed on during the meeting:

   - Change "inform" to "inform-request" but leave "trap2"

   - JS to contact Frank - he wants to see a figure but it is unclear
     what the figure should show

   - Change the requirement to keep trace sources to a should keep
     rather then a must keep. Explain why it is good to keep the
     original data sets but also explain issues arising from this
     material being sensitive

   - The anonymization section should provide sufficient pointers for
     people interested in anonymization but it is not the goal of the
     document to provide an extensive discussion of this topic; the
     document is intended to make the operator communities aware that
     we want trace data; making the document too long will make it
     harder to use it for its intended purpose. Decided to add a
     summary what the state of the art in the area is

   - The main reason to use names for protocol operations is that they
     are frequently read by humans for debugging and analysis while
     the error-status value is usually of secondary importance (as is
     the version number).

     [Ed: the more I think about it, it may actually be useful to use
     strings rather than numbers]

   - Add a statement how the relaxng compact notation schema can be
     converted into other XML schema languages

   - Add a section with warnings about generalizing conclusions from
     biased data sets; conclusions derived from a biased small data
     set might not be universally true

   - Change the base type mapping so as to not loose information (that
     is report Counter32 and friends (including Opaque) correctly; do
     not use the SMIng base type model).

   - Clarify that the IPv6 address type is just there to capture src
     and dst addresses (do we have to add MAC addresses?)
 
   - State that it was a design decision to keep conversion tools MIB
     agnostic. Hence, fancy OID formats can't be done. (JS explained
     that he wrote a separate tool called smixlate to handle this.)

   - Document that packets containing mal-formed SNMP messages or
     messages which are neither SNMPv1/SNMPv2c/SNMPv3 can be dropped
     and that implementations should report the number of such dropped
     messages

   - Add examples for CSV and XML formatted packets

   - Add rough numbers about trace sizes, e.g., a flow polling N
     interfaces (inOctets, outOctets) every 5 minutes causes traces of
     size xxx pcap, yyy csv, zzz xml. It would be nice to extract such
     a flow to get the numbers...

   - Keep XML format since it retains all information; the CSV format
     only retains a subset of the information.

   - Rewrite section 2.5 so that it stresses the point that some trace
     providers may prefer to not give away trace data but are willing
     to execute analysis scripts if they can be checked that they do
     not harm; this requires to use high-level languages typically
     understood by operators (e.g. Perl - make clear Perl is just an
     example).

   - Keep section 3 as it was generally considered to be useful,
     especially for explaining how traces may be used and to give an
     idea which questions will be answered with this research

   - Explain that pcap is a bad format since it requires complex
     analysis code (IP reassembly, BER decoding) and thus makes it
     difficult to verify an analysis script does not do harm

3. Trace Analysis Update (JS)

   JS presented an update of the trace analysis work done at Jacobs
   University and the University of Twente. See the slides for the
   details of the presentation. Below are some questions that came up
   during the presentation.

   Q: You did observe SNMPv3 messages?

   A: Yes, but very sporadic; might have been an attempt to test if an
      agent supports SNMPv3

   Q: Were there responses to the SNMPv3 messages?

   A: I do not recall precisely, but I assume so

   Q: There were only very few informs in traces that use SNMPv2c

   A: Yes, it seems that GetBulk is a stronger incentive to switch to
      SNMPv2c in the traces we have collected so far.

   Q: Can we extrapolate in larger aspect?

   A: No, the data set is way too small for generalizations

   Q: Which applications were used?

   A: We didn't ask for this information, don't even know if we can expect
      operators to know

   Q: Operators should provide us with information what happened on the
      network during the trace collection period. It will be useful to
      capture what applications were used

   A: We want to identify communication patterns, without knowing
      which applications generated them. Note that we already try to
      track meta data but we do not necessarily expect it to be
      complete

   Q: Is the flow definition consistent with the IPFIX definition?
 
   A: No because they use port numbers, but many management scripts
      kick short lived snmp retrieval processes and thus dynamic port
      numbers are assigned for the manager processes

   C: There was also one long trace, huge in size. It turned out to be
      someone walking into a timefilter table and never getting out,
      staying there for days.

   Q: At some point it was mentioned that there are some dumb
      applications that simply retrieve read-only data

   A: Probably applications should look at the semantics of the data
      and then caching is not that hard; of course, a generic MIB
      browser or data poller will not do this

   C: Applications do not support caching anyway

   C: Probably caching is not worth the cost of optimization because
      sometimes routers get rebooted and reconfigured and it is not
      worth the risk, i.e., configuration might be changed suddenly so
      the cost of optimizing applications w.r.t. to retrieving
      read-only data might not be worth because of the risk

4. Distributed Monitoring and Aggregation (KTH)

   AG presented the work done at KTH on distributed monitoring and
   aggregation based on a live demo. The slides are recorded in the
   proceedings.

Questions:

   Q: SL, as an operator, is this useful for your environment?

   A: Our network is not so big, no need to optimize queries, you can
      optimize the number of samples in order to improve the mean
      error objective.

   Q: I would be interested in short term samples, your algorithm is
      adaptive, the network is running stable, you adapt so that
      network is queried every second hour. What about short time
      changes? What will happen if there is a failure after several
      minutes?

   A: We are not polling. The protocol follows the changes, when
      difference from the previous value is significant, a message
      will be sent immediately.

   Q: What about polling overhead? Routers should do useful work and
      polling introduces overhead.

   A: Aggregation is not performed in the router. None of the routers
      have to process more than 1 message per second.

   Q: You are using routers for points of observations. Is there any
      research about what are the better observation points for
      different applications?

   A: I am not aware of this.

5. Open Discussion

  Q: [AB] Discussion during the IETF ops-area meetings concentrated on
     NETCONF, XSD, data model contexts, concerns about document
     control, life cycle management. Is that something the IRTF can
     help with or IETF should do that. Is XSD good enough so we can
     move on?

  C: [DP] Work needs to be done. It is a serious issue when people
     need to do work on modeling and have no language. Work on finding
     a good language needs to be done quickly. Otherwise, every
     company will have its own way of doing things in different
     languages.

  Q: [AP] Do you want standard or research?

  A: [DP] IETF => standard

  Q: XML schema is a optimal language. What is the problem?

  A: [DP] Why it is not sufficient will be explained in standardization.

  C: Cannot wait for research activities. Think it is IETF activity.

  C: [DR] Focus should be what NMRG should do, what specific questions
     on research we should focus on, what data modeling techniques and
     languages are available. Suggest about research discussion on
     NETCONF data modeling. NMRG should prepare a state of art about
     what happens in research.

  C: [JS] SMING lesson is that being protocol independent gets
     difficult, perhaps people can write what the pitfalls are.
     Agreeing on syntax is part of engineering not research.

  C: Get more and more data from companies, research how much meta-data
     is used and how much it is read by humans, how much they read
     descriptive data.

  C: Perhaps we can produce a lessons learned document from the SMING
     experiment before Chicago

  C: [PD] I think a good topic for research should be manageability
     and in particular self-manageability, self, self... I didn't see
     guidelines how to build autonomic systems and components, how to
     build and manage them. This will be good topic for
     research. Suggest to form sub-group and come up with draft
     document. Some work in the IETF will be implemented as system
     entities which sooner or later support self manageability. Some
     documents in IETF have management related aspects. I would be
     interested in small subsection where entities have SELF inside?

  C: [JS] Do you mean interaction between control loops?

  C: Self-management networks are interesting as there you say how you
     can predict unexpected things.

  C: Still use aggregation, traffic aggregation, what properties were
     aggregated, combined. When you have 2 entities that interact some
     of their features disappear.

  C: Behavior can be harmful for the network

  C: [JS] Document what should be considered when autonomic work is
     done, such as control loop interactions

  C: Where is the authoritative control coming from: box or centralized
     entity?

  C: Acceptance of autonomic management correlates with policy based
     network approach acceptance. Should we research policy based network?

--yrj/dFKFPuw6o+aM--

Date: Wed, 21 Mar 2007 12:51:44 +0100
From: Michael Alexander <[email-masked]>
To: [email-masked], [email-masked]
Sender: Michael Alexander <[email-masked]>
Subject: [nmrg] Wed Mini/BOF Material 1/2 'Network Element/Facilities/Lines/Protocols/Services Data Modeling'

This is a multi-part message in MIME format.
--------------080409060000040601070802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Please find a strawman on draft-01 and an updated presentation for the 
Mini-BOF 'Network Element/Facilities/Lines/Protocols/Services Data 
Modeling' attached and at:

http://frankfurt.wu-wien.ac.at/ietf68/dm_ietf68_5.ppt
http://frankfurt.wu-wien.ac.at/ietf68/draft-alexan-datamod-01.txt

Best Regards,

Dr. Michael Alexander
WU Wien Dept. of Information Systems
[email-masked] / +43.1.31336.4467 GSM +43.699.1228.3586

--------------080409060000040601070802
Content-Type: text/plain;
 name="draft-alexan-datamod-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-alexan-datamod-01.txt"

Network Working Group                                       M. Alexander
Internet-Draft                                                   WU-Wien
Intended status: Standards Track                          March 21, 2007
Expires: September 22, 2007

            NE/Facilities/Lines/Protocols/Services Modeling
                      draft-alexan-datamod-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 22, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Alexander              Expires September 22, 2007               [Page 1]

Internet-Draft                Data Modeling                   March 2007

Abstract

   This draft presents a framework document for modeling network
   elements (NE), facilities, lines, protocols and services for
   substantially easing development and operation of element manager
   systems (EMS), network management systems (NMS) and operations
   support systems (OSS).  The framework is independent of the access
   method used, including SNMP, CLI, Netconf, Corba, CMIP, XML-RPC,
   etc.)  It covers configuration, alarms, current-historical
   performance, accounting management and security.  The frameworks
   builds on and reuses the existing base of MIBs.  The documents
   presents a light-weight, structured and very simplified framework and
   process to data modeling for defining and maintaining meta models,
   device etc. models, and device etc. descriptors.

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Backward Compatibility . . . . . . . . . . . . . . . . . . . .  9
   5.  Independence from Access Methods . . . . . . . . . . . . . . . 10
   6.  Core Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Secondary Scope  . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Items NOT in Scope . . . . . . . . . . . . . . . . . . . . . . 14
   9.  Dependencies-Requirements on Others  . . . . . . . . . . . . . 15
   10. Process-Cycle Time . . . . . . . . . . . . . . . . . . . . . . 16
   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 17
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   13. Normative References . . . . . . . . . . . . . . . . . . . . . 19
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21

Alexander              Expires September 22, 2007               [Page 2]

Internet-Draft                Data Modeling                   March 2007

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Alexander              Expires September 22, 2007               [Page 3]

Internet-Draft                Data Modeling                   March 2007

2.  Problem Statement

   Network Management (NM) standards have traditionally been focused on
   protocols, such as pertaining to configuration management and
   discovery.  Yet, all areas of Network Management, ranging from
   Element Management (EM) to Network Management Systems (NMS) and
   Service Management Systems have in common that they critically rely
   on underlying data structures describing devices and services being
   managed.  Network elements (NE) frequently spawn ten thousands of
   managed objects, such as for a multiservice switch.

   In a common fallacy, programmatic access methods towards an NE such
   as operations on attributes via SNMP, CLI or XML-Netconf etc. are
   frequently taken as equating to 'network management'.  Yet, in order
   for a Craft Terminal/EMS/NMS/Service Management System to provide
   sensible services to either a GUI operator or a mechanized interface,
   the device data of an NE has to be in a structured model.  Managed
   objects alone - but in rare cases - do not allow to provision a
   subscriber, retrieve an alarm, examine a performance metric etc.
   From e.g. an NMS viewpoint, they tend to be 'flat' data structures
   which need to be put into a defined structure the NMS can understand
   so to perform any logical flow of actions on them.  That is, a "flat"
   device attribute list does not enable an operator or mechanized
   interface to manage an NE.  Unfortunately, there is little
   commonality in data data models, respectively managed objects exposed
   by NEs to their northbound interfaces.  Even worse, the plethora of
   NMS/Service Managers each have their own models, leading to the
   present-day situation in which a large set of management systems with
   different models map to a large set of NEs with - differing models,
   both of which ever changing.

   The following comparison highlights the problem from an
   implementation-effort perspective: It takes an experienced NM person
   about a year to understand a medium-complexity carrier device's data
   model in its entirety.  This familiarity is necessary to build EMSs/
   NMSs/Service Management Systems with human-operable GUIs, or machine-
   to-machine interfaces for high-level operations (enable a service/
   disable a service etc.).  To adapt a given NMS's model for only one
   NM constituent, such as configuration management, the effort to
   initially map and then maintain the NE's to the NMS's data model is
   vast.  For example, only to cover configuration management of a
   single service of a multi-service switch man-years of effort may be
   necessary to match the two models.

   Yet in contrast, the effort to effect an attribute value change with
   SNMP, CLI or XML- Netconf etc. even with little prior knowledge of a
   device's functionality, model and behavior is comparatively
   minuscule.  Setting a given NE attribute via a prompted CLI may take

Alexander              Expires September 22, 2007               [Page 4]

Internet-Draft                Data Modeling                   March 2007

   an NM-person with only rudimentary knowledge of a given device
   minutes; SNMP, depending on the design of the MIB takes longer,
   similarly for XML or CORBA etc.  Comparing the discrepancy in the
   distribution of efforts again: the implementation of one leg of NM
   tends to be measured in man-years, the second leg of device access
   may range from man-hours to man-weeks.  Logically, one might suppose
   that standards development would match this distribution.

   Traditionally, standardization of access-methods (protocols),
   discovery, etc. have received most attention, while the more
   heterogeneous data models and data modeling per saw comparatively
   less.  As there are real possibilities to standardize underlying and
   universal commonalities in EMS/NMS/Service Management Systems on the
   one side and managed attributes of NEs, protocols, transmission
   facilities, lines and services on the other, the two distributions
   should be closer aligned.  Despite the complexity, it is possible to
   identify and define frameworks and meta models of each constituent
   and their relation to each other, that would substantially ease the
   management of present and future devices, networks and services.

   The problem was recognized early, but it took time until technologies
   such as markup languages, with their key property of being human
   readable, reached the mainstream and ubiquity: "Although some
   positive sentiment was expressed for defining a kind of "super SMI"
   metalanguage to aid in the definition of a general API, it was not
   clear whether the current crop of supporting protocols had sufficient
   semantic commonality to be used in this way.  The matter remains open
   for investigation."  [Vince Cerf, RFC 1109]

Alexander              Expires September 22, 2007               [Page 5]

Internet-Draft                Data Modeling                   March 2007

3.  Use Cases

   The framework addresses the following use cases:

   o  Design and Implementation of EMSs

   o  Design and Implementation of NMSs

   o  Design and Implementation of OSSs

   o  Design and Implementation of Northbound and Southbound Interfaces

   EMSs and NMSs are composed of the following main components: access
   to NEs, data model and database (a special case being '"MIB-less"
   managers with limited modeling and no database), NE-logic to augment
   NE methods or define new ones using entities from the NE's exposed
   management functionality, application logic, presentation logic,
   besides security and system functions at al.

   Over the mission-life of an EMS/NMS/OSS/SMS, the component that
   consomes a majority of design and development resources is the data
   models and their implementation.  This applies to single - NE/Service
   managers as well as multi NE-type or service managers where the
   efforts to initially define and stay current with the respective NE/
   service versions increases non-linearly.  In many cases point-of-
   diminishing returns are reached in multi-NE EMSs due to at large NE
   model differences.  They result in more and more device- specific
   adaptations and shortcuts to the EMS's own meta model or in the
   managers application logic leading to eventually highly comples and
   time-consuming coverage of additional devices and releases.

   EMS/NMS are the more usable the more depth the NEs models have.  In a
   polar extreme, the EMS with a GUI only offers and operator a flat
   representation of an NE data structure, requiring a fair amount of
   device/device model/device behavior knowledge on part of the the
   human operator.  If, however, the device model is detailed, an EMS
   can e.g. give the human operator a detailed

   Covering a new NE with e.g. 2000 managed objects based on an
   "average" MIB model in an existing EMS with pre-existing relatedd
   coverage takes -- depending on the granularity scope -- on the lower-
   end several manyears.  People doing the device integration have to
   build a well-structured, multi-level model of the device in order for
   the EMS to be easy to use for the human operator.

   If the device MIB does not adequately convey the NE behavior, the
   facility hierarchy and interrelation of objects and their attributes,
   the effort can be substantially higher.  The modeler(s) adding

Alexander              Expires September 22, 2007               [Page 6]

Internet-Draft                Data Modeling                   March 2007

   support for a particular device to an EMS may have to (re) model the
   equipment's hierarchy and discover its behavior through (lengthy)
   series of experiments.

   If, in contrast, if there is data model than conveys managed objects
   in a normative way and there is a normative namespace/meta model,
   then the task becomes substantially easier.  If, in addition, the
   device model specifies rules and equipment behavior in at least a
   semi-normative way, then high-depth support for the particular device
   in a fraction of the time than having to go from plain MIBs.

   Similarly, if the task were to build a prompted CLI for the device,
   the main effort would be create a definition file that specifies the
   CLI hierarchy levels and which operations would be permissible at a
   given level -- a formidable task for a large MIB.  In contrast, if
   there is a namespace/meta model in conjunction with a device data
   model that is based on a device class model, then the prompted CLI
   (but of the application logic) could to a large extend be derived or
   generated from the models.

   The same goes for building NMSs, which allow for drilling down into
   lines and devices.  Yet, NMSs in addition require alarm templates.
   Creating alarm templates involves in depth knowledge of the
   equipment's behavior, if it has not been properly abstracted.
   Creating alarm templates for root-cause analysis involving multiple
   devices without pre-existing models is highly time and resource
   intensive, possibly involving multiple testing cycles.  The proposed
   approach for simplifying alarm modeling is: an alarm meta model as
   part of the namespace/meta model and an alarm template class model as
   part of the device/service/protocol class model.

   Not a use case like the prior ones per se is the necessity to
   uniquely locate equipment, facilities, lines and their termination
   points in a network.  If a large number of network elements are
   involved, then they should be put into inventory using a schema which
   incorporates at least a unique serial, a unique product ID bound to
   the vendor partnumber, vendor partnumber, the container equipment
   (for e.g. cards), the organization's location classification (such as
   country/city/location/room), a unique serial and dating.  There needs
   to be a meta model for inventory codes and schemata for the
   individual types of inventory.  The binding between the equipment
   type categories and the unique serial could be done based on a
   normative registry, similar to the binding between domains and IP
   address in DNS.

   Implementing EMSs/NMSs/CLIs and OSS interfaces are different use
   cases from the creation of device models.  Provided a namespace/and
   class-type meta models for the device exist, individual vendors can

Alexander              Expires September 22, 2007               [Page 7]

Internet-Draft                Data Modeling                   March 2007

   model their own devices or charter 3rd parties to do so, thereby
   allowing a wide range of NMS/OSS software to recognize and manage
   their devices.  They could be cataloged and put into a repository,
   and be bound against the various (vendor dependent) unique serials
   from the last paragraph.

Alexander              Expires September 22, 2007               [Page 8]

Internet-Draft                Data Modeling                   March 2007

4.  Backward Compatibility

   MIBs are the most common data structure for internal device data
   representation.  MIBs are also the most common non-proprietary EMS/
   NMS/OSS data representations.  The investment in them is vast, hence
   it should be preserved.  Therefore, backward compatibility with MIBs
   SHALL be preserved.  Existing MIBs need to be covertable ("import")
   into the new set of DM models.  This can be done in two ways: (a) the
   could be converted into an applicable regular namespace, or in as
   free form variant not having the property of a direct line to a
   common root.  Reverse imports of DM Models into MIBs is not feasible.

Alexander              Expires September 22, 2007               [Page 9]

Internet-Draft                Data Modeling                   March 2007

5.  Independence from Access Methods

   Data Models need to be independent of access methods; Talking to a
   device via SNMP, a CLI, Netconf, CORBA, XML-RPC, Batch Config
   Transfer, etc. is relatively insignificant in time/resources relative
   to designing-implementing-maintaining data models.  For example, a
   clean data model of a 5000 managed objects device can be talked to in
   ANY of the above access methods provides the device has an agent that
   exposes the objects.

   The ratio of efforts between adapting an an EMS/NMS/OSS to talk to a
   particular device access method protocol agent to refining an average
   MIB data model that use approaches 0 the more complex a devices is.

Alexander              Expires September 22, 2007              [Page 10]

Internet-Draft                Data Modeling                   March 2007

6.  Core Scope

   The core initial focus includes a set of meta models, an initial
   network type focus, and service focus.  Prior to that, a set of
   initial namespaces is necessary:

   o  Base equipment hierarchy (rack::power::supplies::shelf::slot::
      port::facility::protocols ::services

   o  Base network types: IP, SDH SONET, ATM, Ethernet

   The proposed initial network type focus is: IP-Routing, Ethernet,
   SDH/SONET and ATM.  The proposed initial services to model are:
   barebones SIP, Ethernet VLANs, DiffServ (as a service in the models).

   Prerequisite to model network types or services are a set of meta
   models shown in Figure 1 below:

   The respective layers are explained in the following.

   +-----------+------------------------------------------------------+
   | Layer VII |   Device/Line/Service/Protocol Instance              |
   +-----------+------------------------------------------------------+
   | Layer VI  |   Device/Line/Service/Protocol Model                 |
   +-----------+------------------------------------------------------+
   | Layer V   |   Device/Line/Service/Protocol Type Meta Model       |
   |           |     Derived from class model                         |
   |           |     Captures behavior, rules                         |
   +-----------+------------------------------------------------------+
   | Layer IV  |   Device/Line/Service/Protocol Class Meta Model      |
   |           |     Alarm template class model                       |
   +-----------+------------------------------------------------------+
   | Layer III |   Namespaces/Meta Model                              |
   |           |     Derived from existing CLI (option?),from scratch |
   |           |     Constructs etc.                                  |
   |           |     Alarm template meta model                        |
   +-----------+------------------------------------------------------+
   | Layer II  |   Object Model                                       |
   |           |     Prototype methods-operations, data types         |
   +-----------+------------------------------------------------------+
   | Layer I   |   Access Method                                      |
   |           |     SNMP, CLI, Netcon, CMIP, CORBA, XML-RPC, SOAP .. |
   +-----------+-----------------------------------------------------+

                                 Figure 1

   Layer I (Access Method) is the protocol used to talk to the NE.  As
   emphasized before, in the existing status-quo given different data

Alexander              Expires September 22, 2007              [Page 11]

Internet-Draft                Data Modeling                   March 2007

   models on the device and on the mansger, the effort to code the NE
   communication with a gicen protocol is relatively low compared to
   refining the respective manager models to match that of the device.
   I.e. is the access methods offers sufficient operations to act on a
   given managed object, the choice of protocol may be a matter of other
   criteria.

   Layer II (Object Model) defines the base primitives including
   operations that can effect managed objects.  A superset of data types
   should also be defined in this layer.

   Layer III (Namespaces/Meta Model) is (a) concerned with the naming
   hierarchies (namespaces) for devices/lines/services and protocols.
   For example, part of the base equipment hierarchy from before (rack::
   power::supplies::shelf::slot::port::facility) would form a namespace.
   The meta model is (b) the prototype model for the higher layer
   device/line/service/protocol {Class Meta Model, Type Meta Model,
   Model and Instance}.  That is, it integrates the object model and the
   namespaces and provides a framework model for the higher layers and
   defines constructs, language they can utilize.  In addition, a meta
   model for alarm templates needs to be defined at this layer.

   Layer IV (Device/Line/Service/Protocol Class Meta Model) defines meta
   models for classes of e.g. devices.  An example for classes of
   devices are Routers, Ethernet switches, or ATM switches.  In the same
   layer, alarm template class models (deriving from the alarm template
   model on Layer III) need to be defined in order to support root-cause
   alarming with a high degree of accuracy.

   Layer V (Device/Line/Service/Protocol Class Type Model) extends the
   Layer IV Class Meta Model.  It futher focuses the type of device-
   line/service/protocol.  For example, the class routers might branch
   into routing switches, pure IP routers, multi-protocol routers,
   access routers, edge routers, core routers, etc.  Furthermore, the
   layer suits defintions of rules and attributes describing the
   equipment type's behavior.

   Layer VI (Device/Line/Service/Protocol Model) extends with
   information that is particular to a specific device/line/service/
   protocol.  For devices, this might be a specific product or product
   range in case of an equipment vendor.  For services, it might be a
   service as deployed by a specific operator.

   Layer VII (Device/Line/Service/Protocol Instance) is the actual
   instance of the e.g. device model which could be a data model for a
   particular vendor's device at a given release level.

Alexander              Expires September 22, 2007              [Page 12]

Internet-Draft                Data Modeling                   March 2007

7.  Secondary Scope

   The secondary scope follows in sequence after the intial scope,
   largely because of dependencies.  It includes:

   o  Unique equipment/line locators

   o  Alarm template registries

   o  Protection, failover modeling (1+1, 1:n, 1:1, etc.)

   o  Device/service/protocol models to be defined in the respective
      areas/WGs

   Unique equipment/line locators have been discussed before as a use
   case.  As indicated, a schema which incorporates at least a unique
   serial, a unique product ID bound to the vendor partnumber, vendor
   partnumber, the container equipment, the organization's location
   classification (such as country/city/location/room), a unique serial
   and dating is necessary.  This needs to be in conjunction with a meta
   model for inventory codes and schemata for the individual types of
   inventory.  The binding between the equipment type categories and the
   unique serial could be kept in a public database similar to a
   registry.

   Along the same lines, (a) registry(ies) could be formed for alarm
   templates.  The secondary scope also includes protection, failover
   modeling (1+1, 1:n, 1:1, etc.), which involves a revision of all
   metamodel.  At the 2nd stage in the effort, it could also be trialed
   that individual areas/ working groups define their Device/service/
   protocol models independently, based on the underlying meta models.

Alexander              Expires September 22, 2007              [Page 13]

Internet-Draft                Data Modeling                   March 2007

8.  Items NOT in Scope

   The data model SHALL NOT include support for Business Support Systems
   (BSS) and workflow in general.  It is not set to cover all aspects of
   enterprise and carrier network operations. et ...

Alexander              Expires September 22, 2007              [Page 14]

Internet-Draft                Data Modeling                   March 2007

9.  Dependencies-Requirements on Others

   There are no hard requirements on other efforts.  One item, for which
   there exists a workaround, would be good to have at the earliest
   point though is a Netconf RPC call in-line with the DM object model
   (layer II): Netconf 1.0 presently allows for free-form RPC calls.
   The DM effort and anybody involved in EMS/NMS/OSS modeling would in
   general greatly benefit if devices were to expose more high-level
   functions/methods.  For example, instead of having to set a large
   number of attributes in order to provision a customer on a given
   port, a method provision_customer() exposed by the NE, described in
   the data model and called by the EMS/NMS/OSS would greatly reduce
   complexity.  Having a formalized method call which is congruent with
   the object model might induce more vendors to expose simplified
   methods in their devices.

   Elegant integration of management information into protocol
   specifications natural gets much easier for protocol designers if
   Protocol Class Meta Model is available.  Once this is the case,
   individual working groups outside the OPS area should be able to
   define their own protocol models.  Hence, there is a depency from
   them on the availability of the meta models.

Alexander              Expires September 22, 2007              [Page 15]

Internet-Draft                Data Modeling                   March 2007

10.  Process-Cycle Time

   The complexity for DM is significantly higher than for many protocols
   (e.g. not TCP though).  A high initial rate of changes in the
   specifications is expected until steady-state is reached.  Still,
   even in steady-state a comparatively large number of changes per
   revision is expected to be occuring in the regular update cycle.

   Branches of the models outside the main modeling effort will need to
   be allowed.  Here, the process might become to fold normative schema
   extensions into main as much as possible, allowing of private
   branches and allowing specialization without folding.

   The target time for the first iteration of the initial scope is one
   year.  The projected cycle times are:

   o  Device/Line/Service/Protocol Instances: on discretion of
      equipment/nm vendors

   o  Device/Line/Service/Protocol Model: initial: 6 months, steady-
      state 6 months, synced with protocols

   o  All meta models: initial: 6 months, steady-state 8-9 months

   o  Object model and data types: initial: 6 months, steady-state 3-4
      years or longer

Alexander              Expires September 22, 2007              [Page 16]

Internet-Draft                Data Modeling                   March 2007

11.  Open Issues

   Three issues are not addressed in the present draft: Rules language,
   metamodel language and the issue of state model inclusion and
   language.

   While data modeling is frequently using overspecification (which
   facilitates device modeling), the immediate benefit from the
   inclusion of a state model and a state model specification language
   from the onset is not clear.  Once at least the primary scope has
   completed, the addition of state model information would aid the EMS/
   NMS/OSS modeler in further codifying the equipment's behavior,
   facilitating tasks such as decising on the sequence when to issue
   operations and with timing issues in general.

   Similarly, rules could be specified in a separate rules language,
   which could be added at a later point.  The issue is different,
   however, for a metamodel language.  Having a full language for it
   would greatly increase expressivity.  Introducing a metamodel
   language at a different time than from the onset is not a good option
   though.

Alexander              Expires September 22, 2007              [Page 17]

Internet-Draft                Data Modeling                   March 2007

12.  Security Considerations

   The framework goes beyond assuming both the management stations and
   the NEs being in secure networks.  The Meta models SHALL include both
   authentication and multi-level authorization which to be defined in
   separate drafts.  The frameworks covers both, manging of NEs
   providing security functionality, and the authentication and
   authorization of the NEs per se.

Alexander              Expires September 22, 2007              [Page 18]

Internet-Draft                Data Modeling                   March 2007

13.  Normative References

   [RFC1109]  Cerf, V., "Report of the second Ad Hoc Network Management
              Review Group", RFC 1109, August 1989.

   [RFC1155]  Rose, M. and K. McCloghrie, "Structure and identification
              of management information for TCP/IP-based internets",
              STD 16, RFC 1155, May 1990.

   [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
              "Simple Network Management Protocol (SNMP)", STD 15,
              RFC 1157, May 1990.

   [RFC1212]  Rose, M. and K. McCloghrie, "Concise MIB definitions",
              STD 16, RFC 1212, March 1991.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,
              December 2006.

Alexander              Expires September 22, 2007              [Page 19]

Internet-Draft                Data Modeling                   March 2007

Author's Address

   Michael Alexander
   Wirtschaftsuniversitaet Wien
   Augasse 2-6
   Vienna  1090
   Austria

   Phone: +43.1.31336.4467
   Email: [email-masked]

Alexander              Expires September 22, 2007              [Page 20]

Internet-Draft                Data Modeling                   March 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Alexander              Expires September 22, 2007              [Page 21]


--------------080409060000040601070802
Content-Type: application/vnd.ms-powerpoint;
 name="dm_ietf68_5.ppt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="dm_ietf68_5.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAGAAAA3QIAAAAA
AAAAEAAA/v///wAAAAD+////AAAAANcCAADYAgAA2QIAANoCAADbAgAA3AIAAP//////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////zu//jIylzqWM
///v////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////zs7e3u/v7+/ezs7OjKXOtYyM
zs61jLXOtYyMzs61tc7OjKW1tYyMzs61zu/v/97OjLXejIyM/9613t7vpc7epaWl3rWMtd7/
3s6lzrXO///vjLXejIyM/961////////td7/3s6lzrXO///vzs7ejLXOtYyMzs61zu/v/97O
zt7vjKW1tYyMjLW1tYyMzt7OjKW1tYyMpc7O/961////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////jLXejIyMjIyM3rWMpc7vtYyMzs61jLXO
pYyMjKWlzqWMpc7etYyMjLW1jIyM/961zs7etd7v/9613t7v3t7Ozs7v3t7ezs61pbXOzt7O
/97Ozs7ezu/v797OjKXO/961zs7epbXOzt7O/97Ozs7ejLXOpYyMjKWljIyM/961////pc7v
pYyMjKWlzqWM///vpc7vtYyM3t7O///v////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////zs7e///v////////
////////////////////////zu//paWl/97Ozu//jIyljIyMtYyM///e////////////////
////////////////////////////////7+/v////////////////////////////////////
////////////7///jKXO/961////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////zu//3rWltd7/786lzs7e
zs7O///vpc7v/961jLXe3rWMjLXetYyMzs61zu/v797OjKXOtYyM3t7O///vpc7v/961jLXe
3rWMjLXejIyM/961zs7ezu/v/97Ozs7etd7v786ljLXetYyMzs61///vjLXe3rWMzs7epc7e
7961jKXOtYyMpc7O/961////////zu//3rWltd7/786lzs7ejLXOtYyMzs61zu/v/97O////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////3t7/zs7O3t7O3t7ezs7OjLXO786l
3t7v///vjLXe3s6ljKXOzqWMtbXOzu/e/97Opc7vtYyM3t7O///v3t7v///vjLXe786lzs7e
zu/v/97OjLXejIyM/961tc7ezrW1zs7ejLW1pYyMjKWl786ljLXe786lzs7e3t7e///vtd7/
zqWl3t7O///v////////3t7/zs7O3t7O3t7ezs7OjLXOpYyMjKWljIyM/961////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////zs7ezu/v3rWlzt7/7961////7///jKXO/961
////////////////pc7ezqWl///v////////jLXe7961jKXO/961////////////////////
////////////7+/v////////////////////////////////3u/vjKXO/961pc7vzrWMjKXO
/961////////zs7ezu/v3rWlzt7/7961////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////zs7e///v////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
3u///+/e////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////pc7vjIyM786ljLXetYyMjLW1jIyM7961jKXOtYyM
zs61///vpc7v/961zs7e3u/v7+/e3s7OjLXetYyMzs61zu/v/97Opc7v/961////////jLXe
jIyM/9613t7v///v////3t7vzs7Ozu/v/97O3t7v///vjLXejIyM/961zs7e///vzs7e3u/v
7+/ezs7OjKXOtYyMpc7O/961zs7ejLXOjIyM/961zs7ezu/v/97O7///jKXOtYyMtd7e786l
jLXe3rWMpc7v/961jLXetYyMzs613u/v7+/e3s7OjLXe3rWM////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////3t7v///vzs7ejLXOpYyMjKWljIyM/961pc7vtYyMjLW1786l
3t7v///vjLXejIyMjIyM3rWMjLXepYyMjKWljIyM/9613t7v///v////////jLXejIyM/961
3t7v///v////3t7vjLXOjIyM/9613t7v///vjLXejIyM/961jLXe786ljLXejIyMjIyM3rWM
pc7vtYyM3t7O///vzs7ejLXOjIyM/961jLXejIyM/961////3v//taW1zrW1zs7ejLW1786l
3t7v///vjLXepYyMjKWljIyMjIyM3rWMjLXe786l////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////pc7vjIyM3rWM////////////////////////////////7///jKXO/961
////////////////////////////////7///jKXO/961////////////////////jLXe/961
////3t7v///v////////jLXe/961////////////////////////////////////////7///
jKXO/9617+/v////////////////////////////jLXezqWM///v////////7///jKXO/961
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////pc7vjIyM786lzs7e3t7e///v3t7vtd7v
786l3t7vzs7OjLXOtYyMzs61zu/v797OjKXOtYyMjLW1tYyMzs61///v////////7///tc7O
taW13s61zs7ejLXOtYyMzs61tc7OjKW1tYyMzs61zu/v/97OjLXejIyM/961jLXetYyMzs61
///v////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////3t7v///vzs7ejLXO786l////3t7vzs7Ozs7e3t7O
tc7OjKW1zqWMtbXOzu/e/97Opc7vtYyMjLW1pYyMzrWl///v////////////3t7/zu/e/97O
zs7ejLXOpYyMjKWlzqWMpc7etYyMjLW1jIyM/961zs7etd7v/961jLXepYyMjKWl786l////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////pc7vjIyM3rWM////////////pc7v/9613v//zqW17+/e////
////pc7ezqWl///v////////////////zs7e///v////////////3v//tYy1///ezs7e///v
////////////////////////////////zu//paWl/97O////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////5///AGu1AAAA
lAAA///O////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////tc7//+e1
lM7/AAAAtWsA///nlJTO///Otc7//+e1////lM7/AAAAlAAA///Oa7XnAAAAawAA/+e1////
////////////////////tc7//+e1////////lLXn/+e1AJTOAAAAtWsAa7XOAAAAzpQAlM7/
AAAAawAA/+e1lM7/AAAAlAAA///O////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////tc7//+e1tc7//+e1
////////lJTO///Otc7//+e1////lJTO///OlM7//86UlJTO///OlLXn/+e1////////AJTO
tWsA///n////lM7/awAA/+e1////lLXn/+e1a7XnAAAAtWsAa7XOAAAA57VrtbXn///Otc7/
/+e1tbXO///n////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////tc7//+e1lM7/AAAAtWsA///n
lJTO///OlM7/AAAAzpQAAJTOAAAAtWsA///ntef/AABr57Vr////////////////////////
////tc7/5+e1a2u1/+e1a7XnawAAlLW1AAAAtWsAAJS1AAAAlAAAtbW1///Otc7//+e1a7Xn
AAAAlAAA///O////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////tc7//+e1lM7/AAAAlGsAAGuUAAAAawAA
lLW1AAAAzpQAlM7/AAAAtWsA///na7XnAAAAawAA/+e1////////////////////////lM7/
AAAAAAAA/86U////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////a7XnAAAAAAAAtWsA///n
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////lJTO///O////a7Xn/86U////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////tef/AABrAAAAAAAAzpQA////lM7/AAAAAAAA
lAAA///O5///AGu1lAAAlM7OAAAAAAAAlAAA///O////////tef/zpRr////lM7/tWsA///n
zv//tWuU///n5///AGu1AAAAlAAA///O5///AGu1AAAAa2sA57WU5///AGu1AAAAAAAA/86U
lM7/57VrlM7/57VrlM7/57Vr////lM7/57Vrtef/AABrAAAAlAAA///O////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////tef/zpRr////////AJTO57Vra7Xn/86U5///lGu1///O
zv//tWuU///na7Xn/86U5///lGu1///O////////tef/zpRr////a5TOa5SU/86Uzv//tWuU
///na7Xn57Vr////lM7/zpQAlM7/57Vr////lM7/57Vra7Xn/86U////////////lM7/57Vr
lM7/57VrlM7/57Vr////lM7/57VrlLXn/+e1////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////tef/zpRr////////tef/zpRrtef/AABrAAAAlAAA///Ozv//tWuU
///ntef/AABrAAAAlAAA///O////////tef/zpRrtef/tWtrtefnzpRrzv//tWuU///na7Xn
/86U////zv//tWuUa7XO/86U////lM7/57Vra7XnAAAAAAAAAAAA57VrlM7/57VrlM7/57Vr
lM7/57Vr////lM7/57Vrtef/AABrAAAA57Vr////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////tef/zpRr////////tef/zpRr////////5///lGu1///Ozv//tWuU///n////
////5///lGu1///O////////tef/zpRra7Xn/86U////a5TOzue1tWuU///na7Xn57Vr////
lM7/zpQAlM7/57Vr////lM7/57Vra7Xn57Vr////lM7//86UlM7/57VrlM7/57VrlM7/tWsA
///nlM7/57Vra7Xn/86U5///lGu1///O////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////tef/zpRr////////AJTO57VrlM7/AAAAAAAAzpQA5///AGu1AAAAlAAAlM7OAAAAAAAA
zpQA////////////tef/lJRrtWuU///n////tef/tbWUtWuU///n5///AGu1AAAAawAA/+e1
5///AGu1AAAAAAAA57Vr5///AGu1AAAAtWsA///nlM7/57VrlM7/57VrlM7/lJRrAABrawAA
/+e1tef/AABrAAAAAAAA57Vr////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////tef/
AABrAAAAAAAAzpQA////////////////////////zv//tWuU///n////////////////////
////////tef/AABr57Vr////////5///AGu1tWsA///n////////////////////////////
////lM7/57Vr////////////////////lM7/57Vr////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////lM7/
57Vr////////////////////lM7/57VrlM7/zpQA////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
--------------080409060000040601070802--

Content-class: urn:content-classes:message
Date: Wed, 21 Mar 2007 07:14:46 -0400
From: "Natale, Bob" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: [nmrg]  Wed Mini-BOF G, "MIBs to SOA/WS resource models" presentation

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76BAA.1AAF36D6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Apologies for the late posting.  These are the slides to be discussed
during the OPS Area Mini-BOF G this afternoon.

[Dan/Dave, please post the session presentations page...I could not
find instructions for doing this myself.]

Cheers,
BobN

------_=_NextPart_001_01C76BAA.1AAF36D6
Content-Type: application/vnd.ms-powerpoint;
	name="Converting SNMP MIBs to SOA-WS Resource Models.ppt"
Content-Transfer-Encoding: base64
Content-Description: Converting SNMP MIBs to SOA-WS Resource Models.ppt
Content-Disposition: attachment;
	filename="Converting SNMP MIBs to SOA-WS Resource Models.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAkgAAAAAAAAAA
EAAAlAAAAAEAAAD+////AAAAAJkAAACTAAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////wEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA
AAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAA/v//////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------_=_NextPart_001_01C76BAA.1AAF36D6--

Date: Wed, 21 Mar 2007 00:30:42 +0100
From: Michael Alexander <[email-masked]>
To: [email-masked], [email-masked]
Sender: Michael Alexander <[email-masked]>
Subject: [nmrg] Wed Mini/BOF Material 1/2 'Network Element/Facilities/Lines/Protocols/Services Data Modeling'

This is a multi-part message in MIME format.
--------------020107050005070700070008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Please find the draft-00 and presentation for the Mini-BOF 'Network 
Element/Facilities/Lines/Protocols/Services Data Modeling' attached and at:

http://frankfurt.wu-wien.ac.at/ietf68/dm_ietf68.ppt
http://frankfurt.wu-wien.ac.at/ietf68/draft-alexan-datamod-00.txt

http://frankfurt.wu-wien.ac.at/ietf68/draft-alexan-datamod-01.txt 
(strawman to follow shortly)

Best Regards,

Dr. Michael Alexander
WU Wien Dept. of Information Systems
[email-masked] / +43.1.31336.4467 GSM +43.699.1228.3586

--------------020107050005070700070008
Content-Type: application/x-zip-compressed;
 name="ietf68_1.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="ietf68_1.zip"

--------------020107050005070700070008--

Date: Mon, 19 Mar 2007 14:28:11 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Natale, Bob" <[email-masked]>
Subject: Re: [OPS-AREA] RE: [nmrg] Re: Comments Question aboutdraft-xu-cops-push-00.txt
Mail-Followup-To: "Natale, Bob" <[email-masked]>, "Durham, David" <[email-masked]>, xuheyuan <[email-masked]>, [email-masked], [email-masked], Hexian Huang <[email-masked]>, [email-masked], [email-masked], Tina Tsou <[email-masked]>
Cc: xuheyuan <[email-masked]>, [email-masked], "Durham, David" <[email-masked]>, [email-masked], Tina Tsou <[email-masked]>, Hexian Huang <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]

On Mon, Mar 19, 2007 at 08:51:05AM -0400, Natale, Bob wrote:
 
> [...] The mini-BOF will
> propose a WG to determine the actual make-up of that "best fit" from
> among a set of reasonable alternatives...a degree of "business
> judgment" might not to be applied over and above technical analysis in
> making a final determination, as many of the related standards and open
> source reference projects are at early stages of maturation.

I believe this approach is asking for endless discussions. I would
very much prefer to see a critical number of people agreeing on a
particular approach and committing themself to put energy into working
out the details before a WG is being chartered. Well scoped WGs have a
much better chance to complete in time (whatever that means in the
IETF ;-).

I had the pleasure to participate in a few WGs trying to formulate
requirements before doing the actual work and this has always been a
pain and if you ask me a waste of time. (There might be WGs where this
requirements approach works well but then I did not have the pleasure
to participate in those WGs - or it is because of my absence that it
worked out well. ;-)

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

Content-class: urn:content-classes:message
Subject: RE: [OPS-AREA] RE: [nmrg] Re: Comments Question aboutdraft-xu-cops-push-00.txt
Date: Mon, 19 Mar 2007 08:51:05 -0400
From: "Natale, Bob" <[email-masked]>
To: "Durham, David" <[email-masked]>, <[email-masked]>,  "xuheyuan" <[email-masked]>
Cc: [email-masked], [email-masked], Hexian Huang <[email-masked]>, [email-masked], [email-masked], Tina Tsou <[email-masked]>

Hi Dave,

If I understand your position correctly, then the intent of the
mini-BOF that I will brief is find the "best fit" means of making SNMP
MIBs -- which, at least IMHO, represent the crown jewels of what the
IETF O&M community has given to the practice of network management --
more directly accessible by SOA/WS management tools.  The mini-BOF will
propose a WG to determine the actual make-up of that "best fit" from
among a set of reasonable alternatives...a degree of "business
judgment" might not to be applied over and above technical analysis in
making a final determination, as many of the related standards and open
source reference projects are at early stages of maturation.  This is
more an exercise in standardizing a resource modeling methodology, as
opposed to a new management protocol.

Rushed,
BobN

-----Original Message-----
From: Durham, David [mailto:[email-masked]] 
Sent: Saturday, March 17, 2007 7:23 PM
To: [email-masked]; xuheyuan
Cc: [email-masked]; [email-masked]; Hexian Huang;
[email-masked]; [email-masked]; Tina Tsou
Subject: [OPS-AREA] RE: [nmrg] Re: Comments Question
aboutdraft-xu-cops-push-00.txt

If the goal is to use XML, then why reinvent the wheel on webservices
for management outside of the W3C and DMTF? 
SNMP, COPS, DIAMETER, NETCONF... Where does it end?

Is there an RFC that does a thorough analysis of the alternatives
(IETF's and other standards bodies' included) in terms of capabilities,
latency, bandwidth, complexity, backward compatibility and other such
quantitative metrics? If not, this might be a helpful activity as the
mailing list discussions quickly become crystal ball gazing and
philosophical in nature. Then folks can figure out if their
requirements
make a better fit for one protocol over another. 

-Dave

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Juergen Schoenwaelder
> Sent: Thursday, March 15, 2007 7:47 AM
> To: xuheyuan
> Cc: Tina Tsou; [email-masked]; [email-masked];
Romascanu,
Dan
> (Dan); Hexian Huang; Tom-PT Taylor; [email-masked]; ops-
> [email-masked]
> Subject: [nmrg] Re: Comments Question about draft-xu-cops-push-00.txt
> 
> On Thu, Mar 15, 2007 at 10:19:18PM +0800, xuheyuan wrote:
> 
> > At that time the Re reference point, merged into Rw reference point
> > later, controlled the IP edge, actually an IP-IP gateway. In the
> > current network, most existing IP-IP gateways are routers, which
> > support COPS already. In reality, using COPS is the quickest way to
> > do that as described in approach 2 in this draft.
> 
> I have routers that support NETCONF in my lab and no routers
> supporting COPS-PR or COPS.  Perhaps this is why our views of the
> world are somewhat different.
> 
> > COPS-PR by nature does policy control, Rw interface mainly does
> > policy control dynamically, not just push configuration
> > information. Besides, in 2005,NETCONF was a pretty new protocol,
and
> > few existing routers supported NETCONF.
> 
> I never understood the distinction between configuration and policy
> information when it comes to the device interface. The PDP is the
> policy engine and what comes out of this engine as provisioning
> information is for me not really distinct from configuration data
> coming out of other systems (e.g. customer provisioning systems).
> 
> I agree that NETCONF was pretty new in 2005 and it still is in 2007.
> COPS-PR is older but as far as I can tell not too widely implemented
> and the number of people within the IETF who do understand COPS-PR
> well is like to be somewhat smaller than the number of people within
> the IETF who understand NETCONF and my impression was that COPS-PR
> awareness declines.
> 
> > As RACF supports both fix and mobile, push and pull modes, in the
> > real networking, PD-FE may possibly support both modes, and in pull
> > modes, COPS is very effective, so, in push mode, if approach 2 COPS
> > could be adopted, it will simplify the implementation.
> 
> The implementation simplification is a relative thing (if you have
> COPS, using COPS is simple, if you have NETCONF, using NETCONF is
> simple). Not sure how to make a decision on this.
> 
> Again, I like to see the discussion raised to the technical level to
> first understand if NETCONF could do what you need it to do equally
> well or whether there is any technical feature that really
> distinguishes COPS-PR from NETCONF.
> 
> /js
> 
> --
> Juergen Schoenwaelder		 Jacobs University Bremen
> <http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725
Bremen,
> Germany
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To unsubscribe
or
> adjust
> !! your settings, send a mail message to
<[email-masked]>
> !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area

Date: Mon, 19 Mar 2007 03:03:22 -0700
From: Andy Bierman <[email-masked]>
To: "Durham, David" <[email-masked]>
Subject: Re: [OPS-AREA] RE: [nmrg] Re: Comments Question about	draft-xu-cops-push-00.txt
Cc: xuheyuan <[email-masked]>, [email-masked], [email-masked], [email-masked], Tina Tsou <[email-masked]>, Hexian Huang <[email-masked]>, [email-masked], [email-masked]

Durham, David wrote:
> If the goal is to use XML, then why reinvent the wheel on webservices
> for management outside of the W3C and DMTF? 
> SNMP, COPS, DIAMETER, NETCONF... Where does it end?
>   

I would assume it ends when vendors are given a reasonable solution
that they can deploy in their products at a reasonable cost.
NETCONF is designed to be an "evolution of the CLI",
which can be integrated with the native CLI API relatively easily.

Hopefully,  the migration away from informally documented ad-hoc CLI
with no structured error return codes, towards structured XML with
standard operations and return codes, is enough to foster  interoperability
and improve tool automation.

IMO, protocols which totally ignore the existence of the CLI based 
management,
and rely on large amounts of new code and new data models for success,
will never be adopted by the NE vendor community.

Andy

> Is there an RFC that does a thorough analysis of the alternatives
> (IETF's and other standards bodies' included) in terms of capabilities,
> latency, bandwidth, complexity, backward compatibility and other such
> quantitative metrics? If not, this might be a helpful activity as the
> mailing list discussions quickly become crystal ball gazing and
> philosophical in nature. Then folks can figure out if their requirements
> make a better fit for one protocol over another. 
>
> -Dave
>
>   
>> -----Original Message-----
>> From: [email-masked]
>>     
> [mailto:[email-masked]]
>   
>> On Behalf Of Juergen Schoenwaelder
>> Sent: Thursday, March 15, 2007 7:47 AM
>> To: xuheyuan
>> Cc: Tina Tsou; [email-masked]; [email-masked]; Romascanu,
>>     
> Dan
>   
>> (Dan); Hexian Huang; Tom-PT Taylor; [email-masked]; ops-
>> [email-masked]
>> Subject: [nmrg] Re: Comments Question about draft-xu-cops-push-00.txt
>>
>> On Thu, Mar 15, 2007 at 10:19:18PM +0800, xuheyuan wrote:
>>
>>     
>>> At that time the Re reference point, merged into Rw reference point
>>> later, controlled the IP edge, actually an IP-IP gateway. In the
>>> current network, most existing IP-IP gateways are routers, which
>>> support COPS already. In reality, using COPS is the quickest way to
>>> do that as described in approach 2 in this draft.
>>>       
>> I have routers that support NETCONF in my lab and no routers
>> supporting COPS-PR or COPS.  Perhaps this is why our views of the
>> world are somewhat different.
>>
>>     
>>> COPS-PR by nature does policy control, Rw interface mainly does
>>> policy control dynamically, not just push configuration
>>> information. Besides, in 2005,NETCONF was a pretty new protocol, and
>>> few existing routers supported NETCONF.
>>>       
>> I never understood the distinction between configuration and policy
>> information when it comes to the device interface. The PDP is the
>> policy engine and what comes out of this engine as provisioning
>> information is for me not really distinct from configuration data
>> coming out of other systems (e.g. customer provisioning systems).
>>
>> I agree that NETCONF was pretty new in 2005 and it still is in 2007.
>> COPS-PR is older but as far as I can tell not too widely implemented
>> and the number of people within the IETF who do understand COPS-PR
>> well is like to be somewhat smaller than the number of people within
>> the IETF who understand NETCONF and my impression was that COPS-PR
>> awareness declines.
>>
>>     
>>> As RACF supports both fix and mobile, push and pull modes, in the
>>> real networking, PD-FE may possibly support both modes, and in pull
>>> modes, COPS is very effective, so, in push mode, if approach 2 COPS
>>> could be adopted, it will simplify the implementation.
>>>       
>> The implementation simplification is a relative thing (if you have
>> COPS, using COPS is simple, if you have NETCONF, using NETCONF is
>> simple). Not sure how to make a decision on this.
>>
>> Again, I like to see the discussion raised to the technical level to
>> first understand if NETCONF could do what you need it to do equally
>> well or whether there is any technical feature that really
>> distinguishes COPS-PR from NETCONF.
>>
>> /js
>>
>> --
>> Juergen Schoenwaelder		 Jacobs University Bremen
>> <http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen,
>> Germany
>> --
>> !! This message is brought to you via the `nmrg' mailing list.
>> !! Please do not reply to this message to unsubscribe. To unsubscribe
>>     
> or
>   
>> adjust
>> !! your settings, send a mail message to
>>     
> <[email-masked]>
>   
>> !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
>>     
>
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ops-area
>
>
>   

Date: Sun, 18 Mar 2007 16:02:44 -0700 (PDT)
From: Michael Kirkham <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: [email-masked], [email-masked], "MIB Doctors \(E-mail\)" <[email-masked]>, IETF MIBs <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: [nmrg] Re: [IETFMIBS] Updated OPS Area meetings agenda

With regard to the MIB and XML stuff on the agenda, I would like to point 
out:

http://www.muonics.com/XMLSMI/Schema/XML-SMI-2.1.xsd

And examples:

http://www.muonics.com/XMLSMI/samples/rfc3411.xml
http://www.muonics.com/XMLSMI/samples/rfc3418.xml
http://www.muonics.com/XMLSMI/samples/rfc2578.xml
http://www.muonics.com/XMLSMI/samples/rfc2579.xml

--
Michael Kirkham
President & CEO
Muonics, Inc.
http://www.muonics.com/

On Sun, 18 Mar 2007, Romascanu, Dan (Dan) wrote:

> Date: Sun, 18 Mar 2007 17:35:07 +0200
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: [email-masked], [email-masked],
>     "MIB Doctors (E-mail)" <[email-masked]>,
>     IETF MIBs <[email-masked]>, [email-masked],
>     [email-masked]
> Cc: [email-masked]
> Subject: [IETFMIBS] Updated OPS Area meetings agenda
> 
>
>
> An updated version of the agenda of the OPS area open meetings is
> available at http://www3.ietf.org/proceedings/07mar/agenda/opsarea.txt.
>
> See you all there on Monday and Wednesday.
>
> David, Dan and Ron
>
>
>
>
>
> _______________________________________________
> IETFMIBS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietfmibs
>

content-class: urn:content-classes:message
Date: Sun, 18 Mar 2007 17:35:07 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, "IETF MIBs" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: [nmrg] Updated OPS Area meetings agenda

An updated version of the agenda of the OPS area open meetings is
available at http://www3.ietf.org/proceedings/07mar/agenda/opsarea.txt. 

See you all there on Monday and Wednesday. 

David, Dan and Ron

Content-class: urn:content-classes:message
Subject: RE: [nmrg] Re: Comments Question about draft-xu-cops-push-00.txt
Date: Sat, 17 Mar 2007 16:23:10 -0700
From: "Durham, David" <[email-masked]>
To: <[email-masked]>, "xuheyuan" <[email-masked]>
Cc: [email-masked], [email-masked], "Romascanu, Dan \(Dan\)" <[email-masked]>, Hexian Huang <[email-masked]>, Tom-PT Taylor <[email-masked]>, [email-masked], [email-masked], Tina Tsou <[email-masked]>

If the goal is to use XML, then why reinvent the wheel on webservices
for management outside of the W3C and DMTF? 
SNMP, COPS, DIAMETER, NETCONF... Where does it end?

Is there an RFC that does a thorough analysis of the alternatives
(IETF's and other standards bodies' included) in terms of capabilities,
latency, bandwidth, complexity, backward compatibility and other such
quantitative metrics? If not, this might be a helpful activity as the
mailing list discussions quickly become crystal ball gazing and
philosophical in nature. Then folks can figure out if their requirements
make a better fit for one protocol over another. 

-Dave

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Juergen Schoenwaelder
> Sent: Thursday, March 15, 2007 7:47 AM
> To: xuheyuan
> Cc: Tina Tsou; [email-masked]; [email-masked]; Romascanu,
Dan
> (Dan); Hexian Huang; Tom-PT Taylor; [email-masked]; ops-
> [email-masked]
> Subject: [nmrg] Re: Comments Question about draft-xu-cops-push-00.txt
> 
> On Thu, Mar 15, 2007 at 10:19:18PM +0800, xuheyuan wrote:
> 
> > At that time the Re reference point, merged into Rw reference point
> > later, controlled the IP edge, actually an IP-IP gateway. In the
> > current network, most existing IP-IP gateways are routers, which
> > support COPS already. In reality, using COPS is the quickest way to
> > do that as described in approach 2 in this draft.
> 
> I have routers that support NETCONF in my lab and no routers
> supporting COPS-PR or COPS.  Perhaps this is why our views of the
> world are somewhat different.
> 
> > COPS-PR by nature does policy control, Rw interface mainly does
> > policy control dynamically, not just push configuration
> > information. Besides, in 2005,NETCONF was a pretty new protocol, and
> > few existing routers supported NETCONF.
> 
> I never understood the distinction between configuration and policy
> information when it comes to the device interface. The PDP is the
> policy engine and what comes out of this engine as provisioning
> information is for me not really distinct from configuration data
> coming out of other systems (e.g. customer provisioning systems).
> 
> I agree that NETCONF was pretty new in 2005 and it still is in 2007.
> COPS-PR is older but as far as I can tell not too widely implemented
> and the number of people within the IETF who do understand COPS-PR
> well is like to be somewhat smaller than the number of people within
> the IETF who understand NETCONF and my impression was that COPS-PR
> awareness declines.
> 
> > As RACF supports both fix and mobile, push and pull modes, in the
> > real networking, PD-FE may possibly support both modes, and in pull
> > modes, COPS is very effective, so, in push mode, if approach 2 COPS
> > could be adopted, it will simplify the implementation.
> 
> The implementation simplification is a relative thing (if you have
> COPS, using COPS is simple, if you have NETCONF, using NETCONF is
> simple). Not sure how to make a decision on this.
> 
> Again, I like to see the discussion raised to the technical level to
> first understand if NETCONF could do what you need it to do equally
> well or whether there is any technical feature that really
> distinguishes COPS-PR from NETCONF.
> 
> /js
> 
> --
> Juergen Schoenwaelder		 Jacobs University Bremen
> <http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen,
> Germany
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To unsubscribe
or
> adjust
> !! your settings, send a mail message to
<[email-masked]>
> !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

Content-class: urn:content-classes:message
Date: Thu, 15 Mar 2007 11:46:41 -0400
From: "Natale, Bob" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: [email-masked], [email-masked], "Netconf \(E-mail\)" <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, IETF MIBs <[email-masked]>, [email-masked], [email-masked]
Subject: [nmrg] RE: [IETFMIBS] comments on draft-natale-snmp-mibs-to-ontology-00

Hi Dan,

You are correct in your perception that the proposed work *might* not
be appropriate for an IETF WG, esp. according to our traditional
objectives.  It is a proposal, in part, to move us more directly into a
broader interpretation of the relevance of core IETF O&M work (as
represented by MIBs in particular).  On the other hand, it might also
be seen as an extension of the MIB to XML work, NETCONF, XCAP, and
possibly others.  I will try to make that case during the BOF.

To answer your specific points:

1. I will provide more concrete explanations during the presentation
(and plan to post an updated Draft prior to the session...will e-mail
the link when it is ready).  But note that I do not claim to be an
expert in the set of SOA/WS mgmt related technologies that need to be
considered...I have a growing degree of familiarity with what seem to
be the key ones, but explicitly need the collective community expertise
of interested parties to make firm commitments to an optimal subset.

2.  Yes, "ontology" was used simply as a placeholder for the outputs of
the conversion process.  Since then I have been able to learn a bit
more, and get helpful feedback from some key SOA/WS mgmt developers, so
I can definitely narrow things down better for the BOF.  I strongly
doubt that we will be targeting ontologies as the outputs of the
conversion process at this time.  To give a preview, it is more likely
that resource models expressed as SML-IF documents better reflects the
kind(s) of things we would want the conversion process to produce.
(But see note above about need for community expertise to reach such
conclusions.)

3.  Yes, there was no intent to suggest that the WG (if approved) would
produce any tools.  Rather, the primary objective is to define the
specific rules for converting SNMP MIBs to SOA/WS mgmt artifacts.  I
firmly believe that such a set of rules is essential to both the user
and the developer mgmt communities and that the IETF is the right body
to specify such rules.  So, it is the conversion methodology itself --
not the tools that might use the methodology -- that I am asking the
IETF O&M area to standardize.  (Indeed, there are some open source
tools/projects that we might be able to leverage both to guide this
work efficiently and to test the methodology effectively via existing
tools along the way ... Some examples are the Eclipse COSMOS and Apache
Muse projects ... About which I will provide more details in the
updated Draft and at the BOF.)

Also, Juergen raised some specific questions in a (much) earlier
posting, and I will address those directly in the BOF presentation as
well.

Cheers,
BobN

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 5:29 PM
To: [email-masked]; [email-masked]; IETF MIBs; MIB Doctors
(E-mail); [email-masked]; Netconf (E-mail); [email-masked]
Subject: [IETFMIBS] comments on draft-natale-snmp-mibs-to-ontology-00

I have a few comments related to the proposals in
draft-natale-snmp-mibs-to-ontology-00. While I appreciate the problem
space and recognize its importance, it is far from clear to me how this
work could be structured in a future Working Group in the OPS Area. In
order to help the discussions in Prague I would make the following
observations: 

1. The document relates to SOA-based/Web services management. These
concepts are quite broad, and it would be useful for the seek of the
discussions in Prague if Bob could provide a reference (or more but not
many) that points to what he had in mind when using this terms in the
document

2. The term ontology that is being used here to describe the results of
the conversion process is broad, and defined by a few examples in the
text. We should probably discuss rather sooner which of the output
formats that would be dealt with by a future IETF activity

3. Defining data conversion tools and validation tools is something
that
has not been done yet in the IETF, to the best of my knowledge. They
are
however defined as 'primary outputs' for this effort. As I am not sure
that I understand how the future IETF documents would look like, I
would
suggest that we make some more concrete proposals, maybe examples that
other have issued in this space. 

Dan

_______________________________________________
IETFMIBS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietfmibs

Date: Thu, 15 Mar 2007 15:46:31 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: xuheyuan <[email-masked]>
Mail-Followup-To: xuheyuan <[email-masked]>, Tom-PT Taylor <[email-masked]>, "Romascanu, Dan (Dan)" <[email-masked]>, [email-masked], [email-masked], Hexian Huang <[email-masked]>, [email-masked], [email-masked], Tina Tsou <[email-masked]>
Cc: Tina Tsou <[email-masked]>, [email-masked], [email-masked], "Romascanu, Dan \(Dan\)" <[email-masked]>, Hexian Huang <[email-masked]>, Tom-PT Taylor <[email-masked]>, [email-masked], [email-masked]
Subject: [nmrg] Re: Comments Question about draft-xu-cops-push-00.txt
Reply-To: [email-masked]

On Thu, Mar 15, 2007 at 10:19:18PM +0800, xuheyuan wrote:

> At that time the Re reference point, merged into Rw reference point
> later, controlled the IP edge, actually an IP-IP gateway. In the
> current network, most existing IP-IP gateways are routers, which
> support COPS already. In reality, using COPS is the quickest way to
> do that as described in approach 2 in this draft.

I have routers that support NETCONF in my lab and no routers
supporting COPS-PR or COPS.  Perhaps this is why our views of the
world are somewhat different.

> COPS-PR by nature does policy control, Rw interface mainly does
> policy control dynamically, not just push configuration
> information. Besides, in 2005,NETCONF was a pretty new protocol, and
> few existing routers supported NETCONF.

I never understood the distinction between configuration and policy
information when it comes to the device interface. The PDP is the
policy engine and what comes out of this engine as provisioning
information is for me not really distinct from configuration data
coming out of other systems (e.g. customer provisioning systems).

I agree that NETCONF was pretty new in 2005 and it still is in 2007.
COPS-PR is older but as far as I can tell not too widely implemented
and the number of people within the IETF who do understand COPS-PR
well is like to be somewhat smaller than the number of people within
the IETF who understand NETCONF and my impression was that COPS-PR
awareness declines.

> As RACF supports both fix and mobile, push and pull modes, in the
> real networking, PD-FE may possibly support both modes, and in pull
> modes, COPS is very effective, so, in push mode, if approach 2 COPS
> could be adopted, it will simplify the implementation.

The implementation simplification is a relative thing (if you have
COPS, using COPS is simple, if you have NETCONF, using NETCONF is
simple). Not sure how to make a decision on this.

Again, I like to see the discussion raised to the technical level to
first understand if NETCONF could do what you need it to do equally
well or whether there is any technical feature that really
distinguishes COPS-PR from NETCONF.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

content-class: urn:content-classes:message
Date: Thu, 15 Mar 2007 16:12:37 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "MIB Doctors \(E-mail\)" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: [nmrg] FW: [OPS-AREA] Open Office Hours

 

-----Original Message-----
From: David Kessens [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 6:12 AM
To: Operations and Management Area
Subject: [OPS-AREA] Open Office Hours

We would like to let you know that the Operations and Management Area
Directors have decided to hold Open Office hours again during this IETF.
Feel free to step by to discuss any IETF related issue or to meet Ron
Bonica who will take over David Kessens role after this IETF.

See below for the logistics information:

Date:     Tue, March 20
Time:     15.00-17.20
Location: Rokoska

Date:     Wed, March 21
Time:     16.10-17.00
Location: Rokoska

Date:     Thu, March 22
Time:     16.10-17.00
Location: Rokoska

(most up to date information is always on the wiki at:
 http://www1.tools.ietf.org/area/ops/trac/wiki)

David & Dan
---

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area

Date: Thu, 15 Mar 2007 08:24:41 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Tom-PT Taylor <[email-masked]>
Subject: Re: [nmrg] Re: [OPS-AREA] Question about draft-xu-cops-push-00.txt
Mail-Followup-To: Tom-PT Taylor <[email-masked]>, "Romascanu, Dan (Dan)" <[email-masked]>, Heyuan Xu <[email-masked]>, [email-masked], [email-masked], Hexian Huang <[email-masked]>, [email-masked], [email-masked], Tina Tsou <[email-masked]>
Cc: Heyuan Xu <[email-masked]>, [email-masked], [email-masked], Tina Tsou <[email-masked]>, "Romascanu, Dan \(Dan\)" <[email-masked]>, Hexian Huang <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]

On Tue, Mar 13, 2007 at 04:02:57PM -0400, Tom-PT Taylor wrote:
 
> My co-authors can better explain the choice of COPS.

So can one of your co-authors please speak up and address Dan's
question in technical terms?

In particular, I like to know what you consider the essential
technical features making COPS-PR more desirable than other protocols
to push configuration information (like NETCONF) that seem to have
gained more community support during the last few years (at least in
the IETF).

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

content-class: urn:content-classes:message
Date: Wed, 14 Mar 2007 23:29:10 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "IETF MIBs" <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, <[email-masked]>, "Netconf \(E-mail\)" <[email-masked]>, <[email-masked]>
Subject: [nmrg] comments on draft-natale-snmp-mibs-to-ontology-00

I have a few comments related to the proposals in
draft-natale-snmp-mibs-to-ontology-00. While I appreciate the problem
space and recognize its importance, it is far from clear to me how this
work could be structured in a future Working Group in the OPS Area. In
order to help the discussions in Prague I would make the following
observations: 

1. The document relates to SOA-based/Web services management. These
concepts are quite broad, and it would be useful for the seek of the
discussions in Prague if Bob could provide a reference (or more but not
many) that points to what he had in mind when using this terms in the
document

2. The term ontology that is being used here to describe the results of
the conversion process is broad, and defined by a few examples in the
text. We should probably discuss rather sooner which of the output
formats that would be dealt with by a future IETF activity

3. Defining data conversion tools and validation tools is something that
has not been done yet in the IETF, to the best of my knowledge. They are
however defined as 'primary outputs' for this effort. As I am not sure
that I understand how the future IETF documents would look like, I would
suggest that we make some more concrete proposals, maybe examples that
other have issued in this space. 

Dan

Date: Tue, 13 Mar 2007 16:02:57 -0400
From: "Tom-PT Taylor" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: Heyuan Xu <[email-masked]>, [email-masked], [email-masked], Hexian Huang <[email-masked]>, [email-masked], [email-masked], Tina Tsou <[email-masked]>
Subject: [nmrg] Re: [OPS-AREA] Question about draft-xu-cops-push-00.txt

The other individuals copied on this response are probably better qualified to 
answer, but I'll have a go.

The architecture, using ITU-T terminology, is as follows: the Policy Decision 
Function (PDF) sets policy. The Transport Enforcement function (TEF) enforces 
the policy. The interface between them is variously designated Rw (in the 
ITU-T), Ia (in TISPAN), Go/Gx (in 3GPP), or TC-1 (in the MultiService Forum). 
The particular role of the Rw interface is to carry admission decisions and 
related material such as NAT configuration requests and responses.

To broaden the picture, the Policy Decision Function gets requests from the 
P-CSCF (more abstractly, the Service Control Function, SCF). That interface is 
designated Rs in the ITU-T, Gq' in TISPAN, Gq in 3GPP, and TC-0 in the 
MultiService Forum. Everyone agrees that the protocol across that interface is 
Diameter, but there is variation in the AVPs that have to be supported.

The SCF, PDF, and TEF interact on a per-session basis. Whether push or pull mode 
is used depends on signalling capabilities at the user terminal and the access 
technology in use. That can vary from session to session.

To take the push mode example: suppose the terminal is unable to signal at the 
transport level (e.g. using RSVP or NSIS). Then the network has to act on its 
behalf. The terminal sends a SIP INVITE with SDP to the P-CSCF. The P-CSCF 
analyzes the SDP to determine the implied QoS requirements and the external 
transport addresses associated with the flow and passes an admission request on 
to the PDF. The PDF checks its sources of policy information to decide whether 
the flows can be admitted; if so, it sends a request down to the TEF to admit 
the flow and set up NATing (if applicable). The TEF returns the NAT address 
assignments, which the PDF passes back to the SCF in its response to the 
original request.

A pull mode example is probably more familiar, so I won't go into detail.

My co-authors can better explain the choice of COPS. Back when they first 
started this work, the industry had not yet made a choice between COPS and other 
protocols, so their decision was reasonable. I should mention that the ITU-T is 
also working on draft Recommendations based on H.248 (like the TISPAN Ia 
interface) and on Diameter. Diameter presents similar problems to COPS, in that 
the natural roles of client and server are reversed when moving from pull to 
push mode.

Romascanu, Dan (Dan) wrote:
> I have a question related to
> http://www.ietf.org/internet-drafts/draft-xu-cops-push-00.txt, which
> will be the subject of a mini-BOF in the OPS Area meeting in Prague. The
> document describes an optimization of COPS so that it can be used in a
> push mode at a degree of efficiency that is similar to the one of the
> pull mode for which the protocol was originally designed. What are the
> use cases and application or applications that require using COPS in a
> push mode? And if push mode is required, than why COPS? 
> 
> Thanks and Regards,
> 
> Dan
> 
> 
>  
> 
>  
> 
> 
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ops-area
> 

content-class: urn:content-classes:message
Date: Tue, 13 Mar 2007 02:48:25 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: [nmrg] Question about draft-xu-cops-push-00.txt

I have a question related to
http://www.ietf.org/internet-drafts/draft-xu-cops-push-00.txt, which
will be the subject of a mini-BOF in the OPS Area meeting in Prague. The
document describes an optimization of COPS so that it can be used in a
push mode at a degree of efficiency that is similar to the one of the
pull mode for which the protocol was originally designed. What are the
use cases and application or applications that require using COPS in a
push mode? And if push mode is required, than why COPS? 

Thanks and Regards,

Dan

 

content-class: urn:content-classes:message
Date: Mon, 12 Mar 2007 17:48:29 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, "IETF MIBs" <[email-masked]>, <[email-masked]>
Subject: [nmrg] Some comments on http://www.ietf.org/internet-drafts/draft-harrington-operations-and-management-00.txt

I would suggest to as many folks as possible to red and provide comments
on
http://www.ietf.org/internet-drafts/draft-harrington-operations-and-mana
gement-00.txt prior to the meeting in Prague. This is an important
document for the OPS area, that could impact the work in other area of
the IETF in the future. 

Here are a few of my observations: 

1. Section 1

o  "new protocol" includes new protocols, protocol extensions, data
      models, or other functionality being designed.

I would include in this definition also 'the entities and functional
components implementing the protocol'

2. Section 2 - I believe that instead of 'Protocol designers typically
do not like to look at the management aspects of their new protocol.' we
should rather say 'Protocol designers typically do not take into
considerations the operational and management aspects of their new
protocol at the time of the protocol definition'

3. Section 2 - s/aspects of a protocol design that is unfamiliar to
them/aspects of a protocol design that are unfamiliar to them

4. Section 2 -   'This document is not about requiring all
internet-drafts to include a new "Operations and Management
Considerations" section.' I would add '... although it does not preclude
the addition of such a section either'. 

5. Section 2.1 

The IETF has indicated a desire to have operations and manageability
   considered during the development of new protocols, using a proactive
   "design for operability and manageability" approach that documents
   how a new protocol is expected to be operated and managed.

I do not believe that there was any IETF-wide discussion on this issue.
Did you mean the IESG? 

6. It would help if the last paragraph in 2.1 would be edited as a list
of bullets. 

7. Section 3.4 - 

  These considerations should generally remain illustrative to avoid
   creating restrictions or dependencies, or potentially impacting the
   behavior of existing protocols, or restricting the extensibility of
   other protocols, or assuming other protocols will not be extended in
   certain ways.

I am not sure what 'considerations should remain generally illustrative'
- maybe what we mean here is that the goal of such considerations would
be to identify existing restrictions and dependencies, but avoid
introducing new ones. 

8. Section 4

Some product designers and protocol designers assume that if a device
   can be managed individually using a command line interface or a web
   page interface, that such a solution is enough.  But when equipment
   from multiple vendors is combined into a large network, scalability
   of management becomes a problem.  It is important to have consistency
   in the management interfaces so network-wide operational processes
   can be automated.

I think that we should add to the last phrase '... and to minimize to
the possible extent the number of components of a complete management
solution' 

9. Figure 1 should mention data models at plural and represent them
under different names DM1, DM2 ...

10. The discussion of the data models should also take into
consideration the issues related to the implementability of data model
in network devices - we can use the example of the multiport bridges
with thousands of VLANs modeled as entries of tables per port - is such
a model implementable? 

11. I believe that we should add to 4.2.3 Fault Determination the case
where faults are determined by comparing increases of counters in a
given time interval vs. a threshold, as in the RMON Alarms mechanism

12. Section 4.3 -  The phrase ' Network wide configurations are ideally
stored in central master databases ...' seems to recommend a certain
management model or architecture, which may not be appropriate for all
cases. I do not believe that there is any 'ideal' here and I would
reformulate

13. It is not clear to me what 4.3.2 is meant to say - I believe that
there is a need for more clarity in this section.

14. Section 4.5 should state that for a given protocol the metrics that
characterize the performance of the protocol need to be defined as part
of the manageability considerations information. 

15. I think that it would be good to mention that the content in Section
5 is of informational nature, and reflects the status of the management
protocols at the time of the editing of this document 

16. Should we not include also COPS in Section 5? We refer only to
COPS-PR. CLI also deserves a separate sub-section, even if not standard
it is widely used. I would also mention CAPWAP and ANCP as 'other
protocols'

17. Section 6.4 should also mention IPPM and RTCP XR (RFC 3611) 

Dan

 

content-class: urn:content-classes:message
Date: Fri, 9 Mar 2007 12:32:29 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Tomoyuki Iijima" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], "MIB Doctors \(E-mail\)" <[email-masked]>, IETF MIBs <[email-masked]>, [email-masked], [email-masked], OPS Area <[email-masked]>
Subject: [nmrg] RE: [NGO] Updated Agenda for the OPS AREA meetings in Prague

Sorry for the confusion. Is there a draft to support the presentation
that you will be making in Prague? 

Dan

 

> -----Original Message-----
> From: Tomoyuki Iijima [mailto:[email-masked]] 
> Sent: Friday, March 09, 2007 12:20 PM
> To: Romascanu, Dan (Dan)
> Cc: OPS Area; [email-masked]; [email-masked]; 
> [email-masked]; MIB Doctors (E-mail); IETF MIBs; 
> [email-masked]; [email-masked]
> Subject: Re: [NGO] Updated Agenda for the OPS AREA meetings in Prague
> 
> Dear Dan,
> 
> > 7. Late Submission - requirements to tunneling protocols 
> OAM - KIKUCHI 
> > Yutaka (total: 15 min)
> > 
> > This draft describes requirements to measure end-to-end 
> qualities of 
> > tunnels passively and to monitor them via SNMP. This feature is 
> > necessary for Service Providers, especially, who provide 
> transports to 
> > users using tunnels. In addition, the draft shows an example to 
> > measure Generic Routing Encapsulation (GRE) tunnels.
> > 
> > I-D:
> > 
> http://www.ietf.org/internet-drafts/draft-iijima-ngo-vlandatamodel-00.
> > tx
> > t
> 
> This draft does not correspond to the presentation above.
> 
> Best regards,
> 
> --
> Tomoyuki Iijima
> Hitachi, Ltd. Central Research Laboratory
> TEL:+81-42-323-1111 ext.3579
> FAX:+81-42-327-7868
> E-mail:[email-masked]
> 

Date: Fri, 09 Mar 2007 19:19:52 +0900
From: Tomoyuki Iijima <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], "MIB Doctors \(E-mail\)" <[email-masked]>, IETF MIBs <[email-masked]>, [email-masked], [email-masked], OPS Area <[email-masked]>
Subject: [nmrg] Re: [NGO] Updated Agenda for the OPS AREA meetings in Prague

Dear Dan,

> 7. Late Submission - requirements to tunneling protocols OAM - KIKUCHI
> Yutaka (total: 15 min) 
> 
> This draft describes requirements to measure end-to-end qualities of
> tunnels passively and to monitor them via SNMP. This feature is
> necessary for Service Providers, especially, who provide transports to
> users using tunnels. In addition, the draft shows an example to measure
> Generic Routing Encapsulation (GRE) tunnels. 
> 
> I-D:
> http://www.ietf.org/internet-drafts/draft-iijima-ngo-vlandatamodel-00.tx
> t 

This draft does not correspond to the presentation above.

Best regards,

-- 
Tomoyuki Iijima
Hitachi, Ltd. Central Research Laboratory
TEL:+81-42-323-1111 ext.3579
FAX:+81-42-327-7868
E-mail:[email-masked]

content-class: urn:content-classes:message
Date: Fri, 9 Mar 2007 10:25:24 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "OPS Area" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], "MIB Doctors \(E-mail\)" <[email-masked]>, IETF MIBs <[email-masked]>, [email-masked], [email-masked]
Subject: [nmrg] Updated Agenda for the OPS AREA meetings in Prague

Following a number a comments I have updated the agenda for the OPS Area
meeting in Prague. Comments are still welcome. 

Dan

Meeting : IETF68, Monday March 19, 2007 and Wednesday March 21, 2007 

Location: Congress II, Monday March 19, 2007 15:20 to 17:20 and Congress
I, Wednesday March 21, 2007 13:00 to 16:10 

Chairs : David Kessens ([email-masked]), Dan Romascanu
([email-masked]), Ron Bonica ([email-masked]) 

Jabber : [email-masked] URL : http://www.ops.ietf.org/ Agenda :
version 0.1 (draft)
============================================================== 

Meeting 1 - Monday March 19, 2007 15:20 to 17:20 

1. Meeting Administrivia ADs (total: 5 min) 

Mailing list and URL 
Minutes Scribe 
Jabber Scribe 
Blue Sheets 

2. Introduction of new Area Director - Ron Bonica (5 min) 

3. Mini-BOF A: - Manageability and Operational Guidelines - David
Harrington (total: 30 min) 

We need to develop multi-protocol manageability and operational
guidelines for developers of protocols in the IETF. An internet-draft
has been published that summarizes previous work on this goal as a
starting point. This work would lead to either a WG, if enough people
want to be involved, or a design team to get the document finished. If
we can get enough feedback from operators and from protocol designers,
this could lead to a BCP; with limited input it would lead to an
Informational RFC instead. 

I-D:
http://www.ietf.org/internet-drafts/draft-harrington-operations-and-mana
gement-00.txt 

4. Mini-BOF B: COPS push mode policy configuration - Tom Taylor and Tina
Tsou (total: 30 min) 

This mini-BOF is requested to gain comments on a technical proposal to
reduce the number of messages required when COPS is used to support push
mode policy configuration, where each request-state corresponds to an
user session. The essence of this proposal is to allow the PDP to
request the opening of a new request-state in the same message that
sends down policy to be stored against this request-state. At the other
end of the session life cycle, allow the PDP to delete a request-state.
The proposed extensions to COPS could save two to three messages per
session, depending on the details that are finally agreed. 

I-D: http://www.ietf.org/internet-drafts/draft-xu-cops-push-00.txt 

5. Mini-BOF C: Best Current Practices in Operations and Management -
David Harrington (total: 20 min) 

This would be an effort to get operators together in a WG to develop a
set of best current practices, and a description of supporting
technologies, for manageability and operations, similar to the work done
in the OpSec? WG. There will not be an internet-draft published prior to
ietf68. A WG should be created for operators to do this work. 

6. Improved Efficiency of the OPS Area - proposal for the formation of a
OPS Area WG - ADs (total: 15 min) 

7. Open Microphone - 15 min 

Meeting 2 - Wednesday March 21, 2007 - 13:00 to 16:10 

1. Meeting Administrivia ADs (total: 5 min) 

Mailing list and URL 
Minutes Scribe 
Jabber Scribe 
Blue Sheets 

2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling -
Michael Alexander (total: 40 min) 

Network Management (NM) standards have traditionally been focused on
protocols, such as pertaining to configuration management and discovery.
Yet, all areas of Network Management, ranging from Element Management
(EM) to Network Management Systems (NMS) and Service Management Systems
have in common that they critically rely on underlying data structures
describing devices and services being managed. Network elements (NE)
frequently spawn ten thousands of managed objects, such as for a
multiservice switch...Traditionally, standardization of access-methods
(protocols), discovery, etc. have received most attention, while the
more heterogeneous data models and data modeling per saw comparatively
less. As there are real possibilities to standardize underlying and
universal commonalities in EMS/NMS/Service Management Systems on the one
side and managed attributes of NEs, protocols, transmission facilities,
lines and services on the other, the two distributions should be closer
aligned. Despite the complexity, it is possible to identify and define
frameworks and meta models of each constituent and their relation to
each other, that would substantially ease the management of present and
future devices, networks and services. 

I-D: draft-alexan-datamod-00.txt 

3. MIB-Doctor-sponsored MIB-document-writing template: David Harrington
(total: 10 min) 

I-D:
http://www.ietf.org/internet-drafts/draft-harrington-text-mib-doc-templa
te-02.txt 

4. Mini-BOF E: MIB module editing in XML : Emile Stephan (total: 20 min)

Present the state of the art of editing MIB module in XML; Introduce a
basic template to edit SMI items in pure XML instead of in raw text;
Propose a simple XML template for SMI items; discuss the connections
with XML schema and network management protocols. 

I-D:
http://www.ietf.org/internet-drafts/draft-stephan-ops-xml-mib-module-tem
plate-00.txt 

5. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima (total: 20
min) 

I'd like to show the data model examples we developed and was adopted in
the Japanese Standard body. 

We developed data models of VLAN, Filter (Access Control List), and so
on and those data models were adopted by Japanese standardization body
called INTAP/OSMIC as standard data models. I'd like to make our data
model examples be adopted as an Informational RFC. 

I-D:
http://www.ietf.org/internet-drafts/draft-iijima-ngo-vlandatamodel-00.tx
t 

6. Mini-BOF G: OWL techniques for MIB to XML documents and schema
translation - Bob Natale (total: 40 min) 

Specification of a standard methodology for translating SNMP MIBs into
outputs more directly usable by emerging SOA/web services management
tools, and specification of a standard methodology for validating those
translations. Appropriate translation outputs are TBD by the WG, but can
be expected to include one or more of the following: XML, RDF, WSDL,
WS-Policy, WS-Event/Notification, Ontology. The translation output(s)
should allow for extension of the respective managed element data model
in the native SOA/web services environment. Because of the extensibility
objective, reverse translation back into SNMP MIB format is a non-goal
of the WG, but the possibility should be considered when weighing
alternatives. 

I-D:
http://www.ietf.org/internet-drafts/draft-natale-snmp-mibs-to-ontology-0
0.txt 

7. Late Submission - requirements to tunneling protocols OAM - KIKUCHI
Yutaka (total: 15 min) 

This draft describes requirements to measure end-to-end qualities of
tunnels passively and to monitor them via SNMP. This feature is
necessary for Service Providers, especially, who provide transports to
users using tunnels. In addition, the draft shows an example to measure
Generic Routing Encapsulation (GRE) tunnels. 

I-D:
http://www.ietf.org/internet-drafts/draft-iijima-ngo-vlandatamodel-00.tx
t 

8. Open microphone (total: 40 min)