Guidelines for the Use of the "OAM" Acronym in the IETF
RFC 6291

Note: This ballot was opened for revision 10 and is now closed.

(David Harrington) Discuss

Discuss (2010-08-19 for -)
1) I found the purpose of this document to be rather muddled. In the Abstract,, it says "This document provides a definition ... for use in all future IETF documents that refer to OAM." 

The Introduction says "The main purpose of this document is to provide a definition ... that is useful for MPLS."

I object to the text that says this document provides a definition for use in all future IETF documents.

•The IETF as a whole does not have consensus on the technical approach or document. There are cases where individual working groups or areas have forged rough consensus around a technical approach which does not garner IETF consensus. An AD may DISCUSS a document where she or he believes this to be the case. While the Area Director should describe the technical area where consensus is flawed, the focus of the DISCUSS and its resolution should be on how to forge a cross-IETF consensus."

I suggest that if we want to define new terminology for all future IETF documents that discuss OAM, then the title should be changed to "New Required Terminology for Referencing OAM in IETF Documents" and make it a Proposed Standard.

Otherwise, this is an Informational document that provides a definition of OAM for use in MPLS-TP documents. Other IETF documents MAY choose to use the same definition when discussing OAM. I think the title should be changed to be clear about the purpose and scope of the applicability of this document.

2) As evidenced by the emails we've had recently on the iesg list, I have concerns that this document doesn't offer that much clarity for OAM+P+M.
I'm not convinced this is ready for standards-track, because I think it is not clear and unambiguous.

The issue of ambiguity in the term OAM has been around for a long time, because the terms "operations" and "administration" and "maintenance" are themselves ambiguous. I am not certain how to fix the problem.

However, at a minimum, the document should make sure that the tasks discussed as examples under operations, and under admin, and under maintenance, and under provisioning, and under management do not overlap, and the definitions of O,A,M,P,and mgt should not overlap. While the tasks may legitimately belong under multiple categoris, the document should at least try to separate which aspects of the task belong to which category.

The current document does not do that well.
Comment (2010-08-19 for -)
No email
send info
I think this document should clearly seoarate what exists in practice across SDOs and what will be the new IETF-wide standard for use of these acronymns. I find it unclear about where section 2 falls on this point. Section 3 and 4 define terminology for the MPLS-TP effort, but the section titles limit it to the MPLS-TP effort, and the Informational status of the document makes this less than a standard.

2) Various flavors of OAM from multiple SDOs have started coming into play. If the document provides a definition for use in all future IETF documents that refer to OAM, are the other SDOs agreeing to use the ***SAME*** definition in all their future documents as well? If not, then I think it highly likely that future IETF documents that deal with cross-SDO OAM are likely to have the same problem we face now with MPLS-TP. 

3) "The ITU documents also clearly define a maintenance philosophy." - Does this mean that the IETF hereby adopts the same maintenance philosophy for all future IETF documents? or for MPLS-TP efforts? I don't think the IETF has agreed to that. Are the documents that define this maintenance philosophy freely available?

4) I am not crazy about "Mgt" as the abbreviation for management. A google search shows 1.6M hits for "network Mgt"  but 3.2m hits for "network mgmt"

(Adrian Farrel) Yes

Comment (2011-05-15)
No email
send info
All comments addressed in latest revision

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

Comment (2010-07-12 for -)
No email
send info
I am not sure that "ambivalence" is the right word:

However there is some ambivalence in the definition and scope of the
term "Operation".

Did the authors mean "ambiguity" ?

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

Lars Eggert No Objection

(Stephen Farrell) No Objection

(Russ Housley) (was Discuss, No Objection) No Objection

Comment (2010-07-12)
No email
send info
Please consider the editorial comments in the Gen-ART Review by
  Francis Dupont on 2010-07-01.

(Tim Polk) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection

(Pete Resnick) (was Discuss) Abstain

(Ron Bonica) Recuse

(Dan Romascanu) Recuse