Re: [ippm] John Scudder's No Objection on draft-ietf-ippm-explicit-flow-measurements-03: (with COMMENT)

[Giuseppe Fioccola <[e-mail]>]

Hi John,
Thank you for your review.
Please see inline [GF].

Regards,

Giuseppe

-----Original Message-----
From: John Scudder via Datatracker <[e-mail]> 
Sent: Wednesday, May 24, 2023 11:34 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: John Scudder's No Objection on draft-ietf-ippm-explicit-flow-measurements-03: (with COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-ippm-explicit-flow-measurements-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-explicit-flow-measurements/



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

# John Scudder, RTG AD, comments for
draft-ietf-ippm-explicit-flow-measurements-03 CC @jgscudder

Thanks for this document. While I am not sufficiently expert in the subject
area to give it a deep review, I trust this has been done by others. I do have
a few questions and comments that I hope may help, below.

I support Jim Guichard's DISCUSS position.

## COMMENT

### Section 1

   the encrypted transport-layer headers (e.g.  QUIC, TCP).

Since when are TCP headers encrypted?

[GF]: We will revise this sentence. We meant the possible use of TLS with TCP.

### Section 3.1

There is a list of bullet items that talk about "by setting the T bit", e.g.

   *  the client selects, generates and consequently transmits a first
      train of packets, by setting the T bit to 1;

The way the sentence is constructed, it literally means "the client causes the
train of packets to be generated and transmitted by means of setting the T bit
to 1". I doubt that's what you mean. Possibly you mean something like "it sets
the T bit to 1 to identify packets in this train"?

[GF]: Thank you for the suggestion. We will change these statements.

### Section 3.1.2

The reflection counter is first introduced by mentioning that

                                                             the
       reflection counter is unlocked to start counting incoming marked
       packets that will be reflected later;

This makes for a rather bumpy experience for the first-time reader. I suggest
introducing this counter somehow before referencing it. You might also mention
that as part of initialization, the reflection counter is locked.

[GF]: Ok we can introduce the reflection counter before. It makes sense in section 3.1.

I also have a hard time being sure I've understood this correctly:

   The generation token counter should be capped to limit the effects of
   a subsequent sudden reduction in the other endpoint's packet rate
   that could prevent that endpoint from reflecting collected packets.
   The most conservative cap value is 1.

I presume "capped" is used in the normal sense of not being allowed to exceed a
certain value. I guess yes, 1 is a conservative value in a way, after all the
only lower value is zero and that wouldn't make a lot of sense. As written the
text has the odor of recommending the value of 1 without actually doing so,
it's just that "conservative" sounds like approval in this context. Is all of
that intentional?

[GF]: I think we can also explicitly recommend the value of 1.

### Section 3.3

Surely "IP/IPv6" is the wrong terminology -- should be either "IP" (meaning,
IPv4 or IPv6) or "IPv4/IPv6"?

[GF]: Ok we will replace it.

### Section 3.3

Concerning the Unreported Loss counter you have,

                                    If the protocol is able to rescind
   the loss determination later, a positive Unreported Loss counter may
   be decremented due to the rescission, but it should not become
   negative due to the rescission.

and later,

                                                        (so Unreported
   Loss counter may become negative when a packet with L=1 is sent after
   a partial packet has been lost)

Is my conclusion correct, that negative values are permitted and should be
supported, but only in the latter case and not the former?

[GF]: Yes, but I will modify the first sentence to avoid misunderstanding. We can say that in general it should not become negative due to the rescission, but it can happen in few cases.

## NITS

### Section 3.5, Section 4

s/this draft/this document/

[GF]: Ok

### Section 7

s/gleamed/gleaned/

[GF]: Ok

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments