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
ippm@...
https://www.ietf.org/mailman/listinfo/ippm
