Hi Ron, Thanks for your comments. We have revised the document following the comments from you and Carlos. http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08
The main changes: - Rewrote the introduction. - Added reference to a few RFCs/standards that were missing or were published in the last year. - Bug fixes in the reference list. - Changed the order of some of the sections following the comments we received. Tal. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ronald Bonica Sent: Thursday, January 03, 2013 6:24 PM To: [email protected] Cc: [email protected] Subject: [OPSAWG] Mail regarding draft-ietf-opsawg-oam-overview Authors, Thanks for submitting this draft and for suffering through the drawn out process. The following are a few comments. Section 1 and 1.1 ========= The introduction is harder to parse than it needs to be. In the introduction, I think that that you are trying to make the following points: - This memo summarizes IETF OAM mechanisms - An OAM mechanism provides the following laundry list of functions (e.g., connectivity checking, path discovery, etc.) Provide a definition for each function. - The scope of this document is limited to OAM mechanisms that operate on the data plane. (SNMP is out of bounds). Do I have that much right? If so, would it be possible to craft Sections 1 and 1.1 so that these points are brought to the forefront? Section 1.2 =========== - Should every OAM mechanism listed in Table 1 should appear in the bullet list. Some are missing (e.g., TRACEROUTE). - You list MPLS as an OAM tool. You probably mean to say MPLS LSP Ping. - For the most part, the bullet list is a list of tools. The notable exception is IPPM, which is a WG, not a tool. Should you replace that bullet item with the tools that the produce (e.g., OWAMP, TWAMP)? Section 1.3 =========== - The title of this section is inappropriate, because some of the documents that you list are not on the standards track. Maybe a better title would be IETF OAM Documents, Grouped by the OAM mechanism that they support. - If you accept the suggestion listed above, the first column of Table 1 should specify an OAM mechanism, drawn from the bullet list in Section 1.2. The second column should be an RFC number. The third column should be an RFC title, and the fourth column should be the type. - RFCs 4884, 4950 and 5837 should be associated with TRACEROUTE, because they all augment the ICMP Destination Unreachable message and their output is intended for consumption by TRACEROUTE. (While RFC 4950 has something to do with MPLS, it is a different mechanism than MPLS LSP PING. Section 2.1 ============ - Please do a brief scan of the document to make sure that you actually use all of the acronyms that you define. I found quite a few that are unused. Section 3 ========= The subsections of Section 3 should map to the bullet points in Section 1.2 Section 3.2 =========== By default, traceroute sends 3 probes per TTL. However, in most implementations, this is configurable through the command line Nits ==== Please run the nit checker and correct all errors and warnings -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
