Skip to main content

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