Re: [xrblock] Usage of RFC 6390 in XRBLOCK documents

["Romascanu, Dan (Dan)" <[e-mail]>]

> -----Original Message-----
> From: Glen Zorn [mailto:[e-mail]]
> Sent: Tuesday, December 04, 2012 8:20 AM
> To: Romascanu, Dan (Dan)
> Cc: [e-mail]; Benoit Claise; [e-mail]
> Subject: Re: [xrblock] Usage of RFC 6390 in XRBLOCK documents
> 
> On 12/03/2012 07:56 PM, Romascanu, Dan (Dan) wrote:
> > Most if not all participants in  the work of XRBLOCK are probably
>  > familiar with BCP 170 / RFC 6390 - ' Guidelines for Considering New
> > Performance Metric Development'. This RFC describes a framework and a
> > process for developing Performance Metrics of protocols and  >
> applications transported over IETF-specified protocols and makes a  >
> number of recommendations about the definition of new metrics.
>  >
>  > Specifically section 5.4.2 of the RFC defines the normative part of a
> > Performance Metric definition, which MUST include the following:
>  >
>  > (i) Metric Name (ii) Metric Description (iii) Method of Measurement
> > or Calculation (iv) Units of Measurement (v) Measurement Point(s)  >
> with Potential Measurement Domain (vi) Measurement Timing  >  > In
> XRBLOCK documents we are re-using definitions of metrics already  >
> defined somewhere else and normatively refer these documents. We do  >
> not intent to change this, but we would like to use the list above as  >
> a checklist that all mandatory information does exist in the  >
> definitions of the metrics that we refer. Authors can chose whether  >
> to use the exact format or terminology used by 6390 or not, provided  >
> that all necessary information is present.
>  >
>  > In documents that define new metrics (if there will be such document)
> > it will be required to include all normative parts of the performance
> > metric definition as specified in section 5.4.2 of RFC 6390.
>  >
>  > Please let us know if you see any problem with starting to apply this
> > policy immediately.
> 
> One question: what does one do if one or more of the items listed above
> is missing  from the definition (e.g. an ISO or IEEE spec) of the metric
> we are referencing?  Leave the item(s) out?  Make it up ourselves (thus
> creating an "IETF" version of the metric by definition incompatible with
> the original)?
> 

Hi Glen,

My proposal is that in such cases we need at a minimum discuss in the I-D the missing items. The assumption is that if they were defined in RFC 6390 as a normative part in the definition of any metric in the IETF they are necessary for the metric to be completely defined and ensure interoperability. 

I hardly can see how (i), (ii) or (iv) can be absent. If (iii), (v) or (vi) are missing we should at least discuss in the document what we do in the absence of their definition. One thing we already do in such cases is to add fields that define the different option (e.g. algorithm of calculation) in the xr-block. 

Does this seem reasonable? 

Thanks and Regards,

Dan