[ippm] AD review for draft-ietf-ippm-multimetrics-07

[Lars Eggert <[e-mail]>]

Hi,

I did my AD review during WGLC. On a technical level, this document is  
ready to be published.

However, I'd still like to urge the authors to take the time to  
produce another revision that focuses on improving the writing and  
language. Some sections, especially the earlier ones, are quite  
difficult to follow due to awkward phrasings, grammar issues, and so  
on. Other sections are in much better shape, for example, Sections 7,  
8, and much of 9 are very well written. The document would be much  
improved if other sections were of similar language quality. Although  
the RFC Editor would also fix some of these issues, I feel that this  
won't be quite sufficient in this case.

Also note that this isn't a blocking issue. If the WG comes to  
consensus to request publication of this version as-is, I will bring  
it before the IESG in its current form. (But obviously I'd prefer an  
update.)

Lars


Detailed comments:

   Note: Most comments marked as nits below have been automatically
   flagged by review scripts - there may be some false positives in
   there.


INTRODUCTION, paragraph 11:
 >    The IETF IP Performance Metrics (IPPM) working group has  
standardized
 >    metrics for measuring end-to-end performance between two points.

   Please rephrase to not talk about the IPPM WG - WGs are ephemeral and
   WG history is rarely relevant for a published RFC. (Also elsewhere in
   the document, e.g., the introduction, etc.)


Section 1., paragraph 6:
 >    [[RFC2679], [RFC2680], [RFC3393], [RFC3432].  Seven metrics are

   Nit: s/[[/[/


Section 1., paragraph 7:
 >    methodologies.  Each definion includes a specific section  
discussing

   Nit: s/definion/definition/


Section 1., paragraph 8:
 >    increase results accucacy.  These spatial metrics are:

   Nit: s/accucacy./accuracy./


Section 2.5., paragraph 1:
 >    Points of interest are the hosts* (as per RFC2330 definition, that

   Why is there a * after hosts? Can't find a corresponding footnote.


Section 2.7., paragraph 1:
 >    Src are dT1, dT2,..., dTN, it can be say that a vector V with N

   Nit: s/it can be say/it can be said/


Section 2.8., paragraph 5:
 >          Figure 3: Relation beween Singletons, vectors and matrix

   Nit: s/beween/between/


Section 3.3., paragraph 0:
 > 3.3.  Discussion on Group-to-one and Group-to-group metrics

   Suggest to move this section into an appendix, because it's outside
   the scope of the proposed standard.


Section 4., paragraph 3:
 >    Methodology specificities are common to all the vectors defined  
and

   Nit: s/specificities/specifics/


Section 4.1., paragraph 1:
 >    This section is coupled with the definition of Type-P-One-way- 
Delay
 >    of the section 3 of [RFC2679].  When a parameter of this  
definition
 >    is first used in this section, it will be tagged with a trailing
 >    asterisk.

   "This" appears twice in the last section, which makes it ambigous. Do
   you mean that when the definitions from RFC2679 are used, they're
   marked with an asterisk?


Section 4.1., paragraph 2:
 >    Sections 3.5 to 3.8 of [RFC2679] give requirements and  
applicability
 >    statements for end-to-end one-way-delay measurements.  They are
 >    applicable to each point of interest Hi involved in the measure.
 >    Spatial one-way-delay measurement SHOULD be respectful of them,
 >    especially those related to methodology, clock, uncertainties and
 >    reporting.

   Why isn't this a MUST? (Also, nit "be respectful of" is an awkward
   phrasing - just say "respect".) This also occurs elsewhere in the
   document.


Section 4.4.1., paragraph 1:
 >    Loss threshold is the centrality of any methodology because it

   Nit: awkward phrasing: "is the centrality of" - how about "is central
   to"?


Section 4.4.1., paragraph 3:
 >    depending on the consistency of the loss threshold among the  
points
 >    of interest, a packet may be considered loss a one host but  
present

   Nit: s/loss a/lost at/


Section 4.4.1., paragraph 4:
 >    deterministic: Has the path change?  Does the packet arrive at

   Nit: s/change/changed/; s/Does/Did/; s/at/at the/


Section 2, paragraph 0:
 >    o  method1: Figure 5 andFigure 8 illustrate the method chosen: the

   Nit: s/andFigure/and Figure/


Section 9.4., paragraph 4:
 >    o  Hosts_serie: <H1, H2,..., Hn>, a list of points of interest;

   Nit: s/Hosts_serie:/Hosts_series:/


Section 9.4., paragraph 5:
 >    o  Delays_serie: <dT1,..., dTn> a list of delays;

   Nit: s/Delays_serie:/Delays_series:/


Section 9.4., paragraph 6:
 >    o  Losses_serie: <B1, B2, ..., Bi, ..., Bn>, a list of Boolean  
values

   Nit: s/Losses_serie:/Losses_series:/


Section 9.4., paragraph 7:
 >    o  Result_status_serie: a list of results status;

   Nit: s/Result_status_serie:/Result_status_series:/


Section 9.4., paragraph 10:
 >    o  Hosts_serie: not ordered for one-to-group;

   Nit: s/Hosts_serie:/Hosts_series:/


Section 9.4., paragraph 11:
 >    o  Delays_serie: apply only for delays and ipdv vector, not  
ordered

   Nit: s/Delays_serie:/Delays_series:/


Section 9.4., paragraph 12:
 >    o  Losses_serie: apply only for packets loss vector, not ordered  
for

   Nit: s/Losses_serie:/Losses_series:/


Section 9.4., paragraph 13:
 >    o  Result_status_serie;

   Nit: s/Result_status_serie;/Result_status_series;/


Section 9.4., paragraph 16:
 >    o  Delays_serie: apply only for delays and ipdv samples;

   Nit: s/Delays_serie:/Delays_series:/


Section 9.4., paragraph 17:
 >    o  Losses_serie: apply only for packets loss samples;

   Nit: s/Losses_serie:/Losses_series:/


Section 9.4., paragraph 18:
 >    o  Result_status_serie;

   Nit: s/Result_status_serie;/Result_status_series;/


Section 10.2., paragraph 1:
 >    overload reference point ressources (network, network interfaces,

   Nit: s/ressources/resources/


Section 12., paragraph 1:
 >    Metrics defined in this memo Metrics defined in this memo are
 >    designed to be registered in the IANA IPPM METRICS REGISTRY as
 >    described in initial version of the registry [RFC4148] :

   Nit: s/Metrics defined in this memo Metrics defined in this
   memo/Metrics defined in this memo/


_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm