Alternate-Marking Method for Passive and Hybrid Performance Monitoring
draft-ietf-ippm-alt-mark-14

Firstly, I'd strongly suggest that the authors address Eric's OpsDir review (https://datatracker.ietf.org/doc/review-ietf-ippm-alt-mark-13-opsdir-telechat-vyncke-2017-11-21/).

I really like the concept / approach, but I think that there are many places where the document hand-waves away some of the details - like how do I configure this (and more importantly, how do I detect) so that I'm not making in too many places, and having one device stomp on another devices' markings? Section 3.1.1 says that it is desirable to have a single node coloring -- is this supposed to mean a single node *per network* (which makes this useless)? Or somehow per flow (then how do I know who's the right device to mark?) Perhaps devices should watch for already colored packets if they are intending to color, and alert on this case as an error?

More operational guidance would go a long way towards making this more operational useful - as this is Experimental I'm not making this a discuss.


I had some comments and questions: 
1: The document lists 8 authors above the fold. This may be must better as an Editor (or two) and the rest moved to contributors.

2: The document is Experimental, but I don't really see (perhaps I missed it) a description of the experiment to be performed -- Section 5.1 has a writeup of experience gained from running this at TI, but that seems more like a separate Informational document.

Nits:
Section 1.  Introduction
"The lack of adequate tools to measure packet loss with the desired accuracy drove an effort to design a new method for the performance monitoring of live traffic, possibly easy to implement and deploy." -- did you mean "possibly" here? This makes it sound like having it easy to implement and deploy isn't a goal/ desirable, more like a lucky coincidence if it happens... 

Section 1.  Introduction
"In case the marking field is obtained by changing existing field values of"  -- perhaps: "In cases where the marking..."? Actually, this whole sentence feels a bit clumsy. 

Section 2.  Overview of the method
"Since a flow is continuous and cannot be stopped when a counter has to be read, it could be difficult to determine exactly when to read the counter. " -- I think that this would be better if it were "it can be difficult" or "it would be difficult".

Section 3.1.  Packet loss measurement
"Traffic coloring could be done by R1 itself or by an upward router." -- what is an "upward" router? Was this supposed to be upstream? Even if so, I think that there needs to be more precision here.

The normative SHOULD in Sec 5.1.1 seems a bit troubling. If there is to be a normative recommendation about this, wouldn't it be a MUST? If not, under what circumstances would it be ok to flip header bits at one endpoint or at an intermediate node to color a packet when the other endpoint might interpret those bits as being used for a different purpose?

Two minor comments:

(1) For traceability purposes, it would be nice if the datatracker showed that draft-tempia-opsawg-p3m was replaced by draft-tempia-ippm-p3m…. The same for draft-chen-ippm-coloring-based-ipfpm-framework and draft-cociglio-mboned-multicast-pm, which according to the Shepherd's write-up were precursors of this document.

(2) What is the Experiment?  I very much like the explanation in the Shepherd’s write up; having something like that in the document would be nice.

What is the nature of the experiment? Section 5.1 seems to describe an experiment that predates publication, but I don't see anything to describe why the draft is experimental.

I see that there was agreement with the addition as suggested by the SecDir reviewer and I also agree with these suggested additions, but I don't see them in the version under review.  Are these planned additions already, if not, could you please add in that text?

https://mailarchive.ietf.org/arch/msg/secdir/dYwXHZ__a4o9qPA8LXEfHj0URg4

Thank you!

A couple of high level comments on the structure and intention of this document:

1) As the shepherd write-up states „this specification does not define protocol extensions but instead a method which can be used by different protocols“ therefore I think it should be informational.

2) I think section 5.1 should be moved to the appendix or even into a new document that could be send to the ISE. If the intention is that DSCP marking is explained as an example, there is no need to talk about Telecom Italia or any specific details of their implementation. The level of detail for the DCSP approach should stay similar as for sections 5.2-5.4 with no need to mention that this is in use by Telecom Italia. Respectively, section 8 does also not need to name Telecom Italia’s deployment but can simply refer to the use of DSCP as one example. 

3) There is quite some redundancy in the text that could be removed and would make the document shorter and even easier to read. Respectively, I don’t think section 7 as well as some of the motivation text in the intro is needed.

Nits:
1) maybe s/a live traffic flow/an active traffic flow/ … not sure what is meant with „live“ here.
2) In section 9, this is incorrect:

„Nevertheless, the method implies modifications on the fly to the IP header of data packets…“
as using DSCP is just one possible implementation. It should say probably instead:
„Nevertheless, the method implies modifications on the fly to a header or encapsulation of the data packets…“

Similarly, this sentence should be adapted:

„The privacy concerns of network measurement are limited because the method only relies on information contained in the IP header without any release of user data.“