[ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-initial-registry-14: (with DISCUSS and COMMENT)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-ippm-initial-registry-14: Discuss

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think these entries shows well how the registry is intended to extended and
the benefit in being clear on what information is needed. I do have a question
that I think needs an answer:

Regarding Section 4.2.2:

   o  IPv6 header values:

      *  DSCP: set to 0

      *  Hop Count: set to 255

      *  Protocol: Set to 17 (UDP)

Does anything about the IPv6 flow ID need to be stated here? As this is a path
delay measurement, the value of the flow ID field has the potential to change
the result. If one would use a new random value for each individual measurement
in a sequence one may see different results than from using the same ID for all
the measurements. Or is this specified in any of the references? In most case I
would expect one use a single value, but likely randomly selected. However, it
does depend on what purpose of ones measurement one have, thus I think this do
matter.

I think this question applies to all measurements that are multi-packet ones so
section 5, 7, 8 and 9 most definitely.

I also wonder if IPv6 Flow ID is an output parameter that needs to be kept?


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

Section 4.2.2:

   o  UDP header values:

      *  Checksum: the checksum MUST be calculated and included in the
         header

I guess this implies that a non-zero UDP checksum is to be used. Maybe one
could make this water tight by changing it to:

      *  Checksum: the checksum MUST be calculated and the non-zero checksum
           included in the header