A YANG Network Data Model for Layer 2 VPNs
draft-ietf-opsawg-l2nm-19
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-09-15
|
19 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-09-02
|
19 | (System) | RFC Editor state changed to AUTH48 |
2022-07-22
|
19 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2022-06-16
|
19 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-06-16
|
19 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-06-16
|
19 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-06-15
|
19 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-06-07
|
19 | (System) | RFC Editor state changed to EDIT |
2022-06-07
|
19 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-06-07
|
19 | (System) | Announcement was received by RFC Editor |
2022-06-07
|
19 | (System) | IANA Action state changed to In Progress |
2022-06-07
|
19 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-06-07
|
19 | Cindy Morgan | IESG has approved the document |
2022-06-07
|
19 | Cindy Morgan | Closed "Approve" ballot |
2022-06-07
|
19 | Cindy Morgan | Ballot approval text was generated |
2022-06-07
|
19 | Robert Wilton | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2022-06-07
|
19 | Robert Wilton | Ballot approval text was generated |
2022-06-02
|
19 | (System) | Removed all action holders (IESG state changed) |
2022-06-02
|
19 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2022-06-02
|
19 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2022-06-02
|
19 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-19.txt |
2022-06-02
|
19 | Mohamed Boucadair | New version accepted (logged-in submitter: Mohamed Boucadair) |
2022-06-02
|
19 | Mohamed Boucadair | Uploaded new revision |
2022-06-02
|
18 | Zaheduzzaman Sarker | [Ballot comment] Thanks for addressing my discuss comments. I think I got what I wanted to achieve with the Discuss.. that is to see whether … [Ballot comment] Thanks for addressing my discuss comments. I think I got what I wanted to achieve with the Discuss.. that is to see whether those references are conscious choicee or oversights. Hence, I am clearing by discuss. I, however, think it will be great if the authors ( along with AD) can go through the document again and make sure references are correctly categorized. |
2022-06-02
|
18 | Zaheduzzaman Sarker | [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from Discuss |
2022-06-02
|
18 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2022-06-02
|
18 | Andrew Alston | [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston |
2022-06-02
|
18 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of draft-ietf-opsawg-l2nm-18 CC @evyncke Thank you for the work put … [Ballot comment] # Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of draft-ietf-opsawg-l2nm-18 CC @evyncke Thank you for the work put into this document. It solves a common and important issue while keeping backward compatibility. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Adrian Farrel for the shepherd's write-up including the WG consensus and the intended status. The use of IANA-maintained YANG modules looks attractive to me. I hope that this helps to improve the document, Regards, -éric ## COMMENTS ### Set of L2VPN technologies Just wondering how extensible this model is ? I.e., the L2 cross-connect of RFC 8986 is not included, any reason why ? How easy would it be to extend this model to also include RFC 8986 ? ### Section 2 ``` The corresponding YANG module can be used by a service orchestrator to request a VPN service to a network controller or to expose the list of active L2VPN services. ``` Does this mean that state information (e.g., counters) are not included ? Actually, sections 7.3 & 7.6.3 mention some status & OAM support so suggest adding status & OAM to the above text. ### Section 6 While I understand that "ethernet" is used in a broad concept (i.e., also covering Wi-Fi), I find the use of 'ethernet' a little restrictive as layer-2 VPN could exist in a near future with technologies that are not IEEE 802.3 based (e.g., some IoT networks or the good old frame relay). Alas, probably too late to change anything. ### Section 7.4 ``` 'svc-mtu': Is the service MTU for an L2VPN service (i.e., Layer 2 MTU including L2 frame header/tail). It is also known as the maximum transmission unit or maximum frame size. ``` Does it include CRC and/or preamble ? It would be nice also to mention the unit of this metric. Same question in the 'mtu' in section 7.6.4. ### Section 8.4 Missing "units" in "svc-mtu'. Is 300 msec a valid default aging timer for a MAC address ? This seems really short. ### Sections A.2 & A.3 Thanks for providing an IPv6 example ;-) ## NITS ### MAC is uppercase I noticed at least one occurence of 'mac' in lower case. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments |
2022-06-02
|
18 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2022-06-02
|
18 | Zaheduzzaman Sarker | [Ballot discuss] Thanks for the effort to produce this YANG model, I always fascinate by the work done in creating the YANG models. I have … [Ballot discuss] Thanks for the effort to produce this YANG model, I always fascinate by the work done in creating the YANG models. I have found inconsistencies in the classification of normative references and informative references, hence, would like to discuss those. Some examples below- - in the terminology section while [RFC6241], [RFC7950], [RFC8466], [RFC4026], and [RFC8309] are normative references, [RFC8969] and [RFC8340] are not. But clearly this document uses terms defined in those documents and I as a reader had to open those RFCs to understand what the terms are and without that I would not be possible to understand this document. - sometimes the this document is correctly referring to other documents as normative, as terms or processes are defines there but sometimes it is not. for example - 'signaling-option': Indicates a set of signaling options that are specific to a given VPN network access, e.g., a CE ID ('ce-id' identifying the CE within the VPN) and a remote CE ID as discussed in Section 2.2.2 of [RFC6624]. Now, without understanding what is discussed or defined in RFC6624 it was hard for me to understand the node/leaf mentioned in this document. Thus, I felt RFCC6624 should be a normative reference but it was not. - The reference modules from this document cannot be informative reference, can they? For example in section 8.1 it says - This module references [RFC3032], [RFC4446], [RFC4448], [RFC4553], [RFC4618], [RFC4619], [RFC4717], [RFC4761], [RFC4816], [RFC4842], and [RFC5086]. however, RFC4842 and RFC5086 is informative reference. I would say, please go through the document and correctly categorise all the references. |
2022-06-02
|
18 | Zaheduzzaman Sarker | [Ballot Position Update] New position, Discuss, has been recorded for Zaheduzzaman Sarker |
2022-06-01
|
18 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2022-06-01
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-06-01
|
18 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-18.txt |
2022-06-01
|
18 | Mohamed Boucadair | New version accepted (logged-in submitter: Mohamed Boucadair) |
2022-06-01
|
18 | Mohamed Boucadair | Uploaded new revision |
2022-06-01
|
17 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2022-06-01
|
17 | Francesca Palombini | [Ballot comment] # ART AD Review of draft-ietf-opsawg-l2nm-17 cc @fpalombini Thank you for the work on this document. I have a couple of comments, hopefully … [Ballot comment] # ART AD Review of draft-ietf-opsawg-l2nm-17 cc @fpalombini Thank you for the work on this document. I have a couple of comments, hopefully easy to fix. I have not finished reviewing the examples in appendix, I might update this ballot if I have additional comments. Francesca ## Comments ### boolean for enabled/disabled Section 8.4: ``` "Controls whether loss measurement is enabled/disabled."; ``` ``` "Controls whether ingress replication is enabled/disabled."; ``` ``` "Controles whether P2MP replication is enabled/disabled."; ``` Suggest rephrasing for clarity as other boolean fields: "Controls whether X is enabled ('true') or disabled ('false')."; ### needs a language tag Section 8.4: ``` leaf description { type string; description "A textual description of the VPN network access."; ``` ``` leaf description { type string; description "Textual description of a VPN node."; } ``` As these fields contain human-readable text, I believe it might need a language tag, or specify why a tag is not needed, as specified by RFC 5646. I think that such a tag is not necessary for pw-description and vpn-description as, if I read them correctly, that is covered by the docs where those are initially defined (for example, for pw-description, this is covered by the last paragraph of section 5.5 of RFC 4447). Do let me know if I missed these vpn-network-access description and vpn-node description, and their language are also described here or inherited from another doc. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments |
2022-06-01
|
17 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2022-06-01
|
17 | Roman Danyliw | [Ballot comment] Thank you to Chris Lonvick for the SECDIR review. ** Section 7.3. vpn-services tracks two different last-change timestamps. Would it be useful to … [Ballot comment] Thank you to Chris Lonvick for the SECDIR review. ** Section 7.3. vpn-services tracks two different last-change timestamps. Would it be useful to also track a “created-on” timestamp? |
2022-06-01
|
17 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2022-05-31
|
17 | Erik Kline | [Ballot comment] # Internet AD comments for {draft-ietf-opsawg-l2nm-17} CC @ekline ## Comments ### S6 * Should the 'df-election' description make brief mention of … [Ballot comment] # Internet AD comments for {draft-ietf-opsawg-l2nm-17} CC @ekline ## Comments ### S6 * Should the 'df-election' description make brief mention of the meaning and use of the 'revertive' boolean? ### S8.3 * I can find neither 'revertive' nor 'preempt' in RFC 8584. Can the description be expanded a bit to provide more context (or maybe the reference section)? |
2022-05-31
|
17 | Erik Kline | [Ballot Position Update] New position, Yes, has been recorded for Erik Kline |
2022-05-31
|
17 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2022-05-30
|
17 | Lars Eggert | [Ballot comment] # GEN AD review of draft-ietf-opsawg-l2nm-17 CC @larseggert Thanks to Dale Worley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/iTZYyhVQ7nygCX_KIedl1RhPBE4). … [Ballot comment] # GEN AD review of draft-ietf-opsawg-l2nm-17 CC @larseggert Thanks to Dale Worley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/iTZYyhVQ7nygCX_KIedl1RhPBE4). ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Outdated references Reference `[RFC5143]` to `RFC5143`, which was obsoleted by `RFC4842` (this may be on purpose). ### Grammar/style #### Section 4, paragraph 9 ``` ider does not assume, nor does it precludes exposing the VPN service via the ^^^^^^^^^ ``` Did you mean "preclude"? As "do" is already inflected, the verb cannot also be inflected. #### Section 8.4, paragraph 54 ``` MAC address' situation has occurred and the duplicate MAC address has been ^^^^ ``` Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short). ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool |
2022-05-30
|
17 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2022-05-25
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-05-25
|
17 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-17.txt |
2022-05-25
|
17 | Mohamed Boucadair | New version accepted (logged-in submitter: Mohamed Boucadair) |
2022-05-25
|
17 | Mohamed Boucadair | Uploaded new revision |
2022-05-23
|
16 | Yingzhen Qu | Request for Telechat review by RTGDIR Completed: Has Nits. Reviewer: Yingzhen Qu. Sent review to list. |
2022-05-13
|
16 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2022-05-13
|
16 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2022-05-13
|
16 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
2022-05-13
|
16 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2022-05-13
|
16 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-opsawg-l2nm-16. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-opsawg-l2nm-16. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete. First, in the ns registry on the IETF XML Registry page located at: https://www.iana.org/assignments/xml-registry/ four namespaces will be registered as follows: ID: yang:iana-bgp-l2-encaps URI: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] ID: yang:iana-pseudowire-types URI: urn:ietf:params:xml:ns:yang:iana-pseudowire-types Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] ID: yang:ietf-ethernet-segment URI: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] ID: yang:ietf-l2vpn-ntw URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, in the YANG Module Names registry on the YANG Parameters registry page located at: https://www.iana.org/assignments/yang-parameters/ four new YANG modules will be registered as follows: Name: iana-bgp-l2-encaps Maintained by IANA? Y Namespace: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps Prefix: iana-bgp-l2-encaps Reference: [ RFC-to-be ] Name: iana-pseudowire-types Maintained by IANA? Y Namespace: urn:ietf:params:xml:ns:yang:iana-pseudowire-types Prefix: iana-pw-types Reference: [ RFC-to-be ] Name: ietf-ethernet-segment Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment Prefix: l2vpn-es Reference: [ RFC-to-be ] Name: ietf-l2vpn-ntw Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw Prefix: l2vpn-ntw Reference: [ RFC-to-be ] While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published. Third, in the YANG Module Names registry on the YANG Parameters registry page located at: https://www.iana.org/assignments/yang-parameters/ two YANG modules will be created called iana-bgp-l2-encaps and iana-pseudowire-types based on the contents in sections 8.1 and 8.2. We will also add the following notes to the registry's Notes field: iana-bgp-l2-encaps: BGP Layer 2 encapsulation types must not be directly added to the "iana-bgp-l2-encaps" YANG module. They must instead be added to the "BGP Layer 2 Encapsulation Types" registry. iana-pseudowire-types: MPLS pseudowire types must not be directly added to the "iana-bgp-l2-encaps" YANG module. They must instead be added to the "MPLS Pseudowire Types" registry. Fourth, the following note will be added to top of the BGP Layer 2 Encapsulation Types registry located at: https://www.iana.org/assignments/bgp-parameters When this registry is modified, the YANG module "iana-bgp-l2-encaps" must be updated as defined in [ RFC-to-be ]. Fifth, the following note will be added to the top of the MPLS Pseudowire Types Registry located at: https://www.iana.org/assignments/pwe3-parameters When this registry is modified, the YANG module "iana-pseudowire-types" must be updated as defined in [ RFC-to-be ]. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. 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-05-13
|
16 | Chris Lonvick | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Chris Lonvick. Sent review to list. |
2022-05-13
|
16 | Cindy Morgan | Placed on agenda for telechat - 2022-06-02 |
2022-05-13
|
16 | Robert Wilton | Ballot has been issued |
2022-05-13
|
16 | Robert Wilton | [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton |
2022-05-13
|
16 | Robert Wilton | Created "Approve" ballot |
2022-05-13
|
16 | Robert Wilton | IESG state changed to IESG Evaluation from Waiting for Writeup |
2022-05-13
|
16 | Robert Wilton | Ballot writeup was changed |
2022-05-13
|
16 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-16.txt |
2022-05-13
|
16 | Mohamed Boucadair | New version accepted (logged-in submitter: Mohamed Boucadair) |
2022-05-13
|
16 | Mohamed Boucadair | Uploaded new revision |
2022-05-13
|
15 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2022-05-10
|
15 | Dale Worley | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list. |
2022-05-09
|
15 | Luc André Burdet | Request for Telechat review by RTGDIR is assigned to Yingzhen Qu |
2022-05-09
|
15 | Luc André Burdet | Request for Telechat review by RTGDIR is assigned to Yingzhen Qu |
2022-05-09
|
15 | Alvaro Retana | Requested Telechat review by RTGDIR |
2022-05-06
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2022-05-06
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2022-05-03
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2022-05-03
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2022-05-03
|
15 | Jean Mahoney | Assignment of request for Last Call review by GENART to Paul Kyzivat was rejected |
2022-05-03
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2022-05-03
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2022-04-29
|
15 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2022-04-29
|
15 | Cindy Morgan | The following Last Call announcement was sent out (ends 2022-05-13): From: The IESG To: IETF-Announce CC: adrian@olddog.co.uk, draft-ietf-opsawg-l2nm@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com … The following Last Call announcement was sent out (ends 2022-05-13): From: The IESG To: IETF-Announce CC: adrian@olddog.co.uk, draft-ietf-opsawg-l2nm@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (A YANG Network Data Model for Layer 2 VPNs) to Proposed Standard The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'A YANG Network Data Model for Layer 2 VPNs' 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 last-call@ietf.org mailing lists by 2022-05-13. 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 defines an L2VPN Network YANG Model (L2NM) which can be used to manage the provisioning of Layer 2 Virtual Private Network services within a network (e.g., service provider network). The L2NM complements the Layer 2 Service Model (L2SM) by providing a network- centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that defines a set of identities of BGP Layer 2 encapsulation types and pseudowire types. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/ No IPR declarations have been submitted directly on this I-D. |
2022-04-29
|
15 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2022-04-29
|
15 | Robert Wilton | Last call was requested |
2022-04-29
|
15 | Robert Wilton | Ballot approval text was generated |
2022-04-29
|
15 | Robert Wilton | Ballot writeup was generated |
2022-04-29
|
15 | Robert Wilton | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2022-04-29
|
15 | Robert Wilton | Last call announcement was generated |
2022-04-29
|
15 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-15.txt |
2022-04-29
|
15 | Mohamed Boucadair | New version accepted (logged-in submitter: Mohamed Boucadair) |
2022-04-29
|
15 | Mohamed Boucadair | Uploaded new revision |
2022-04-28
|
14 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-14.txt |
2022-04-28
|
14 | Mohamed Boucadair | New version accepted (logged-in submitter: Mohamed Boucadair) |
2022-04-28
|
14 | Mohamed Boucadair | Uploaded new revision |
2022-04-14
|
13 | (System) | Changed action holders to Robert Wilton (IESG state changed) |
2022-04-14
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-04-14
|
13 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-13.txt |
2022-04-14
|
13 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2022-04-14
|
13 | Mohamed Boucadair | Uploaded new revision |
2022-03-17
|
12 | (System) | Changed action holders to Oscar de Dios, Mohamed Boucadair, Robert Wilton, Luis Munoz, samier barguil (IESG state changed) |
2022-03-17
|
12 | Robert Wilton | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2022-01-14
|
12 | (System) | Changed action holders to Robert Wilton (IESG state changed) |
2022-01-14
|
12 | Robert Wilton | IESG state changed to AD Evaluation from Publication Requested |
2022-01-06
|
12 | Joe Clarke | Shepherd write-up for draft-ietf-opsawg-l2nm-12 (1) What type of RFC is being requested Publication is being requested a Proposed Standard. This is … Shepherd write-up for draft-ietf-opsawg-l2nm-12 (1) What type of RFC is being requested Publication is being requested a Proposed Standard. This is appropriate for an implementable YANG model. This status is shown on the title page. (2) The IESG approval announcement includes a Document Announcement Write-Up. Technical Summary: This document defines an L2VPN Network YANG Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network services within a network (e.g., service provider network). The L2NM complements the Layer 2 Service Model (L2SM) by providing a network- centric view of the service that is internal to a service provider. This document also defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that defines a set of identities of BGP Layer 2 encapsulation types and pseudowire types. The L2VPN model makes use of the Layer 2/3 VPN Common YANG Model defined in draft-ietf-opsawg-vpn-common Working Group Summary: There was no controversy. Note that the L3NM model shares much of the same history and has already advanced to the RFC Editor queue. Work on the L3NM model and this document gave rise to the common L2/3 VPN model that is used by both the L3NM and L2NM models and has also advanced to the RFC Editor queue. Note that the L3NM document attracted considerable review comments during and after IETF last call. The authors of this document have attempted to factor those comments into the work on this draft since they have some relevance here. Document Quality: This document does not record implementation status, however, the shepeherd is personally aware of two implementations under development. There is plenty of interest from operators and vendors mirroring the work for the L3NM. Personnel: Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd Rob Wilton (rwilton@cisco.com) is the Responsible Area Director (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. This document is ready for pulication. The document shepherd has reviewed it three times: once at WG last call, once before the shepherd write-up, and once to check that all changes from all reviews had been made. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (5) Do portions of the document need review from a particular or from broader perspective. This document contains a YANG model and so review by YANG specialists is in order. A YANG Doctor review was conducted on -07 by Ladislav Lhotka and the issues raised were fixed. As this is related to Routing but is progressing in the OPS Area, an early Routing Directorate review was commissioned at version -01 and was performed by Yingzhen Qu. The issues raised were resolved. Additional reviews were performed on version -10: - by Chris Lovnick for Secdir - by Himanshu Shah for Rtgdir The issues raised were resolved. (6) Describe any specific concerns or issues that the Document Shepherd has with this document. None (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. Yes. All OK. No IPR disclosed. See threads at: https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ https://mailarchive.ietf.org/arch/msg/opsawg/hPKPTLF4JclrAFxjApA4D6NgyJg/ https://mailarchive.ietf.org/arch/msg/opsawg/t2FQTeC6DqM6t34gWLYVkqe7hCk/ (8) Has an IPR disclosure been filed that references this document? No (9) How solid is the WG consensus behind this document? OPSAWG is an odd WG in that it has several different communities of interest that rarely cross-review work. As a result, judging broad consensus in the WG is a challenge. Nevertheless, the enthusiastic participation by a long list of authors and contributors, the frequent open design team tele-meetings, and the additional reviews from five people during last call with no major objections, suggest good consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No (11) Identify any ID nits the Document Shepherd has found in this document. idnits reports a few false negatives that are of no concern. Note that reference to RFC 5143 (obsoleted by TFC 4842) is deliberate and results from the IANA registry supporting an obsoleted spec to enable compatibility with old, deployed implementations (12) Describe how the document meets any required formal review criteria. YANG doctor review has been held and addressed as described above. YANG validation shows 0 errors, 0 warnings. Note that the validation shown in the datatracker is for an older version. (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? No (15) Are there downward normative references references (see RFC 3967)? No (16) Will publication of this document change the status of any existing RFCs? No (17) Describe the Document Shepherd's review of the IANA considerations section. The IANA section is simple. It requests assignments from two clearly identified registries to register the YANG modules defined in this document and in accordance with the allocation procedures for those registries. It also requests IANA to maintain two YANG modules that contain values for BGP Layer 2 Encapsulation Types and for Pseudowire Types. Initial versions (populations) of these modules are provided and have passed all YANG checks. Procedures for maintaining these modules are clearly stated. No new registries are created. (18) List any new IANA registries that require Expert Review for future allocations. None (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. YANG validation is clean. See (12) and (20) (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools The YANG validation results are clean. To the best of my knowledge, the model complies with the NMDA. |
2022-01-06
|
12 | Joe Clarke | Responsible AD changed to Robert Wilton |
2022-01-06
|
12 | Joe Clarke | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2022-01-06
|
12 | Joe Clarke | IESG state changed to Publication Requested from I-D Exists |
2022-01-06
|
12 | Joe Clarke | IESG process started in state Publication Requested |
2022-01-06
|
12 | Joe Clarke | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2021-12-29
|
12 | Adrian Farrel | Shepherd write-up for draft-ietf-opsawg-l2nm-12 (1) What type of RFC is being requested Publication is being requested a Proposed Standard. This is … Shepherd write-up for draft-ietf-opsawg-l2nm-12 (1) What type of RFC is being requested Publication is being requested a Proposed Standard. This is appropriate for an implementable YANG model. This status is shown on the title page. (2) The IESG approval announcement includes a Document Announcement Write-Up. Technical Summary: This document defines an L2VPN Network YANG Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network services within a network (e.g., service provider network). The L2NM complements the Layer 2 Service Model (L2SM) by providing a network- centric view of the service that is internal to a service provider. This document also defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that defines a set of identities of BGP Layer 2 encapsulation types and pseudowire types. The L2VPN model makes use of the Layer 2/3 VPN Common YANG Model defined in draft-ietf-opsawg-vpn-common Working Group Summary: There was no controversy. Note that the L3NM model shares much of the same history and has already advanced to the RFC Editor queue. Work on the L3NM model and this document gave rise to the common L2/3 VPN model that is used by both the L3NM and L2NM models and has also advanced to the RFC Editor queue. Note that the L3NM document attracted considerable review comments during and after IETF last call. The authors of this document have attempted to factor those comments into the work on this draft since they have some relevance here. Document Quality: This document does not record implementation status, however, the shepeherd is personally aware of two implementations under development. There is plenty of interest from operators and vendors mirroring the work for the L3NM. Personnel: Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd Rob Wilton (rwilton@cisco.com) is the Responsible Area Director (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. This document is ready for pulication. The document shepherd has reviewed it three times: once at WG last call, once before the shepherd write-up, and once to check that all changes from all reviews had been made. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (5) Do portions of the document need review from a particular or from broader perspective. This document contains a YANG model and so review by YANG specialists is in order. A YANG Doctor review was conducted on -07 by Ladislav Lhotka and the issues raised were fixed. As this is related to Routing but is progressing in the OPS Area, an early Routing Directorate review was commissioned at version -01 and was performed by Yingzhen Qu. The issues raised were resolved. Additional reviews were performed on version -10: - by Chris Lovnick for Secdir - by Himanshu Shah for Rtgdir The issues raised were resolved. (6) Describe any specific concerns or issues that the Document Shepherd has with this document. None (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. Yes. All OK. No IPR disclosed. See threads at: https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ https://mailarchive.ietf.org/arch/msg/opsawg/hPKPTLF4JclrAFxjApA4D6NgyJg/ https://mailarchive.ietf.org/arch/msg/opsawg/t2FQTeC6DqM6t34gWLYVkqe7hCk/ (8) Has an IPR disclosure been filed that references this document? No (9) How solid is the WG consensus behind this document? OPSAWG is an odd WG in that it has several different communities of interest that rarely cross-review work. As a result, judging broad consensus in the WG is a challenge. Nevertheless, the enthusiastic participation by a long list of authors and contributors, the frequent open design team tele-meetings, and the additional reviews from five people during last call with no major objections, suggest good consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No (11) Identify any ID nits the Document Shepherd has found in this document. idnits reports a few false negatives that are of no concern. Note that reference to RFC 5143 (obsoleted by TFC 4842) is deliberate and results from the IANA registry supporting an obsoleted spec to enable compatibility with old, deployed implementations (12) Describe how the document meets any required formal review criteria. YANG doctor review has been held and addressed as described above. YANG validation shows 0 errors, 0 warnings. Note that the validation shown in the datatracker is for an older version. (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? No (15) Are there downward normative references references (see RFC 3967)? No (16) Will publication of this document change the status of any existing RFCs? No (17) Describe the Document Shepherd's review of the IANA considerations section. The IANA section is simple. It requests assignments from two clearly identified registries to register the YANG modules defined in this document and in accordance with the allocation procedures for those registries. It also requests IANA to maintain two YANG modules that contain values for BGP Layer 2 Encapsulation Types and for Pseudowire Types. Initial versions (populations) of these modules are provided and have passed all YANG checks. Procedures for maintaining these modules are clearly stated. No new registries are created. (18) List any new IANA registries that require Expert Review for future allocations. None (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. YANG validation is clean. See (12) and (20) (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools The YANG validation results are clean. To the best of my knowledge, the model complies with the NMDA. |
2021-12-29
|
12 | Adrian Farrel | Shepherd actions to be done: - Check IPR disclosures - all OK, no IPR disclosed Threads : https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ … Shepherd actions to be done: - Check IPR disclosures - all OK, no IPR disclosed Threads : https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ https://mailarchive.ietf.org/arch/msg/opsawg/hPKPTLF4JclrAFxjApA4D6NgyJg/ https://mailarchive.ietf.org/arch/msg/opsawg/t2FQTeC6DqM6t34gWLYVkqe7hCk/ - Check WG last call and Directorate issues addressed - Done - Check idnits - Done Note that reference to 5143 (obsoleted by 4842) is deliberate and results from the IANA registry supporting an obsoleted spec to enable compatibility with old, deployed implementations - YANG compilation Compilation of the latest revision is clean - Consider IETF last call and IESG issues on L3NM and VPN common All updates have been made consistent with those documents - Review document - Review sent. New revision addresses comments - Do shepherd write-up |
2021-11-22
|
12 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-12.txt |
2021-11-22
|
12 | (System) | New version approved |
2021-11-22
|
12 | (System) | Request for posting confirmation emailed to previous authors: Luis Munoz , Mohamed Boucadair , Oscar de Dios , samier barguil |
2021-11-22
|
12 | Mohamed Boucadair | Uploaded new revision |
2021-11-18
|
11 | Adrian Farrel | Shepherd actions to be done: - Check IPR disclosures - all OK, no IPR disclosed Threads : https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ … Shepherd actions to be done: - Check IPR disclosures - all OK, no IPR disclosed Threads : https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ https://mailarchive.ietf.org/arch/msg/opsawg/hPKPTLF4JclrAFxjApA4D6NgyJg/ https://mailarchive.ietf.org/arch/msg/opsawg/t2FQTeC6DqM6t34gWLYVkqe7hCk/ - Check WG last call and Directorate issues addressed - Done - Check idnits Note that reference to 5143 (obsoleted by 4842) is deliberate and results from the IANA registry supporting an obsoleted spec to enable compatibility with old, deployed implementations - YANG compilation https://yangcatalog.org/results/ietf-l2vpn-ntw@2020-11-02_ietf.html shows errors compiling the 2nd November version - Consider IETF last call and IESG issues on L3NM and VPN common - Review document - Review sent. Pending new revision - Do shepherd write-up |
2021-11-18
|
11 | Adrian Farrel | Shepherd actions to be done: - Check IPR disclosures - all OK, no IPR disclosed Threads : https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ … Shepherd actions to be done: - Check IPR disclosures - all OK, no IPR disclosed Threads : https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ https://mailarchive.ietf.org/arch/msg/opsawg/hPKPTLF4JclrAFxjApA4D6NgyJg/ https://mailarchive.ietf.org/arch/msg/opsawg/t2FQTeC6DqM6t34gWLYVkqe7hCk/ - Check WG last call and Directorate issues addressed - Done - Check idnits Note that reference to 5143 (obsoleted by 4842) is deliberate and results from the IANA registry supporting an obsoleted spec to enable compatibility with old, deployed implementations - YANG compilation - Consider IETF last call and IESG issues on L3NM and VPN common - Review document - Review sent. Pending new revision - Do shepherd write-up |
2021-11-18
|
11 | Adrian Farrel | Shepherd actions to be done: - Check IPR disclosures - all OK, no IPR disclosed Threads : https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ … Shepherd actions to be done: - Check IPR disclosures - all OK, no IPR disclosed Threads : https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ https://mailarchive.ietf.org/arch/msg/opsawg/hPKPTLF4JclrAFxjApA4D6NgyJg/ https://mailarchive.ietf.org/arch/msg/opsawg/t2FQTeC6DqM6t34gWLYVkqe7hCk/ - Check WG last call issues addressed - Check idnits Note that reference to 5143 (obsoleted by 4842) is deliberate and results from the IANA registry supporting an obsoleted spec to enable compatibility with old, deployed implementations - YANG compilation - Consider IETF last call and IESG issues on L3NM and VPN common - Review document - RFCs in reference clauses should be mentioned in the main body to give easy citations - Do shepherd write-up |
2021-11-16
|
11 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-11.txt |
2021-11-16
|
11 | (System) | New version approved |
2021-11-16
|
11 | (System) | Request for posting confirmation emailed to previous authors: Luis Munoz , Mohamed Boucadair , Oscar de Dios , samier barguil |
2021-11-16
|
11 | Mohamed Boucadair | Uploaded new revision |
2021-11-14
|
10 | Luc André Burdet | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Himanshu Shah. Submission of review completed at an earlier date. |
2021-11-11
|
10 | Luc André Burdet | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Himanshu Shah. |
2021-11-07
|
10 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-10.txt |
2021-11-07
|
10 | (System) | New version approved |
2021-11-07
|
10 | (System) | Request for posting confirmation emailed to previous authors: Luis Munoz , Mohamed Boucadair , Oscar de Dios , samier barguil |
2021-11-07
|
10 | Mohamed Boucadair | Uploaded new revision |
2021-11-07
|
09 | Adrian Farrel | Shepherd actions to be done: - Check IPR disclosures - all OK, no IPR disclosed Threads : https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ … Shepherd actions to be done: - Check IPR disclosures - all OK, no IPR disclosed Threads : https://mailarchive.ietf.org/arch/msg/opsawg/ODaFQ6PgzJ3FSGPcOGslDC2bMls/ https://mailarchive.ietf.org/arch/msg/opsawg/hPKPTLF4JclrAFxjApA4D6NgyJg/ https://mailarchive.ietf.org/arch/msg/opsawg/t2FQTeC6DqM6t34gWLYVkqe7hCk/ - Check WG last call issues addressed - Check idnits - 145 lines too long - Why reference 5143 not 4842? - YANG compilation - Consider IETF last call and IESG issues on L3NM and VPN common - Review document - RFCs in reference clauses should be mentioned in the main body to give easy citations - Do shepherd write-up |
2021-10-26
|
09 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Himanshu Shah |
2021-10-26
|
09 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Himanshu Shah |
2021-10-26
|
09 | Luc André Burdet | Assignment of request for Last Call review by RTGDIR to Lou Berger was rejected |
2021-10-20
|
09 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-09.txt |
2021-10-20
|
09 | (System) | New version approved |
2021-10-20
|
09 | (System) | Request for posting confirmation emailed to previous authors: Luis Munoz , Mohamed Boucadair , Oscar de Dios , samier barguil |
2021-10-20
|
09 | Mohamed Boucadair | Uploaded new revision |
2021-10-11
|
08 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-08.txt |
2021-10-11
|
08 | (System) | New version approved |
2021-10-11
|
08 | (System) | Request for posting confirmation emailed to previous authors: Luis Munoz , Mohamed Boucadair , Oscar de Dios , samier barguil |
2021-10-11
|
08 | Mohamed Boucadair | Uploaded new revision |
2021-10-10
|
07 | Chris Lonvick | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. Sent review to list. |
2021-10-05
|
07 | Ladislav Lhotka | Request for Last Call review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Ladislav Lhotka. Sent review to list. |
2021-10-04
|
07 | Joe Clarke | Tag Revised I-D Needed - Issue raised by WGLC set. |
2021-10-04
|
07 | Joe Clarke | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2021-10-01
|
07 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-07.txt |
2021-10-01
|
07 | (System) | New version approved |
2021-10-01
|
07 | (System) | Request for posting confirmation emailed to previous authors: Luis Munoz , Mohamed Boucadair , Oscar de Dios , samier barguil |
2021-10-01
|
07 | Mohamed Boucadair | Uploaded new revision |
2021-09-30
|
06 | Adrian Farrel | Shepherd actions to be done: - check IPR disclosures - check WG last call issues addressed - check idnits - check YANG compilations etc - … Shepherd actions to be done: - check IPR disclosures - check WG last call issues addressed - check idnits - check YANG compilations etc - consider IETF last call and IESG issues on L3NM and VPN common - review document - do shepherd write-up |
2021-09-30
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2021-09-30
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2021-09-29
|
06 | Joe Clarke | IETF WG state changed to In WG Last Call from WG Document |
2021-09-29
|
06 | Joe Clarke | Notification list changed to adrian@olddog.co.uk because the document shepherd was set |
2021-09-29
|
06 | Joe Clarke | Document shepherd changed to Adrian Farrel |
2021-09-29
|
06 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2021-09-23
|
06 | Tim Chown | Assignment of request for Last Call review by OPSDIR to Tim Chown was rejected |
2021-09-22
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2021-09-22
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2021-09-17
|
06 | Haomian Zheng | Request for Last Call review by RTGDIR is assigned to Lou Berger |
2021-09-17
|
06 | Haomian Zheng | Request for Last Call review by RTGDIR is assigned to Lou Berger |
2021-09-17
|
06 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Ladislav Lhotka |
2021-09-17
|
06 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Ladislav Lhotka |
2021-09-16
|
06 | Joe Clarke | Requested Last Call review by YANGDOCTORS |
2021-09-16
|
06 | Joe Clarke | Requested Last Call review by RTGDIR |
2021-09-16
|
06 | Joe Clarke | Requested Last Call review by OPSDIR |
2021-09-16
|
06 | Joe Clarke | Requested Last Call review by SECDIR |
2021-09-12
|
06 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-06.txt |
2021-09-12
|
06 | (System) | New version approved |
2021-09-12
|
06 | (System) | Request for posting confirmation emailed to previous authors: Luis Munoz , Mohamed Boucadair , Oscar de Dios , samier barguil |
2021-09-12
|
06 | Mohamed Boucadair | Uploaded new revision |
2021-09-09
|
05 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-05.txt |
2021-09-09
|
05 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2021-09-09
|
05 | Mohamed Boucadair | Uploaded new revision |
2021-08-04
|
04 | Joe Clarke | Added to session: IETF-111: opsawg Fri-1600 |
2021-07-28
|
04 | Oscar de Dios | New version available: draft-ietf-opsawg-l2nm-04.txt |
2021-07-28
|
04 | (System) | New version accepted (logged-in submitter: Oscar de Dios) |
2021-07-28
|
04 | Oscar de Dios | Uploaded new revision |
2021-07-09
|
03 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-03.txt |
2021-07-09
|
03 | (System) | New version approved |
2021-07-09
|
03 | (System) | Request for posting confirmation emailed to previous authors: Luis Munoz , Mohamed Boucadair , Oscar de Dios , samier barguil |
2021-07-09
|
03 | Mohamed Boucadair | Uploaded new revision |
2021-04-30
|
02 | Mohamed Boucadair | New version available: draft-ietf-opsawg-l2nm-02.txt |
2021-04-30
|
02 | (System) | New version approved |
2021-04-30
|
02 | (System) | Request for posting confirmation emailed to previous authors: Jichun Ma , Luay Jalil , Luis Munoz , Mohamed Boucadair , Oscar de Dios , opsawg-chairs@ietf.org … Request for posting confirmation emailed to previous authors: Jichun Ma , Luay Jalil , Luis Munoz , Mohamed Boucadair , Oscar de Dios , opsawg-chairs@ietf.org, samier barguil |
2021-04-30
|
02 | Mohamed Boucadair | Uploaded new revision |
2020-12-20
|
01 | Yingzhen Qu | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Yingzhen Qu. Sent review to list. |
2020-11-30
|
01 | Min Ye | Request for Early review by RTGDIR is assigned to Yingzhen Qu |
2020-11-30
|
01 | Min Ye | Request for Early review by RTGDIR is assigned to Yingzhen Qu |
2020-11-30
|
01 | Min Ye | Assignment of request for Early review by RTGDIR to Victoria Pritchard was rejected |
2020-11-27
|
01 | Min Ye | Request for Early review by RTGDIR is assigned to Victoria Pritchard |
2020-11-27
|
01 | Min Ye | Request for Early review by RTGDIR is assigned to Victoria Pritchard |
2020-11-27
|
01 | Joe Clarke | Requested Early review by RTGDIR |
2020-11-02
|
01 | Oscar de Dios | New version available: draft-ietf-opsawg-l2nm-01.txt |
2020-11-02
|
01 | (System) | New version accepted (logged-in submitter: Oscar de Dios) |
2020-11-02
|
01 | Oscar de Dios | Uploaded new revision |
2020-10-19
|
00 | Joe Clarke | Changed consensus to Yes from Unknown |
2020-10-19
|
00 | Joe Clarke | Intended Status changed to Proposed Standard from None |
2020-07-27
|
00 | Joe Clarke | Added to session: IETF-108: opsawg Tue-1410 |
2020-07-02
|
00 | Oscar de Dios | This document now replaces draft-barguil-opsawg-l2sm-l2nm instead of None |
2020-07-02
|
00 | Oscar de Dios | New version available: draft-ietf-opsawg-l2nm-00.txt |
2020-07-02
|
00 | (System) | New version accepted (logged-in submitter: Oscar de Dios) |
2020-07-02
|
00 | Oscar de Dios | Uploaded new revision |