Guidelines for the Use of the "OAM" Acronym in the IETF
draft-ietf-opsawg-mpls-tp-oam-def-10

[Ballot comment]
I do not believe this document is necessary when the definition could be given in one sentence at the top of any document that wants to use it. I do not think this document should be BCP instead of Informational given that I don't see the harm in defining the term differently in a document that wants to use it differently (again, so long as it is appropriately defined), and I would hate to see a future document objected to because it did not use this definition, if it did so for good reasons. I do not think that this document should be trying to mandate the definition of a term IETF-wide when its original motivation was only for the MPLS arena of discussion. I do not think that silence from the non-working group portion of the IETF should have been construed as consensus to publish in this particular case, because I suspect it is just that nobody can determine that this definition is the one they like or don't like until they wish to use the term themselves. I think that this document should not have been published at all, or, barring that, as Informational with WG-only scope.

[Ballot discuss]
The Gen-ART Review by Scott Brim in 12-Apr-2011 raises some major
  concerns, but I have not seen a response.  Please provide a response
  to this review.

[Ballot discuss]
The Gen-ART Review by Scott Brim in 12-Apr-2011 raises some major
  concerns, but I have not seen a response.  Please provide a response
  to this review.

[Ballot comment]
Repagination shows that this is really just an 8 page document not the 14 that it appears. I think some pruning could usefully be done to make it even shorter.

1. What value does the long list of "wrong" OAM expansions in Section 1 serve?

2. Section 2.1 immediately lapses into a discussion of different interpretations of "OAM" in the source material of other SDOs. This has some interest in qualifying that the problem exists in other SDOs as well as in the IETF, but nothing in this section seems to have relevance to the purpose of the document or to the IETF scope. I wonder about the value of this whole section.

---

The main purpose of the document is clear from the first paragraph of the Introduction:

  The main purpose of this document is to provide a definition of the
  OAM acronym such that it is useful for the IETF.

But the document does not say *why* this objective is worthwhile.

---

Section 2.1 says:

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

This may be true, but as it stands no context or explanation is given, and so the sentence is not helpful.

---

An alternative to consider, even at this late stage, is to move the recommended acronym expansions into I-D.ietf-opsawg-oam-overview and scrap this document.

[Ballot discuss]
I do not understand why this document is necessary when the definition could be given in 1 sentence at the top of any document that wants to use it. I do not understand why this document is going for BCP instead of Informational given that I don't see the harm in defining the term differently in a document that wants to use it differently (again, so long as it is appropriately defined). I do not think that this document should be trying to mandate the definition of a term IETF-wide when its motivation is only for the MPLS arena of discussion. I do not think that dead silence from the non-working group portion of the IETF should be construed as consensus to publish in this particular case, because I don't see anybody noticing that this definition is the one they like or don't like until they wish to use it. I would prefer that this document be published as Informational with WG-only scope, or simply not published at all.

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:  ("Guidelines for the use of the OAM acronym in the IETF") to BCP


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- '"Guidelines for the use of the OAM acronym in the IETF"'
  as a BCP

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

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

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

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
Hi authors,

Thanks for the work you put into generalising this document from the previous version sent to the IESG. I think you have it nearly right, but...

---

I feel that you are skirting around something here. This document is a BCP and you make some recommendations on which acronym expansions to use, but the scope of your recommendations are not clear.

Shouldn't you be more clear in:
- the Introduction
- Section 3
- Section 4
about where you expect your recommendations to be applied. I think that you have in mind that they should apply to all future IETF documents.

Curiously, the Abstract nails this perfectly, so you probably only just copy some text. I fear that if you don't the IESG will simply push back on this point, and the community may be confused as to the level of guidance/imperative that you are applying.

---

Should not use "draft" in the text. Suggest changing it to "document".

---

Although these are both small points and don't change the document significantly (i.e. no further WG last call would be required), I think it would be helpful to revise the document before IETF last call. If you update the I-D I will start the ball rolling.

Thanks,
Adrian

The Operations Area Working Group has reached consensus on draft-ietf-opsawg-mpls-tp-oam-def and are requesting it to be published as an RFC. The RFC 4858 questions/considerations are addressed below:

1a) I will be the shepherd and I have personally reviewed the document and believe it is ready
1b) There has been adequate review both in and out of the WG
1c) I have no concerns in general, nor specifically wrt to AAA, security, XML, etc.
1d) I have no concerns about the content, and no IPR considerations have been raised
1e) There is solid consensus
1f) There has been no extreme discontent
1g) All nit's nitted
1h) no normative references, only informative
1i) The IANA consideration section exists and is consistent
1h) There is no need for formal language
1k)
Technical Summary
At first glance the acronym "OAM" seems to be well known and well
understood. Looking at the acronym a bit more closely reveals a set
of recurring problems that are revisited time and again.

This document provides a definition of the acronym OAM (Operations,
Administration, and Maintenance) for use in all future IETF documents
that refer to OAM. There are other definitions and acronyms that
will be discussed while exploring the definition of the constituent
parts of the OAM term.

Working group summary:
There was nothing noteworthy in the working group process

Document quality:
The document does not identify any protocol or implementable system. It sets out an agreed upon taxonomy for the OAM and O&M terms.

Any questions, please don't hesitate to contact me in the first instance, or Scott.

Chris

This draft passed working group and IETF last call and has been discussed by the IESG. During the IESG evaluation a question was raised about the scope of the document. In particular, the authors were asked to clarify whether this document was intended to apply to all uses of the OAM acronym in the IETF, or whether it was strictly limited to the use of OAM in the MPLS-TP work. The IESG felt that the current document text attempts to strongly influence the IETF-wide behavior while being an Informational document that describes the use of the acronym in the MPLS-TP project. The IESG considered this to be sitting on the fence and asked the authors to polarise the document one way or the other.

Either change would be a considerable modification to the text that would be larger than reasonable at this stage in the publication process.

Consequently, I am returning the document to the working group. I understand that the authors have decided on the way they wish to take the document forward, and I look forward to seeing a new publication request in the near future.

[Ballot comment]
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"

[Ballot discuss]
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.

[Ballot comment]
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?

[Ballot discuss]
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.

[Ballot comment]
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" ?

AD Review

Hi,

Don't panic!

Because Ron and Dan are co-authors of this I-D, I have picked up the
job of "responsible AD" for this document.

Below is my AD review. The purpose of my review is to catch issues
that might be raised in IETF last call and IESG review.

I found the document to be solid, and my concerns are relatively
minor. My comments are not mandatory to fix; they are open for
discussion, but if you agree to my proposals, I would appreciate a
revised I-D.

I have moved the document into the DataTracker state
AD-Evaluation:Revise-ID-Needed

Thanks,
Adrian

===

Abstract

  The immediate goal of this document is to find an understanding of
  the OAM acronym that is useful for MPLS.  This document is
  specifically applicable to the new OAM functionality developed for
  the MPLS Transport Profile (MPLS-TP) project.  However, broader
  applicability of the definitions in this document may also come to
  light, e.g. the intention is to use these definitions for all future
  IETF documents.

I think that this text was fine while the draft was being developed, but
it now needs to be reshaped to be appropriate for an RFC. That is, the
document should provide an acronym, not set a goal of finding an
understanding. And any broader applicability should not be left to "come
to light", but should be stated in the document.

---

Section 1

You say:

  It is
  understood that all future IETF documents will use these definitions
  when appropriate.

This sounds like you are asking to impose these definitions on the IETF.
Doesn't that make this document a BCP?

---

Section 1

  The examples below show a number of different ways that the OAM
  acronym could be expanded and understood.

This use of "could" implies some form of legitimacy. I don't think you
want to make that implication. It may be better to say:

  The examples below show a number of different ways that the OAM
  acronym has been expanded in previous documents.

---

Could you go through and capitalise the section headings. For example,

2.1.  OAM as a Functional Unit

---

Section 2.1

  The Metro Ethernet Forum refers to OAM as the tools and utilities to
  install, monitor and troubleshoot a network, helping carriers run
  their networks more efficiently.

Can you add a reference for this assertion?

---

Section 2.2.2

  The A in the OAM acronym mostly stands for "Administration", though
  in a few cases it seems like "Accounting" is also used.

Does it "seem like" Accounting is used, or is it used?
Do you have any references for this?

---

Section 2.2.3

  Since Maintenance and Management are defined as two different
  activities it does not seem to be a good idea to use them
  interchangeably.  The concept behind OAM is management, so it makes
  more sense to use maintenance as the expansion of the "M" in the
  acronym.

You say that Maintenance and Management are defined as different
activities, but you don't give the definitions!

I cannot follow the logic here. Because the concept behind OAM is
management, it makes sense for the M to be expanded to not mean
management.

I guess that you are saying that the whole of the acronym OAM refers
to management. Therefore, you are saying, expanding M to mean
management would be tautology.

Am I right? Is there a way you can make the second sentence clearer?

If I am right, how does the last paragraph of Section 3 and Section 4
make sense when it says:

  O&M - OAM and Management

In this case, OAM is a subset of Management, so O&M means "a subset
of Management and Management."

I think this is all most simply resolved by replacing the paragraph I
quoted as:

OLD
  Since Maintenance and Management are defined as two different
  activities it does not seem to be a good idea to use them
  interchangeably.  The concept behind OAM is management, so it makes
  more sense to use maintenance as the expansion of the "M" in the
  acronym.
NEW
  Maintenance and Management may have different interpretations.
  Maintenance is defined further in Section 3, while Management is a
  broader term applicable to many functions applied to the network as
  described in Section 3.

  Since these terms have different interpretations, it is not a good
  idea to use them interchangeably.  This document defines the "M" in
  the OAM acronym to mean Maintenance.

---

Section 3 and Section 4

Please make sure that you use:

"Operations, Administration, and Maintenance"

I.e. include the comma before "and".

This achieves consistency with comments made during review of MPLS-TP
documents as they went through the process (and also seems to be
correct house style for the RFC Editor).

---

Section 3

OLD
  OAM tools and protocols and the "Management space" are complementary
NEW
  OAM tools and protocols, and the "Management space" are complementary

---

Section 3

  From an architecture point of view OAM protocols and tools deployed
  in the data plane tend to be "horizontal" i.e. network element to
  network element while the management protocols tend to be "vertical".

This is quite hard to parse.

How about:

  From an architecture point of view OAM protocols and tools deployed
  in the data plane tend to be "horizontal", i.e., network element to
  network element. The management protocols tend to be "vertical",
  i.e., between management stations and network elements.

---

Section 3

In the definition of Maintenance, do you mean "efficiently" or
"effectively"?

---

Section 3

  Even though "Provisioning" is not included in this document, the
  following definition is provided for completeness.

Hmmm. That makes it look like "Provisioning" *is* included in this
document. Perhaps you could say...

  "Provisioning" is outside the scope of this document, but the
  following definition is provided for completeness.

---

Section 3

  In general, Provisioning is used to configure the network for
  providing new services, whereas OAM is used to keep the network in a
  state that it can support already existing services.

This is a little off, I think.
Firstly s/for providing/to provide/
Secondly, doesn't OAM also keep the network in a state that can support
provisioning new services?

---

Section 6

This is a bit confused.

  Security is a significant requirement of MPLS-TP.  However, this
  informational document is intended only to provide guidance on the
  use of the OAM acronym, and the security concerns are, therefore, out
  of scope.

This document is not limited to MPLS-TP and is not specific to MPLS-TP.
The first sentence is not relevant!

How about replacing the paragraph as:

OLD
  Security is a significant requirement of MPLS-TP.  However, this
  informational document is intended only to provide guidance on the
  use of the OAM acronym, and the security concerns are, therefore, out
  of scope.
NEW
  This document provides guidance for the use of the OAM acronym in
  other documents. It has not direct security implications.

  Misunderstanding of an acronym may lead to incorrect specification or
  implementation which may, in turn, open up security concerns with
  protocols or deployed networks. Clarifying the meaning of OAM is,
  therefore, a benefit for future stability of specifications.

---

Section 7

I think it might be nice to either generally mention the useful review
and feedback you received from the experts of SG15, or to specifically
name them (I think it was Kam and Dieter).

(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?
not too much discussion but reasonable support shown

(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

(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].
only has informative references

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

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?

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?

writeup

Technical Summary
This document provides a definition of the acronym "OAM" as relating to
MPLS. However, the definition is not specific to MPLS and the
definition can be more broadly applied.

Working Group Summary
This document is a product of the opsawg. The draft was presented at
opsawg sessions at IETF meetings and discussed on the opsawg mailing
list. The WG supports its publication as an informational RFC.

Document Quality
The WG last call for this draft was copied to a number of other IETF
working groups and to groups within the ITU-T. The document was revised
based on the comments received from both sources.