Skip to main content

Alternate-Marking Method
draft-ietf-ippm-rfc8321bis-03

Revision differences

Document history

Date Rev. By Action
2024-01-26
03 Gunter Van de Velde Request closed, assignment withdrawn: Sarah Banks Last Call OPSDIR review
2024-01-26
03 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2022-12-12
03 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-12-02
03 (System) RFC Editor state changed to AUTH48
2022-10-21
03 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-09-26
03 (System) IANA Action state changed to No IANA Actions from In Progress
2022-09-23
03 (System) RFC Editor state changed to EDIT
2022-09-23
03 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-09-23
03 (System) Announcement was received by RFC Editor
2022-09-22
03 (System) IANA Action state changed to In Progress
2022-09-22
03 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-09-22
03 Cindy Morgan IESG has approved the document
2022-09-22
03 Cindy Morgan Closed "Approve" ballot
2022-09-22
03 Cindy Morgan Ballot approval text was generated
2022-09-22
03 Martin Duke IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2022-09-22
03 (System) Removed all action holders (IESG state changed)
2022-09-22
03 Martin Duke IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup
2022-09-14
03 Dan Harkins Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Dan Harkins.
2022-09-08
03 Robert Wilton [Ballot comment]
Thanks for updating the text.
2022-09-08
03 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss
2022-09-07
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2022-09-07
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2022-08-29
03 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2022-08-29
03 Zaheduzzaman Sarker [Ballot comment]
Thanks for addressing my discuss point.
2022-08-29
03 Zaheduzzaman Sarker [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from Discuss
2022-08-26
03 Warren Kumari
[Ballot comment]
Many of my original concerns around the controlled / limited domains text still remain; the document has attempted to address them, and, while …
[Ballot comment]
Many of my original concerns around the controlled / limited domains text still remain; the document has attempted to address them, and, while not perfect, I think it is good enough (and the impact of escaping packets is IMO sufficiently low) that I am clearing my DISCUSS.

Much thanks to the authors, and apologies for my somewhat pissey / snarky tone in the original DISCUSS.
2022-08-26
03 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss
2022-08-25
03 Éric Vyncke
[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-ippm-rfc8321bis-02
CC @evyncke

Thank you for the work put into this document and for addressing my …
[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-ippm-rfc8321bis-02
CC @evyncke

Thank you for the work put into this document and for addressing my previous DISCUSS and most of the COMMENTs. Those are kept below for archiving and not for action.

Please note that Tim Winters is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when Tim will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/reviewrequest/16061/

Special thanks to Tommy Pauly for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## Previous DISCUSS (kept for archiving)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 5

Unsure whether I understand correctly:
```
  Color switching is the reference for all the network devices, and the
  only requirement to be achieved is that all network devices have to
  recognize the right batch along the path.
```
Why do *all network devices* have to recognize the right batch? Isn't this transparent for them?

## Previous COMMENTS (kept for archiving)

### Roman's DISCUSS

Just to let you know that I support Roman Danyliw's DISCUSS point.

But, I also wonder why there is a recommendation to use this method only within controlled domains (except to falsify measurements).

### Changes of reference types between RFC 8321 and the -bis

What is the reason why some references (e.g., RFC 3393) moved from the normative (in RFC 8321) to the informative section (in this document).

### Section 1

```
  RFC 7799 [RFC7799] defines Passive and Hybrid Methods of Measurement.
  In particular, Passive Methods of Measurement are based solely on
  observations of an undisturbed and unmodified packet stream of
  interest; Hybrid Methods are Methods of Measurement that use a
  combination of Active Methods and Passive Methods.
```

This short summary would benefit of an "active methods" definition.

### Section 3.1

In `A safe choice is to wait L/2 time units`, some experimental feedbacks or a theoretical reasoning would be welcome. (I am not a transport expert, but a packet delayed a lot is probably worse than a packet loss).

### Section 3.2.1.1 using the mean

Just wondering whether the authors have experimented with other statistical metrics, e.g., the median (more 'complex' to compute of course) or taking into account the standard deviation ?

Also, what is the impact of the arrival rate distribution on using the mean ?

### Section 3.2.2

While this section answers my previous comment, may I suggest moving the description of "double-marking" earlier in the flow ? It now appears "out of the blue" ;-)

Moreover, the description is rather opaque, e.g., some examples would be welcome.

### Section 4.3 telemetry

Is there a YANG model specified (or under specification) for data collection ?

### Section 5

```
  Additionally, in practice, besides clock
  errors, packet reordering is also very common in a packet network due
  to equal-cost multipath (ECMP).
```
Unsure whether ECMP really causes a "very common packet re-ordering". Suggest to s/very common/common/ at least ;-)

### Section 5 bound

```
  The network delay between the network devices can be represented as a
  data set and 99.7% of the samples are within 3 standard deviation of
  the average
```
Does the above assume a specific packet distribution ?

### Section 6 fragmentation

Should there be a note about:

* IPv6 routers never fragment
* use of DF bit for IPv4


## NITS


### Capitalized Passive

Unsure whether "Passive" needs to be capitalized in the text.

### Section 3.2

s/There are three alternatives, as described hereinafter./There are three methodologies, as described hereinafter./ ? (notably because there can only be *TWO* alternatives AFAIK)

## 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
2022-08-25
03 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to Yes from Discuss
2022-08-05
03 Roman Danyliw [Ballot comment]
Thank you for addressing my DISCUSS feedback.
2022-08-05
03 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2022-08-02
03 Alvaro Retana [Ballot comment]
[Thanks for addressing my DISCUSS.]
2022-08-02
03 Alvaro Retana [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss
2022-07-25
03 (System) Changed action holders to Martin Duke (IESG state changed)
2022-07-25
03 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-07-25
03 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2022-07-25
03 Giuseppe Fioccola New version available: draft-ietf-ippm-rfc8321bis-03.txt
2022-07-25
03 (System) New version approved
2022-07-25
03 (System) Request for posting confirmation emailed to previous authors: Giuseppe Fioccola , Greg Mirsky , Mauro Cociglio , Tal Mizrahi , Tianran Zhou
2022-07-25
03 Giuseppe Fioccola Uploaded new revision
2022-07-15
02 Timothy Winters Request for Telechat review by INTDIR Completed: Not Ready. Reviewer: Timothy Winters. Sent review to list.
2022-07-14
02 (System) Changed action holders to Martin Duke, Tal Mizrahi, Mauro Cociglio, Greg Mirsky, Tianran Zhou, Giuseppe Fioccola (IESG state changed)
2022-07-14
02 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2022-07-14
02 Paul Wouters [Ballot comment]
I do support the DISCUSSes filed, especially those by Roman and Warren.
2022-07-14
02 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2022-07-14
02 Robert Wilton
[Ballot discuss]
Sorry, another discuss, but hopefully a trivial one to resolve.

I found this text to be a unclear regarding passive vs hybrid:

  …
[Ballot discuss]
Sorry, another discuss, but hopefully a trivial one to resolve.

I found this text to be a unclear regarding passive vs hybrid:

  Therefore, the Alternate-Marking Method could be considered Hybrid or
  Passive, depending on the case.  In the case where the marking method
  is obtained by changing existing field values of the packets the
  technique is Hybrid.  In the case where the marking field is
  dedicated, reserved, and included in the protocol specification, the
  Alternate-Marking technique can be considered as Passive.

Please can you clarify the third sentence, to clarify that the marking is done at source, or at least outside the controlled domain?  I.e., I presume that even if there were some reserved bits in the protocol header for colouring packets, that were then written at the edge of the controlled domain, then this would be a active rather than passive measurement?

Thanks,
Rob
2022-07-14
02 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2022-07-13
02 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-07-13
02 Zaheduzzaman Sarker
[Ballot discuss]
Thanks for working on this specification.

My fellow AD colleagues have already put discusses on the concerns I have. Overall, I found this …
[Ballot discuss]
Thanks for working on this specification.

My fellow AD colleagues have already put discusses on the concerns I have. Overall, I found this document easy to ready but lacking some clarity on the assumptions and instructions. For, this I am supporting Roman's and Lars's discuss.

Apart from those I have one additional concern.

## Section 7 : says -
      In the case where the marking method is applied by changing existing
  fields of the packets, it is RECOMMENDED to use an additional flag or
  some out-of-band signaling to indicate if the measurement is
  activated or not in order to inform the measurement points.

  It is not clear who is changing existing fields of which packets? It needs more specific description for at least which packets are we talking about (IP packets? ) and what additional flag we are referring to here.
2022-07-13
02 Zaheduzzaman Sarker [Ballot Position Update] New position, Discuss, has been recorded for Zaheduzzaman Sarker
2022-07-12
02 Warren Kumari
[Ballot discuss]
Section 7.1 says:
"The Alternate Marking Method is an example of a solution limited to a controlled domain [RFC8799].
A controlled …
[Ballot discuss]
Section 7.1 says:
"The Alternate Marking Method is an example of a solution limited to a controlled domain [RFC8799].
A controlled domain is a managed network that selects, monitors, and controls access by enforcing policies at the domain boundaries, in order to discard undesired external packets entering the domain and check internal packets leaving the domain. [...] It must be possible to control the domain boundaries, and use specific precautions if traffic traverses the Internet."

"Controlled domain" isn't a magic incantation you invoke to make all security issues disappear. Your definition of controlled domain sounds suspiciously like "the network should magically stop bad packets, and evil people wanting to do bad things!!!!".

RFC8799 does not define what makes a domain, nor how the boundary is protected. Instead, it "it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes." and notes that "the Internet does not have a well-defined concept of limited domains" and further that "Domain boundaries that are defined administratively (e.g., by address filtering rules in routers) are prone to leakage caused by human error, especially if the limited domain traffic appears otherwise normal to the boundary routers.  In this case, the network operator needs to take active steps to protect the boundary."

The document states that "For security reasons, the Alternate Marking Method is RECOMMENDED only for controlled domains." - but you have not defined how a network operator is expected to define and enforce the domain boundary; simply saying that the network should select, monitor, and control access by enforcing policies at the domain boundaries, in order to discard undesired external packets doesn't explain how the network should do this. How exactly does the network know what packets are marked? How does the operator filter these? What matching rule can be applied at the boundary to make sure that marked packets do not enter or exit the network?
2022-07-12
02 Warren Kumari [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari
2022-07-12
02 Lars Eggert
[Ballot discuss]
# GEN AD review of draft-ietf-ippm-rfc8321bis-02

CC @larseggert

Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/tX3DO8ZB3yeiaKC_xnI1khVAcss). …
[Ballot discuss]
# GEN AD review of draft-ietf-ippm-rfc8321bis-02

CC @larseggert

Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/tX3DO8ZB3yeiaKC_xnI1khVAcss).

## Discuss

### Section 3.1, paragraph 5
```
    The rest of the document assumes that the blocks are created
    according to a fixed timer.  The switching after a fixed number of
    packets is an additional possibility but its detailed specification
    is out of scope.
```
This should more strongly say that the use fixed timers are REQUIRED when
implementing the spec. This document should then also be stripped of all text
discussing the "fixed number of packets" approach, to improve clarity. (You
could move it to a non-normative appendix, if there is a desire to keep the text
around.)

### Section 3.1, paragraph 16
```
    Two different strategies that can be used when implementing the
    method:
```
If both of these strategies are part of the standard, concrete guidance needs to
be given when to use one or the other. The text below about "a limited number of
traffic flows") is too unspecific.

### Section 3.2, paragraph 1
```
    The same principle used to measure packet loss can be applied also to
    one-way delay measurement.  There are three alternatives, as
    described hereinafter.
```
As above, there is a lot of discussion text around these alternatives, but no
concrete guidance when one SHOULD be used but not the other two. If that
guidance cannot be given, I wonder if we have enough deployment experience to
lift this to the Standards Track.

### Section 5, paragraph 1
```
    This document introduces two color-switching methods: one is based on
    a fixed number of packets, and the other is based on a fixed timer.
    But the method based on a fixed timer is preferable because it is
    more deterministic, and it is considered in the document.
```
Section 3.1 says that the fixed-number-based approach is out of scope for this
specification. The text above is inconsistent with that. Again, please remove
the text that talks about the option that is not actually part of the intended
standard (or move it to an appendix.)
2022-07-12
02 Lars Eggert
[Ballot comment]

## Comments

### Section 1, paragraph 5
```
    [RFC7276] provides a good overview of existing Operations,
    Administration, …
[Ballot comment]

## Comments

### Section 1, paragraph 5
```
    [RFC7276] provides a good overview of existing Operations,
    Administration, and Maintenance (OAM) mechanisms defined in the IETF,
    ITU-T, and IEEE.  In the IETF, a lot of work has been done on fault
    detection and connectivity verification, while little has been thus
    far dedicated to performance monitoring.  The IETF has defined
    standard metrics to measure network performance; however, its methods
    mainly focus on Active measurement techniques.For example, [RFC6374]
    defines mechanisms for measuring packet loss, one-way and two-way
    delay, and delay variation in MPLS networks, but its applicability to
    Passive measurements has some limitations, especially for connection-
    less networks.
```
This statement on the current state of work in the IETF might not age well in an
RFC - maybe remove?

### Section 1.2, paragraph 0
```
  1.2.  Requirements Language
```
Like draft-ietf-ippm-rfc8889bis, this document is very light on RFC2119
language, which leaves it quite unclear what the actually specified technique is
intended to be. There are a lot of options for various pieces, but not enough
guidance on when an option MUST/SHOULD/MAY be chosen and why.

### Section 3.1, paragraph 17
```
    Using a fixed timer for color switching offers better control over
    the method: the (time) length of the blocks can be chosen large
    enough to simplify the collection and the comparison of measures
    taken by different network devices.  It's preferable to read the
    value of the counters not immediately after the color switch: some
    packets could arrive out of order and increment the counter
    associated with the previous block (color), so it is worth waiting
    for some time.  A safe choice is to wait L/2 time units (where L is
    the duration for each block) after the color switch, to read the
    counter of the previous color.  The drawback is that the longer the
    duration of the block, the less frequently the measurement can be
    taken.
```
Example of a paragraph that can be removed or moved, since the "fixed timer"
option isn't being standardized.

### Section 4.3, paragraph 9
```
    The Alternate-Marking Method described in this document literally
    splits the packets of the measured flow into different measurement
    blocks.  An implementation MAY use a Block Number (BN) for data
    correlation.  The BN MAY be assigned to each measurement block and
    associated with each packet count and timestamp reported to or pulled
    by other nodes or NMSs. 
```
Shouldn't the second MAY be a MUST? It MAY be done, and if it's done it MUST be
done in this specific way?

### Section 5, paragraph 8
```
    It is assumed that all network devices are synchronized to a common
    reference time with an accuracy of +/- A/2.  Thus, the difference
    between the clock values of any two network devices is bounded by A.
```
This should be made an RFC2119 deployment requirement, because if this cannot be
guaranteed, wouldn't the mechanism break down?

### Section 5, paragraph 17
```
    If the time duration L of each block is not so small, the
    synchronization requirement could be satisfied even with a relatively
    inaccurate synchronization method.  This is true for packet loss and
    two-way delay measurement, but not for one-way delay measurement,
    where clock synchronization must be accurate.  Therefore, a system
    that uses only packet loss and two-way delay measurement may not
    require a very precise synchronization.  This is because the value of
    the clocks of network devices does not affect the computation of the
    two-way delay measurement.
```
This paragraph does not give actionable guidance on what clock sync scheme to
use for a given deployment.

### Section 6, paragraph 5
```
        Measurement points MAY simply ignore unmarked fragments and count
        marked fragments as full packets.  However, if resources allow,
        measurement points MAY make note of both marked and unmarked
        initial fragments and only increment the corresponding counter if
        (a) other fragments are also marked, or (b) it observes all other
        fragments and they are unmarked.
```
Shouldn't this more strongly RECOMMEND noting marked fragments, and give
resource consumption as a reason to not follow the recommendation?

### Section 7, paragraph 2
```
    Either one or two flag bits might be available for marking in
    different deployments:
```
The combination of SHOULDs and MAYs in the two following paragraphs leaves
things underspecified.

### Section 7.1, paragraph 3
```
    For security reasons, the Alternate Marking Method is RECOMMENDED
    only for controlled domains.
```
Shouldn't this be a MUST-level requirement? I thought the security
considerations were only valid inside a limited domain.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `man`; alternatives might be `individual`, `people`, `person`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Grammar/style

#### Section 3.1, paragraph 1
```
packets is an additional possibility but its detailed specification is out o
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 3.1, paragraph 18
```
where load-balancing is seldom used and static joins are frequently used to
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 3.1, paragraph 22
```
rent to intermediate nodes and independent from the path followed by traffic
                              ^^^^^^^^^^^^^^^^
```
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

#### Section 13.2, paragraph 4
```
ut not detailed. o Explanation of the the intrinsic error in section 3.3.1 on
                                  ^^^^^^^
```
Possible typo: you repeated a word.

## 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. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2022-07-12
02 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert
2022-07-12
02 Éric Vyncke
[Ballot discuss]
# Éric Vyncke, INT AD, comments for draft-ietf-ippm-rfc8321bis-02
CC @evyncke

Thank you for the work put into this document.

Please find below one …
[Ballot discuss]
# Éric Vyncke, INT AD, comments for draft-ietf-ippm-rfc8321bis-02
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Please note that Tim Winters is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when Tim will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/reviewrequest/16061/

Special thanks to Tommy Pauly for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 5

Unsure whether I understand correctly:
```
  Color switching is the reference for all the network devices, and the
  only requirement to be achieved is that all network devices have to
  recognize the right batch along the path.
```
Why do *all network devices* have to recognize the right batch? Isn't this transparent for them?
2022-07-12
02 Éric Vyncke
[Ballot comment]

## COMMENTS

### Roman's DISCUSS

Just to let you know that I support Roman Danyliw's DISCUSS point.

But, I also wonder why there …
[Ballot comment]

## COMMENTS

### Roman's DISCUSS

Just to let you know that I support Roman Danyliw's DISCUSS point.

But, I also wonder why there is a recommendation to use this method only within controlled domains (except to falsify measurements).

### Changes of reference types between RFC 8321 and the -bis

What is the reason why some references (e.g., RFC 3393) moved from the normative (in RFC 8321) to the informative section (in this document).

### Section 1

```
  RFC 7799 [RFC7799] defines Passive and Hybrid Methods of Measurement.
  In particular, Passive Methods of Measurement are based solely on
  observations of an undisturbed and unmodified packet stream of
  interest; Hybrid Methods are Methods of Measurement that use a
  combination of Active Methods and Passive Methods.
```

This short summary would benefit of an "active methods" definition.

### Section 3.1

In `A safe choice is to wait L/2 time units`, some experimental feedbacks or a theoretical reasoning would be welcome. (I am not a transport expert, but a packet delayed a lot is probably worse than a packet loss).

### Section 3.2.1.1 using the mean

Just wondering whether the authors have experimented with other statistical metrics, e.g., the median (more 'complex' to compute of course) or taking into account the standard deviation ?

Also, what is the impact of the arrival rate distribution on using the mean ?

### Section 3.2.2

While this section answers my previous comment, may I suggest moving the description of "double-marking" earlier in the flow ? It now appears "out of the blue" ;-)

Moreover, the description is rather opaque, e.g., some examples would be welcome.

### Section 4.3 telemetry

Is there a YANG model specified (or under specification) for data collection ?

### Section 5

```
  Additionally, in practice, besides clock
  errors, packet reordering is also very common in a packet network due
  to equal-cost multipath (ECMP).
```
Unsure whether ECMP really causes a "very common packet re-ordering". Suggest to s/very common/common/ at least ;-)

### Section 5 bound

```
  The network delay between the network devices can be represented as a
  data set and 99.7% of the samples are within 3 standard deviation of
  the average
```
Does the above assume a specific packet distribution ?

### Section 6 fragmentation

Should there be a note about:

* IPv6 routers never fragment
* use of DF bit for IPv4


## NITS


### Capitalized Passive

Unsure whether "Passive" needs to be capitalized in the text.

### Section 3.2

s/There are three alternatives, as described hereinafter./There are three methodologies, as described hereinafter./ ? (notably because there can only be *TWO* alternatives AFAIK)

## 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
2022-07-12
02 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2022-07-11
02 Alvaro Retana
[Ballot discuss]
§7 ("Results of the Alternate Marking Experiment") makes several
recommendations about the use of one or two flag bits:

      One …
[Ballot discuss]
§7 ("Results of the Alternate Marking Experiment") makes several
recommendations about the use of one or two flag bits:

      One flag: packet loss measurement SHOULD be done as described in
      Section 3.1, while delay measurement MAY be done according to the
      single-marking method described in Section 3.2.1.  Mean delay
      (Section 3.2.1.1) is NOT RECOMMENDED since it implies more
      computational load.

      Two flags: packet loss measurement SHOULD be done as described in
      Section 3.1, while delay measurement SHOULD be done according to
      double-marking method Section 3.2.2.  In this case single-marking
      MAY also be used in combination with double-marking and the two
      approaches provide slightly different pieces of information that
      can be combined to have a more robust data set.

These recommendations are good, as they are the result of experimentation. 
However, they don't provide any deployment or operational guidelines of when
is it ok to follow them and when it isn't.  For example, for the one flag case,
when it is ok to not measure packet loss as described in §3.1?  Why is the use
of that mechanism only recommended and not required?

I have the same questions for all the recommendations and optional indications
in the text above.  To clear this DISCUSS I expect deployment or operational
recommendations that can be used as implementation/deployment guidance.
2022-07-11
02 Alvaro Retana
[Ballot comment]
(1) I support Roman's DISCUSS position, and have a related question to this text in §7.1 (Controlled Domain requirement):

  For security reasons, …
[Ballot comment]
(1) I support Roman's DISCUSS position, and have a related question to this text in §7.1 (Controlled Domain requirement):

  For security reasons, the Alternate Marking Method is RECOMMENDED
  only for controlled domains.

When is it ok to use the Alternate Marking Method in any other deployment?  IOW, given the definition of a controlled domain earlier in this section, why is its use only recommended and not required?

[I am not including this point as a DISCUSS because I expect it to be solved when Roman's concern is addressed.]


(2) §7 says that a deployment "SHOULD also take into account how to handle and recognize marked and unmarked traffic".  I don't see any interoperability need to use an rfc2199 keyword.  IOW, s/SHOULD/should
2022-07-11
02 Alvaro Retana [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana
2022-07-11
02 John Scudder
[Ballot comment]
Thanks for this quite readable document.

I support Roman's DISCUSS. I also have some questions and comments:

1. In §2,

      …
[Ballot comment]
Thanks for this quite readable document.

I support Roman's DISCUSS. I also have some questions and comments:

1. In §2,

                                                  Each change of color
  represents a sort of auto-synchronization signal that guarantees the
  consistency of measurements taken by different devices along the
  path.
 
I realize this is fairly picky, but isn't "guarantee" over-promising? In situations like this there's usually some low-probability chance that something will go awry, and that does seem to be possible in this case. Presumably some slightly weaker language like "maximizes the probability of" or similar would be more accurate?

2. In §3.2.1,

        Since the timestamps refer to specific packets (the first packet
  of each block), we are sure that timestamps compared to compute delay
  refer to the same packets.
 
But two paragraphs down you explain how in real life, we are actually not sure, because of the potential for packet loss and misordering. It might, then, be worthwhile to correct the sentence? E.g., "... in the ideal case where no packet loss or misordering exists, we would be sure that timestamps compared to compute the delay refer to the same packets."

3. In §4.3, I must be missing something:

                                                          In any case,
      the NMS has to collect all the relevant values from all the
      routers within one cycle of the timer.

"Within one cycle of the timer" seems to assume that the routers don't maintain a table of past values that can be collected at some less demanding cadence, as long as entries aren't allowed to age out. Is there some reason that's not so? (I'm assuming that the timer you're referring to is the fixed color switching timer. If that's not what it is, clarification is needed here.)

4. Thank you very much for reporting results of the earlier experiment, in §7. However, I don't understand why a section titled "Results of the Alternate Marking Experiment" uses RFC 2119 keywords. I guess they'd make more sense if the part that includes 2119 keywords were called something like "Recommendations for Deployment"... or you could just retitle the section as "Results of the Alternate Marking Experiment, with Recommendations for Deployment" as a minimal patch.

5. In §7.1,

  For security reasons, the Alternate Marking Method is RECOMMENDED
  only for controlled domains.

Do you mean, "the Alternate Marking Method is NOT RECOMMENDED other than in controlled domains"? Because surely you aren't saying all controlled domains SHOULD deploy alt-mark, which is what a strict reading of this sentence, considering the formal definition of RECOMMENDED, means.

Also, what exactly is the controlled domain supposed to control? Is it only the scope of marked packets? Or is it also the scope of the data derived from the marked packets?

6. In §10 I find myself bemused by,

  This document specifies a method to perform measurements in the
  context of a Service Provider's network and has not been developed to
  conduct Internet measurements, so it does not directly affect
  Internet security nor applications that run on the Internet.

The Internet is nothing other than the concatenation of many networks, many of which are Service Provider networks, so I don't see how your premise leads to your conclusion?

Nits:

7. In §4.2, where you write "(included)" although the meaning is clear, I think "(inclusive)" is more standard usage.
2022-07-11
02 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2022-07-11
02 Roman Danyliw
[Ballot discuss]
Please clarify the expected deployment model of this approach.

(a) Section 7.1

  For security reasons, the Alternate Marking Method is RECOMMENDED
  …
[Ballot discuss]
Please clarify the expected deployment model of this approach.

(a) Section 7.1

  For security reasons, the Alternate Marking Method is RECOMMENDED
  only for controlled domains.

(b) Section 10
  This document specifies a method to perform measurements in the
  context of a Service Provider's network and has not been developed to
  conduct Internet measurements, so it does not directly affect
  Internet security nor applications that run on the Internet.

The text in (a) suggests that deployment can occur on the Internet (although it isn’t recommended).  However, (b) and other documents out of IPPM (e.g., RFC9197) seem to suggest that OAM meta-data must be filtered.
2022-07-11
02 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2022-06-24
02 Elwyn Davies Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Sent review to list.
2022-06-23
02 Bernie Volz Request for Telechat review by INTDIR is assigned to Timothy Winters
2022-06-23
02 Bernie Volz Request for Telechat review by INTDIR is assigned to Timothy Winters
2022-06-23
02 Éric Vyncke Requested Telechat review by INTDIR
2022-06-22
02 Martin Duke Placed on agenda for telechat - 2022-07-14
2022-06-22
02 Martin Duke Ballot has been issued
2022-06-22
02 Martin Duke [Ballot Position Update] New position, Yes, has been recorded for Martin Duke
2022-06-22
02 Martin Duke Created "Approve" ballot
2022-06-22
02 Martin Duke IESG state changed to IESG Evaluation from Waiting for Writeup
2022-06-22
02 Martin Duke Ballot writeup was changed
2022-06-21
02 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-06-14
02 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2022-06-14
02 Michelle Thangtamsatid
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-ippm-rfc8321bis-02, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-ippm-rfc8321bis-02, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist
2022-06-12
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sandra Murphy
2022-06-12
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sandra Murphy
2022-06-08
02 Peter Yee Request for Last Call review by GENART is assigned to Elwyn Davies
2022-06-08
02 Peter Yee Request for Last Call review by GENART is assigned to Elwyn Davies
2022-06-08
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sarah Banks
2022-06-08
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sarah Banks
2022-06-07
02 Cindy Morgan IANA Review state changed to IANA - Review Needed
2022-06-07
02 Cindy Morgan
The following Last Call announcement was sent out (ends 2022-06-21):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ippm-rfc8321bis@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, martin.h.duke@gmail.com, tpauly@apple.com …
The following Last Call announcement was sent out (ends 2022-06-21):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ippm-rfc8321bis@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, martin.h.duke@gmail.com, tpauly@apple.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Alternate-Marking Method) to Proposed Standard


The IESG has received a request from the IP Performance Measurement WG (ippm)
to consider the following document: - 'Alternate-Marking Method'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-06-21. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the Alternate-Marking technique to perform
  packet loss, delay, and jitter measurements on live traffic.  This
  technology can be applied in various situations and for different
  protocols.  It could be considered Passive or Hybrid depending on the
  application.  This document obsoletes RFC8321.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5649/





2022-06-07
02 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2022-06-07
02 Martin Duke Last call was requested
2022-06-07
02 Martin Duke Last call announcement was generated
2022-06-07
02 Martin Duke Ballot approval text was generated
2022-06-07
02 Martin Duke Ballot writeup was generated
2022-06-07
02 (System) Changed action holders to Martin Duke (IESG state changed)
2022-06-07
02 Martin Duke IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2022-06-07
02 (System) Removed all action holders (IESG state changed)
2022-06-07
02 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-06-07
02 Giuseppe Fioccola New version available: draft-ietf-ippm-rfc8321bis-02.txt
2022-06-07
02 (System) New version approved
2022-06-07
02 (System) Request for posting confirmation emailed to previous authors: Giuseppe Fioccola , Greg Mirsky , Mauro Cociglio , Tal Mizrahi , Tianran Zhou
2022-06-07
02 Giuseppe Fioccola Uploaded new revision
2022-06-01
01 Martin Duke Changed action holders to Tal Mizrahi, Mauro Cociglio, Greg Mirsky, Tianran Zhou, Giuseppe Fioccola
2022-06-01
01 (System) Changed action holders to Martin Duke, Tal Mizrahi, Mauro Cociglio, Greg Mirsky, Tianran Zhou, Giuseppe Fioccola (IESG state changed)
2022-06-01
01 Martin Duke IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2022-06-01
01 (System) Changed action holders to Martin Duke (IESG state changed)
2022-06-01
01 Martin Duke IESG state changed to AD Evaluation from Publication Requested
2022-05-27
01 Tommy Pauly
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering …
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This is small bis update we took through the WG quickly. It had clear consensus, with 
about 1/3-1/2 of the active WG chiming in. Both RFC8321bis and RFC8889bis are
being taken through the process together.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no controversy in these updates within the WG.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals threatened.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Our adoption call of the -bis document raised the question of implementations,
and several implementations were discussed on the mailing list.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

This -bis effort was spurred on by draft-ietf-6man-ipv6-alt-mark, which normatively
references the work. Authors are participants of both WGs, and that WG is aware of this work.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG model.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I think these documents are ready to progress.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

I do not believe this document requires further area reviews.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

Proposed Standard. The point of this bis effort is to move from Experimental
to Proposed Standard.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

Yes, IPR is filed for both RFC8321bis and RFC8889bis, which is just a carry-over
of the existing IPR on the original RFC8321 and RFC8889 documents.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Both documents have 5 authors each, and all authors were involved with the
original RFCs.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

Nits for RFC8321bis:

  ** The abstract seems to contain references ([RFC8321]), which it
    shouldn't.  Please replace those with straight textual mentions of the
    documents in question.

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-1588'

These items should be addressed by making the reference to RFC8321 in the
abstract textual as suggesting, making the reference to IEEE-1588 informative.

15. Should any informative references be normative or vice-versa?

For RFC8321bis: the reference to IEEE-1588 might need to become informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are available.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

See note above about IEEE-1588.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Yes, RFC8321bis obsoletes RFC8321, as described in the abstract.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

This document does not have IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This document does not have IANA actions.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html
2022-05-27
01 Tommy Pauly Responsible AD changed to Martin Duke
2022-05-27
01 Tommy Pauly IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2022-05-27
01 Tommy Pauly IESG state changed to Publication Requested from I-D Exists
2022-05-27
01 Tommy Pauly IESG process started in state Publication Requested
2022-05-27
01 Tommy Pauly
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering …
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This is small bis update we took through the WG quickly. It had clear consensus, with 
about 1/3-1/2 of the active WG chiming in. Both RFC8321bis and RFC8889bis are
being taken through the process together.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no controversy in these updates within the WG.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals threatened.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Our adoption call of the -bis document raised the question of implementations,
and several implementations were discussed on the mailing list.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

This -bis effort was spurred on by draft-ietf-6man-ipv6-alt-mark, which normatively
references the work. Authors are participants of both WGs, and that WG is aware of this work.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG model.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I think these documents are ready to progress.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

I do not believe this document requires further area reviews.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

Proposed Standard. The point of this bis effort is to move from Experimental
to Proposed Standard.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

Yes, IPR is filed for both RFC8321bis and RFC8889bis, which is just a carry-over
of the existing IPR on the original RFC8321 and RFC8889 documents.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Both documents have 5 authors each, and all authors were involved with the
original RFCs.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

Nits for RFC8321bis:

  ** The abstract seems to contain references ([RFC8321]), which it
    shouldn't.  Please replace those with straight textual mentions of the
    documents in question.

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-1588'

These items should be addressed by making the reference to RFC8321 in the
abstract textual as suggesting, making the reference to IEEE-1588 informative.

15. Should any informative references be normative or vice-versa?

For RFC8321bis: the reference to IEEE-1588 might need to become informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are available.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

See note above about IEEE-1588.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Yes, RFC8321bis obsoletes RFC8321, as described in the abstract.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

This document does not have IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This document does not have IANA actions.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html
2022-05-25
Tina Dang Posted related IPR disclosure Telecom Italia SpA's Statement about IPR related to draft-ietf-ippm-rfc8321bis
2022-05-18
01 Tommy Pauly Notification list changed to tpauly@apple.com because the document shepherd was set
2022-05-18
01 Tommy Pauly Document shepherd changed to Tommy Pauly
2022-05-18
01 Tommy Pauly IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2022-05-18
01 Tommy Pauly Changed consensus to Yes from Unknown
2022-05-18
01 Tommy Pauly Intended Status changed to Proposed Standard from None
2022-04-28
01 Tommy Pauly IETF WG state changed to In WG Last Call from WG Document
2022-04-28
01 Giuseppe Fioccola New version available: draft-ietf-ippm-rfc8321bis-01.txt
2022-04-28
01 (System) New version approved
2022-04-28
01 (System) Request for posting confirmation emailed to previous authors: Giuseppe Fioccola , Greg Mirsky , Mauro Cociglio , Tal Mizrahi , Tianran Zhou
2022-04-28
01 Giuseppe Fioccola Uploaded new revision
2022-04-26
00 Tommy Pauly This document now replaces draft-fioccola-rfc8321bis instead of None
2022-04-26
00 Giuseppe Fioccola New version available: draft-ietf-ippm-rfc8321bis-00.txt
2022-04-26
00 Tommy Pauly WG -00 approved
2022-04-26
00 Giuseppe Fioccola Set submitter to "Giuseppe Fioccola ", replaces to draft-fioccola-rfc8321bis and sent approval email to group chairs: ippm-chairs@ietf.org
2022-04-26
00 Giuseppe Fioccola Uploaded new revision