Re: [ippm] Murray Kucherawy's No Objection on draft-ietf-ippm-rfc8889bis-03: (with COMMENT)

[Giuseppe Fioccola <[e-mail]>]

Hi Murray,
Thank you for your review.
Please find my replies inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Murray Kucherawy via Datatracker <[e-mail]> 
Sent: Thursday, September 22, 2022 8:19 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Murray Kucherawy's No Objection on draft-ietf-ippm-rfc8889bis-03: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-ippm-rfc8889bis-03: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8889bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work on this.  It was pretty easy to follow.

[GF]: Thanks.

In Section 5, the document suddenly starts using the term "arc".  What's an arc?

[GF]: For this purpose, we can further explain that a monitoring network can be modeled as a set of nodes and a set of directed arcs which connect pairs of nodes.

Two problems in Section 9.  The first:

      One flag: packet loss measurement MUST be done as described in
      Section 6 by applying the network clustering partition described
      in Section 5.  While delay measurement MUST be done according to
      the Mean delay calculation representative of the multipoint path,
      as described in Section 7.1.1.  Single-marking method based on the
      first/last packet of the interval cannot be applied, as mentioned
      in Section 7.2.1.

The "While delay ..." sentence seems to be incomplete.  Should it be attached
(via comma) to the sentence before it, or is there something missing here?

[GF]: I will revise the text. That sentence can be attached via comma to the sentence before or "While" can also be removed.

The same problem occurs in the next ("Two flags:") paragraph.

[GF]: Right, I will also revise it.

The second problem is the SHOULD in that same paragraph.  SHOULD presents the
implementer with a choice, and I suggest adding some prose here to explain why
one might legitimately decide to do something other than what the SHOULD says.

[GF]: There are more details later, but, I agree, it would be better to add some considerations also here.

Lastly, some nits:

In Section 5:

   In addition, it is also possible to leverage [...]

You don't need both "In addition" and "also".

[GF]: I will delete one of them.

In Section 7.2.1:

      Double marking or multiplexed marking work but only through
      statistical means.  [...]

s/work/works/

[GF]: Ok

   If it is performed a delay measurement for more than one [...]

Suggest "If a delay measurement is performed for more than one ...".

[GF]: Ok, I will replace it.

In Section 9:

   ... there is different kind of information that can be derived.

Missing "a", I believe?

[GF]: Yes, I will add it.

      For example, to get measurements on a multipoint-paths
      basis, one flag can be used.  While, to get measurements on a
      single-packet basis, two flags are preferred.

Suggest removing "While".

[GF]: Ok, I will remove it.