Skip to main content

MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking
draft-ietf-pwe3-mpls-eth-oam-iwk-08

Revision differences

Document history

Date Rev. By Action
2013-10-07
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2013-09-09
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2013-08-23
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2013-07-22
08 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2013-07-22
08 (System) RFC Editor state changed to EDIT
2013-07-22
08 (System) Announcement was received by RFC Editor
2013-07-22
08 (System) IANA Action state changed to No IC from In Progress
2013-07-22
08 (System) IANA Action state changed to In Progress
2013-07-22
08 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2013-07-22
08 Amy Vezza IESG has approved the document
2013-07-22
08 Amy Vezza Closed "Approve" ballot
2013-07-22
08 Amy Vezza Ballot approval text was generated
2013-07-22
08 Stewart Bryant Ballot writeup was changed
2013-07-15
08 Nabil Bitar New version available: draft-ietf-pwe3-mpls-eth-oam-iwk-08.txt
2013-02-21
07 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2013-02-20
07 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2013-02-19
07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-02-19
07 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2013-02-18
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2013-02-18
07 Adrian Farrel
[Ballot comment]
I am balloting No Objection on this document.  There is nothing
fundamentally wrong with the procedures or the explanation, but I
have quite …
[Ballot comment]
I am balloting No Objection on this document.  There is nothing
fundamentally wrong with the procedures or the explanation, but I
have quite a number of WIBNI-style Comments that I have set out below.
I don't think that any of them should be used to hold up the document,
but I wish that the issues could be made to go away.

---

The formatting of this I-D seems to be strange around the left margin
and the top-of-page margins.

---

Does Dinesh really still work for Nortel?
                                                                                                                                         
---

The only names in the "Authors' Addresses" section should be those on
the front page.  Other names should be moved to a new "Contributors"
section.                                                                                                                                 

---

The guidelines for writing I-Ds say that the first section in the
document should be the Introduction.

I suspect that you have put the 2119 boilerplate first because you have
use 2119 language within the Intrduction. This probably points to the
fact that the Introduction is actually far more than an introduction,
but is actually an introduciton, a problem, statement, and an overview
of the solution.

My preference would be for some restructuring work to make the
separation of material cleaner, and the document a little more
approachable, but it is a long shot to ask you to do this at the end of
a long development sysle for this work.  I would at least like you to
look again at the use of 2119 language in the Introduction.  Do you
really need it?

For example:

    When an Ethernet
    AC is an Ethernet physical port, there MAY be some application of
    Ethernet Link OAM [802.3].

Is that really a conformance rule for this specification, or just an
observation that could be written in Enlgish?

For example:

    The procedures outlined in this document define the entry and exit
    criteria for each of the four defect states with respect to
    Ethernet ACs and corresponding PWs, and the consequent actions that
    PE1 MUST support to properly interwork these defect states and
    corresponding notification messages between the PW domain and the
    Native Service (NS) domain.

The "MUST" is surely fine in plain English.

---

There seems to be a lot of duplicate material from RFC 6310. It is not
easy to tell what is new material and what has been reproduced for
reference.

On the whole, I am not a fan of reproducing material from one RFC in
another.  If any discrepency is introduced there is an immediate problem
determining which is the correct version.  My preference is to make
direct reference to the pre-existing material, rather than to reproduce
it.

Actually, I found it *really* hard to work out what material in this
document is tutorial, and what material is a new specification. In my
opinion, that really devalues this document.  It certainly made my
review less thorough because it is unclear whether text like that in
section 5.1...

    PE1 enters the AC Receive Defect state if any of the following
    conditions is met: 

...is a new definition of just commentary.

---

Does this document update RFC 6310? he distinguish factor is whether
you consider it makes sense to implement 6310 without this augmentation,
or if you consider that this document only provides additional function
for some cases such that 6310 is fine and fully functional without it.

---

Section 2
          - Ethernet Local Management Interface {E-LMI} [MEF16] 
Seems to use the wrong type of braces around E-LMI

---

You have two different meanings for "MEP" in this document.

---

The definition of MIP in Section 3.1 is surely wrong.

---

In 3.2 you say that a MIP cannot terminate an OAM frame. But I thought
that a MEP could send OAm specificially targetted at a MIP.  It
certainly can in MPLS.  Is it different in Ethernet?  Or do you have
some special meaning for "terminate".

---

In Section 4 you have "MPLS-IP PSN".  Is this what is normally called an
"IP/MPLS network" or is this a new term?  And in this context is "MPLS
PSN" meant to mean an MPLS network that has no IP support?

---

A bit of nasty passive voice has crept in to Section 4.1

    These NS OAM notifications are inserted into the corresponding PW. 

Who inserts, and where in the network?

---

In 4.2

    When PWs are established using the Label Distribution Protocol
    (LDP), LDP status notification signaling MUST be used as the
    default mechanism to signal AC and PW status and defects [RFC4447].

Is this restating 2119 language from RFC 4447, or is it making a new
specification requirement?  I'm almost at the point of a Discuss with
this question, because if the answer is "new requirement" then I think
you are probably updating a number of RFCs.  OTOH, if it is a
restatement, then you should not use 2119 language.

---

In 4.2

    For PWs established over
    an MPLS or MPLS-IP PSN using other mechanisms (e.g. static
    configuration), inband signaling using VCCV-BFD [RFC5885] SHOULD be
    used to convey AC and PW status and defects.

What are the alternatives to "SHOULD"? Please state them and note when
they can be used.

---

4.3

    When using VCCV, the control channel (CC) type and Connectivity
    Verification (CV) Type are agreed on between the peer PEs using the
    VCC parameter field signaled as a sub-TLV of the interface
    parameters TLV when using FEC 129 and the interface parameter sub-
    TLV when using FEC 128. 

This paragraph should have a citation.

Actually, I am not sure that anything in 4.3 is new material. Is it?

---

4.3
  As defined in [RFC6310], when CV type of 0x04 0r 0x10 is used to
s/0r/or/

---

It is customary and really useful to add a note at the start of an
Appendix to indicate whether the material is informative or normative.
2013-02-18
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-02-18
07 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-02-18
07 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-02-18
07 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-02-17
07 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2013-02-17
07 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-02-16
07 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms
2013-02-16
07 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-02-15
07 David Black Request for Telechat review by GENART Completed: Ready. Reviewer: David Black.
2013-02-14
07 Jean Mahoney Request for Telechat review by GENART is assigned to David Black
2013-02-14
07 Jean Mahoney Request for Telechat review by GENART is assigned to David Black
2013-02-14
07 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2013-02-12
07 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-02-08
07 Stewart Bryant Placed on agenda for telechat - 2013-02-21
2013-02-08
07 Stewart Bryant State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2013-02-08
07 Stewart Bryant Ballot has been issued
2013-02-08
07 Stewart Bryant [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant
2013-02-08
07 Stewart Bryant Created "Approve" ballot
2013-02-08
07 Stewart Bryant Ballot writeup was changed
2013-01-30
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-01-30
07 Nabil Bitar New version available: draft-ietf-pwe3-mpls-eth-oam-iwk-07.txt
2012-08-31
06 Stewart Bryant State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead
2012-08-21
06 Samuel Weiler Request for Last Call review by SECDIR Completed: Ready. Reviewer: Steve Hanna.
2012-08-21
06 David Black Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: David Black.
2012-08-20
06 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-08-16
06 Pearl Liang
IANA has reviewed draft-ietf-pwe3-mpls-eth-oam-iwk-06, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there …
IANA has reviewed draft-ietf-pwe3-mpls-eth-oam-iwk-06, 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.
2012-08-10
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Steve Hanna
2012-08-10
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Steve Hanna
2012-08-09
06 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2012-08-09
06 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2012-08-06
06 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (MPLS and Ethernet OAM Interworking) to …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (MPLS and Ethernet OAM Interworking) to Proposed Standard


The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'MPLS and Ethernet OAM Interworking'
  as Proposed Standard

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 2012-08-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


This document specifies the mapping of defect states between
    Ethernet Attachment Circuits (ACs) and associated Ethernet
    Pseudowires (PWs) connected in accordance to the PWE3 architecture
    to realize an end-to-end emulated Ethernet service. It standardizes
    the behavior of Provider Edges (PEs) with respect to Ethernet PW
    and AC defects.






The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth-oam-iwk/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth-oam-iwk/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1781/



2012-08-06
06 Amy Vezza State changed to Last Call Requested from None
2012-08-06
06 Stewart Bryant Last call was requested
2012-08-06
06 Stewart Bryant Ballot approval text was generated
2012-08-06
06 Stewart Bryant Ballot writeup was generated
2012-08-06
06 Stewart Bryant State changed to Publication Requested from None
2012-08-06
06 Stewart Bryant Last call announcement was changed
2012-08-06
06 Stewart Bryant Last call announcement was generated
2012-07-26
06 Cindy Morgan
(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?  …
(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?

  Standards track.

  This is appropriate as the draft describes a set of procedures for
  interworking defect notifications between Ethernet attachment circuits
  and PWs that will have interoperability implications.

  The intended status is properly indicated.

(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 specifies the mapping of defect states between
  Ethernet Attachment Circuits (ACs) and associated Ethernet
  Pseudowires (PWs) connected in accordance to the PWE3
  architecture to realize an end-to-end emulated Ethernet service.
  It standardizes the behavior of Provider Edges (PEs) with
  respect to Ethernet PW and AC defects.


Working Group Summary

    Solutions for mapping OAM messages related to defect notifications from
  attachement circuits to PWs for ATM, FR, and TDM services were specified
  in RFC6310. This RFC did not cover Ethernet attachment circuits because
  of a perception at the time that Ethernet OAM mechanisms were less widely
  deployed and their standardization was on-going. The WG decided to handle
  the Ethernet case in a separate draft. This was considered to be an important
  work item by the PWE3 working group, and there were a number of requests to
  roll this working into the draft that became RFC6310. However, ultimately the
  consensus was to progress the Ethernet case separately to not further delay RFC6310.

  The document received two working group last calls, the second as a result of IPR
  declaration 1781. The second WG last call resulted in the security section being
  improved, but no issues were raised about the IPR declaration.

Document Quality

  Previous PW deployment surveys (see
  draft-ietf-pwe3-pw-vccv-impl-survey-results-00) have indicated that the
  majority of PWs are Ethernet, and therefore standardizing the interworking
  of defect notifications for emulated Ethernet services is expected to be
  of significant interest to the IETF and the operator community in general.
  There are believed to be numerous implementations and deployments of Ethernet
  OAM mechanisms referred to in this draft, including cases where the Ethernet
  service is supported over PWs and where OAM interworking is used.

  The document does not specify any MIB changes or additions which would need review.



Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@alcatel-lucent.com).
  The responsible Area Director is Stewart Bryant (stbryant@cisco.com).

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

  The document shepherd reviewed the document and provided detailed technical
  and editorial comments. This were addressed by the authors before progressing
  the draft.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns. The document has received adequate review. The document has
        received significant review by the WG over a number of years and
        received a number
        of comments during WG last call.

(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 further review required.

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

  No specific concerns.

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

  Each author listed in the Authors Addresses section has indicated that
  they are not aware of any IPR that has not been declared in accordance
  with BCP 78 and 79.

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

  There is one IPR declaration (1781) that was made after the original WG last call.
  The document was given a second WG last call as a result of this. There were no issues
  raised as a result of this.

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

    I am comfortable that the document represents WG consensus and has
      been reviewed by a reasonable number of active WG participants. It has been
      discussed over a period of a number of years, both in face to face IETF meetings
      and on the list. It has also been through two working group last calls with comments
      raised at each.

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

  None indicated.

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

      Yes. There is one I-D nits warning related to some pages with too many lines.
      This results in I-D Nits generating an  additional false comments.
      There are also a few spelling or gramatical errors.
      These should be fixed before publication.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no relevant formal review criteria.

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

  There is a downward normative reference to the published MetroEthernet Forum
  specification MEF16. It is reasonable to require conformance to MEF16 for any
  interworking between PW OAM and MEF16.

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

  This document does not change the status of any existing RFCs.

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

  There are no IANA actions.

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

  There are no IANA actions.

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

  There are no sections containing formal language that needs reviewing.

2012-07-26
06 Cindy Morgan Note added 'Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.'
2012-07-26
06 Cindy Morgan Intended Status changed to Proposed Standard
2012-07-26
06 Cindy Morgan IESG process started in state Publication Requested
2012-07-26
06 (System) Earlier history may be found in the Comment Log for draft-mohan-pwe3-mpls-eth-oam-iwk
2012-07-26
06 Matthew Bocci Annotation tag Doc Shepherd Follow-up Underway cleared.
2012-07-26
06 Matthew Bocci Changed protocol writeup
2012-07-26
06 Matthew Bocci IETF state changed to Submitted to IESG for Publication from In WG Last Call
2012-07-26
06 Matthew Bocci Annotation tag Other - see Comment Log cleared.
2012-07-16
06 Matthew Bocci
draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the …
draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt

Document Shepherd Write-Up

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

  Standards track.
 
  This is appropriate as the draft describes a set of procedures for
  interworking defect notifications between Ethernet attachment circuits
  and PWs that will have interoperability implications.
 
  The intended status is properly indicated.

(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 specifies the mapping of defect states between
  Ethernet Attachment Circuits (ACs) and associated Ethernet
  Pseudowires (PWs) connected in accordance to the PWE3
  architecture to realize an end-to-end emulated Ethernet service.
  It standardizes the behavior of Provider Edges (PEs) with
  respect to Ethernet PW and AC defects.


Working Group Summary

    Solutions for mapping OAM messages related to defect notifications from
  attachement circuits to PWs for ATM, FR, and TDM services were specified
  in RFC6310. This RFC did not cover Ethernet attachment circuits because
  of a perception at the time that Ethernet OAM mechanisms were less widely
  deployed and their standardization was on-going. The WG decided to handle
  the Ethernet case in a separate draft. This was considered to be an important
  work item by the PWE3 working group, and there were a number of requests to
  roll this working into the draft that became RFC6310. However, ultimately the
  consensus was to progress the Ethernet case separately to not further delay RFC6310.
 
  The document received two working group last calls, the second as a result of IPR
  declaration 1781. The second WG last call resulted in the security section being
  improved, but no issues were raised about the IPR declaration.

Document Quality

  Previous PW deployment surveys (see
  draft-ietf-pwe3-pw-vccv-impl-survey-results-00) have indicated that the
  majority of PWs are Ethernet, and therefore standardizing the interworking
  of defect notifications for emulated Ethernet services is expected to be
  of significant interest to the IETF and the operator community in general.
  There are believed to be numerous implementations and deployments of Ethernet
  OAM mechanisms referred to in this draft, including cases where the Ethernet
  service is supported over PWs and where OAM interworking is used.

  The document does not specify any MIB changes or additions which would need review.

 
 
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@alcatel-lucent.com).
  The responsible Area Director is Stewart Bryant (stbryant@cisco.com).

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

  The document shepherd reviewed the document and provided detailed technical
  and editorial comments. This were addressed by the authors before progressing
  the draft.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns. The document has received adequate review. The document has
        received significant review by the WG over a number of years and
        received a number
        of comments during WG last call.

(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 further review required.

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

  No specific concerns.

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

  Each author listed in the Authors Addresses section has indicated that
  they are not aware of any IPR that has not been declared in accordance
  with BCP 78 and 79.

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

  There is one IPR declaration (1781) that was made after the original WG last call.
  The document was given a second WG last call as a result of this. There were no issues
  raised as a result of this.
 
(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?

    I am comfortable that the document represents WG consensus and has
      been reviewed by a reasonable number of active WG participants. It has been
      discussed over a period of a number of years, both in face to face IETF meetings
      and on the list. It has also been through two working group last calls with comments
      raised at each.

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

  None indicated.

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

      Yes. There is one I-D nits warning related to some pages with too many lines.
      This results in I-D Nits generating an  additional false comments.
      There are also a few spelling or gramatical errors. 
      These should be fixed before publication.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no relevant formal review criteria.

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

  There is a downward normative reference to the published MetroEthernet Forum
  specification MEF16. It is reasonable to require conformance to MEF16 for any
  interworking between PW OAM and MEF16.

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

  This document does not change the status of any existing RFCs.

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

  There are no IANA actions.

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

  There are no IANA actions.

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

  There are no sections containing formal language that needs reviewing.
2012-07-16
06 Cindy Morgan New version available: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt
2012-05-16
05 Matthew Bocci IETF state changed to In WG Last Call from Submitted to IESG for Publication
2012-05-14
(System) Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-pwe3-mpls-eth-oam-iwk-05
2012-04-18
05 Matthew Bocci IETF state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2012-04-18
05 Matthew Bocci Annotation tag Other - see Comment Log set. Annotation tag Awaiting Expert Review/Resolution of Issues Raised cleared.
2012-04-16
05 Matthew Bocci Returned for second WG last call after Cisco IPR declaration 1781.
2012-04-16
05 Matthew Bocci Doc shepherd write up complete and publication requested. Awaiting confirmation of any IPR (none so far declared) from authors.
2012-04-16
05 Anabel Martinez New version available: draft-ietf-pwe3-mpls-eth-oam-iwk-05.txt
2011-09-03
04 (System) Document has expired
2011-06-10
04 Matthew Bocci IETF state changed to Waiting for WG Chair Go-Ahead from WG Document
2011-06-10
04 Matthew Bocci Reviews requested from two experts in this area. Document shepherd will also provide detailed review. Deadline is 10th June 2011.
2011-06-10
04 Matthew Bocci Annotation tag Awaiting Expert Review/Resolution of Issues Raised set.
2011-03-02
04 (System) New version available: draft-ietf-pwe3-mpls-eth-oam-iwk-04.txt
2010-07-12
03 (System) New version available: draft-ietf-pwe3-mpls-eth-oam-iwk-03.txt
2010-03-11
02 (System) New version available: draft-ietf-pwe3-mpls-eth-oam-iwk-02.txt
2009-10-26
01 (System) New version available: draft-ietf-pwe3-mpls-eth-oam-iwk-01.txt
2009-03-02
00 (System) New version available: draft-ietf-pwe3-mpls-eth-oam-iwk-00.txt