Skip to main content

IPv6 Application of the Alternate Marking Method
draft-ietf-6man-ipv6-alt-mark-14

Revision differences

Document history

Date Rev. By Action
2022-04-28
14 Martin Duke [Ballot comment]
Thanks for addressing my DISCUSS.

Thanks to Yoshi for the TSVART review.
2022-04-28
14 Martin Duke [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss
2022-04-28
14 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-14.txt
2022-04-28
14 (System) New version approved
2022-04-28
14 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2022-04-28
14 Giuseppe Fioccola Uploaded new revision
2022-03-31
13 Martin Duke
[Ballot discuss]
Thanks for addressing most of my DISCUSS points.

I would like an unambiguous statement in Section 3.1 that the FlowMonID MUST appear to …
[Ballot discuss]
Thanks for addressing most of my DISCUSS points.

I would like an unambiguous statement in Section 3.1 that the FlowMonID MUST appear to be random. There is still language that suggests it might not be: (e.g., "The disambiguation issue is more visible when the FlowMonID is pseudorandomly generated...". If it is anything less than a MUST, there needs to be additional Security Considerations to reflect the impact of not doing so.
2022-03-31
13 Martin Duke Ballot discuss text updated for Martin Duke
2022-03-31
13 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-13.txt
2022-03-31
13 (System) New version approved
2022-03-31
13 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2022-03-31
13 Giuseppe Fioccola Uploaded new revision
2022-01-10
12 Roman Danyliw
[Ballot comment]
Thank you to Chris Wood for the SECDIR review and to the authors for responding to it.

Thank you for the document revisions …
[Ballot comment]
Thank you to Chris Wood for the SECDIR review and to the authors for responding to it.

Thank you for the document revisions to address my DISCUSS and COMMENT feedback.
2022-01-10
12 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2021-11-29
Tina Dang Posted related IPR disclosure Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-6man-ipv6-alt-mark
2021-10-26
12 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2021-10-22
12 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-12.txt
2021-10-22
12 (System) New version approved
2021-10-22
12 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2021-10-22
12 Giuseppe Fioccola Uploaded new revision
2021-10-21
11 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-11.txt
2021-10-21
11 (System) New version approved
2021-10-21
11 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2021-10-21
11 Giuseppe Fioccola Uploaded new revision
2021-10-07
10 Éric Vyncke
[Ballot comment]
Giuseppe,

Thank you for the -10 revision, which indeed addresses all my previous DISCUSS. Hence, I am now balloting NO OBJECTION to the …
[Ballot comment]
Giuseppe,

Thank you for the -10 revision, which indeed addresses all my previous DISCUSS. Hence, I am now balloting NO OBJECTION to the document. Please ignore the DISCUSS points below that I kept only for documentation.

Regards

-éric

-- everything below is for archiving purpose only --

Thank you for the work put into this document.

As Brian Carpenter kindly reminded me that an Area Director may not put back a previous argument when the WG consensus was to ignore it, I am updating this ballot by moving the generic DISCUSS as a COMMENT.

The other two DISCUSS points remains blocking ones but Giuseppe have already addressed them over email, I am clearing the DISCUSS position as soon as the revised I-D is posted.

Special thanks to Ole Trøan for his shepherd's write-up, which contains a good summary of the WG consensus and the SW (?) implementation status. Thanks as well to Bob Halley for his INT directorate review.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated).

I also agree with DISCUSS points by other ADs:
- Lars's one about the size and usefulness of FlowMonID (see my very similar point)
- Roman's one about the inconsistencies about limited domain (from my point of view, this should not be limited to a single domain)

All in all, I strongly suggest to change the intended status of this document to 'experimental' as this document builds on experimental RFCs.

I hope that this helps to improve the document,

Regards,

-éric


== PREVIOUS DISCUSS (only for archives) ==


-- Section 2 --
  "In the end, [I-D.fioccola-v6ops-ipv6-alt-mark] demonstrated that a
  new Hop-by-Hop or a new Destination Option was the best approach."

The above draft has not been published and is even expired for 2 years now... so please remove the 'demonstrated' as there is no proof at all ;-)

-- Section 4 --
Please remove "the destination node removes it" as there is no reason to remove it. Extension headers are usually not presented / used by upper layers anyway.

-- generic --
This discussion already happened in the 6MAN WG but I still have to be convinced that hop-by-hop is a good idea at all. The fate of packets with HbH is unknown at best and, IMHO, this is a wrong use of HbH because the forwarding/processing of packets is NOT influenced at all by the AltMark option. What is required is a simple 'marking/coloring', which could be at any place in a packet (including destination option). The only benefit of HbH is its location just after the IPv6 header.

After all, existing devices can measure and generate IPFIX records in hardware/fastpath by inspecting at the bare minimum the 5-tuple and many devices can also parse extension headers in the fast path (of course not processing HbH in this case). I.e., finding the marking in the Dest Option is probably much easier and doable in current hardware rather than using HbH as HbH forces a software processing.

--- PREVIOUS COMMENT (for archive) ---

-- Section 2.1 --
While I agree with my fellow AD about the inconsistencies of the text around 'limited domain' (and being inconsistent deserves a blocking DISCUSS), I do not agree with this section as I do not see any harm to extend this marking outside of a single domain, marked packets with this specification can traverse the whole Internet without causing any harm and not opening for any attack on the transit nodes. (See also my point about Hop-by-hop)

E.g., packets from organisation A can traverse networks of organizations B, C, ..., Z to reach another site of organization A and still provide useful measurements for A without causing harm to B, C, ..., Z. Of course the survivability of those marked packets is not guaranteed.

-- Section 3.1 --
Is there any reason why the FlowMonID is 20 bit long ? Exactly as the 20-bit Flow Label of the IPv6 header... See my comments for section 5.3

s/Unrecognized Types MUST be ignored on receipt./Unrecognized Types MUST be ignored on processing./ as the option should be processed not only by the destination node.

-- Section 5 --
This section (in a standard track I-D) repeats many things from experimental RFCs... This is really confusing and, while I am usually not dogmatic, I support my fellow AD on this point.

Moreover, repeating contents from other docs can only introduce inconsistencies among docs => suggest to remove section 5.1 and 5.2.

-- Section 5.3 --
The general reasons of using a 20-bit FlowMonID appear quite weak to me with the risk of collision being very high, e.g., in a DC with thousands of VM and millions of containers there will be collisions rendering this field useless. Strongly suggest to make its use optional
2021-10-07
10 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss
2021-09-21
10 Luc André Burdet Request closed, assignment withdrawn: Emmanuel Baccelli Telechat RTGDIR review
2021-09-21
10 Luc André Burdet
Closed request for Telechat review by RTGDIR with state 'Overtaken by Events': Document has been through the IESG — waiting on DISCUSS but don’t need …
Closed request for Telechat review by RTGDIR with state 'Overtaken by Events': Document has been through the IESG — waiting on DISCUSS but don’t need the rtg-dir review anymore
2021-09-17
10 Haomian Zheng Request for Telechat review by RTGDIR is assigned to Emmanuel Baccelli
2021-09-17
10 Haomian Zheng Request for Telechat review by RTGDIR is assigned to Emmanuel Baccelli
2021-09-14
10 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-10.txt
2021-09-14
10 (System) New version approved
2021-09-14
10 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2021-09-14
10 Giuseppe Fioccola Uploaded new revision
2021-08-27
09 (System) Changed action holders to Erik Kline (IESG state changed)
2021-08-27
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-08-27
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-08-27
09 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-09.txt
2021-08-27
09 (System) New version approved
2021-08-27
09 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2021-08-27
09 Giuseppe Fioccola Uploaded new revision
2021-08-13
08 Luc André Burdet Assignment of request for Telechat review by RTGDIR to Tony Przygienda was withdrawn
2021-08-13
08 Luc André Burdet Request for Telechat review by RTGDIR is assigned to Tony Przygienda
2021-08-13
08 Luc André Burdet Request for Telechat review by RTGDIR is assigned to Tony Przygienda
2021-08-12
08 (System) Changed action holders to Erik Kline, Mauro Cociglio, Tianran Zhou, Giuseppe Fioccola, Fengwei Qin, Ran Pang (IESG state changed)
2021-08-12
08 Amy Vezza IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-08-12
08 Stewart Bryant Request for Telechat review by GENART Completed: Not Ready. Reviewer: Stewart Bryant. Sent review to list.
2021-08-12
08 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss
2021-08-12
08 Éric Vyncke
[Ballot discuss]
Thank you for the work put into this document.

As Brian Carpenter kindly reminded me that an Area Director may not put back …
[Ballot discuss]
Thank you for the work put into this document.

As Brian Carpenter kindly reminded me that an Area Director may not put back a previous argument when the WG consensus was to ignore it, I am updating this ballot by moving the generic DISCUSS as a COMMENT.

The other two DISCUSS points remains blocking ones but Giuseppe have already addressed them over email, I am clearing the DISCUSS position as soon as the revised I-D is posted.

Special thanks to Ole Trøan for his shepherd's write-up, which contains a good summary of the WG consensus and the SW (?) implementation status. Thanks as well to Bob Halley for his INT directorate review.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated).

I also agree with DISCUSS points by other ADs:
- Lars's one about the size and usefulness of FlowMonID (see my very similar point)
- Roman's one about the inconsistencies about limited domain (from my point of view, this should not be limited to a single domain)

All in all, I strongly suggest to change the intended status of this document to 'experimental' as this document builds on experimental RFCs.

I hope that this helps to improve the document,

Regards,

-éric


== DISCUSS ==


-- Section 2 --
  "In the end, [I-D.fioccola-v6ops-ipv6-alt-mark] demonstrated that a
  new Hop-by-Hop or a new Destination Option was the best approach."

The above draft has not been published and is even expired for 2 years now... so please remove the 'demonstrated' as there is no proof at all ;-)

-- Section 4 --
Please remove "the destination node removes it" as there is no reason to remove it. Extension headers are usually not presented / used by upper layers anyway.
2021-08-12
08 Éric Vyncke
[Ballot comment]
--- OLD DISCUSS ----
This discussion already happened in the 6MAN WG but I still have to be convinced that hop-by-hop is a …
[Ballot comment]
--- OLD DISCUSS ----
This discussion already happened in the 6MAN WG but I still have to be convinced that hop-by-hop is a good idea at all. The fate of packets with HbH is unknown at best and, IMHO, this is a wrong use of HbH because the forwarding/processing of packets is NOT influenced at all by the AltMark option. What is required is a simple 'marking/coloring', which could be at any place in a packet (including destination option). The only benefit of HbH is its location just after the IPv6 header.

After all, existing devices can measure and generate IPFIX records in hardware/fastpath by inspecting at the bare minimum the 5-tuple and many devices can also parse extension headers in the fast path (of course not processing HbH in this case). I.e., finding the marking in the Dest Option is probably much easier and doable in current hardware rather than using HbH as HbH forces a software processing.

--- END OF OLD DISCUSS ---

-- Section 2.1 --
While I agree with my fellow AD about the inconsistencies of the text around 'limited domain' (and being inconsistent deserves a blocking DISCUSS), I do not agree with this section as I do not see any harm to extend this marking outside of a single domain, marked packets with this specification can traverse the whole Internet without causing any harm and not opening for any attack on the transit nodes. (See also my point about Hop-by-hop)

E.g., packets from organisation A can traverse networks of organizations B, C, ..., Z to reach another site of organization A and still provide useful measurements for A without causing harm to B, C, ..., Z. Of course the survivability of those marked packets is not guaranteed.

-- Section 3.1 --
Is there any reason why the FlowMonID is 20 bit long ? Exactly as the 20-bit Flow Label of the IPv6 header... See my comments for section 5.3

s/Unrecognized Types MUST be ignored on receipt./Unrecognized Types MUST be ignored on processing./ as the option should be processed not only by the destination node.

-- Section 5 --
This section (in a standard track I-D) repeats many things from experimental RFCs... This is really confusing and, while I am usually not dogmatic, I support my fellow AD on this point.

Moreover, repeating contents from other docs can only introduce inconsistencies among docs => suggest to remove section 5.1 and 5.2.

-- Section 5.3 --
The general reasons of using a 20-bit FlowMonID appear quite weak to me with the risk of collision being very high, e.g., in a DC with thousands of VM and millions of containers there will be collisions rendering this field useless. Strongly suggest to make its use optional
2021-08-12
08 Éric Vyncke Ballot comment and discuss text updated for Éric Vyncke
2021-08-12
08 Martin Vigoureux [Ballot comment]
very late review and as such not much to add to the existing ones, with which I largely agree
2021-08-12
08 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2021-08-11
08 Murray Kucherawy
[Ballot discuss]
A procedural question about the IPR disclosures, which I expect we can clear up during the telechat in a few hours:

Though there …
[Ballot discuss]
A procedural question about the IPR disclosures, which I expect we can clear up during the telechat in a few hours:

Though there have been two IPR disclosures on this document, the shepherd writeup conspicuously claims there has been no discussion about either.  For at least one of them the licensing terms indicate a fee may apply.  As this is seeking Proposed Standard status, I'd like to inquire about this.  In particular, Section 4 of BCP 79 says:

      A working group may take into
      consideration the results of this procedure in evaluating the
      technology, and the IESG may defer approval when a delay may
      facilitate obtaining such assurances.

I note the "may", but still it feels like an important step was missed here.  So: Was there an implicit conclusion that the IPR claims don't hinder the technology?  Or did nobody check it out?  Or did the WG decide consciously not to worry about it?  Or is it actually fine to just ignore them?
2021-08-11
08 Murray Kucherawy
[Ballot comment]
I support the DISCUSS positions of Lars, Warren, Martin, and Roman.  I'm particularly interested in Martin's DISCUSS point about the two Experimental references …
[Ballot comment]
I support the DISCUSS positions of Lars, Warren, Martin, and Roman.  I'm particularly interested in Martin's DISCUSS point about the two Experimental references and their statuses.

That's a lot right there, so in addition from me, just some minor things:

The answer to question 1 of the shepherd document is not complete.

Section 1:

* "... an on-path telemetry technique and consists in synchronizing ..." -- s/in/of/

* "... and therefore divide the packet ..." -- s/divide/dividing/ (must match "synchronizing" and "switching" earlier in the sentence)

OLD:
  The threat model for the application of the Alternate Marking Method
  in an IPv6 domain is reported in Section 6.  As for all the on-path
  telemetry technique, the only definitive solution is that this
  methodology MUST be applied in a controlled domain and therefore the
  application to untrusted domain is NOT RECOMMENDED.
NEW:
  The threat model for the application of the Alternate Marking Method
  in an IPv6 domain is reported in Section 6.  As with all on-path
  telemetry techniques, the only definitive solution is that this
  methodology MUST be applied in a controlled domain and therefore
  application to untrusted domains is NOT RECOMMENDED.

Sections 2, 4, and 6 variably use "behavior" and "behaviour".  I think you need to pick one and use it consistently.  Same for "analyze" and "analyse" (though in different sections).
2021-08-11
08 Murray Kucherawy [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy
2021-08-11
08 Benjamin Kaduk
[Ballot comment]
My colleagues already made some good reviews, so I don't have any more
comments to add at the Discuss level (though I will …
[Ballot comment]
My colleagues already made some good reviews, so I don't have any more
comments to add at the Discuss level (though I will follow the
resolution of the other reviews).  I do have a number of COMMENT-level
comments (plus some NITS-level remarks at the end that probably don't
need individual responses).

Section 1

  application in an IPv6 domain.  While the case of Segment Routing
  Header (SRH), defined in [RFC8754], is also discussed, it is valid
  for all the types of Routing Header (RH).

Given that it's not required to use a routing header with this option,
and the discussion in section 4 explicitly covers the ordering between
destination option and (an arbitrary) routing header, I think it might
be okay to drop this sentence.

Section 2

  The Alternate Marking Method requires a marking field.  As mentioned,
  several alternatives have been analysed in
  [I-D.fioccola-v6ops-ipv6-alt-mark] such as IPv6 Extension Headers,
  IPv6 Address and Flow Label.

If one follows the "replaced by" chain, it seems that
draft-fioccola-v6ops-ipv6-alt-mark is listed as a direct predecessor of
this document.  So it seems a little odd to refer back to a previous
version of this draft (without even acknowledging that it is a previous
version of this work) for additional details on a topic that is also
treated here in a summary form.  Why not just eliminate the reference
and include the needed information here (perhaps in an appendix if
needed)?  For what it's worth, I think that the summary in this section
can stand on its own without need for further supporting references.

  Furthermore the Flow Label may be changed en route and this may also
  violate the measurement task.  [...]

My (hasty) reading of RFC 6437 is that such changes are strongly
discouraged and only allowed in exceptional circumstances.  Perhaps the
description here should account for that?

  monitored flow.  Flow Label and FlowMonID within the same packet are
  totally disjoint, have different scope, identify different flows, and
  are intended for different use cases.

Can you explain a bit more (not necessarily in the document) what
"identify different flows" means?  It seems like if two identifiers are
carried in the same packet they must in some sense identify the same
thing, so I'm not sure what the different "flows" would be in this
scenario.

  The rationale for the FlowMonID is further discussed in Section 5.3.
  This 20 bit field allows easy and flexible identification of the
  monitored flow and enables a finer granularity and improved
  measurement correlation. [...]

I'm a bit confused at how "finer granularity" comes in -- if the
FlowMonID is 20 bits, isn't that the same granularity as the 20-bit Flow
Label?

Section 2.1

  [RFC8799] introduces the concept of specific limited domain solutions
  and, in this regard, it is reported the IPv6 Application of the
  Alternate Marking Method as an example.

I think Roman already touched on this point as well, but RFC 8799 only
introduces the concept; it's not the final word on the concept, and
8799 seems to expect that documents using the concept of a controlled
domain will add on much more specifics about what is actually meant.

  Some scenarios may imply that the Alternate Marking Method is applied
  outside a controlled domain, either intentionally or unintentionally,
  but in these cases, IPsec authentication and encryption MUST be used.

I appreciate the sentiment, but a hard MUST requirement for IPsec
specifically may be needlessly limiting.  Why would some other VPN
technology that provides full packet confidentiality+integrity
protection while traversing the external domain be insufficient?

Section 4

  Options Header to a slow processing path.  In case of the AltMark
  data fields described in this document, the motivation to standardize
  a new Hop-by-Hop Option is that it is needed for OAM (Operations,
  Administration, and Maintenance).  [...]

It seems to also be worth mentioning here that the limitation of use to
a controlled domain helps mitigate the risk of arbitrary nodes dropping
packets with HbH options.

Section 5

  This section describes how the method operates.  [RFC8321] introduces
  several alternatives but in this section the most applicable methods
  are reported and a new field is introduced to facilitate the
  deployment and improve the scalability.

If only the "most applicable methods" are reported, and both RFC 8321
and this document say to prefer a batching strategy based on a fixed
time interval, doesn't that make the batching strategy based on fixed
packet count "not most applicable" and thus undeserving of mention at
all in this document?

Section 5.2

  The same principle used to measure packet loss can be applied also to
  one-way delay measurement.  Delay metrics MAY be calculated using the
  two possibilities:

Again, how are there two possibilities that are both "most applicable
methods"?

  In summary the approach with double marking is better than the
  approach with single marking.  Moreover the two approaches can also
  be combined to have even more information and statistics on delay.

It might be worth saying a little more about how the approaches can be
"combined"; my current understanding seems more like they are both
executed in parallel on the same input data, but they produce
independent result values and any combination of those results is left
to the system (or human) processing the results.

Section 5.3

  o  First, it helps to reduce the per node configuration.  Otherwise,
      each node needs to configure an access-control list (ACL) for each
      of the monitored flows.  Moreover, using a flow identifier allows
      a flexible granularity for the flow definition.

This seems to only be relevant in the case where there is definitely a
central controller involved, if I'm understanding correctly -- if the
source is assigning the FlowMonIDs the consumers will still need to look
for those flows by ACL.  So maybe this could be rephrased slightly to
account for that.

Section 5.3.1

  of collision for 1206 flows.  So, for more entropy, FlowMonID can
  either be combined with other identifying flow information in a
  packet (e.g. it is possible to consider the hashed 3-tuple Flow
  Label, Source and Destination addresses) or the FlowMonID size could
  be increased.

This document is about to become a final, standards-track, RFC.  I
strongly suggest removing discussion of things that are not possible
once the protocol becomes immortalized in an RFC (that is, increasing
the FlowMonID size).

Section 6

Thank you for putting so much effort into the security considerations
section already!  I have a few thoughts on potential additional topics
to consider.

Not necessarily something that needs to be discussed in the security
considerations section itself, but the security considerations in
practice will depend on whether the marking is always enabled for all
flows, always enabled for a subset of flows, only enabled for specific
flows on-demand, etc..  Some kind of scope-setting for the expected
usage could be helpful to see, since the expected usage shapes what
analysis has been done of the security properties.

Separately, it is perhaps too banal to mention, but attacks on the
reporting/consolidation of the statistics between the monitoring devices
and the analysis platform can interfere with the proper functioning of
the system.  The channels used to report back flow statistics should be
secured.

There are also some considerations to note when the FlowMonIDs are
centrally allocated by a controller -- the controller knows a lot about
what traffic is flowing!  That might make it the target of an attack,
depending on the attacker goals.

Another factor that comes into play when the controller (or anyone,
really) is non-randomly assigning IDs, is that the actual structure of
the ID allocation itself can cause issues -- for example, predictable
sequential assignment can give an attacker insight into the rate of flow
creation, what fraction of flows they have visibility into from their
current vantage point, and makes attacks that are contingent on guessing
the "next" identifier very feasible.  The considerations in
draft-gont-numeric-ids-sec-considerations seem to apply.

  Harm caused by the measurement: Alternate Marking implies

I think Roman already touched on this to some extent, but the FlowMonID
in the measurement option adds some privacy considerations that can in
some cases mean that the measurement causes harm.

      single monitoring point.  The only way for an attacker can be to
      eavesdrop on multiple monitoring points at the same time, because
      they have to do the same kind of calculation and aggregation as
      Alternate Marking requires, and, after that, it can finally gain
      information about the network performance, but this is not
      immediate.

Just my own opinion, but I think this would be more useful if it stopped
after "have to do the same kind of calculation and aggregation as
Alternate Marking requires."  That is, the attacker doesn't have an
advantage over the rightful admin, but can get the same data; we don't
need to say anything more, and the mention of "not immediate" is
arguably misleading.

  Furthermore, in a pervasive surveillance attack, the information that
  can be derived over time is more.  But the application of the
  Alternate Marking to a controlled domain helps to mitigate all the
  above aspects of privacy concerns.

I suggest adding another clause or sentence about why/how the controlled
domain mitigates the privacy concerns (perhaps just as a forward
reference to the text currently two paragraphs later than this one,
which might be easier to achieve if the security considerations were
split into subsections).

  this document.  As an example, the AltMark Option can be used as Hop-
  by-Hop or Destination Option and, in case of Destination Option,
  multiple domains may be traversed by the AltMark Option that is not
  confined to a single domain.  In this case, the user, aware of the

(This statement might be added to the list that Roman enumerated of
places where we do/don't talk about being confined to a limited domain.)

  confined to a single domain.  In this case, the user, aware of the
  kind of risks, may still want to use Alternate Marking for telemetry
  and test purposes but the inter-domain links need to be secured
  (e.g., by IPsec) in order to avoid external threats.  For these

(Interesting that here IPsec is only an "e.g." and not a MUST...even
though the "MUST" is repeated in the following sentence!  C.f. my remark
on Section 2.1.)

  measurement.  A detailed discussion about the threats against time
  protocols and how to mitigate them is presented in [RFC7384].  Also,

NTS was recently published as RFC 8915; it might be worth mentioning
here.

Section 9.2

It's not really clear to me that RFCs 8321 and 8889 can be classified as
informative.

NITS

Section 1

  The Alternate Marking is an on-path telemetry technique and consists
  in synchronizing the measurements in different points of a network by
  switching the value of a marking bit and therefore divide the packet
  flow into batches.  Each batch represents a measurable entity

s/divide/dividing/, to match up with the conjugation of "synchronizing"
and "switching".

  unambiguously recognizable by all network nodes along the path.  By

I think that "unambiguously" can fail in the face of extreme reording
(relative to the marking window).

  in an IPv6 domain is reported in Section 6.  As for all the on-path
  telemetry technique, the only definitive solution is that this

s/all the on-path telemetry technique/all on-path telemetry techniques/

Section 2

  Hop-by-Hop Option Header is also useful to signal to routers on the
  path to process the Alternate Marking.  However, as said, routers
  will examine this option if properly configured.

I think that "only" should be added, either for "will only examine" or
"only if properly configured" (but not both).

  Furthermore the Flow Label may be changed en route and this may also
  violate the measurement task.  [...]

"violate the measurement task" is an unusual phrasing, and I'm not
actually sure what meaning it's intended to convey.  Perhaps it's
something about invalidating the integrity of the measurement result?

Section 4

  In general, it is needed to perform both end to end and hop by hop
  measurements, and the Alternate Marking methodology allows, by
  definition, both performance measurements.  But, in many cases the
  end-to-end measurement is not enough and it is required also the hop-
  by-hop measurement, so the most complete choice is the Hop-by-Hop
  Options Header.

The paragraph structure here doesn't make much sense: we say that in
general, both (end-to-end and hop-by-hop) measurements are possible, but
then follow up with a note that "in many cases end-to-end is not
enough".  There's no previous situation described where only end-to-end
is possible that merits this comparison.  It seems that some specific
mention of Destination Options would be needed in order to be able to
make such a comparison.

Section 5.1

  single batch between any two nodes.  Each batch represents a
  measurable entity unambiguously recognizable by all network nodes
  along the path.

(Same remark about "unambiguous" as above)

  It is worth mentioning that the length of the batches is considered
  stable over time in the previous figure.  In theory, it is possible

I'd consider "duration" rather than "length", here (indeed, the figure
shows batches of both 10 and 11 packets, and possibly 9 as well if
"batch 1" is not considered to be truncated

Section 6

      The FlowMonID field is used in the AltMark Option as identifier of
      the monitored flow.  It represents a more sensitive information

"identifier" needs an article; I'm not sure whether "a" or "the" would
better match the intended meaning.
2021-08-11
08 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-08-11
08 Warren Kumari
[Ballot discuss]
I must be missing something fairly fundamental here.
"As stated above, the precondition for the application of the
  Alternate Marking is that …
[Ballot discuss]
I must be missing something fairly fundamental here.
"As stated above, the precondition for the application of the
  Alternate Marking is that it MUST be applied in specific controlled
  domains, thus confining the potential attack vectors within the
  network domain.  [RFC8799] analyzes and discusses the trend towards
  network behaviors that can be applied only within a limited domain.
  This is due to the specific set of requirements especially related to
  security, network management, policies and options supported which
  may vary between such limited domains.  A limited administrative
  domain provides the network administrator with the means to select,
  monitor and control the access to the network, making it a trusted
  domain.  In this regard it is expected to enforce policies at the
  domain boundaries to filter both external packets with AltMark Option
  entering the domain and internal packets with AltMark Option leaving
  the domain.  Therefore the trusted domain is unlikely subject to
  hijacking of packets since packets with AltMark Option are processed
  and used only within the controlled domain."

The above says that this must only be done in a limited/controlled domain, and that operators are: "expected to enforce policies at the domain boundaries to filter both external packets with AltMark Option entering the domain and internal packets with AltMark Option leaving the domain.". The "only do this in in limited domain" seems to simply punt on the security concerns / considerations.

What is an operator supposed to do if their device doesn't understand this option? Are you really suggesting that everyone needs to do though and update edge firewall filters everywhere to block this? What happens when a filter is unintentionally missed? Or when the device cannot filter N headers deep?

[edit firewall family inet6 filter altmark term demo]
wkumari@rtr2.pao# set from extension-header ?
Possible completions:
  <range>              Range of values
  [                    Open a set of values
  ah                  Authentication header
  any                  Any extension header
  dstopts              Destination options
  esp                  Encapsulating security payload
  fragment            Fragment
  hop-by-hop          Hop by hop options
  mobility            Mobility
  routing              Routing

Yes, many networks use automation to apply filters, but it is still unreasonable to force operators to have to keep updating and deploying new filters when new protocols are created.
2021-08-11
08 Warren Kumari [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari
2021-08-11
08 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-08-11
08 Éric Vyncke
[Ballot discuss]
Thank you for the work put into this document.

Special thanks to Ole Trøan for his shepherd's write-up, which contains a good summary …
[Ballot discuss]
Thank you for the work put into this document.

Special thanks to Ole Trøan for his shepherd's write-up, which contains a good summary of the WG consensus and the SW (?) implementation status. Thanks as well to Bob Halley for his INT directorate review.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated).

I also agree with DISCUSS points by other ADs:
- Lars's one about the size and usefulness of FlowMonID (see my very similar point)
- Roman's one about the inconsistencies about limited domain (from my point of view, this should not be limited to a single domain)

All in all, I strongly suggest to change the intended status of this document to 'experimental' as this document builds on experimental RFCs.

I hope that this helps to improve the document,

Regards,

-éric


== DISCUSS ==

This discussion already happened in the 6MAN WG but I still have to be convinced that hop-by-hop is a good idea at all. The fate of packets with HbH is unknown at best and, IMHO, this is a wrong use of HbH because the forwarding/processing of packets is NOT influenced at all by the AltMark option. What is required is a simple 'marking/coloring', which could be at any place in a packet (including destination option). The only benefit of HbH is its location just after the IPv6 header.

After all, existing devices can measure and generate IPFIX records in hardware/fastpath by inspecting at the bare minimum the 5-tuple and many devices can also parse extension headers in the fast path (of course not processing HbH in this case). I.e., finding the marking in the Dest Option is probably much easier and doable in current hardware rather than using HbH as HbH forces a software processing.

-- Section 2 --
  "In the end, [I-D.fioccola-v6ops-ipv6-alt-mark] demonstrated that a
  new Hop-by-Hop or a new Destination Option was the best approach."

The above draft has not been published and is even expired for 2 years now... so please remove the 'demonstrated' as there is no proof at all ;-)

-- Section 4 --
Please remove "the destination node removes it" as there is no reason to remove it. Extension headers are usually not presented / used by upper layers anyway.
2021-08-11
08 Éric Vyncke
[Ballot comment]

-- Section 2.1 --
While I agree with my fellow AD about the inconsistencies of the text around 'limited domain' (and being inconsistent …
[Ballot comment]

-- Section 2.1 --
While I agree with my fellow AD about the inconsistencies of the text around 'limited domain' (and being inconsistent deserves a blocking DISCUSS), I do not agree with this section as I do not see any harm to extend this marking outside of a single domain, marked packets with this specification can traverse the whole Internet without causing any harm and not opening for any attack on the transit nodes. (See also my point about Hop-by-hop)

E.g., packets from organisation A can traverse networks of organizations B, C, ..., Z to reach another site of organization A and still provide useful measurements for A without causing harm to B, C, ..., Z. Of course the survivability of those marked packets is not guaranteed.

-- Section 3.1 --
Is there any reason why the FlowMonID is 20 bit long ? Exactly as the 20-bit Flow Label of the IPv6 header... See my comments for section 5.3

s/Unrecognized Types MUST be ignored on receipt./Unrecognized Types MUST be ignored on processing./ as the option should be processed not only by the destination node.

-- Section 5 --
This section (in a standard track I-D) repeats many things from experimental RFCs... This is really confusing and, while I am usually not dogmatic, I support my fellow AD on this point.

Moreover, repeating contents from other docs can only introduce inconsistencies among docs => suggest to remove section 5.1 and 5.2.

-- Section 5.3 --
The general reasons of using a 20-bit FlowMonID appear quite weak to me with the risk of collision being very high, e.g., in a DC with thousands of VM and millions of containers there will be collisions rendering this field useless. Strongly suggest to make its use optional
2021-08-11
08 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2021-08-10
08 Martin Duke
[Ballot discuss]
I have some concerns about this approach, plus some points of confusion that hopefully will clear up quickly.

I support Lars's first two …
[Ballot discuss]
I have some concerns about this approach, plus some points of confusion that hopefully will clear up quickly.

I support Lars's first two DISCUSS points.

(edited)

(1) The precise use case is unclear to me. An end-user (not in the controlled domain)  generates an IPv6 packet, and I gather some sort of middlebox then inserts the header if it meets some criteria (perhaps that the destination IP is also within the domain). If this is correct, I would like to check with the experts if a non-endpoint inserting a header is compliant with RFC8200. Also, this should be written down somewhere. If not correct, I have many more questions.

(2) The draft informatively references the (Experimental) RFCs 8321 and 8889 and covers some of the same ground, but as a Proposed Standard. Is part of the purpose here to update or obsolete these RFCs?

(3) Are there any restrictions on FlowMon IDs? Need these be pseudorandom, or can they encode information in the clear?

(4) Sec 5.1: When using timer-based batches, I gather you use times well in excess of potential reordering. If using a counter-based method, how does the measurement account for potential reordering? There could easily be a very large instantaneous burst followed by a path change that lowered the latency.
2021-08-10
08 Martin Duke Ballot discuss text updated for Martin Duke
2021-08-10
08 Alvaro Retana
[Ballot comment]
(1) I support the DISCUSS positions from Lars, Roman, and Martin. 

(1a) Of special concern to me is Martin's point about the relationship …
[Ballot comment]
(1) I support the DISCUSS positions from Lars, Roman, and Martin. 

(1a) Of special concern to me is Martin's point about the relationship between this document and rfc8321/8889, and the potential ability to reference this work without proper review by the ippm WG.  Note that neither RFC is explicit about the criteria to complete the respective experiments; the Shepherd writeup for rfc8321 [a] states that "the measurement utility of this extension still is to be demonstrated at a variety of scales in a plurality of network conditions." Furthermore, I am not aware of discussions about the maturity of rfc8321 in the ippm WG. 

[a] https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/shepherdwriteup/


(2) There are several references to I-D.fioccola-v6ops-ipv6-alt-mark, which was replaced by draft-fz-6man-ipv6-alt-mark and ultimately by this document.  IOW, it looks like this document refers to an old version of itself.  Since the references are mostly about analysis made in the early drafts, it may be better to include some of that in an appendix instead.
2021-08-10
08 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-08-10
08 Christopher Wood Request for Telechat review by SECDIR Completed: Ready. Reviewer: Christopher Wood. Sent review to list.
2021-08-09
08 Martin Duke
[Ballot discuss]
I have some concerns about this approach, plus some points of confusion that hopefully will clear up quickly.

I support Lars's first two …
[Ballot discuss]
I have some concerns about this approach, plus some points of confusion that hopefully will clear up quickly.

I support Lars's first two DISCUSS points.

(1) I am unclear about the relationship between limited domains and the prohibition against modifying either option before the destination. Is the intent that (a) this is only used for traffic that begins and ends in the domain; (b) user traffic is encapsulated with an outer IPv6 header that is removed prior to domain exit; or (c) the "destination" actually means the egress point from the domain?

(2) Relatedly, if the source nodes are  user-generated packets, how is this in practice a limited domain? Source nodes have enormous power to degrade the measurement by sending packets that fill the entire FlowMon space with only 1M packets, which not only consumes router resources but also pollutes every single measurement in the domain.

(3) The draft informatively references the (Experimental) RFCs 8321 and 8889 and covers some of the same ground, but as a Proposed Standard. Is part of the purpose here to update these RFCs? For other measurement techniques, we've had a generic measurement draft in IPPM and encapsulations in the appropriate protocol-specific groups like 6man. Why was that approach not taken here? Will future encapsulations of alternate marking refer to this one normatively on how to conduct the measurement?

(4) Are there any restrictions on FlowMon IDs? Need these be pseudorandom, or can they encode information in the clear?

(5) I don't understand the basic motivation for using HBH options if these can result in the packet being diverted to the slow path on intermediate nodes. This seems like a major drawback for a delay measurement!

(6) Sec 5.1: When using timer-based batches, I gather you use times well in excess of potential reordering. If using a counter-based method, how does the measurement account for potential reordering? There could easily be a very large instantaneous burst followed by a path change that lowered the latency.
2021-08-09
08 Martin Duke [Ballot comment]
Thanks to Yoshi for the TSVART review.
2021-08-09
08 Martin Duke [Ballot Position Update] New position, Discuss, has been recorded for Martin Duke
2021-08-09
08 Roman Danyliw
[Ballot discuss]
Please provide consistent guidance on where this methodology can be used.  Consider:

(a) Section 2.1. “Therefore, the IPv6 application of the Alternate Marking …
[Ballot discuss]
Please provide consistent guidance on where this methodology can be used.  Consider:

(a) Section 2.1. “Therefore, the IPv6 application of the Alternate Marking Method MUST NOT be deployed outside a controlled domain.”

(b) Section 2.1.  “Some scenarios may imply that the Alternate Marking Method is applied outside a controlled domain, either intentionally or unintentionally, but in these cases, IPsec authentication and encryption MUST be used.”

(c) Section 6. “This document aims to apply a method to perform measurements that does not directly affect Internet security nor applications that run on the Internet.”

(d) Section 6. “As stated above, the precondition for the application of the Alternate Marking is that it MUST be applied in specific controlled domains, thus confining the potential attack vectors within the network domain. 

(e) Section 6. “In this case, the user, aware of the kind of risks, may still want to use Alternate Marking for telemetry and test purposes but the inter-domain links need to be secured (e.g., by IPsec) in order to avoid external threats.  For these specific scenarios the application of the Alternate Marking Method outside a controlled domain is possible but IPsec through AH    (Authentication Header) or ESP (Encapsulating Security Payload) MUST be used.”

(a) and (d) seem to very clear that this approach MUST only be used in a controlled domain.  However (b) and (d) seem to suggest that this prohibition is at best a “SHOULD”.  If (b) and (d) are true, than (c) not affecting applications on the internet might not be true.

** Section 6.  Thanks for mentioning “At the management plane, attacks can be set up by misconfiguring or by maliciously configuring AltMark Option.”  Please be clearer on what these attacks could look like.  Would these include:

-- using the FlowMonId as a tracking identifier?

-- (Likely possible at both the data and management plane would be a) covert channel between the sender and an on-path observer?
2021-08-09
08 Roman Danyliw
[Ballot comment]
Thank you to Chris Wood for the SECDIR review and to the authors for responding to it.

** Is those a tighter applicability …
[Ballot comment]
Thank you to Chris Wood for the SECDIR review and to the authors for responding to it.

** Is those a tighter applicability statement than can be applied where this approach will be used.  A few things are said:

(a) Section 1. “As for all the on-path telemetry technique, the only definitive solution is that this methodology MUST be applied in a controlled domain ...”

(b) Section 1. “... therefore the application to untrusted domain is NOT RECOMMENDED”

(c) Section 6. “As stated above, the precondition for the application of the    Alternate Marking is that it MUST be applied in specific controlled  domains, thus confining the potential attack vectors within the network domain.  [RFC8799] analyzes and discusses the trend towards network behaviors that can be applied only within a limited domain.”

-- While citing RFC8799 is helpful as the basis of phrase “controlled domain”, that reference also explains that “The requirements of limited domains will depend on the deployment scenario.  Policies, default parameters, and the options supported may vary.  Also, the style of network management may vary between a completely unmanaged network, one with fully autonomic management, one with traditional central management, and mixtures of the above.  Finally, the requirements and solutions for security and privacy may vary.”  Put in another way, unless further specified, RFC8799 doesn’t actually say anything about the properties of the network except that it isn’t the Internet.  Will it be a managed network? A single administrative domain? Etc.

-- Per (b), stating “untrusted domain” (thanks for responding to the SECDIR reviewer with this) is orthogonal to “controlled domain”.  Being  “controlled” doesn’t suggest “trusted” or “untrusted”.  Can “untrusted” be elaborated on?

** Section 2.1.  Per “Some scenarios may imply that the Altenative Marking Method is applied outside a controlled domain ... unintentionally, ...”, it seems odd to provide normative guidance for unintentional behavior.

** Section 2.1.  Per “It is RECOMMENDED that an implementation can be able to reject packets that carry Alternate Marking data and are entering or leaving the controlled domains”, what is the “implementation” in this case?  I was under the impression that these are end-node applying this marking.  However, it seems like routers/firewalls would be the ones enforcing the policy of dropping these packets.

** Section 5.3.  Per “The FlowMon identifier field is to uniquely identify a monitored flow within the measurement domain”, what is a measurement domain? What is the relationship between it and the controlled domain in which it is supposed to be operating?  Perhaps there is a definition for “measurement domain” that can be cited?

** Section 6.
  As
  already discussed in Section 4, it is RECOMMENDED that the AltMark
  Option does not affect the throughput and therefore the user
  experience.

This text appears to be stating a desired functional requirement of the AltMark not having an impact on the network, but the practical guidance to an adopter isn’t clear to me.

** Various editorial comments

-- Section 1.  Editorial. Per “The Alternate Marking is an on-path telemetry technique and consists in synchronizing …", there is a grammar nit with “... and consists in synchronizing ...” but I don’t follow the intent enough to provide a suggestion.

-- Section 5.1. Editorial.  Per “The measurement of the packet loss is really straightforward”, straightforward in comparison to what?

-- Section 5.1.  Editorial.  s/and and/and/

-- Section 5.3.  Editorial.  s/if the/If the/

-- Section 6.  Editorial.  s/or insert deliberately/or deliberately insert/
2021-08-09
08 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2021-08-06
08 Lars Eggert
[Ballot discuss]
Section 2.1. , paragraph 4, discuss:
>    Therefore, the IPv6 application of the Alternate Marking Method MUST
>    NOT be deployed …
[Ballot discuss]
Section 2.1. , paragraph 4, discuss:
>    Therefore, the IPv6 application of the Alternate Marking Method MUST
>    NOT be deployed outside a controlled domain.

That's not what Section 6 says, which allows use outside a controlled
domain (across the Internet) if protection is applied?

Section 2.1. , paragraph 4, discuss:
>    Some scenarios may imply that the Alternate Marking Method is applied
>    outside a controlled domain, either intentionally or unintentionally,
>    but in these cases, IPsec authentication and encryption MUST be used.

How can one require use of IPsec for an unintentional use outside of a
controlled domain? If the header leaks by accident, surely it's unreasonable to
expect that IPsec had been set up to catch any and all such possible leakage?

Also (as a comment), if IPsec is required by this document, it needs to be
normatively cited.

Section 5.3.1. , paragraph 2, discuss:
>    It is important to note that if the 20 bit FlowMonID is set
>    independently and pseudo randomly there is a chance of collision.
>    Indeed, by using the well-known birthday problem in probability
>    theory, if the 20 bit FlowMonID is set independently and pseudo
>    randomly without any additional input entropy, there is a 50% chance
>    of collision for 1206 flows.  So, for more entropy, FlowMonID can
>    either be combined with other identifying flow information in a
>    packet (e.g. it is possible to consider the hashed 3-tuple Flow
>    Label, Source and Destination addresses) or the FlowMonID size could
>    be increased.

It seems odd to define a dedicated FlowMonID, but make it so short that it is
basically not usable in many realistic scenarios. If other parts of the packet
headers need to be inspected to disambiguate FlowMonID collisions, this (1)
should at least be more carefully specified in this document (since every node
will need to do it in the same way) but (2) probably argues for a much longer
FlowMonID - why not make it 64 bits or longer?

The IANA review of this document seems to not have concluded yet; I am holding
a DISCUSS for IANA until it has.
2021-08-06
08 Lars Eggert
[Ballot comment]
Section 5.1. , paragraph 4, comment:
>    issues.  Specifically, if the effects of network delay are ignored,
>    the condition to …
[Ballot comment]
Section 5.1. , paragraph 4, comment:
>    issues.  Specifically, if the effects of network delay are ignored,
>    the condition to implement the methodology is that the clocks in
>    different nodes MUST be synchronized to the same clock reference with
>    an accuracy of +/- B/2 time units, where B is the fixed time duration
>    of the block.

What is a block? Do you mean a batch? I see that RFC8321 uses "block", should
this document adopt that term?

Also, how can a block (of packets) have a "fixed time duration"? Is this
supposed to mean transmission time of the block at line-rate? What about pacing?

-------------------------------------------------------------------------------
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.

Section 2.1. , paragraph 4, nit:
-    an implementation can be able to reject packets that carry Alternate
-                      ---------------
+    an implementation rejects packets that carry Alternate
+                            +

Section 3.1. , paragraph 5, nit:
-    o  Option Type: 8 bit identifier of the type of Option that needs to
-                    ^
+    o  Option Type: 8-bit identifier of the type of Option that needs to
+                    ^

Section 3.1. , paragraph 7, nit:
-    o  FlowMonID: 20 bits unsigned integer.  The FlowMon identifier is
-                    ^  -
+    o  FlowMonID: 20-bit unsigned integer.  The FlowMon identifier is
+                    ^

Section 3.1. , paragraph 7, nit:
-      picked 20 bit since it is a reasonable value and a good compromise
+      picked as 20 bit since it is a reasonable value and a good compromise
+            +++

Section 4. , paragraph 6, nit:
-    are useable when SRv6 header is present.  Because SRv6 is implemented
-          -
+    are usable when SRv6 header is present.  Because SRv6 is implemented

Section 1. , paragraph 3, nit:
> sely measure the packet loss. In a similar way the alternation of the values
>                              ^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

Section 1.1. , paragraph 1, nit:
> I-D.fioccola-v6ops-ipv6-alt-mark] analyzed and discussed all the available po
>                                  ^^^^^^^^
Do not mix variants of the same word ("analyze" and "analyse") within a single
text.

Section 2. , paragraph 8, nit:
> and on the nodes that support it. However it is important to mention that th
>                                  ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 2. , paragraph 11, nit:
> intent and forwarding behaviour. Furthermore the Flow Label may be changed en
>                                  ^^^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Furthermore".

Section 2.1. , paragraph 2, nit:
> f IPsec for an unintentional use outside of a controlled domain? If the head
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 3.1. , paragraph 1, nit:
> rd-highest-order bit specifies whether or not the Option Data can change en r
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Section 3.1. , paragraph 4, nit:
> ssed below, it has been picked as 20 bit since it is a reasonable value and a
>                                      ^^^
Possible agreement error. The noun "bit" seems to be countable.

Section 4. , paragraph 6, nit:
> intermediate node can read it or not but this does not affect the packet beh
>                                    ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 4. , paragraph 8, nit:
> an-hbh-processing], this means "skip if do not recognize and data do not cha
>                                      ^^
It seems that a pronoun is missing.

Section 4. , paragraph 12, nit:
> most applicable methods are reported and a new field is introduced to facili
>                                    ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Section 5.1. , paragraph 4, nit:
> ge the length of batches over time and and among different flows for more fle
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 5.1. , paragraph 9, nit:
> rage timestamp for each batch. In addition the information is limited to a me
>                                  ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

Section 5.2. , paragraph 3, nit:
> the approach with single marking. Moreover the two approaches can also be com
>                                  ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Moreover".

Section 5.2. , paragraph 7, nit:
> table in most of the applications. Indeed with 20 bits the number of combinat
>                                    ^^^^^^
A comma may be missing after the conjunctive/linking adverb "Indeed".

Section 5.3.1. , paragraph 3, nit:
> r of IPv6 packets by the source node but this must be performed in a way tha
>                                    ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 6. , paragraph 2, nit:
> privacy concerns also need to be analyzed even if the method only relies on
>                                  ^^^^^^^^
Do not mix variants of the same word ("analyze" and "analyse") within a single
text.

Section 6. , paragraph 4, nit:
>  paths. AltMark Option contains two kind of metadata: the marking bits (L and
>                                    ^^^^
Possible agreement error. The noun "kind" seems to be countable.

Section 6. , paragraph 5, nit:
> n data-plane traffic is difficult. Indeed an attacker cannot gain information
>                                    ^^^^^^
A comma may be missing after the conjunctive/linking adverb "Indeed".

Section 6. , paragraph 6, nit:
> hin the network domain. [RFC8799] analyzes and discusses the trend towards ne
>                                  ^^^^^^^^
Do not mix variants of the same word ("analyze" and "analyse") within a single
text.

Section 6. , paragraph 7, nit:
> tMark Option leaving the domain. Therefore the trusted domain is unlikely su
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Therefore".

Section 6. , paragraph 7, nit:
> ome packets might exceed the MTU. However the relative small size (48 bit in
>                                  ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 6. , paragraph 9, nit:
>  described in this document relies on an time synchronization protocol. Thus,
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Document references draft-peng-v6ops-hbh-04, but -05 is the latest available
revision.

Document references draft-fioccola-v6ops-ipv6-alt-mark-01, but -08 is the
latest available revision.
2021-08-06
08 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert
2021-08-05
08 Bob Halley Request for Telechat review by INTDIR Completed: Ready. Reviewer: Bob Halley. Sent review to list.
2021-07-29
08 Carlos Bernardos Request for Telechat review by INTDIR is assigned to Bob Halley
2021-07-29
08 Carlos Bernardos Request for Telechat review by INTDIR is assigned to Bob Halley
2021-07-29
08 Éric Vyncke Requested Telechat review by INTDIR
2021-07-29
08 Tero Kivinen Request for Telechat review by SECDIR is assigned to Christopher Wood
2021-07-29
08 Tero Kivinen Request for Telechat review by SECDIR is assigned to Christopher Wood
2021-07-28
08 Alvaro Retana Requested Telechat review by RTGDIR
2021-07-26
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-07-26
08 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-08.txt
2021-07-26
08 (System) New version approved
2021-07-26
08 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2021-07-26
08 Giuseppe Fioccola Uploaded new revision
2021-07-23
07 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-07-23
07 Jean Mahoney Request for Telechat review by GENART is assigned to Stewart Bryant
2021-07-23
07 Jean Mahoney Request for Telechat review by GENART is assigned to Stewart Bryant
2021-07-22
07 Cindy Morgan Placed on agenda for telechat - 2021-08-12
2021-07-22
07 Erik Kline Ballot has been issued
2021-07-22
07 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2021-07-22
07 Erik Kline Created "Approve" ballot
2021-07-22
07 Erik Kline IESG state changed to IESG Evaluation from Waiting for Writeup
2021-07-22
07 Erik Kline Ballot writeup was changed
2021-06-22
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-06-22
07 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-07.txt
2021-06-22
07 (System) New version approved
2021-06-22
07 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2021-06-22
07 Giuseppe Fioccola Uploaded new revision
2021-06-16
06 Yoshifumi Nishida Request for Last Call review by TSVART Completed: On the Right Track. Reviewer: Yoshifumi Nishida. Sent review to list.
2021-06-15
06 Christopher Wood Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Christopher Wood. Sent review to list.
2021-06-15
06 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-06-09
06 Magnus Westerlund Assignment of request for Last Call review by TSVART to Tommy Pauly was withdrawn
2021-06-09
06 Magnus Westerlund Request for Last Call review by TSVART is assigned to Yoshifumi Nishida
2021-06-09
06 Magnus Westerlund Request for Last Call review by TSVART is assigned to Yoshifumi Nishida
2021-06-07
06 Stewart Bryant Request for Last Call review by GENART Completed: Not Ready. Reviewer: Stewart Bryant. Sent review to list.
2021-06-07
06 Magnus Westerlund Request for Last Call review by TSVART is assigned to Tommy Pauly
2021-06-07
06 Magnus Westerlund Request for Last Call review by TSVART is assigned to Tommy Pauly
2021-06-04
06 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2021-06-04
06 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-6man-ipv6-alt-mark-06. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-6man-ipv6-alt-mark-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Destination Options and Hop-by-Hop Options registry on the Internet Protocol Version 6 (IPv6) Parameters registry page located at:

https://www.iana.org/assignments/ipv6-parameters/

a new registration will be made as follows:

Hex Value Binary Value Description Reference
act chg rest
-----------------------+---------------+--------------------+-------------
[ TBD-at-Registration ] 00 0 [TBD} AltMark [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2021-06-03
06 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2021-06-03
06 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2021-06-03
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Christopher Wood
2021-06-03
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Christopher Wood
2021-06-03
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2021-06-03
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2021-06-01
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-06-01
06 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-06-15):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: 6man-chairs@ietf.org, bob.hinden@gmail.com, …
The following Last Call announcement was sent out (ends 2021-06-15):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: 6man-chairs@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-ipv6-alt-mark@ietf.org, ek.ietf@gmail.com, ipv6@ietf.org, otroan@employees.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-6man-ipv6-alt-mark-06.txt> (IPv6 Application of the Alternate Marking Method) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'IPv6 Application of the Alternate Marking
Method'
  <draft-ietf-6man-ipv6-alt-mark-06.txt> 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 2021-06-15. 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 how the Alternate Marking Method can be used
  as a passive performance measurement tool in an IPv6 domain.  It
  defines a new Extension Header Option to encode alternate marking
  information in both the Hop-by-Hop Options Header and Destination
  Options Header.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/


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

  https://datatracker.ietf.org/ipr/3650/
  https://datatracker.ietf.org/ipr/3325/





2021-06-01
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-06-01
06 Erik Kline Last call was requested
2021-06-01
06 Erik Kline Ballot approval text was generated
2021-06-01
06 Erik Kline Ballot writeup was generated
2021-06-01
06 (System) Changed action holders to Erik Kline (IESG state changed)
2021-06-01
06 Erik Kline IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-06-01
06 Erik Kline Last call announcement was generated
2021-06-01
06 Ole Trøan
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated 1 November 2019.
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain.  It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header.

Working Group Summary:

This has had discussion on the ipv6 list and detailed comments were received from several people.  General support for advancing this document.

Document Quality:
There is at least one commercial implementation of alternate marking for MPLS and SRv6.
An implementation of this draft (alternative marking for HBH and DestOpt options) as a proof of concept is in progress.
This implementation is using an experimental code point.

Personnel:

Shepherd: Ole Troan
AD: Erik Kline

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (including shepherd) reviewed the document in detail and provided comments that were incorporated in the draft

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.
Extension header option format reviewed by 6man.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes, there are two IPRs filed.
No working group discussion has been had.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is good support among the interested individuals.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits found.

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

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

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

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section has been reviewed. The correct IANA registries are identified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2021-05-31
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-05-31
06 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-06.txt
2021-05-31
06 (System) New version approved
2021-05-31
06 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2021-05-31
06 Giuseppe Fioccola Uploaded new revision
2021-05-29
05 Erik Kline
[S1] [nit]

* s/often referred as/often referred to as/

[S2] [question]

* "..., anyway it is to be expected that some routers cannot process it …
[S1] [nit]

* s/often referred as/often referred to as/

[S2] [question]

* "..., anyway it is to be expected that some routers cannot process it
  unless explicitly configured"

  doesn't strike me as grammatically correct and perhaps a run-on sentence.

  Is the intention to say that routers are expected to ignore the option
  unless configured (i.e. for performance reasons)?  If so, consider
  splitting this paragraph into two sentences, with the 2nd being something
  like:

  ".  It is expected that routers will ignore this option unless explicitly
  configured to process it." (something similar to the text in section 4)

[S2] [question]

* ", and associate different uses." seems a bit unclear to me.  Does mean
  something like "are intended for different use cases."?

[S2] [nit]

* s/the the uniqueness/the uniqueness/

[S2] [discuss]

* "and this could also happen to the IP addresses that can change due to NAT"
  (and in the subsequent sentence)

  How did IPv6 NAT find its way into this discussion?  Unless it is somehow
  critical to open up this discussion, I'd recommend just removing mention
  of it.

[S4] [nit]

* "by every node that is an identity in the SR path"

  I'm sure "identity" is the best word here.  Perhaps "that is identified
  by the SR path"?

[S4] [question]

* The intended meaning of the final paragraph of this section eludes me.
  What is an example of a "non-conventional application" of a Dest option
  that has a similar effect to an HbH option?

[S6] [question]

* Can you explain how "network reconnaissance through passive eavesdropping
  on data-plane traffic does not allow attackers to gain information about
  the network performance"?  It seems to me that an eavesdropping observer
  would have all the same information that src and dst do for inferring
  performance...yes?  (In the case of an HbH option, each on-path router is
  indistinguishable from an eavesdropping observer?)

[S7] [nit]

* "assignments" -> "assignment", I think, since it appears the doc is only
  requesting a single assignment from a single registry.
2021-05-29
05 (System) Changed action holders to Erik Kline, Mauro Cociglio, Tianran Zhou, Giuseppe Fioccola, Fengwei Qin, Ran Pang (IESG state changed)
2021-05-29
05 Erik Kline IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-05-29
05 (System) Changed action holders to Erik Kline (IESG state changed)
2021-05-29
05 Erik Kline IESG state changed to AD Evaluation from Publication Requested
2021-05-28
05 Ole Trøan
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated 1 November 2019.
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain.  It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header.

Working Group Summary:

This has had discussion on the ipv6 list and detailed comments were received from several people.  General support for advancing this document.

Document Quality:
There is at least one commercial implementation of alternate marking for MPLS and SRv6.
An implementation of this draft (alternative marking for HBH and DestOpt options) as a proof of concept is in progress.

Personnel:

Shepherd: Ole Troan
AD: Erik Kline

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (including shepherd) reviewed the document in detail and provided comments that were incorporated in the draft

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.
Extension header option format reviewed by 6man.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes, there are two IPRs filed.
No working group discussion has been had.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is good support among the interested individuals.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits found.

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

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

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

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section has been reviewed. The correct IANA registries are identified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2021-05-28
05 Ole Trøan Responsible AD changed to Erik Kline
2021-05-28
05 Ole Trøan IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-05-28
05 Ole Trøan IESG state changed to Publication Requested from I-D Exists
2021-05-28
05 Ole Trøan IESG process started in state Publication Requested
2021-05-28
05 Ole Trøan
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated 1 November 2019.
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain.  It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header.

Working Group Summary:

This has had discussion on the ipv6 list and detailed comments were received from several people.  General support for advancing this document.

Document Quality:
There is at least one commercial implementation of alternate marking for MPLS and SRv6.
An implementation of this draft (alternative marking for HBH and DestOpt options) as a proof of concept is in progress.

Personnel:

Shepherd: Ole Troan
AD: Erik Kline

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (including shepherd) reviewed the document in detail and provided comments that were incorporated in the draft

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.
Extension header option format reviewed by 6man.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes, there are two IPRs filed.
No working group discussion has been had.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is good support among the interested individuals.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits found.

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

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

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

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section has been reviewed. The correct IANA registries are identified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2021-05-26
05 Ole Trøan
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated 1 November 2019.
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain.  It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header.

Working Group Summary:

Nothing to note.

Document Quality:
There is at least one commercial implementation of alternate marking for MPLS and SRv6.
An implementation of this draft (alternative marking for HBH and DestOpt options) as a proof of concept is in progress.

Personnel:

Shepherd: Ole Troan
AD: Erik Kline

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (including shepherd) reviewed the document in detail.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.
Extension header option format reviewed by 6man.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes, there are two IPRs filed.
No working group discussion has been had.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is good support among the interested individuals.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits found.

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

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

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

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section has been reviewed. The correct IANA registries are identified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2021-05-26
05 Ole Trøan
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated 1 November 2019.
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain.  It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header.

Working Group Summary:

Nothing to note.

Document Quality:

**TBD

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There is at least one commercial implementation of alternate marking for MPLS and SRv6.
An implementation of this draft (alternative marking for HBH and DestOpt options) as a proof of concept is in progress.

Personnel:

Shepherd: Ole Troan
AD: Erik Kline

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (including shepherd) reviewed the document in detail.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.
Extension header option format reviewed by 6man.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes, there are two IPRs filed.
No working group discussion has been had.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is good support among the interested individuals.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits found.

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

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

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

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section has been reviewed. The correct IANA registries are identified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2021-05-25
05 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-05.txt
2021-05-25
05 (System) New version approved
2021-05-25
05 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2021-05-25
05 Giuseppe Fioccola Uploaded new revision
2021-05-21
04 Ole Trøan
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.
This version is dated 1 November 2019.
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed standard

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain.  It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header.

Working Group Summary:

Nothing to note.

Document Quality:

** Question asked to Giuseppe.
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Shepherd: Ole Troan
AD: Erik Kline

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (shepherd) reviewed the document in detail.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.
Extension header option format reviewed by 6man.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

*** Awaiting response.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes, there are two IPRs filed.
No working group discussion has been had.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is good support among the interested individuals.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

*** awaiting resolution from authors.

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

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

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

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

IANA section has been reviewed. The correct IANA registries are identified.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2021-05-21
04 Ole Trøan Notification list changed to bob.hinden@gmail.com, otroan@employees.org from bob.hinden@gmail.com because the document shepherd was set
2021-05-21
04 Ole Trøan Document shepherd changed to Ole Trøan
2021-03-08
04 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-04.txt
2021-03-08
04 (System) New version approved
2021-03-08
04 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2021-03-08
04 Giuseppe Fioccola Uploaded new revision
2021-03-07
03 Ole Trøan IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2021-03-07
03 Ole Trøan Added to session: IETF-110: 6man  Thu-1700
2021-01-28
03 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-03.txt
2021-01-28
03 (System) New version approved
2021-01-28
03 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Tianran Zhou <zhoutianran@huawei.com>
2021-01-28
03 Giuseppe Fioccola Uploaded new revision
2021-01-18
02 Ole Trøan Notification list changed to bob.hinden@gmail.com because the document shepherd was set
2021-01-18
02 Ole Trøan Document shepherd changed to Bob Hinden
2021-01-18
02 Ole Trøan Changed consensus to Yes from Unknown
2021-01-18
02 Ole Trøan Intended Status changed to Proposed Standard from None
2020-10-13
02 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-02.txt
2020-10-13
02 (System) New version approved
2020-10-13
02 (System)
Request for posting confirmation emailed to previous authors: Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Fengwei Qin …
Request for posting confirmation emailed to previous authors: Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Ran Pang <pangran@chinaunicom.cn>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Fengwei Qin <qinfengwei@chinamobile.com>, Tianran Zhou <zhoutianran@huawei.com>
2020-10-13
02 Giuseppe Fioccola Uploaded new revision
2020-06-22
01 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-01.txt
2020-06-22
01 (System) New version approved
2020-06-22
01 (System)
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Tianran Zhou <zhoutianran@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Giuseppe Fioccola …
Request for posting confirmation emailed to previous authors: Fengwei Qin <qinfengwei@chinamobile.com>, Tianran Zhou <zhoutianran@huawei.com>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, 6man-chairs@ietf.org
2020-06-22
01 Giuseppe Fioccola Uploaded new revision
2020-05-30
00 Ole Trøan This document now replaces draft-fz-6man-ipv6-alt-mark instead of None
2020-05-30
00 Giuseppe Fioccola New version available: draft-ietf-6man-ipv6-alt-mark-00.txt
2020-05-30
00 (System) WG -00 approved
2020-05-30
00 Giuseppe Fioccola Set submitter to "Giuseppe Fioccola <giuseppe.fioccola@huawei.com>", replaces to draft-fz-6man-ipv6-alt-mark and sent approval email to group chairs: 6man-chairs@ietf.org
2020-05-30
00 Giuseppe Fioccola Uploaded new revision