I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-opsawg-oam-overview-08.txt Reviewer: Elwyn Davies Review Date: 22 Jan 2013 IETF LC End Date:25 Jan 2013 IESG Telechat date: (if known) - Summary: In my opinion, this draft has serious issues as described below. Major issues: General 1: Title vs Abstract vs Section 1 vs actual content: Here in the UK a well-known brand of varnishes and wood preservative paints uses the slogan 'Does what it says on the tin!'. If my understanding and the write-up in RFC 6491, OAM covers a whole lot more than the coverage of the specific mechanisms discussed in this document .. and there are various other mechanisms such as SNMP and Netconf that support the OAM constellation. I would take the view that this document certainly does not 'do what it says on the tin'. Accordingly I take issue with the title as it doesn't provide a total overview of OAM mechanisms; the abstract closes down the scope of OAM as compared with RFC 6491 and s1 restricts it even more - and certainly does not summarize all the OAM tools and mechanisms defined in the IETF. The last para of s1 claims that 'management aspects are outside the scope of this document' - if this is really saying that this 'overview' of OAM skips the whole M aspect of OAM then I'm afraid the document is badly misnamed. And it significantly reduces the value of the work. General (2): The intended purpose of this document: Back in 2011 Stewart Bryant summarized a review of a previous version of this document from the routing directorate (https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/history/ entry dated 2011-08-10 referring to version 05 of the document). IMO the initial section of that review regarding the audience of this document was well targeted and *has not been fixed*. If this is intended as an introductory overview for people wishing to see what OAM is about in the IETF then it needs further introductory text and some background. It should also state what its target audience actually is. General (3): I don't know if Scott Bradner has actually produced a proto shpeherd write up, but I would be intrigued to know the level of concensus behind this document. In particular the tool classification in s1.1 and terminology in s2 (particularly s2.2.2) is that used exclusively in the MPLS-TP work in the IETF which is derived from the 802.1ag terminology. The terminology is presented as if it is common to OAM work across the IETF. Does the IETF management community at large concur with this expansion of the applicability of the terminology set based on 'Management Domains' etc? General (4): As an overview, I think it would be advisable to point out that one reason for the multiplicity of tools is that they support at least four different data plane technologies (native IP, vanilla MPLS, MPLS-TP and PWE) and note that in several cases the data plane technologies rely on distinct (IP-based) management channels to allow the information gleaned by the operations in the the data plane to be reported back to the application that originated the operation. Minor (or at least less major) issues: s1, para1: For consistency with the abstract, s1.1 .. and because I'd expect OAM to handle it as well ... OAM deals with performance monitoring and statistics gathering as well as dealing with degradation. s1.1: The section is entitled building blocks but actually only mentions one block, i.e., the OAM protocol. Presumably this section really ought to say something about the applications and device drivers that have to instantiated in the MPs. In particular as introduction to the text in the following section it should say something about classifying applications into continuously running or proactive monitoring and on-demand applications (since the latter are introduced without any definition in the next section.) s2.2.2/3: I am not familiar with 802.1 management issues and I was rather confused by the logical status of MIPs . The text here seems to indicate that they are intermediate and generally don't terminate messages but then says in s2.2.3 that messages are 'destined to' MIPs. Looking for some additional understanding, I fetched up at Wikipedia (now there's a surprise) http://en.wikipedia.org/wiki/IEEE_802.1ag. This page mentions the concept of maintenance domains and the explanation of MIPs as internal points in the domain that generally forward messages within the domain whereas end points (MEPs) are effectively on the domain boundary. This makes a whole lot more sense and seemed to be a rather better set of term definitions than we have in this draft. I noticed eventually that the term Management Domain (MD) had appeared in the first line of s1.1 but does not appear in s2 at all. If we are going to accept the Management Domain terminology set, then MD certainly ought to be defined and discussed here. s2.2.3, para1, sentence 1: > either initiates or reacts to OAM messages. The following sentences contradict this. Should be 'initiates and/or reacts to OAM messages'. See comment above. s3, general: The level of detail regarding the various toolsets is not very even. In particular, the MPLS-TP toolset gets significantly more attention than others and the detail in OWAMP/TWAMP may be more than is desirable for an overview. s3.1: A few words about the likely suppression of pings and traceroute messages due to ICMP filtering is probably desirable as these limit their usefulness in the wider Internet. s3.3: What about RFC6374 (MPLS packet loss measurement)? It appears in the list in s1.4 but is not mentioned here. s3.4.1: Talking about what the MPLS working group 'is currently doing' will not be helpful for an archival document. s3.4.3.1: The OnDemand-CV reference is for non-TP MPLS... do you mean RFC 6426 which appears to be the TP variant? Nits/editorial comments: General: For a reader who wants to go on and look at the RFCs that define the various tools, it would probably be helpful to use reference tags that either are or include the RFC number. s1.3, para 2: s/in several fronts/covering several different approaches/ s2.2.2, last para: Need to expand 'p2mp'. s3.4.3.8: Should this section reference RFC6375? s3.5.1: It appears that the basic AC acronym (associated channel) is not defined.