Subject: [OPSAWG] AD review of draft-ietf-opsawg-mpls-tp-oam-def

From: Adrian Farrel <[email-masked]>
Date: Fri, 18 Jun 2010 00:40:37 +0100

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

---

From: Scott Mansfield <[email-masked]>
Date: Mon, 21 Jun 2010 11:33:49 -0400

If all the authors agree, I'm willing to spin another draft.

Please see my comment in-line. 

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

<scott>  New abstract...

This document provides a definition of the acronym OAM (Operations, Administration, and Maintenance) for use in MPLS Transport Profile (MPLS-TP) documents.  The intention is to use this definition for all future IETF documents.

> Doesn't that make this document a BCP?

<scott>
The intention of the document was to support the MPLS-TP effort, but also have wider applicability.  From the previous comments (last spin of document) it was clear that the authors wanted the information used in this document to be available (and applicable) for use in all IETF documents that require the use of the term OAM.

If this is too strong of a statement, we need to tone down the abstract.  Thoughts?

> 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:
> 

<scott>
I suggest we accept this change.

> 2.1.  OAM as a Functional Unit

<scott>
I suggest we accept this change.

> Can you add a reference for this assertion?

<scott>
Add a reference to MEF 17
I suggest we accept this change

> Do you have any references for this?

<scott>
I suggest we take out "seems like" and leave the rest of the sentence or delete the sentence.  Thoughts?

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

<scott>
Your analysis of the paragraph is correct.  I suggest accepting the new text.

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

<scott>
I suggest accepting this change and ensuring consistency throughout the document.  Actually...
A change to Section 1 is needed if we want to use "Operations, Administration, and Maintenance", because that format isn't listed.

> 
> ---
> 
> Section 3
> 
> OLD
>    OAM tools and protocols and the "Management space" are 
> complementary NEW

<scott>
I suggest we accept this change.

>    i.e., between management stations and network elements.

<scott>
I suggest we accept this change

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

<scott>
Efficiently is fine with me.  Neither word is very precise, but I think "efficient" matches the "corrective and preventive measures" better than "effective".

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

<scott>
I suggest we accept this change

> Secondly, doesn't OAM also keep the network in a state that 
> can support provisioning new services?

<scott>
Well...  The distinction is between OAM and OAM&P.  Based on our definition, the distinction between setting up new services and monitoring/maintaining existing services is one of the reasons 'provisioning' is considered out of scope when defining OAM.

I suggest we make your editorial change.  Other clarifications are welcome...

>    therefore, a benefit for future stability of specifications.

<scott>
I suggest we accept the change

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

<scott>
Looking for input here...
Kam Lam and Dieter Beller  (others?)

Regards,
-scott.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Jun 2010 10:12:08 +0200

OK with me. See a few detail level comments in-line. 

Regards, 

Dan
(speaking as a co-author)

> -----Original Message-----
> From: Scott Mansfield [mailto:[email-masked]] 
> Sent: Monday, June 21, 2010 6:34 PM
> To: Adrian Farrel; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [OPSAWG] AD review of draft-ietf-opsawg-mpls-tp-oam-def
> 
> 
> 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.
> > 
> 
> <scott>  New abstract...
> 
> This document provides a definition of the acronym OAM 
> (Operations, Administration, and Maintenance) for use in MPLS 
> Transport Profile (MPLS-TP) documents.  The intention is to 
> use this definition for all future IETF documents.
> 

s/all future IETF documents/all future IETF documents when appropriate/

> The intention of the document was to support the MPLS-TP 
> effort, but also have wider applicability.  From the previous 
> comments (last spin of document) it was clear that the 
> authors wanted the information used in this document to be 
> available (and applicable) for use in all IETF documents that 
> require the use of the term OAM.
> 

I believe that with the change I suggest above (adding 'when
appropriate') the text is toned down enough, but there may be other
opinions. 

> >    The Metro Ethernet Forum refers to OAM as the tools and 
> utilities 
> > to
> I suggest we take out "seems like" and leave the rest of the 
> sentence or delete the sentence.  Thoughts?

I suggest that we just leave 'The A in the OAM acronym mostly stands for
"Administration" and drop the rest. 

> > In this case, OAM is a subset of Management, so O&M means 
> "a subset of 
> > Management and Management."
> > 
> paragraph I 
> A change to Section 1 is needed if we want to use 
> "Operations, Administration, and Maintenance", because that 
> format isn't listed.
> 
> > 
> > ---
> > 
> > Section 3
> > 
> > OLD
> Efficiently is fine with me.  Neither word is very precise, 
> but I think "efficient" matches the "corrective and 
> preventive measures" better than "effective".
> 
> > 
> > ---
> > 
> > Section 3
> > 
> >    providing new services, whereas OAM is used to keep the 
> network in 
> > a
> > Secondly, doesn't OAM also keep the network in a state that can 
> > support provisioning new services?
> 
> <scott>
> Well...  The distinction is between OAM and OAM&P.  Based on 
> our definition, the distinction between setting up new 
> services and monitoring/maintaining existing services is one 
> of the reasons 'provisioning' is considered out of scope when 
> defining OAM.
> 

Seems clear enough to me (with the accepted edit). 

> >    use of the OAM acronym, and the security concerns are, 
> therefore, 
> > out
> >    of scope.
> > 
> >    use of the OAM acronym, and the security concerns are, 
> therefore, 
> > out
> >    of scope.
> > NEW
> >    Misunderstanding of an acronym may lead to incorrect 
> specification 
> > or
> useful review 

Adding the names to the acknowledgments section would be fine.

---

From: Loa Andersson <[email-masked]>
Date: Tue, 22 Jun 2010 11:27:12 +0200

I'm OK with most of this; even with the change to BCP,
though I'm not sure about the procedural implications,
a BCP requires an IETF last call, doesn't it? And the
wg should have a chance to express its opinion.

Nevertheless if that is what it takes to have an BCP
I'm OK with that.

/Loa

On 2010-06-21 17:33, Scott Mansfield wrote:
>> utilities to
>> network in a
>> therefore, out
>> therefore, out
>> specification or
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Jun 2010 11:37:14 +0200

I do not know what Adrian's plans are as Sponsoring AD, but I would say
that doing an IETF LC would be a good thing anyway because of the wide
implication of the OAM terminology. 

I am not crazy about going to BCP, although I do not see harm either -
just maybe overkill for a terminology document. 

Dan
(speaking as co-author)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Tuesday, June 22, 2010 12:27 PM
> To: Scott Mansfield
> Cc: [email-masked]; 
> Adrian Farrel; [email-masked]
> Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-mpls-tp-oam-def
> 
> I'm OK with most of this; even with the change to BCP, though 
> I'm not sure about the procedural implications, a BCP 
> requires an IETF last call, doesn't it? And the wg should 
> have a chance to express its opinion.
> 
> Nevertheless if that is what it takes to have an BCP I'm OK with that.
> 
> /Loa
> 
> >> 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 
> >> 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 Metro Ethernet Forum refers to OAM as the tools 
> and utilities 
> >> to
> > I suggest we take out "seems like" and leave the rest of 
> the sentence or delete the sentence.  Thoughts?
> >
> >
> >
> >>
> >> Section 2.2.3
> >>
> "a subset 
> >>     providing new services, whereas OAM is used to keep 
> the network 
> >> in a
> > Well...  The distinction is between OAM and OAM&P.  Based 
> on our definition, the distinction between setting up new 
> >> 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).
> >>
> >
> > <scott>
>                                               +46 767 72 92 
> 13 _______________________________________________
> OPSAWG mailing list
> [email-masked]

---

From: Adrian Farrel <[email-masked]>
Date: Tue, 22 Jun 2010 14:31:34 +0100

Hi Scott,

Mainly snipped...

> New abstract...
> This document provides a definition of the acronym OAM (Operations,
> Administration, and Maintenance) for use in MPLS Transport Profile
> (MPLS-TP) documents.  The intention is to use this definition for all
> future IETF documents.

This food can be used for Scott's lunch. It can also be used to end world 
hunger.

I think you have your pririties the wrong way around :-)

This document provides a definition of the acronym OAM (Operations, 
Administration, and Maintenance) for use in all future IETF documents that 
refer to OAM. In particular, it will be applied in all MPLS Transport 
Profile (MPLS-TP) documents.

>> Section 1
>>
>> You say:
>>
>>    It is
>>    understood that all future IETF documents will use these
>>    definitions when appropriate.
>>
> The intention of the document was to support the MPLS-TP effort, but
> also have wider applicability.  From the previous comments (last spin of
> document) it was clear that the authors wanted the information used in
> this document to be available (and applicable) for use in all IETF
> documents that require the use of the term OAM.
>

Per my previous, this is a fine purpose and I think it has overtaken the 
MPLS-TP purpose.

I suggest deleting this sentence which, since it includes "when 
appropriate", does not add anything.

> I suggest we take out "seems like" and leave the rest of the sentence or 
> delete
> the sentence.  Thoughts?

Taking out "seems like" is good.
Amybe taking out "also" as well, because it is not used "as well."

I think that still leaves you short of a reference for "in a few cases 
'Accounting' is used"

You don't need to list them all, but adding "(for example, [xxx])" would be 
nice.

> A change to Section 1 is needed if we want to use "Operations,
> Administration, and Maintenance", because that format isn't listed.

If you need an example for your list of references...
RFC 5860

> Efficiently is fine with me.  Neither word is very precise, but I think
> "efficient" matches the "corrective and preventive measures" better
> than "effective".

Efficient is without waste (of time, money, or materials)
Effective means that the desired result is achieved.

>>    network in a state that it can support already existing services.
>>
> our definition, the distinction between setting up new services and
> monitoring/maintaining existing services is one of the reasons
> 'provisioning' is considered out of scope when defining OAM.
>

My point was not that OAM achieved P (for that you need OAM&P).
I was trying to observe that OAM keeps resources available, or tracks the 
availability state, ready to support P.

It is not a very important point.

> Kam Lam and Dieter Beller  (others?)

If in doubt...
"Thanks to the experts of ITU-T SG15 for their review and comments."

Cheers,
Adrian

---

From: Scott Mansfield <[email-masked]>
Date: Tue, 22 Jun 2010 11:37:38 -0400

More snipping... 

I'm unclear on the desired "status" of the document.  Should we leave this document as Informational (Dan is in favor of this based on his comment (as an author))?

> I think that still leaves you short of a reference for "in a 
> few cases 'Accounting' is used"
> 
> You don't need to list them all, but adding "(for example, 
> [xxx])" would be nice.

<scott>
I like Dan's suggestion here to remove the note about Accounting altogether...

> If you need an example for your list of references...

Thanks, this is useful

> > Efficiently is fine with me.  Neither word is very precise, but I 
> > think "efficient" matches the "corrective and preventive measures" 
> > better than "effective".
> 

<scott>
My affect has been effected efficiently....  Effectively it is...

> "Thanks to the experts of ITU-T SG15 for their review and comments."

Other than Kam and Dieter , I am "in doubt".  So I will add the "Thanks....

---

From: Loa Andersson <[email-masked]>
Date: Tue, 22 Jun 2010 17:42:35 +0200

On 2010-06-22 17:37, Scott Mansfield wrote:
<snip>
> I like Dan's suggestion here to remove the note about Accounting altogether...
i won't object to that

/Loa

<snip to the end>

--

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jun 2010 10:57:30 +0200

> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Tuesday, June 22, 2010 4:32 PM
> To: Scott Mansfield; 
> This food can be used for Scott's lunch. It can also be used 
> to end world hunger.
> 
> (Operations, Administration, and Maintenance) for use in all 
> future IETF documents that refer to OAM. In particular, it 
> will be applied in all MPLS Transport Profile (MPLS-TP) documents.
> 
> >> Section 1
> >>
> >> You say:
> >>
> >>    It is
> effort, but 
> > also have wider applicability.  From the previous comments 
> (last spin 
> > of
> > If this is too strong of a statement, we need to tone down 
> the abstract. 
> > Thoughts?
> 
> Per my previous, this is a fine purpose and I think it has 
> overtaken the MPLS-TP purpose.
> 
> I suggest deleting this sentence which, since it includes 
> "when appropriate", does not add anything.
> 

As a co-author I have no problem with the priorities as described and
reworded by the shepherding AD. 

Dan

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 24 Jun 2010 02:15:00 +0100

Scott,

I can live with Informational if it has been thought through by the authors.

A
----- Original Message ----- 
From: "Scott Mansfield" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 22, 2010 4:37 PM
Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-mpls-tp-oam-def

> More snipping...
>
> I'm unclear on the desired "status" of the document.  Should we leave this 
> document as Informational (Dan is in favor of this based on his comment 
> (as an author))?
>
>
>> >> Section 2.2.2
>> >>

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 25 Jun 2010 14:38:36 +0200

All,

Sorry for the late reply.
However, I don't have any additional comments.
The text is OK for me.

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...