An Overview of Operations, Administration, and Maintenance (OAM) Tools
draft-ietf-opsawg-oam-overview-16

[Ballot comment]
Please consider the following comments Elwyn Davies and his Gen-ART review:

Summary:
Ready with nits and a couple of very minor issues.
I was pleased that this version of the document seems to have been
greatly improved since -08 which I reviewed previously in Jan 2013, and
the scope is now quite clear.  Thanks for the work that has been done! 

Major issues:
None.

Minor issues:
General:  I wondered about the wisdom of using more or less mnemonic
tags for the multitude of references but on reflection the mnemonic
value is probably worthwhile.  I toyed with the idea of adding the RFC
number next to the reference in the text on first occurrence so that
people don't have to keep skipping off to the references, but in the end
this is probably a silly idea.

s2.2.9, Discussion: The added complexity of P2MP is called out but
nothing is said about MP2MP, which I think would be even more tricky.
Would it be useful to say something also about MP2MP? [*Are* there any
tools for this case?]

s4.4.1, para 6: There seems to be possibly a minor contradiction between
the statements:

LSP Ping is easily extensible to
  include additional information needed to support new functionality,
  by use of Type-Length-Value (TLV) constructs.

and

The usage of TLVs is
  typically not easy to perform in hardware, and is thus typically
  handled by the control plane.

What is the implication of adding a new TLV as regards hardware and
performance? Does the second statement mean that either the hardware
will throw away messages with unknown, new TLVs, complain about such
messages or have poor performance?  If so, the "easily" in the first
statement is possibly "easily but impractically".  A little explanation
is probably needed (or maybe this is just too complex to explain here).
Maybe reducing all this to "LSP Ping is extensible using additional TLVs
but there may be hardware issues (see RFC...)."

Nits/editorial comments:
General: s/i.e./i.e.,/, s/e.g./e.g.,/ (a couple of missing cases)

General: It would be helpful to use non-breaking hyphens in MPLS-TP and
all references if possible.

s1.2, first bullet: s/Standard development/Standards development/

s1.3: It would be useful to put a forward reference to the terminology
section 2.1 to cover the various acronyms and abbreviations in Table 1.

s3, 2nd bullet: s/also allows to detect/also allows detection of/  It
might also be appropriate to be a bit less definite about localization -
add in 'attempts' or 'tries' maybe?

s3, Delay Measurement: Maybe mention 'jitter' as an alternative for
delay variation.

s4.3.3, 2nd bullet: s/a failure is detected/a failure is reported/

s4.3.3, last para: s/i.e. no failures are detected,/i.e., when no
failures have been detected,/

s4.3.3, last para: "...negotiated transmission time" Do you mean
"transmission rate" as mentioned in the previous para?  If not it might
be good to make it clear that this isn't a typo.

s4.4.1, para 4 (after 2nd bullet): s/and also Maximum Transmission Unit
(MTU) problems/and also identify Maximum Transmission Unit (MTU)
problems/

s4.4.1, para 5: s/the MPLS faults/MPLS faults/

s4.5.1, 2nd bullet:
and there is a need to
    differentiate OAM packets from data plane ones.
This is slightly confusing - the congruence requirement makes all the
packets (OAM and user) to be data plane packets. How about:

and there is a need to
    differentiate OAM packets from ordinary user packets in the data plane.


s4.5.1, Maintencance Intermediate Point section:
A MIP in MPLS-TP identifies OAM packets destined
  to it by the value of the TTL field in the OAM packet.
This is not terribly helpful: Either a reference to where to find out
what TTL value is needed or some explanation of the required value would
be a good idea.

s4.5.1, Up and Down MEPs:
The term "bridge interface" is IEEE/MPLS-TP jargon and needs defining.
Might be also worth a note that, unlike prior usage of up/down, this has
nothing to do with defects (or layabout parliamentarians in
Brussels). ;-)

s4.5.3: Please add a reference for PWE3 ACH and VCCV and a pointer to a
document where "PW control word" is defined (preferably with section
numbers.

s4.5.4.6: s/if there a return path exists/if a return path exists/

s4.7.3, last para: s/Server accepts the modes./Server accepts the mode./

s4.7.3, last para: I think there is a bit of interaction missing: (i)
server tells Session-sender to start sending; (ii) if Control-client
stops the session, it tells server and server tells Session-sender;
(iii) when session is finished Session-sender reports to Server which
recovers data from Session-receiver (or controls Fetch client?)

s5.1, Traceroute: Should this mention the Paris traceroute?

s5.1, OWAMP/TWAMP: For consistency should probably reference RFCs.

s5.3: s/in as much accuracy/with as much accuracy/

[Ballot comment]
I'm glad that we have this sort of overview; thanks for the work on this.

I have a couple of small points below, and one of more significance.  Please consider them -- especially the last:

1. The Introduction says this (and it's also in the Abstract):

  This document focuses on tools for detecting and isolating failures
  and for performance monitoring. Hence, this document focuses on the
  tools used for monitoring and measuring the data plane; control and
  management aspects of OAM are outside the scope of this document.

But the title says this:
"An Overview of Operations, Administration, and Maintenance (OAM) Tools"

Might it be better to change the title to something that indicates that it's limited, and not an overview of *all* OAM tools?  Something, maybe, like "An Overview of Operations, Administration, and Maintenance (OAM) Tools for Detecting and Isolating Failures and for Performance Monitoring"

I know that makes for a long title, but I think it's better than overselling the document.


2.
-- Section 1.2 --

  It should be noted that this document is not necessarily suitable for
  beginners without any background in OAM.

I'd think that a statement of what's necessary would be more useful.  Pick one or two references that are the most critical, perhaps, and say something like this instead:

  It should be noted that some background in OAM is necessary in order
  to understand and benefit from this document.  [OAM-Def] and [..other..]
  are particularly important starting points.


3. Further to that point, I see that you have no normative references.  Perhaps you think that Informational documents don't need normative references, an opinion I don't share.  I think that the references that are required in order to understand the document at hand are normative references, regardless of the status of the document at hand.  I'm not making this a DISCUSS point, but I strongly urge you to do a separation of the references, and at least move the most critical ones into a Normative References section, to make it clear to the reader which documents absolutely have to be read as background material.

[Ballot comment]
The draft provides a nice overview.  I was surprised that the Security Considerations section does not cover reconnaissance (network addresses, ports, and path) and should at least mention it as it is one of the major concerns between security and performance management techniques (ping, traceroute, etc.).  It is the typical first stage of an attack to gather information on a network - what hosts exist, what ports are active, how many routes are there to the network (think DoS attack), and any additional information revealed through OAM techniques.  I'd like to see some text added to generally cover this topic.

[Ballot comment]
In Sec 4.5.4: "The MPLS  working group currently plans to use a mixture of OAM tools that are
  based on various existing standards, and adapt them to the requirements of [MPLS-TP-OAM]."

Hasn't the MPLS WG finished up the MPLS-TP work and specifically the OAM related work?  Could this be rephrased to reflect that?

[Ballot comment]
I want to thank the authors for working so hard to address the concerns
raised by Stewart Bryant during the previous IESG review. I know it was
not an easy process for all concerned, but I believe the resulting
document is substantially improved.

I have checked for the Discuss issues and Comments that I raised last
time around. Thank you or doing an excellent job of mopping them up. I
am left with just a few that I carry over as Comments, this time.

---

I still feel that sections 4.1 and 4.2 should include some mention of
OAM in multicast IP scenarios. Perhaps this got added somewhere else,
but  couldn't find it.

---

I should have liked Section 6 to have included a discussion of the
security considerations of OAM in general, and the security provisions
available for the various OAM mechanisms discussed. What you have
still seems like a bid of a dodge.

(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?

Informational
because it is an informational document
yes

(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 summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS for the transport profile (MPLS-TP), pseudowires, and TRILL.

Working Group Summary
There were no particular issues raised in the working group
about this document

Document Quality
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, 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?
This is a review document and is not the kind of thing that gets implemented.
No special mentions

Personnel
Who is the Document Shepherd?
Scott Bradner

Who is the Responsible Area Director?
Benoit Claise

(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.
I reviewed the document and feel it is ready for publication modulo a few dangling references that can be fixed during review or by
an IESG note

(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

(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.
n/a (this is a review document)

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

(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?
solid (in the context of a not all that active WG list)

(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.
a few dangling references and a bug in the ID Nits program - former can be fixed during review or by IESG note

(12) Describe how the document meets any required formal review criteria, such as the MIB 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 5226).
I reviewed the IANA Considerations section by reading it - the section is accurate

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

(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, etc.
n/a

(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?

Informational
because it is an informational document
yes

(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 summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS for the transport profile (MPLS-TP), pseudowires, and TRILL.

Working Group Summary
There were no particular issues raised in the working group
about this document

Document Quality
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, 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?
This is a review document and is not the kind of thing that gets implemented.
No special mentions

Personnel
Who is the Document Shepherd?
Scott Bradner

Who is the Responsible Area Director?
Ron Bonica

(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.
I reviewed the document and feel it is ready for publication modulo a few dangling references that can be fixed during review or by
an IESG note

(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

(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.
n/a (this is a review document)

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

(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?
solid (in the context of a not all that active WG list)

(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.
a few dangling references and a bug in the ID Nits program - former can be fixed during review or by IESG note

(12) Describe how the document meets any required formal review criteria, such as the MIB 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 5226).
I reviewed the IANA Considerations section by reading it - the section is accurate

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

(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, etc.
n/a

Significant issues have been raised with the document during the IESG review, dated from August 2011. Only 5 ADs are currently active from that period.
Therefore, I'm sending the document back to the working group for resolution of those issues, to make sure that the working group fully understands the issues and is in control of managing the resolution.

Regards, Benoit

IANA has reviewed draft-ietf-opsawg-oam-overview-08, which is currently
in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'An Overview of Operations, Administration, and Maintenance (OAM)
  Mechanisms'
  as Informational RFC

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
ietf@ietf.org mailing lists by 2013-01-25. 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


  Operations, Administration, and Maintenance (OAM) is a general term
  that refers to a toolset that can be used for fault detection and
  isolation, and for performance measurement. OAM mechanisms have been
  defined for various layers in the protocol stack, and are used with a
  variety of protocols.

  This document presents an overview of the OAM mechanisms that have
  been defined and are currently being defined by the IETF.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/


No IPR declarations have been submitted directly on this I-D.

(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?

Informational
because it is an informational document
yes

(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 presents an overview of the OAM mechanisms that
have been defined and are currently being defined by the IETF.

Working Group Summary
There were no particular issues raised in the working group
about this document

Document Quality
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, 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?
This is a review document and is not the kind of thing that gets implemented.
No special mentions

Personnel
Who is the Document Shepherd?
Scott Bradner

Who is the Responsible Area Director?
Ron Bonica

(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.
I reviewed the document and feel it is ready for publication modulo a few dangling references that can be fixed during review or by
an IESG note

(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

(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.
n/a (this is a review document)

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

(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?
solid (in the context of a not all that active WG list)

(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.
a few dangling references and a bug in the ID Nits program - former can be fixed during review or by IESG note

(12) Describe how the document meets any required formal review criteria, such as the MIB 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 5226).
I reviewed the IANA Considerations section by reading it - the section is accurate

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

(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, etc.
n/a

[Ballot comment]
I have cleared my Discuss on the basis of the RFC Editor notes that have been entered. I hope that the authors have time to examined the Comments that I and other ADs have raised.

---

I'm nervous of a document that makes a comparative analysis of OAM
mechanisms developed in another SDO without seeking input from that
SDO.

---

idnits warns about the unnecessary 2119 boilerplate and the unresolved
references. There is no reason for an I-D to reach this stage with
theese warnings. Please clean up before passing to the RFC Editor.
                                   
---

You say:
                                   
  o ICMP Echo request, also known as Ping, as defined in [ICMPv4], and
      [ICMPv6]. ICMP Ping is a very simple and basic mechanism in
      failure diagnosis, and is not traditionally associated with OAM,

"Traditionally" gives me an image of my great grandfather hand-crafting
packets from kiln-dried apple wood.

You might want to find out which tools are most commonly used by network
operators to diagnose their networks. According to that research and
your definition of OAM, you will possibly find that ICMP Ping is very
much associated with OAM.

---

Odd that Section 1 calls out MPLS-TP and RFC 5860, butdoes not call out
RFCs 4377 and 4378.

---

Table 1 seems confused about whether it needs to make citations (in
square brackets). It does not need to state "work in progress" for
I-Ds that are referenced and marked as such in the references section.

---

Table 1 seems to be missing some of the references used in the text.
For example for p2mp LSP ping. Can you do a cross-check with the text?

Actually, the table seems a bit mixed. Some protocols are listed, while
in other areas you just list the requirements and frameworks.

---

Did you consider discussing permformance metrics at other layers as
part of the diagnostic toolset? You certainly seem open to OAM at
"various layers." Have a look at draft-ietf-pmol-metrics-framework
and maybe think about RFC 6076.

---

Section 3.1

Add ACH, ETH, FEC, GAL, LDP, LOC, LOCV, MC, MTU, UC
LSP is a Label Switched Path
I thought the 'M' in ME and MIP stood for MEG

---

Section 3.2.6

The table shows "System" for BFD Maintenance Point Terminology. It is
not clear to me what that word means.

---

Section 4.12

  |BFD        |BFD    |Negotiat|UC |My Discr| Control Detection Time |
  |          |Control|ed durin|  |iminator| Expired                |

"My Discriminator"? Who are you?

---

I should have liked Section 5 to have included a discussion of the
security considertions of OAM in general, and the security provisions
available for the various OAM mechanisms discussed.

---

Should you include RFC 4950?

---

NEW COMMENT

I wonder if you need to also consider draft-ietf-trill-rbridge-channel

[Ballot discuss]
Following the Gen-ART Review by Francis Dupont on 23-Jul-2011,
  there was discussion that lead me to expect changes to this
  document where traceroute is discussed.  The authors have not
  made the changes yet.

[Ballot comment]
RFC Editor note addresses my comment.

And now, some snark and sarcasm for the amusement of my fellow ADs and anyone else who cares:

My ballot notwithstanding, I hereby object to the fact that this document (a) defines OAM and (b) does not normatively reference RFC 6291/BCP 161. (*snort*)

[Ballot comment]
Section 2 should be removed. This document does not use 2119 keywords, and the [KEYWORDS] citation is missing in References anyway.

And now, some snark and sarcasm for the amusement of my fellow ADs and anyone else who cares:

My ballot notwithstanding, I hereby object to the fact that this document (a) defines OAM and (b) does not normatively reference RFC 6291/BCP 161. (*snort*)

[Ballot comment]
Minor editorial suggestions...


In section 3.2.5, the word "intermittently" doesn't seem right.
Perhaps "interchangeably"?

I was OK with this sentence in section 3.2.5:

  The terms Failure, Fault, and Defect are intermittently used in the
  standards, [...]

until I read in the next paragraph that ITU-T differentiates among the
three terms.  Perhaps the quoted sentence should specify which
standards?  Also in the title of 3.2.6?

[Ballot discuss]
I expect this one will be easily cleared (author has agreed to add some information in the security considerations):

Tal: I think we can add a general description (1-2 paragraphs) of the security threats in OAM protocols, and list the security mechanisms defined in the protocols discussed in this document.

secdir reviewer (Paul Hoffman): A short list in the Security Considerations section saying briefly what each OAM protocol currently has for security (even if it is "well, um, none") should be fine for a "catalog" document such as this.

[Ballot comment]
Unidirectional/Bidirectional OAM vs. One-way/Two-way OAM -
Both pairs of terms are used in the draft (One-way/Two-way -
in Section 4.5.1, Unidirectional – in section 4.12, /Bidirectional –
in Section 4.2.2).  Neither  the terms nor their
equivalence are explained in the draft.


In section 4.10.3.1: “Continuity Check and Connectivity
Verification (CC-V) are OAM operations generally used in
tandem, and compliment each other.” – probably should
be “complement”?

“There are a few differences between the two standards in t
erms of terminology”  do you mean: “There are a few differences
in terminology between the two standards”.

[Ballot discuss]
The following is an edited version of the comments received
from the Routing Directory Review.

Summary:

There are significant concerns that need to be addressed
before publication.

The document does no needs to clearly identify the target
audience. Since a document written as a tutorial for a beginner
has different requirements from that written for a subject
matter expert this clarification is important in terms of
expectations in terms of depth and precision of the text. A
tutorial document for the beginner would be most welcome
considering the extent of OAM discussions that have taken
place in the IETF and it is assumed by the reviewer that
this is the intent of the document.

To that end the document needs to -

Include  a “Historical Background”  session that goes
beyond the single sentence in Section 1 (“OAM was originally
used in the world of telephony, and has been adopted in packet
based networks”)

Provide a clear view of OAM functionality and its relationship
to various “planes” of networking (data plane, control plane,
management plane). In particular, the importance of
fate-sharing of OAM and user traffic flows in packet networks
should be explained.

Explicitly map the ideas,  terms and methods that have been
adopted  from technologies owned by ITU-T and/or IEEE to 
IETF-owned technologies.  If such a mapping is not possible,
it should be explicitly stated.

Explain in a neutral way points of contention regarding
various OAM-related issues.

The draft as written is is a partial annotated list of
references to IETF and non-IETF protocols and mechanisms that
deal with certain aspects of OAM in IP, IP/MPLS, MPLS-TP
and Ethernet networks. The draft does not describe the underlying
reasons for selecting particular protocols for description.

It is not clear why the now obselete is ITU-T Y.1711 considered
in detail. The reviewer proposed giving consideration to I.610
as a protocol, although I am not sufficinetly familiar with
I.610 to determine its relevence. It should however be examined.
Similarly it may be useful to introduce the reader to E-LMI
(defined by MEF).

In terms of MPLS-TP why is there no discussion of MPLS-TP
fault management OAM - (draft-ietf-mpls-tp-fault-05) is omitted??

There are a number of readibility issues that arrise from the
terms and concepts taken from  the referenced documents
having different meaning in these documents.  E.g.,. in Section 4.1
the draft states that ICMP ping provides “connectivity
verification for Internet Protocol”. However, in Section 3.2.4
the draft says that “connectivity verification function allows
an MP to check whether it is connected to a peer MP or not”.
Since MPs are not mentioned with regard to ICMP, it is not
clear whether “connectivity verification” means the same thing
in these two cases.

In some cases the text is detailed beyond the needs of the
beginner, whilst other imporatnt concepts are not detailed
sufficiently for example:

- The OWAMP TCP port information is not needed, whilst the IPPM

- In Section 3.2.3 the draft defines the term “Maintenance
Entity” (ME), whilst “Maintenance Entity Group” (MEG), a.k.a.
“Maintenance Association (MA), is only defined by reference

-  In Section 4.5.2 the draft mentions security aspects of
IPPM protocols. Howeverwhilst, these aspects are not even
mentioned in Section 4.2. discussing BFD.

The document therefore needs another pass to ensure
consistency of detail.



Major Issues:


The concepts of data plane, control plane and management
plane are not well explored in the draft and need to
expained with their OAM context.

=======

The relationship between OAM functionality and network
management as presented in the draft is unclear. 
For example

a. (Section 1) Other aspects associated with the OAM
acronym, such as management, are outside the scope of
this  document  <>

b. (Section 4.6.4)  The FDI function is used by
an LSR to report a defect to affected client layers,
allowing them to suppress alarms  about this defect
<< Alarms are arguable part of management >>

c. (Section 4.7.2) When the ETH-CC function detects
a defect, it reports one of the following defect conditions:

i. Loss of continuity (LOC): Occurs when at least when
no CCM messages have been received from a peer MEP during
a period of 3.5 times the configured transmission period

iii. Unexpected period: Occurs when the transmission
period field in the CCM does not match the expected
transmission period value  << Since transmission period
field in ETH-CC is defined by management, this defect
reports a management issue>

d. (Section 4.7.6)  The Alarm Indication Signal
indicates that a MEG should suppress alarms about
a defect condition at a lower MEG level, i.e., since
a defect has occurred in a lower hierarchy in the
network, it should  not be reported by the current node 
<>

e. (Section 4.7.9)  The Y.1731 standard defines the
frame format for Automatic Protection  Switching
frames. The protection switching operations are defined
in  other ITU-T standards. <>

3.  OAM in connectionless vs. connection-oriented networks:

a. (2a) above suggests that OAM is applicable only
to connection-oriented networks (if you do not have
connections, connection problems do not exist by definition)

b. At  the same time, the draft discusses ICMP Ping
(Section 4.1) operating in connectionless IP networks,
and Ethernet OAM (Sections  4.7 and 4.8) operating
in connectionless Ethernet networks.

The authors should define the scope of OAM explicitly
and clearly - and then remove the sections dealing with
protocols and mechanisms that happen to be out of this
scope. In particular, explaining the relationship of
each specific defect to a specific networking plane.



MEs, MPs, MEPs and MIPs


Caveat: It may well be that the problem is not with the
draft but with the concept itself (or at least with the
attempts to extend it to IP, IP/MPLS and MPLS-TP networks)

Consider the following statements:


1. (Section 3.2.2)  A Maintenance Entity (ME)
is a point-to-point relationship between two Maintenance
Points (MP). The connectivity between these Maintenance
Points is managed and monitored by the OAM protocol. 
A pair of MPs engaged in an ME are connected by a Communication Link

2. (Section 3.2.3) A Maintenance Point (MP) is a
functional entity that is defined at a node in the
network, and either initiates or reacts to OAM messages.
A Maintenance End Point (MEP) is one of the end points of an ME,
and  can initiate OAM messages and respond to them. A Maintenance
Intermediate Point (MIP) is an intermediate point between two MEPs,
that does not initiate OAM frames, but is able to respond to
OAM  frames that are destined to it, and to forward others.

3. (Section 3.2.3)  The 802.1ag defines a finer distinction
between Up MPs and Down MPs. An MP is a bridge
interface, that is monitored by an OAM protocol…

4. (Section 4.1)  ICMP provides a connectivity
verification function for the Internet Protocol… ICMP is
also used in Traceroute for path discovery.

An OAM beginner would not be able to answer the following
questions:

1.      Can a communication link exist without any
MPs on it?

2.      Suppose that I have defined a P2P bidirectional
communication link with two MEPs  forming an ME.  What
would happen to this ME if I add a MIP between the two MEPs?

3.      What is the relationship (if any) between MEPs
and interfaces? Or is it just something specific to Ethernet bridges?

4.      Does a MIP really forward OAM frames that
are not destined to it?

5.      Operation of ICMP Ping does not require creation of
MPs. How does it provide a connectivity verification function for IP?

The authors need to remove conflicting definitions, to fix typos
(e.g., the definition of ME would be less problematic if it referred
to a pair of MEPs and not to a pair of MPs) and inaccurate statements
(in IP, IP/MPLS and MPLS-TP MIPs (as a component) do NOT forward
OAM packets that are not destined to them – but they do
that in Ethernet OAM).


Minor Issues:

Connectivity Check vs. Continuity Check

The draft mainly uses the term “Continuity Check”. However,
in some places the term “Connectivity Check” is used as well, e.g.:

1.      (Section 4.12) A key element in some of the OAM standards
that are analyzed in this document is the continuity check. It is
thus important  to present a more detailed comparison of the
connectivity check mechanisms defined in OAM standards.

2.      (Section 4.3)  LSP Ping extends the basic ICMP Ping
operation (of data-plane connectivity and continuity check)…

Please look at the use of the terms and ensure they are
applied consistently.


Caveat: Similar inconsistency in IEEE 802.1ag (but not in ITU-T Y.1731).


Continuity Check vs. Connectivity Verification

In Section 3.2.4. the draft refers to  RFC 5860 as the ultimate
source of information about the difference between Continuity
Check and Connectivity Verification. Looking up RFC 5860 (Section 2.2.3),
I’ve learned that connectivity verification is a function that
allows an End Point to find out whether it is connected to a specific
End Point(s) by means of an expected PW, LSP or Section. At the same
time, the draft says (in the same Section 3.2.4) that “A connectivity
verification function allows an MP to check whether it is connected
to a peer MP or not”.  The omitted  words from RFC 5860 “by means of…”
make such a definition unclear; also it is unclear whether End Points
(of Section, LSP or PW) which, presumably, are MEPs, can be
extended to be MEPs or MIPs (the draft uses the term MPs).

It is also not clear whether the draft considers LSP Ping (see
Section 4.3.) functionality “to verify data-plane vs. control-plane
consistency for a Forwarding Equivalence Class (FEC)”  as  related to
Connectivity Verification. This is especially strange since the
draft also states (in the same section)  that “LSP Ping extends the
basic ICMP Ping operation”  while Section 4.1 states that “ICMP
provides a connectivity verification function for the Internet  Protocol”. 


Another problem is the statement (in Section 4.2.3) that “BFD
Echo provides a connectivity verification function”, especially
since draft-ietf-mpls-tp-cc-cv-rdi-05 in Section 3.5 expands
format of the BFD control packets in order to provide CV function,
while BFD Echo is not even mentioned in this document. It might be
worth noting that we are not considering BFD Echo mode for MPLS-TP.

Finally, the draft does not explain whether there is any
correlation between the defects detected by the continuity
check and those detected by connectivity verification
(Section 4.10.3.1 looks  a logical place for this).



Inaccurate Representation of IEEE 802.1ag


In Section 3.2.3 of the draft theer is the following text:

“The 802.1ag defines a finer distinction between Up MPs and Down
MPs. An MP is a bridge interface, that is monitored by an OAM
protocol either in the direction facing the network, or in the
direction    facing the bridge. A Down MP is an MP that receives
OAM packets from,    and transmits them to the direction of the
network. An Up MP receives OAM packets from, and transmits
them to the direction of the bridging entity”.


However IEEE 802.1ag states (see Section 22.1.3 of that
document ) that: “All Up MEPs belonging to MAs that are attached
to specific VIDs are placed between the Frame filtering entity
(8.6.3) and the Port filtering entities (8.6.1, 8.6.2, and 8.6.4).
Separately for each VLAN, there can be from zero to eight Up
MEPs, ordered by increasing MD Level, from Frame filtering
towards Port filtering”.


That seems to imply that 802.1ag MEPs are NOT bridge interfaces
(since there can be are multiple MEPs per VLAN and multiple
VLANs per bridge interface).


Defects, Faults and Failures

In Section 3.2.5 the draft discusses the terms Defect, Fault
and Failure. However, these terms seem to apply to the
“communication link” the term needs to be clarified to
indicate that this is a data plane entity, or the term data
plane used in its place.

At the same time, “Unexpected Period” and “Unexpected MEP”
are mentioned as defects detected by ETH-CC in Section 4.7.2
even if, to the best of my understanding, these conditions
are side effects of mis-configuration i.e., a management plane problem.



VCCV: An OAM Mechanism or a Control Channel?


In Section 4.4. the draft states that VCCV “provides
end-to-end fault detection and diagnostics for PWs”.
This seems to point that VCCV is an OAM mechanism/protocol.

However, later in the same section is states that “The
VCCV switching function provides a control channel associated
with each PW… and allows sending OAM packets in-band with PW data”. 
And on the next line it explains that “VCCV currently supports
the following OAM mechanisms: ICMP Ping, LSP Ping, and BFD”
(which are all mentioned as OAM mechanisms providing
continuity check and/or connectivity verification in the draft).
So it remains completely unclear whether VCCV is an OAM
mechanism or just a channel for separating user data from OAM flows.

The issue here may well be historic because VCCV predates
the modern ACH mechanism. This should be clarified in the text.


MEs, MEGs and MEG levels

The draft explicitly defines a Maintenance Entity (ME) in
Section 3.2.2, but defers to MPLS-TP OAM Framework for
the definition of the Maintenance Entity Group (MEG). The
text defining ME in the draft differs from that in the
MPLS-T_ OAM Framework document 
(see http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-framework/?include_text=1, Section 2.2).
At the same time, it resembles the definition of ME in
Section 3.1 of this document.

MEG level is mentioned a couple of times in the draft,
but the only explanation given (in Section 4.7.2) is
“The MEG level is a 3-bit number that defines the level
of hierarchy of the MEG”; and this seems to be the only
text in the draft that deals with MEG hierarchy. A more
details description should be provided.


Differences between Approaches to Packet/Frame Loss Measurement

There is no description the fundamental difference
between two approaches to measuring packet loss –
that of the IPPM WG (based on counting synthetic packets)
and that of Y.1731 (based on counting the user packets),
even if both are mentioned in the draft. MPLS-TP BTW
provides a tool for doing loss measurement and notes
that the instrumentation technique is independent of
the method of making the measuremnet.

[Ballot discuss]
Following the Gen-ART Review by Francis Dupont on 23-Jul-2011,
  there was discussion that lead me to expect changes to this
  document where traceroute is discussed.  The authors have not
  made the changes yet.

[Ballot comment]
1. The use of the term "localization" in the Abstract is potentially confusing, since localization in application protocols refers to presenting textual strings that are appropriate for a given locale. Perhaps the term "isolation" might be more appropriate?

2. This paragraph is confusing:

  o IP Performance Metrics (IPPM) is a working group in the IETF that
      defined common metrics for performance measurement, as well as a
      protocol for measuring delay and packet loss in IP networks.
      Alternative protocols for performance measurement are defined, for
      example, in MPLS-TP OAM [MPLS-TP OAM], and in Ethernet OAM [ITU-T
      Y.1731].

As far as I can see, MPLS-TP OAM and Ethernet OAM were not developed in the IETF's IPPM WG; I suggest moving the second sentence to a separate paragraph.

[Ballot comment]
The Ballot Text write-up seems missing the Technical Summary.

---

I'm nervous of a document that makes a comparative analysis of OAM
mechanisms developed in another SDO without seeking input from that
SDO.

---

idnits warns about the unnecessary 2119 boilerplate and the unresolved
references. There is no reason for an I-D to reach this stage with
theese warnings. Please clean up before passing to the RFC Editor.
                                   
---

You say:
                                   
  o ICMP Echo request, also known as Ping, as defined in [ICMPv4], and
      [ICMPv6]. ICMP Ping is a very simple and basic mechanism in
      failure diagnosis, and is not traditionally associated with OAM,

"Traditionally" gives me an image of my great grandfather hand-crafting
packets from kiln-dried apple wood.

You might want to find out which tools are most commonly used by network
operators to diagnose their networks. According to that research and
your definition of OAM, you will possibly find that ICMP Ping is very
much associated with OAM.

---

Odd that Section 1 calls out MPLS-TP and RFC 5860, butdoes not call out
RFCs 4377 and 4378.

---

Table 1 seems confused about whether it needs to make citations (in
square brackets). It does not need to state "work in progress" for
I-Ds that are referenced and marked as such in the references section.

---

Table 1 seems to be missing some of the references used in the text.
For example for p2mp LSP ping. Can you do a cross-check with the text?

Actually, the table seems a bit mixed. Some protocols are listed, while
in other areas you just list the requirements and frameworks.

---

Did you consider discussing permformance metrics at other layers as
part of the diagnostic toolset? You certainly seem open to OAM at
"various layers." Have a look at draft-ietf-pmol-metrics-framework
and maybe think about RFC 6076.

---

Section 3.1

Add ACH, ETH, FEC, GAL, LDP, LOC, LOCV, MC, MTU, UC
LSP is a Label Switched Path
I thought the 'M' in ME and MIP stood for MEG

---

Section 3.2.6

The table shows "System" for BFD Maintenance Point Terminology. It is
not clear to me what that word means.

---

Section 4.12

  |BFD        |BFD    |Negotiat|UC |My Discr| Control Detection Time |
  |          |Control|ed durin|  |iminator| Expired                |

"My Discriminator"? Who are you?

---

I should have liked Section 5 to have included a discussion of the
security considertions of OAM in general, and the security provisions
available for the various OAM mechanisms discussed.

---

Should you include RFC 4950?

---

NEW COMMENT

I wonder if you need to also consider draft-ietf-trill-rbridge-channel

[Ballot comment]
IPPM has defined other metrics that aren't mentioned here (e.g. duplication and reordering) ... is there a reason why those aren't included?

It was also unclear if psamp, netflow, and ipfix were excluded for a reason.

[Ballot comment]
The Ballot Text write-up seems missing the Technical Summary.

---

I'm nervous of a document that makes a comparative analysis of OAM
mechanisms developed in another SDO without seeking input from that
SDO.

---

idnits warns about the unnecessary 2119 boilerplate and the unresolved
references. There is no reason for an I-D to reach this stage with
theese warnings. Please clean up before passing to the RFC Editor.
                                   
---

You say:
                                   
  o ICMP Echo request, also known as Ping, as defined in [ICMPv4], and
      [ICMPv6]. ICMP Ping is a very simple and basic mechanism in
      failure diagnosis, and is not traditionally associated with OAM,

"Traditionally" gives me an image of my great grandfather hand-crafting
packets from kiln-dried apple wood.

You might want to find out which tools are most commonly used by network
operators to diagnose their networks. According to that research and
your definition of OAM, you will possibly find that ICMP Ping is very
much associated with OAM.

---

Odd that Section 1 calls out MPLS-TP and RFC 5860, butdoes not call out
RFCs 4377 and 4378.

---

Table 1 seems confused about whether it needs to make citations (in
square brackets). It does not need to state "work in progress" for
I-Ds that are referenced and marked as such in the references section.

---

Table 1 seems to be missing some of the references used in the text.
For example for p2mp LSP ping. Can you do a cross-check with the text?

Actually, the table seems a bit mixed. Some protocols are listed, while
in other areas you just list the requirements and frameworks.

---

Did you consider discussing permformance metrics at other layers as
part of the diagnostic toolset? You certainly seem open to OAM at
"various layers." Have a look at draft-ietf-pmol-metrics-framework
and maybe think about RFC 6076.

---

Section 3.1

Add ACH, ETH, FEC, GAL, LDP, LOC, LOCV, MC, MTU, UC
LSP is a Label Switched Path
I thought the 'M' in ME and MIP stood for MEG

---

Section 3.2.6

The table shows "System" for BFD Maintenance Point Terminology. It is
not clear to me what that word means.

---

Section 4.12

  |BFD        |BFD    |Negotiat|UC |My Discr| Control Detection Time |
  |          |Control|ed durin|  |iminator| Expired                |

"My Discriminator"? Who are you?

---

I should have liked Section 5 to have included a discussion of the
security considertions of OAM in general, and the security provisions
available for the various OAM mechanisms discussed.

---

Should you include RFC 4950?

[Ballot discuss]
In general, Informational documents are unlikely to do harm to the
Internet and so do not so easily attract Discusses. However, I find
a number of errors of ommission that mean that the document may
result in confusion. You may be able to fix these by clarifying the
scope of the document, or by adding text.

---

I don't think your definition of OAM is tight enough to limit the
discussion to only the mechanisms that you describe. You refer to OAM
being scoped as:
  this document refers to OAM in
  the context of monitoring communication entities, e.g., nodes, paths,
  physical links, or logical links.

And you define:
  Operations, Administration, and Maintenance (OAM) is a general term
  that refers to a toolset that can be used for fault detection and
  localization, and for performance measurement.

You also talk about

  OAM mechanisms are used in various
  layers in the protocol stack, and are applied to a variety of
  different protocols.

With these definitions:
- a control plane module is possibly a communication entity
- a node component (e.g., a CPU) is possibly a communication entity
- a protocol keep-alive for an out-of-band protocol is possibly an OAM
  mechanism
- a protocol keep-alive for an in-band protocol is definitely an OAM
  mechanism
- LoS and LoL mechnisms in optical networks are OAM
- Control plane error propagation and falt isolation mechanisms are OAM
- Management plane tools and protocols are OAM (notwithstanding that
  you say:
  Other aspects associated with the
  OAM acronym, such as management, are outside the scope of this
  document.
  ...because management tools may be used for fault detection and
  localization, and for performance measurement.

You appear to have limited yourself to monitoring layer-3 and below                 
forwarding plane components of packet/frame networks. Please take the
time to scope this document more clearly.

---

You should include a discussion of multicast ping and multicast
traceroute (draft-ietf-mboned-ssmping and draft-ietf-mboned-mtrace-v2)

---

Section 4.2.1

You cite [MPLS-TP Ping BFD] as an example and give it as a reference,
but this work has been retired by the MPLS working group, and the
relevant material moved to another document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'An Overview of Operations, Administration, and Maintenance (OAM)
  Mechanisms'
  as an Informational RFC

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
ietf@ietf.org mailing lists by 2011-07-20. 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


Operations, Administration, and Maintenance (OAM) is a general term
that refers to a toolset that can be used for fault detection and
localization, and for performance measurement. OAM mechanisms have
been defined for various layers in the protocol stack, and are used
with a variety of protocols.

This document presents an overview of the OAM mechanisms that have
been defined and are currently being defined by the IETF, as well as
a comparison to other OAM mechanisms that have been defined by the
IEEE and ITU-T.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/


No IPR declarations have been submitted directly on this I-D.

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 September 17,
2008.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Scott Bradner
yes
yes

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?
yes
no

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?
no

(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.
no

(1.e) 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?
solid (in the context of a not all that active WG list)

(1.f) 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
entered into the ID Tracker.)
no

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?
yes
yes

(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].
yes
no
no

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?
yes

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?
n/a

(1.k) 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
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.
This document presents an overview of the OAM mechanisms that have
been defined and are currently being defined by the IETF, as well as
a comparison to other OAM mechanisms that have been defined by the
IEEE and ITU-T.


Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?
There were no particular issues raised in the working group
about this document.

Document Quality
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, 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?
n/a