Re: [OPSAWG] Review of draft-ersue-opsawg-management-fw-01, part 2

[Benoit Claise <[e-mail]>]

Hi Mehmet,
>
> Hi Benoit,
>
> thank you for your review and comments. See inline.
>
> Mehmet
>
> *From:*ext Benoit Claise [mailto:[e-mail]]
> *Sent:* Wednesday, December 01, 2010 1:51 AM
> *To:* Ersue, Mehmet (NSN - DE/Munich); [e-mail]
> *Subject:* Review of draft-ersue-opsawg-management-fw-01, part 2
>
> Hi Mehmet,
>
> Here is the review of the remaining part.
>
> . . .
>   
>
>
>         3.9.2.  COPS-PR
>
>     [RFC3159] defines the Structure of Policy Provisioning Information
>     (SPPI), an extension to the SMImodeling language used to write
>     Policy Information Base (PIB) modules.  COPS-PR [RFC3084  <http://tools.ietf.org/html/rfc3084>] uses the
>     Common Open Policy Service (COPS) protocol for support of policy
>     provisioning.  COPS-PR and the Structure of Policy Provisioning
>     Information (SPPI) have been approved as Proposed Standards.
>
> I would cut/paste this sentence below.
> Expressed like this, it means that this is an important standard, but 
> the end of the section is quite different.
> [Mehmet]: I assume you mean the last sentence above.
>
Yes, sorry.
>
>   
>
> . . .
>
>   
>     These metrics are designed for network operator use and provide
>     unbiased quantitative measures of performance.
>
> This sentence, copied from the charter, should be in here.
>
> The metrics developed by the WG were developed inside an active
> measurement context, that is, the devices used to measure the metrics
> produce their own traffic. However, most metrics can be used inside a
> passive context as well. No work is planned is this area though,
> this may be changed with AD approval.
>
> [Mehmet]: I agree. I would though skip "this may be changed with AD 
> approval."
>
>         The main properties of individual IPPM performance and reliability
>
>         metrics are that the metrics should be well-defined and concrete thus
>
>         implementable, and they should exhibit no bias for IP clouds
>
>         implemented with identical technology.  In addition, the methodology
>
>         used to implement a metric should have the property of being
>
>         repeatable with consistent measurements.
>
>       
>
>         IETF IP Performance Metrics have been introduced widely in the
>
>         industry and adopted by different SDOs such as ITU-T.
>
> Actually, any others than ITU-T?
> [Mehmet]: Al wrote MEF was active in this area too.
>
>   
>   
>     RTFM is e.g. used for the measurement of DNS performance.
>
> I consider RTFM as an experiment done before IPFIX.
> btw, http://tools.ietf.org/html//rfc2724 
> <http://tools.ietf.org/html/rfc2724> is experimental.
> Again, it depends on the target audience. If we want to keep a history 
> of what has been done in OPS, that's interesting. Otherwise, I would 
> remove RTFM
> [Mehmet]: I think I can agree. RTFM is probably not important anymore.
>
>   
> . . .
>   
>     Management data models have a slightly different interpretation for
>     interoperability.  This is discussed in detail in [BCP27]
>     "Advancement of MIB specifications on the IETF Standards Track"
>     [RFC2438  <http://tools.ietf.org/html/rfc2438>] with special considerations about the advancement process
>     for management data models.  However most IETF management data models
>     never advance beyond Proposed Standard.
>
> Note that MIB is just one data model.
> What about IPFIX?
> [Mehmet]: What would be your proposal? Should we put it into chapter 4.2?
>
First list the different data models in the intro of sectoin 4.0: MIB, 
IPFIX, RADIUS. Somehow, when I read it, because the second paragraph 
focuses on MIB, I misinterpreted that you were only covering MIB. 
Re-reading this, I missed the "s" at the end of the data models in:

    This section lists solutions for which information or data models
    have been standardized at the IETF


Then, for IPFIX, at least list it in accounting and performance management.
>
>   
>   
>
>
>       4.4.  Performance Management
>
> Should we mention the IPPM perf metrics in here?
>
> [Mehmet]: RFC4150 and BCP0108(RFC4148) are mentioned below. Which RFC 
> do you mean?
>

>   
> . . .
>   
>     The RMON matrix group stores statistics for conversations between
>     sets of two addresses.  The filter group allows packetsto be matched
>     by a filter equation.  These matched packets form a data stream that
>     may be captured or may generate events.  The Packet Capture group
>     allows packets to be captured after they flow through a channel.  The
>     event group controls the generation and notification of events from
>     this device.
>
> Don't want to start a lengthy debate here, but my personal view is 
> that RMON host, matrix are superseded by IPFIX: more granular, more 
> flexible
> At the minimum, we should mention IPFIX somewhere here. This comes 
> back to my point before that MIBs are not the only data model at the IETF.
>
> Indeed, this is worth a discussion. At the end, I think we may not 
> skip RMON, which is still important for some folks.
>
The goal is certainly to skip RMON, but to explain RMON and IPFIX scopes.
>
> I would like to suggest to describe this use case in IPFIX chapter in 
> detail. Would like to provide text for it?
>
Not sure exactly where this text should be, but yes, I will provide some 
text.

Regards, Benoit.
>
> . . .
>