Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network
draft-ietf-ccamp-gmpls-otn-b100g-applicability-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2023-03-29
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2023-02-28
|
15 | (System) | RFC Editor state changed to AUTH48 |
2023-02-19
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2022-12-05
|
15 | (System) | RFC Editor state changed to EDIT |
2022-12-05
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-12-05
|
15 | (System) | Announcement was received by RFC Editor |
2022-12-05
|
15 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2022-12-05
|
15 | (System) | IANA Action state changed to In Progress |
2022-12-05
|
15 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-12-05
|
15 | Cindy Morgan | IESG has approved the document |
2022-12-05
|
15 | Cindy Morgan | Closed "Approve" ballot |
2022-12-05
|
15 | Cindy Morgan | Ballot approval text was generated |
2022-12-05
|
15 | John Scudder | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2022-12-01
|
15 | (System) | Removed all action holders (IESG state changed) |
2022-12-01
|
15 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2022-12-01
|
15 | Cindy Morgan | Changed consensus to Yes from Unknown |
2022-12-01
|
15 | Andrew Alston | [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston |
2022-11-30
|
15 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2022-11-29
|
15 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2022-11-29
|
15 | Roman Danyliw | [Ballot comment] (revised ballot to correctly acknowledge the SECDIR reviewer; thanks to Rob Wilton for pointing it out) Thank you to David Mandelberg for the … [Ballot comment] (revised ballot to correctly acknowledge the SECDIR reviewer; thanks to Rob Wilton for pointing it out) Thank you to David Mandelberg for the SECDIR review. ** Section 8. As the premise of this document appears be around applicability to [ITU-T_G709_2020], it seems that relationship should be explicitly described in the Security Considerations. Consider: OLD This document analyses and reuses the protocol extensions in [RFC7138] and [RFC7139] without introducing any new extensions. Therefore, this document introduces no new security considerations to the existing signalling protocol and routing protocol comparing to [RFC7138] and [RFC7139]. NEW This document analyzed the applicability of protocol extensions in [RFC7138] and [RFC7139] for use in the 2020 version of G.709 [ITU-T_G709_2020] and found that no new extensions are needed. Therefore, this document introduced no new security considerations to the existing signaling and routing protocols beyond those already described in [RFC7138] and [RFC7139]. |
2022-11-29
|
15 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2022-11-29
|
15 | Robert Wilton | [Ballot comment] Thanks to Joe Clarke for the OPSDIR review. |
2022-11-29
|
15 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2022-11-28
|
15 | Éric Vyncke | [Ballot comment] As I am not an expert on GMPLS at all, I can only have high-level comments. The draft explains in length in section … [Ballot comment] As I am not an expert on GMPLS at all, I can only have high-level comments. The draft explains in length in section 3 how OTN next generation could work. The only part that is relevant to the IETF appears to be the 1-page section 4.2 (which basically writes "all is good for now"). While I am unsure about the added value of this document (again I am *not* an expert on this topic by far), if the CCAMP WG wants to publish this document and as I trust the AD and doc shepherd, then it is of course fine. Before publication, please fix the authors' section as it has an unusual format. |
2022-11-28
|
15 | Éric Vyncke | Ballot comment text updated for Éric Vyncke |
2022-11-28
|
15 | Éric Vyncke | [Ballot comment] As I am not an expert on GMPLS at all, I can only have high-level comments. The draft explains in length in section … [Ballot comment] As I am not an expert on GMPLS at all, I can only have high-level comments. The draft explains in length in section 3 how OTN next generation could work. The only part that is relevant to the IETF appears to be the 1-page section 4.2 (which basically writes "all is good for now"). While I am unsure about the added value of this document (again I am *not* an expert on this topic by far), if the CCAMP WG wants to publish this document, then it is of course fine. Before publication, please fix the authors' section as it has an unusual format. |
2022-11-28
|
15 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2022-11-26
|
15 | Joe Clarke | Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Joe Clarke. Sent review to list. |
2022-11-22
|
15 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Joe Clarke |
2022-11-22
|
15 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Joe Clarke |
2022-11-21
|
15 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2022-11-18
|
15 | Radha Valiveti | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-15.txt |
2022-11-18
|
15 | (System) | New version approved |
2022-11-18
|
15 | (System) | Request for posting confirmation emailed to previous authors: Haomian Zheng , Huub van Helvoort , Qilei Wang , Radha Valiveti , Sergio Belotti |
2022-11-18
|
15 | Radha Valiveti | Uploaded new revision |
2022-11-17
|
14 | Roman Danyliw | [Ballot comment] Thank you to Joe Clarke for the SECDIR review. ** Section 8. As the premise of this document appears be around applicability to … [Ballot comment] Thank you to Joe Clarke for the SECDIR review. ** Section 8. As the premise of this document appears be around applicability to [ITU-T_G709_2020], it seems that relationship should be explicitly described in the Security Considerations. Consider: OLD This document analyses and reuses the protocol extensions in [RFC7138] and [RFC7139] without introducing any new extensions. Therefore, this document introduces no new security considerations to the existing signalling protocol and routing protocol comparing to [RFC7138] and [RFC7139]. NEW This document analyzed the applicability of protocol extensions in [RFC7138] and [RFC7139] for use in the 2020 version of G.709 [ITU-T_G709_2020] and found that no new extensions are needed. Therefore, this document introduced no new security considerations to the existing signaling and routing protocols beyond those already described in [RFC7138] and [RFC7139]. |
2022-11-17
|
14 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2022-11-16
|
14 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2022-11-02
|
14 | Joe Clarke | Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Joe Clarke. Sent review to list. |
2022-10-25
|
14 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Joe Clarke |
2022-10-25
|
14 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Joe Clarke |
2022-10-23
|
14 | Cindy Morgan | Placed on agenda for telechat - 2022-12-01 |
2022-10-23
|
14 | John Scudder | Ballot has been issued |
2022-10-23
|
14 | John Scudder | [Ballot Position Update] New position, Yes, has been recorded for John Scudder |
2022-10-23
|
14 | John Scudder | Created "Approve" ballot |
2022-10-23
|
14 | John Scudder | IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup |
2022-10-23
|
14 | John Scudder | Ballot writeup was changed |
2022-10-20
|
14 | (System) | Changed action holders to John Scudder (IESG state changed) |
2022-10-20
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-10-20
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2022-10-20
|
14 | Radha Valiveti | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-14.txt |
2022-10-20
|
14 | (System) | New version approved |
2022-10-20
|
14 | (System) | Request for posting confirmation emailed to previous authors: Haomian Zheng , Huub van Helvoort , Qilei Wang , Radha Valiveti , Sergio Belotti |
2022-10-20
|
14 | Radha Valiveti | Uploaded new revision |
2022-10-07
|
13 | John Scudder | Hi Authors, The IETF LC has concluded and I didn't see any showstoppers. It does appear there are some outstanding edits to be done (in … Hi Authors, The IETF LC has concluded and I didn't see any showstoppers. It does appear there are some outstanding edits to be done (in the thread between the authors following up to "Opsdir last call review of draft-ietf-ccamp-gmpls-otn-b100g-applicability-11"). I also see a Genart review was provided today, which it would probably be good to respond to (and possibly act on). I'll wait for a revised version before scheduling this for IESG review. Thanks, --John |
2022-10-07
|
13 | (System) | Changed action holders to John Scudder, Huub van Helvoort, Sergio Belotti, Qilei Wang, Haomian Zheng, Radha Valiveti (IESG state changed) |
2022-10-07
|
13 | John Scudder | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2022-10-06
|
13 | Dale Worley | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list. |
2022-10-06
|
13 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2022-10-05
|
13 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2022-10-05
|
13 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-ccamp-gmpls-otn-b100g-applicability-11, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-ccamp-gmpls-otn-b100g-applicability-11, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2022-10-03
|
13 | Radha Valiveti | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-13.txt |
2022-10-03
|
13 | (System) | New version approved |
2022-10-03
|
13 | (System) | Request for posting confirmation emailed to previous authors: Haomian Zheng , Huub van Helvoort , Qilei Wang , Radha Valiveti , Sergio Belotti |
2022-10-03
|
13 | Radha Valiveti | Uploaded new revision |
2022-09-29
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2022-09-29
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2022-09-28
|
12 | Radha Valiveti | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-12.txt |
2022-09-28
|
12 | (System) | New version approved |
2022-09-28
|
12 | (System) | Request for posting confirmation emailed to previous authors: Haomian Zheng , Huub van Helvoort , Qilei Wang , Radha Valiveti , Sergio Belotti |
2022-09-28
|
12 | Radha Valiveti | Uploaded new revision |
2022-09-28
|
11 | Joe Clarke | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Joe Clarke. Sent review to list. |
2022-09-28
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2022-09-28
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2022-09-23
|
11 | David Mandelberg | Request for Last Call review by SECDIR Completed: Ready. Reviewer: David Mandelberg. Sent review to list. |
2022-09-23
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2022-09-23
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2022-09-22
|
11 | Susan Hares | Request for Early review by RTGDIR Completed: Ready. Reviewer: Susan Hares. Sent review to list. |
2022-09-22
|
11 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2022-09-22
|
11 | Cindy Morgan | The following Last Call announcement was sent out (ends 2022-10-06): From: The IESG To: IETF-Announce CC: adrian@olddog.co.uk, ccamp-chairs@ietf.org, ccamp@ietf.org, draft-ietf-ccamp-gmpls-otn-b100g-applicability@ietf.org, jgs@juniper.net … The following Last Call announcement was sent out (ends 2022-10-06): From: The IESG To: IETF-Announce CC: adrian@olddog.co.uk, ccamp-chairs@ietf.org, ccamp@ietf.org, draft-ietf-ccamp-gmpls-otn-b100g-applicability@ietf.org, jgs@juniper.net, oscar.gonzalezdedios@telefonica.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Applicability of GMPLS for Beyond 100G Optical Transport Network) to Informational RFC The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Applicability of GMPLS for Beyond 100G Optical Transport Network' as Informational RFC 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 last-call@ietf.org mailing lists by 2022-10-06. 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 examines the applicability of using existing GMPLS routing and signalling mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of G.709. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-otn-b100g-applicability/ No IPR declarations have been submitted directly on this I-D. |
2022-09-22
|
11 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2022-09-22
|
11 | Cindy Morgan | Last call announcement was generated |
2022-09-21
|
11 | John Scudder | Last call was requested |
2022-09-21
|
11 | John Scudder | Last call announcement was generated |
2022-09-21
|
11 | John Scudder | Ballot approval text was generated |
2022-09-21
|
11 | John Scudder | Ballot writeup was generated |
2022-09-21
|
11 | John Scudder | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2022-09-21
|
11 | (System) | Changed action holders to John Scudder (IESG state changed) |
2022-09-21
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-09-21
|
11 | Radha Valiveti | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-11.txt |
2022-09-21
|
11 | (System) | New version approved |
2022-09-21
|
11 | (System) | Request for posting confirmation emailed to previous authors: Haomian Zheng , Huub van Helvoort , Qilei Wang , Radha Valiveti , Sergio Belotti |
2022-09-21
|
11 | Radha Valiveti | Uploaded new revision |
2022-09-21
|
10 | John Scudder | A couple final nits to fix, see https://mailarchive.ietf.org/arch/msg/ccamp/_UzPwyHP9jkciFmElB1sm7Kl7-M/ |
2022-09-21
|
10 | (System) | Changed action holders to John Scudder, Huub van Helvoort, Sergio Belotti, Qilei Wang, Haomian Zheng, Radha Valiveti (IESG state changed) |
2022-09-21
|
10 | John Scudder | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2022-09-21
|
10 | (System) | Changed action holders to John Scudder (IESG state changed) |
2022-09-21
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-09-21
|
10 | Radha Valiveti | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-10.txt |
2022-09-21
|
10 | (System) | New version approved |
2022-09-21
|
10 | (System) | Request for posting confirmation emailed to previous authors: Haomian Zheng , Huub van Helvoort , Qilei Wang , Radha Valiveti , Sergio Belotti |
2022-09-21
|
10 | Radha Valiveti | Uploaded new revision |
2022-09-19
|
09 | John Scudder | See review sent to WG mailing list. |
2022-09-19
|
09 | (System) | Changed action holders to John Scudder, Huub van Helvoort, Sergio Belotti, Qilei Wang, Haomian Zheng, Radha Valiveti (IESG state changed) |
2022-09-19
|
09 | John Scudder | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2022-09-15
|
09 | (System) | Changed action holders to John Scudder (IESG state changed) |
2022-09-15
|
09 | John Scudder | IESG state changed to AD Evaluation from Publication Requested |
2022-08-17
|
09 | Haomian Zheng | Request for Early review by RTGDIR is assigned to Susan Hares |
2022-08-17
|
09 | Haomian Zheng | Request for Early review by RTGDIR is assigned to Susan Hares |
2022-08-17
|
09 | John Scudder | Requested Early review by RTGDIR |
2022-05-10
|
09 | Daniele Ceccarelli | Document shepherd write-up for draft-ietf-ccamp-gmpls-otn-b100g-applicability > ## Document History > > 1. Does the working group (WG) consensus represent the strong concurrence of a > … Document shepherd write-up for draft-ietf-ccamp-gmpls-otn-b100g-applicability > ## Document History > > 1. Does the working group (WG) consensus represent the strong concurrence of a > few individuals, with others being silent, or did it reach broad agreement? The document has 5 co-authors and 12 contributors which constitutes a significant percentage of the active members of the working group. That makes for broad consensus. WG last call (which can be found in the archive at https://mailarchive.ietf.org/arch/msg/ccamp/Hy114Qs06ANb36KQUX4XAQqKQzk/ attracted just one review (from the current document shepherd) and a few emails of support from authors/contributors. There was no objection to publication. > 2. Was there controversy about particular points, or were there decisions where > the consensus was particularly rough? None observed. > 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? No. > 4. For protocol documents, are there existing implementations of the contents of > the document? Have a significant number of potential implementers indicated > plans to implement? Are any existing implementations reported somewhere, > either in the document itself (as [RFC 7942][3] recommends) or elsewhere > (where)? This is an applicability statement so cannot be implemented. However, there are many implementations of G.709 2012 and 2016 in hardware, and many of those vendors use the GMPLS control plane in their other products. No specific implementations of GMPLS for the 2020 version of G.709 have been reported. > ### Additional Reviews > > 5. Does this document need review from other IETF working groups or external > organizations? Have those reviews occurred? None needed. > 6. Describe how the document meets any required formal expert review criteria, > such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal language. > 7. If the document contains a YANG module No YANG module. > 8. Describe reviews and automated checks performed to validate sections of the > final version of the document written in a formal language, such as XML code, > BNF rules, MIB definitions, CBOR's CDDL, etc. None applicable. > ### Document Shepherd Checks The document shepherd reviewed this document during working group last call (-07) and in their role as document shepherd (-05). In each case, the authors made updates and addressed all of the comments. > 9. Based on the shepherd's review of the document, is it their opinion that this > document is needed, clearly written, complete, correctly designed, and ready > to be handed off to the responsible Area Director? The document is clearly written, complete, and well structured. It is a niche area, but the document is useful because it explains how existing IETF technology can be applied to a newly extended dataplane. By doing so, it saves attempts to unnecessarily extend the IETF technology, and explains some of the potential issues that may arise so that implementers can be aware. The document is ready to hand off to the AD. > 10. Several IETF Areas have assembled [lists of common issues that their > reviewers encounter][6]. Do any such issues remain that would merit specific > attention from subsequent reviews? It would be easier to answer this question if a pointer was provided to those lists. No reviews or reviewers have pointed to any open issues that need attention. > 11. What type of RFC publication is being requested on the IETF stream (Best > Current Practice, Proposed Standard, Internet Standard, Informational, > Experimental, or Historic)? Why is this the proper type of RFC? Do all > Datatracker state attributes correctly reflect this intent? This document is the product of the CCAMP WG and is presented for publication as an Informational RFC. This is appropriate for an applicability statement. The status is properly indicated on the title page and in the Datatracker. > 12. Has the interested community confirmed that any and all appropriate IPR > disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, > explain why. If yes, summarize any discussion and conclusion regarding the > intellectual property rights (IPR) disclosures, including links to relevant > emails. The WG chairs requested an IPR response from all authors and contributors in an email to the CCAMP mailing list at the time of WG last call. Responses from all of the authors can be seen on the CCAMP mailing list at https://mailarchive.ietf.org/arch/msg/ccamp/dgj7jwwY9YPxF8OJHVGS3JbVe3g/ No IPR has been disclosed, and all respondents declared no IP needed to be disclosed. The CCAMP mailing list was also invited to disclose any IPR at the same time, but no responses were received. > 13. Has each Author or Contributor confirmed their willingness to be listed as > such? Well, no. But they have been listed there for a long time, and their silence may be assumed to be consent. Note also that the IPR poll has made all authors and contributors aware of their status on the document. > If the number of Authors/Editors on the front page is greater than 5, > please provide a justification. It isn't. > 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] > and the checkbox items found in Guidelines to Authors of Internet-Drafts). > Simply running the idnits tool is not enough; please review the entire > guidelines document. id-nits is clean. xml2rfc reports two formatting warnings (width of figures) that it is able to autocorrect. Manual check of guidance for documents reveals no issues. > 15. Should any informative references be normative or vice-versa? The distribution seems to be right. > 16. List any normative references that are not freely available to anyone. None > 17. Are there any normative downward references (see [RFC 3967][10], > [BCP 97][11])? If so, list them. None > 18. Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? None > 19. Will publication of this document change the status of any existing RFCs? No > 20. Describe the document shepherd's review of the IANA considerations section, > especially with regard to its consistency with the body of the document. The document shepherd made themself coffee (it was quite late at night) and sat down in their office. They then read the document including the IANA considerations section, and thought about it carefully, concluding that it was appropriate to make no requests of IANA. > Confirm that all aspects of the document requiring IANA assignments are > associated with the appropriate reservations in IANA registries. Confirmed > Confirm that any referenced IANA registries have been clearly identified. No such references > Confirm that each newly created IANA registry specifies its initial contents, > allocations procedures, and a reasonable name (see [RFC 8126][12]). No new registries > 21. List any new IANA registries that require Designated Expert Review for > future allocations. Are the instructions to the Designated Expert clear? > Please include suggestions of designated experts, if appropriate. No new registries |
2022-05-10
|
09 | Daniele Ceccarelli | Responsible AD changed to John Scudder |
2022-05-10
|
09 | Daniele Ceccarelli | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2022-05-10
|
09 | Daniele Ceccarelli | IESG state changed to Publication Requested from I-D Exists |
2022-05-10
|
09 | Daniele Ceccarelli | IESG process started in state Publication Requested |
2022-05-10
|
09 | Daniele Ceccarelli | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2022-05-10
|
09 | Daniele Ceccarelli | IETF WG state changed to In WG Last Call from WG Consensus: Waiting for Write-Up |
2022-05-10
|
09 | Adrian Farrel | Document shepherd write-up for draft-ietf-ccamp-gmpls-otn-b100g-applicability > ## Document History > > 1. Does the working group (WG) consensus represent the strong concurrence of a > … Document shepherd write-up for draft-ietf-ccamp-gmpls-otn-b100g-applicability > ## Document History > > 1. Does the working group (WG) consensus represent the strong concurrence of a > few individuals, with others being silent, or did it reach broad agreement? The document has 5 co-authors and 12 contributors which constitutes a significant percentage of the active members of the working group. That makes for broad consensus. WG last call (which can be found in the archive at https://mailarchive.ietf.org/arch/msg/ccamp/Hy114Qs06ANb36KQUX4XAQqKQzk/ attracted just one review (from the current document shepherd) and a few emails of support from authors/contributors. There was no objection to publication. > 2. Was there controversy about particular points, or were there decisions where > the consensus was particularly rough? None observed. > 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? No. > 4. For protocol documents, are there existing implementations of the contents of > the document? Have a significant number of potential implementers indicated > plans to implement? Are any existing implementations reported somewhere, > either in the document itself (as [RFC 7942][3] recommends) or elsewhere > (where)? This is an applicability statement so cannot be implemented. However, there are many implementations of G.709 2012 and 2016 in hardware, and many of those vendors use the GMPLS control plane in their other products. No specific implementations of GMPLS for the 2020 version of G.709 have been reported. > ### Additional Reviews > > 5. Does this document need review from other IETF working groups or external > organizations? Have those reviews occurred? None needed. > 6. Describe how the document meets any required formal expert review criteria, > such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal language. > 7. If the document contains a YANG module No YANG module. > 8. Describe reviews and automated checks performed to validate sections of the > final version of the document written in a formal language, such as XML code, > BNF rules, MIB definitions, CBOR's CDDL, etc. None applicable. > ### Document Shepherd Checks The document shepherd reviewed this document during working group last call (-07) and in their role as document shepherd (-05). In each case, the authors made updates and addressed all of the comments. > 9. Based on the shepherd's review of the document, is it their opinion that this > document is needed, clearly written, complete, correctly designed, and ready > to be handed off to the responsible Area Director? The document is clearly written, complete, and well structured. It is a niche area, but the document is useful because it explains how existing IETF technology can be applied to a newly extended dataplane. By doing so, it saves attempts to unnecessarily extend the IETF technology, and explains some of the potential issues that may arise so that implementers can be aware. The document is ready to hand off to the AD. > 10. Several IETF Areas have assembled [lists of common issues that their > reviewers encounter][6]. Do any such issues remain that would merit specific > attention from subsequent reviews? It would be easier to answer this question if a pointer was provided to those lists. No reviews or reviewers have pointed to any open issues that need attention. > 11. What type of RFC publication is being requested on the IETF stream (Best > Current Practice, Proposed Standard, Internet Standard, Informational, > Experimental, or Historic)? Why is this the proper type of RFC? Do all > Datatracker state attributes correctly reflect this intent? This document is the product of the CCAMP WG and is presented for publication as an Informational RFC. This is appropriate for an applicability statement. The status is properly indicated on the title page and in the Datatracker. > 12. Has the interested community confirmed that any and all appropriate IPR > disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, > explain why. If yes, summarize any discussion and conclusion regarding the > intellectual property rights (IPR) disclosures, including links to relevant > emails. The WG chairs requested an IPR response from all authors and contributors in an email to the CCAMP mailing list at the time of WG last call. Responses from all of the authors can be seen on the CCAMP mailing list at https://mailarchive.ietf.org/arch/msg/ccamp/dgj7jwwY9YPxF8OJHVGS3JbVe3g/ No IPR has been disclosed, and all respondents declared no IP needed to be disclosed. The CCAMP mailing list was also invited to disclose any IPR at the same time, but no responses were received. > 13. Has each Author or Contributor confirmed their willingness to be listed as > such? Well, no. But they have been listed there for a long time, and their silence may be assumed to be consent. Note also that the IPR poll has made all authors and contributors aware of their status on the document. > If the number of Authors/Editors on the front page is greater than 5, > please provide a justification. It isn't. > 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] > and the checkbox items found in Guidelines to Authors of Internet-Drafts). > Simply running the idnits tool is not enough; please review the entire > guidelines document. id-nits is clean. xml2rfc reports two formatting warnings (width of figures) that it is able to autocorrect. Manual check of guidance for documents reveals no issues. > 15. Should any informative references be normative or vice-versa? The distribution seems to be right. > 16. List any normative references that are not freely available to anyone. None > 17. Are there any normative downward references (see [RFC 3967][10], > [BCP 97][11])? If so, list them. None > 18. Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? None > 19. Will publication of this document change the status of any existing RFCs? No > 20. Describe the document shepherd's review of the IANA considerations section, > especially with regard to its consistency with the body of the document. The document shepherd made themself coffee (it was quite late at night) and sat down in their office. They then read the document including the IANA considerations section, and thought about it carefully, concluding that it was appropriate to make no requests of IANA. > Confirm that all aspects of the document requiring IANA assignments are > associated with the appropriate reservations in IANA registries. Confirmed > Confirm that any referenced IANA registries have been clearly identified. No such references > Confirm that each newly created IANA registry specifies its initial contents, > allocations procedures, and a reasonable name (see [RFC 8126][12]). No new registries > 21. List any new IANA registries that require Designated Expert Review for > future allocations. Are the instructions to the Designated Expert clear? > Please include suggestions of designated experts, if appropriate. No new registries |
2022-05-10
|
09 | Qilei Wang | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-09.txt |
2022-05-10
|
09 | (System) | New version approved |
2022-05-10
|
09 | (System) | Request for posting confirmation emailed to previous authors: Haomian Zheng , Huub van Helvoort , Qilei Wang , Radha Valiveti , Sergio Belotti |
2022-05-10
|
09 | Qilei Wang | Uploaded new revision |
2022-05-09
|
08 | Adrian Farrel | PENDING A NEW REVISION OF THE DRAFT TO ADDRESS SHEPHERD REVIEW *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT … PENDING A NEW REVISION OF THE DRAFT TO ADDRESS SHEPHERD REVIEW *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** Document shepherd write-up for draft-ietf-ccamp-gmpls-otn-b100g-applicability > ## Document History > > 1. Does the working group (WG) consensus represent the strong concurrence of a > few individuals, with others being silent, or did it reach broad agreement? The document has 5 co-authors and 12 contributors which constitutes a significant percentage of the active members of the working group. That makes for broad consensus. WG last call (which can be found in the archive at https://mailarchive.ietf.org/arch/msg/ccamp/Hy114Qs06ANb36KQUX4XAQqKQzk/ attracted just one review (from the current document shepherd) and a few emails of support from authors/contributors. There was no objection to publication. > 2. Was there controversy about particular points, or were there decisions where > the consensus was particularly rough? None observed. > 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? No. > 4. For protocol documents, are there existing implementations of the contents of > the document? Have a significant number of potential implementers indicated > plans to implement? Are any existing implementations reported somewhere, > either in the document itself (as [RFC 7942][3] recommends) or elsewhere > (where)? This is an applicability statement so cannot be implemented. However, there are many implementations of G.709 2012 and 2016 in hardware, and many of those vendors use the GMPLS control plane in their other products. No specific implementations of GMPLS for the 2020 version of G.709 have been reported. > ### Additional Reviews > > 5. Does this document need review from other IETF working groups or external > organizations? Have those reviews occurred? None needed. > 6. Describe how the document meets any required formal expert review criteria, > such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal language. > 7. If the document contains a YANG module No YANG module. > 8. Describe reviews and automated checks performed to validate sections of the > final version of the document written in a formal language, such as XML code, > BNF rules, MIB definitions, CBOR's CDDL, etc. None applicable. > ### Document Shepherd Checks The document shepherd reviewed this document during working group last call (-07) and in their role as document shepherd (-05). In each case, the authors made updates and addressed all of the comments. > 9. Based on the shepherd's review of the document, is it their opinion that this > document is needed, clearly written, complete, correctly designed, and ready > to be handed off to the responsible Area Director? The document is clearly written, complete, and well structured. It is a niche area, but the document is useful because it explains how existing IETF technology can be applied to a newly extended dataplane. By doing so, it saves attempts to unnecessarily extend the IETF technology, and explains some of the potential issues that may arise. The document is ready to hand off to the AD. > 10. Several IETF Areas have assembled [lists of common issues that their > reviewers encounter][6]. Do any such issues remain that would merit specific > attention from subsequent reviews? It would be easier to answer this question if a pointer was provided to those lists. No reviews or reviewers have pointed to any open issues that need attention. > 11. What type of RFC publication is being requested on the IETF stream (Best > Current Practice, Proposed Standard, Internet Standard, Informational, > Experimental, or Historic)? Why is this the proper type of RFC? Do all > Datatracker state attributes correctly reflect this intent? This document is the product of the CCAMP WG and is presented for publication as an Informational RFC. This is appropriate for an applicability statement. The status is properly indicated on the title page and in the Datatracker. > 12. Has the interested community confirmed that any and all appropriate IPR > disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, > explain why. If yes, summarize any discussion and conclusion regarding the > intellectual property rights (IPR) disclosures, including links to relevant > emails. The WG chairs requested an IPR response from all authors and contributors in an email to the CCAMP mailing list at the time of WG last call. Responses from all of the authors can be seen on the CCAMP mailing list at https://mailarchive.ietf.org/arch/msg/ccamp/dgj7jwwY9YPxF8OJHVGS3JbVe3g/ No IPR has been disclosed, and all respondents declared no IP needed to be disclosed. The CCAMP mailing list was also invited to disclose any IPR at the same time, but no responses were received. > 13. Has each Author or Contributor confirmed their willingness to be listed as > such? Well, no. But they have been listed there for a long time, and their silence may be assumed to be consent. Note also that the IPR poll has made all authors and contributors aware of their status on the document. > If the number of Authors/Editors on the front page is greater than 5, > please provide a justification. It isn't. > 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] > and the checkbox items found in Guidelines to Authors of Internet-Drafts). > Simply running the idnits tool is not enough; please review the entire > guidelines document. id-nits is clean. Manual check of guidance for documents reveals no issues. > 15. Should any informative references be normative or vice-versa? The distribution seems to be right. > 16. List any normative references that are not freely available to anyone. None > 17. Are there any normative downward references (see [RFC 3967][10], > [BCP 97][11])? If so, list them. None > 18. Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? None > 19. Will publication of this document change the status of any existing RFCs? No > 20. Describe the document shepherd's review of the IANA considerations section, > especially with regard to its consistency with the body of the document. The document shepherd made themself coffee (it was quite late at night) and sat down in their office. They then read the document including the IANA considerations section, and thought about it carefully, concluding that it was appropriate to make no requests of IANA. > Confirm that all aspects of the document requiring IANA assignments are > associated with the appropriate reservations in IANA registries. Confirmed > Confirm that any referenced IANA registries have been clearly identified. Confirmed > Confirm that each newly created IANA registry specifies its initial contents, > allocations procedures, and a reasonable name (see [RFC 8126][12]). Confirmed > 21. List any new IANA registries that require Designated Expert Review for > future allocations. Are the instructions to the Designated Expert clear? > Please include suggestions of designated experts, if appropriate. No new registries |
2022-05-05
|
08 | Adrian Farrel | PENDING A NEW REVISION OF THE DRAFT TO ADDRESS SHEPHERD REVIEW Document shepherd write-up for draft-ietf-ccamp-gmpls-otn-b100g-applicability > ## Document History > > 1. Does the … PENDING A NEW REVISION OF THE DRAFT TO ADDRESS SHEPHERD REVIEW Document shepherd write-up for draft-ietf-ccamp-gmpls-otn-b100g-applicability > ## Document History > > 1. Does the working group (WG) consensus represent the strong concurrence of a > few individuals, with others being silent, or did it reach broad agreement? The document has 5 co-authors and 12 contributors which constitutes a significant percentage of the active members of the working group. That makes for broad consensus. WG last call (which can be found in the archive at https://mailarchive.ietf.org/arch/msg/ccamp/Hy114Qs06ANb36KQUX4XAQqKQzk/ attracted just one review (from the current document shepherd) and a few emails of support from authors/contributors. There was no objection to publication. > 2. Was there controversy about particular points, or were there decisions where > the consensus was particularly rough? None observed. > 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? No. > 4. For protocol documents, are there existing implementations of the contents of > the document? Have a significant number of potential implementers indicated > plans to implement? Are any existing implementations reported somewhere, > either in the document itself (as [RFC 7942][3] recommends) or elsewhere > (where)? This is an applicability statement so cannot be implemented. However, there are many implementations of G.709 2012 and 2016 in hardware, and many of those vendors use the GMPLS control plane in their other products. No specific implementations of GMPLS for the 2020 version of G.709 have been reported. > ### Additional Reviews > > 5. Does this document need review from other IETF working groups or external > organizations? Have those reviews occurred? None needed. > 6. Describe how the document meets any required formal expert review criteria, > such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal language. > 7. If the document contains a YANG module No YANG module. > 8. Describe reviews and automated checks performed to validate sections of the > final version of the document written in a formal language, such as XML code, > BNF rules, MIB definitions, CBOR's CDDL, etc. None applicable. > ### Document Shepherd Checks The document shepherd reviewed this document during working group last call (-07) and in their role as document shepherd (-05). In each case, the authors made updates and addressed all of the comments. > 9. Based on the shepherd's review of the document, is it their opinion that this > document is needed, clearly written, complete, correctly designed, and ready > to be handed off to the responsible Area Director? The document is clearly written, complete, and well structured. It is a niche area, but the document is useful because it explains how existing IETF technology can be applied to a newly extended dataplane. By doing so, it saves attempts to unnecessarily extend the IETF technology, and explains some of the potential issues that may arise. The document is ready to hand off to the AD. > 10. Several IETF Areas have assembled [lists of common issues that their > reviewers encounter][6]. Do any such issues remain that would merit specific > attention from subsequent reviews? It would be easier to answer this question if a pointer was provided to those lists. No reviews or reviewers have pointed to any open issues that need attention. > 11. What type of RFC publication is being requested on the IETF stream (Best > Current Practice, Proposed Standard, Internet Standard, Informational, > Experimental, or Historic)? Why is this the proper type of RFC? Do all > Datatracker state attributes correctly reflect this intent? This document is the product of the CCAMP WG and is presented for publication as an Informational RFC. This is appropriate for an applicability statement. The status is properly indicated on the title page and in the Datatracker. > 12. Has the interested community confirmed that any and all appropriate IPR > disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, > explain why. If yes, summarize any discussion and conclusion regarding the > intellectual property rights (IPR) disclosures, including links to relevant > emails. The WG chairs requested an IPR response from all authors and contributors in an email to the CCAMP mailing list at the time of WG last call. Responses from all of the authors can be seen on the CCAMP mailing list at https://mailarchive.ietf.org/arch/msg/ccamp/dgj7jwwY9YPxF8OJHVGS3JbVe3g/ No IPR has been disclosed, and all respondents declared no IP needed to be disclosed. The CCAMP mailing list was also invited to disclose any IPR at the same time, but no responses were received. > 13. Has each Author or Contributor confirmed their willingness to be listed as > such? Well, no. But they have been listed there for a long time, and their silence may be assumed to be consent. Note also that the IPR poll has made all authors and contributors aware of their status on the document. > If the number of Authors/Editors on the front page is greater than 5, > please provide a justification. It isn't. > 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] > and the checkbox items found in Guidelines to Authors of Internet-Drafts). > Simply running the idnits tool is not enough; please review the entire > guidelines document. id-nits is clean. Manual check of guidance for documents reveals no issues. > 15. Should any informative references be normative or vice-versa? The distribution seems to be right. > 16. List any normative references that are not freely available to anyone. None > 17. Are there any normative downward references (see [RFC 3967][10], > [BCP 97][11])? If so, list them. None > 18. Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? None > 19. Will publication of this document change the status of any existing RFCs? No > 20. Describe the document shepherd's review of the IANA considerations section, > especially with regard to its consistency with the body of the document. The document shepherd made themself coffee (it was quite late at night) and sat down in their office. They then read the document including the IANA considerations section, and thought about it carefully, concluding that it was appropriate to make no requests of IANA. > Confirm that all aspects of the document requiring IANA assignments are > associated with the appropriate reservations in IANA registries. Confirmed > Confirm that any referenced IANA registries have been clearly identified. Confirmed > Confirm that each newly created IANA registry specifies its initial contents, > allocations procedures, and a reasonable name (see [RFC 8126][12]). Confirmed > 21. List any new IANA registries that require Designated Expert Review for > future allocations. Are the instructions to the Designated Expert clear? > Please include suggestions of designated experts, if appropriate. No new registries |
2022-04-22
|
08 | Daniele Ceccarelli | Notification list changed to oscar.gonzalezdedios@telefonica.com, adrian@olddog.co.uk from oscar.gonzalezdedios@telefonica.com because the document shepherd was set |
2022-04-22
|
08 | Daniele Ceccarelli | Document shepherd changed to Adrian Farrel |
2021-11-07
|
08 | Qilei Wang | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-08.txt |
2021-11-07
|
08 | (System) | New version approved |
2021-11-07
|
08 | (System) | Request for posting confirmation emailed to previous authors: Haomian Zheng , Huub van Helvoort , Qilei Wang , Radha Valiveti , Sergio Belotti |
2021-11-07
|
08 | Qilei Wang | Uploaded new revision |
2021-09-13
|
07 | Oscar de Dios | Notification list changed to oscar.gonzalezdedios@telefonica.com because the document shepherd was set |
2021-09-13
|
07 | Oscar de Dios | Document shepherd changed to Oscar Gonzalez de Dios |
2021-09-13
|
07 | Oscar de Dios | WGLC poll for adoption concluded with consensus for publications and comments that have to be solved. |
2021-09-13
|
07 | Oscar de Dios | Tag Revised I-D Needed - Issue raised by WGLC set. |
2021-09-13
|
07 | Oscar de Dios | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2021-08-20
|
07 | Daniele Ceccarelli | IPR poll (Daniele) https://mailarchive.ietf.org/arch/msg/ccamp/dgj7jwwY9YPxF8OJHVGS3JbVe3g/ AUTHORS Qilei Wang wang.qilei@zte.com.cn https://mailarchive.ietf.org/arch/msg/ccamp/6trKgY5QmyAVvWYTudjRbyNQ2kI/ Radha Valiveti rvaliveti@infinera.com https://mailarchive.ietf.org/arch/msg/ccamp/78NkT9TNOT73J7PlG6eC_848dWU/ Haomian Zheng zhenghaomian@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/p1Qz-y6Po9q6XnDJRSjwK4aqgMw/ Huub van Helvoort huubatwork@gmail.com https://mailarchive.ietf.org/arch/msg/ccamp/-CUl0cWtDd6X9RktvYatw7Jo60k/ Sergio Belotti sergio.belotti@nokia.com … IPR poll (Daniele) https://mailarchive.ietf.org/arch/msg/ccamp/dgj7jwwY9YPxF8OJHVGS3JbVe3g/ AUTHORS Qilei Wang wang.qilei@zte.com.cn https://mailarchive.ietf.org/arch/msg/ccamp/6trKgY5QmyAVvWYTudjRbyNQ2kI/ Radha Valiveti rvaliveti@infinera.com https://mailarchive.ietf.org/arch/msg/ccamp/78NkT9TNOT73J7PlG6eC_848dWU/ Haomian Zheng zhenghaomian@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/p1Qz-y6Po9q6XnDJRSjwK4aqgMw/ Huub van Helvoort huubatwork@gmail.com https://mailarchive.ietf.org/arch/msg/ccamp/-CUl0cWtDd6X9RktvYatw7Jo60k/ Sergio Belotti sergio.belotti@nokia.com https://mailarchive.ietf.org/arch/msg/ccamp/xJt5C5sqdP2gy5Flmfc08TRgEf8/ Iftekhar Hussain IHussain@infinera.com https://mailarchive.ietf.org/arch/msg/ccamp/Cl1L-JvIWpSkltnRaNsniNCxfEE/ Daniele Ceccarelli daniele.ceccarelli@ericsson.com https://mailarchive.ietf.org/arch/msg/ccamp/KnjewYzY9O7JeIQuf9zzk_jji3E/ Rajan Rao rrao@infinera.com https://mailarchive.ietf.org/arch/msg/ccamp/7Q-allGKfNL973VOIrjqmJkEZDU/ Fatai Zhang zhangfatai@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/zdxKYH5Xug-7heXzOMvE_i7XEDI/ Italo Busi italo.busi@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/YT3s7in0iGP-1a8ugGQQ6xYT3mk/ Dieter Beller Dieter.Beller@nokia.com https://mailarchive.ietf.org/arch/msg/ccamp/MqWlx6H9hzy82dXB5jNqOBa1tNY/ Yuanbin Zhang zhang.yuanbin@zte.com.cn https://mailarchive.ietf.org/arch/msg/ccamp/9E_p9N3s7oxHRmPv1-ORVESUU3k/ Zafar Ali zali@cisco.com https://mailarchive.ietf.org/arch/msg/ccamp/6VzmP6cWfe3J70jsS-zXCPBKvTA/ Daniel King d.king@lancaster.ac.uk https://mailarchive.ietf.org/arch/msg/ccamp/737YDEq_RIVnMzUuOzCbCfBV6jg/ Manoj Kumar manojk2@cisco.com https://mailarchive.ietf.org/arch/msg/ccamp/v88KR_wV-JJgmLkgvH1S5iDru34/ Antonello Bonfanti abonfant@cisco.com https://mailarchive.ietf.org/arch/msg/ccamp/avzZmKV1C4FJtyGBQ6Z-qMh7gIs/ Yuji Tochio tochio@fujitsu.com https://mailarchive.ietf.org/arch/msg/ccamp/QUoWa9yFsZr3xliCxvxEvgZAxP8/ |
2021-08-20
|
07 | Daniele Ceccarelli | IETF WG state changed to In WG Last Call from WG Document |
2021-08-20
|
07 | Daniele Ceccarelli | Intended Status changed to Informational from None |
2021-06-14
|
07 | Qilei Wang | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-07.txt |
2021-06-14
|
07 | (System) | New version approved |
2021-06-14
|
07 | (System) | Request for posting confirmation emailed to previous authors: Haomian Zheng , Huub van Helvoort , Qilei Wang , Radha Valiveti , Sergio Belotti |
2021-06-14
|
07 | Qilei Wang | Uploaded new revision |
2021-06-10
|
06 | (System) | Document has expired |
2020-12-07
|
06 | Qilei Wang | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-06.txt |
2020-12-07
|
06 | (System) | New version approved |
2020-12-07
|
06 | (System) | Request for posting confirmation emailed to previous authors: Qilei Wang , Haomian Zheng , Huub van Helvoort , Radha Valiveti , Sergio Belotti |
2020-12-07
|
06 | Qilei Wang | Uploaded new revision |
2020-12-01
|
05 | Qilei Wang | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-05.txt |
2020-12-01
|
05 | (System) | New version approved |
2020-12-01
|
05 | (System) | Request for posting confirmation emailed to previous authors: Radha Valiveti , Sergio Belotti , Huub van Helvoort , Qilei Wang , Haomian Zheng |
2020-12-01
|
05 | Qilei Wang | Uploaded new revision |
2020-11-19
|
04 | Qilei Wang | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-04.txt |
2020-11-19
|
04 | (System) | New version approved |
2020-11-19
|
04 | (System) | Request for posting confirmation emailed to previous authors: Haomian Zheng , Qilei Wang , Radha Valiveti , Huub van Helvoort , Sergio Belotti |
2020-11-19
|
04 | Qilei Wang | Uploaded new revision |
2020-11-01
|
03 | Qilei Wang | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-03.txt |
2020-11-01
|
03 | (System) | New version approved |
2020-11-01
|
03 | (System) | Request for posting confirmation emailed to previous authors: Radha Valiveti , Sergio Belotti , Haomian Zheng , Huub van Helvoort , Qilei Wang |
2020-11-01
|
03 | Qilei Wang | Uploaded new revision |
2020-09-07
|
02 | (System) | Document has expired |
2020-03-06
|
02 | Qilei Wang | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-02.txt |
2020-03-06
|
02 | (System) | New version approved |
2020-03-06
|
02 | (System) | Request for posting confirmation emailed to previous authors: Haomian Zheng , Qilei Wang , Radha Valiveti , Huub van Helvoort , Sergio Belotti |
2020-03-06
|
02 | Qilei Wang | Uploaded new revision |
2020-01-08
|
01 | (System) | Document has expired |
2019-07-07
|
01 | Qilei Wang | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-01.txt |
2019-07-07
|
01 | (System) | New version approved |
2019-07-07
|
01 | (System) | Request for posting confirmation emailed to previous authors: Sergio Belotti , Huub van Helvoort , Radha Valiveti , Haomian Zheng , Qilei Wang |
2019-07-07
|
01 | Qilei Wang | Uploaded new revision |
2019-02-27
|
00 | Qilei Wang | New version available: draft-ietf-ccamp-gmpls-otn-b100g-applicability-00.txt |
2019-02-27
|
00 | (System) | WG -00 approved |
2019-02-27
|
00 | Qilei Wang | Set submitter to "Qilei Wang ", replaces to (none) and sent approval email to group chairs: ccamp-chairs@ietf.org |
2019-02-27
|
00 | Qilei Wang | Uploaded new revision |