I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ippm-pam-06 Reviewer: Peter Yee Review Date: 2023-10-09 IETF LC End Date: 2023-10-20 IESG Telechat date: Not scheduled for a telechat Summary: This specification offers a scheme for metrics that are used in determining if what you’re getting on a network is what you contracted for. I have some issues with the draft and the usual nits. [Ready with issues] Major issues: None Minor issues: General: For something that's Standards Track, I find the heavy use of "can", "could", and “might” leaving me wondering if this specification should be Informational instead. It all seems a bit loose. You could do this or that, if you wanted… I get that the specific metrics are defined here, but even so, there's not a lot of meat on the bone. Page 4, 1st full paragraph, 2nd sentence: I've not followed this work, so pardon me if I'm repeating a previous argument. However, I would find terms like "compliance", "compliant", and "non-compliant" (maybe "incompliant") preferable over "availability", "available", and "unavailable". Sure, you get PCM for an initialism instead of a nice acronym like PAM, but "available" also has a common meaning that makes it less desirable, in my opinion. Compliance is already used in the previous paragraph and seems like it could be substituted without a lot of drama. Of course, this will also affect section 3.3, should you choose the change the terms. Page 8, 2nd paragraph, 3rd sentence: I don’t find availability based on successive intervals all that good a way of making that determination. A service with an unavailability threshold set would be deemed "available" if it had a pattern of "unavailability threshold" - 1 interval violations followed by one VFI, rinse and repeat. Might you not want something like a percentage of VIs over a larger window of time instead? I realize this a couched in permissive language, but then the following text runs with the idea that successive intervals is the way to go. This also goes back to my general issue above about the looseness of this specification. Nits/editorial comments: Page 2, center header: I'm not sure how “PAM for Multi-SLO” applies as a compression of the title. “Multi-SLO” never appears in any other context than the header of the document. Page 3, 1st full paragraph, 4th sentence: I’d change “set of thereof” to “set thereof”. Page 4, 1st full paragraph, 3rd sentence: delete “, and which” along with “therefore” and if that parses better. Otherwise, the sentence feels like a phrase. Page 4, 2nd full paragraph, 1st sentence: change “is” to “are”. Page 5, section 3.1, 1st paragraph, 3rd sentence: “second” is given of an example of a different granularity, but that’s the granularity given in the second sentence, so it doesn’t make a good example of a different granularity. Decamillisecond is fine. Page 5, section 3.1, 1st paragraph, 5th sentence: remove a spurious white space from “(VFI )”. Page 5, section 3.1, 1st paragraph after the bullet items, 1st sentence: insert “of” between “monitoring” and “performance”. Page 6, 2nd paragraph, 2nd sentence: change “to distinguish” to “distinguishing”. Page 6, definitions for “VPC” and “SVPC”: How is a severely VPC different from a VPC? It’s also not clear to me from the text that the performance parameters for VI/SVI apply to individual packets, so how is this count generated? Only from parameters that can be applied on a per-packet basis (so not things like jitter)? Page 7, 6th and 7th bullet items: I’d change “measurement interval” to “measurement session” (session was used previously) or “period”. Otherwise, the term “interval” becomes unnecessarily overloaded. Id-nits says: == There is 1 instance of lines with non-ascii characters in the document. I’m not sure where that character is and I admit to not searching for it.