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 |