Skip to main content

A Common YANG Data Model for Layer 2 and Layer 3 VPNs
draft-ietf-opsawg-vpn-common-12

Revision differences

Document history

Date Rev. By Action
2022-02-11
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-02-09
12 (System) RFC Editor state changed to AUTH48 from AUTH48-DONE
2022-02-08
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-02-07
12 (System) RFC Editor state changed to AUTH48 from AUTH48-DONE
2022-02-03
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-01-21
12 (System) RFC Editor state changed to AUTH48
2021-12-22
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-10-18
12 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2021-10-18
12 Tero Kivinen Assignment of request for Last Call review by SECDIR to Tim Polk was marked no-response
2021-10-13
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-10-13
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-10-13
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-10-12
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-10-11
12 (System) RFC Editor state changed to EDIT
2021-10-11
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-10-11
12 (System) Announcement was received by RFC Editor
2021-10-08
12 (System) IANA Action state changed to In Progress
2021-10-08
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-10-08
12 Amy Vezza IESG has approved the document
2021-10-08
12 Amy Vezza Closed "Approve" ballot
2021-10-08
12 Robert Wilton IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2021-10-08
12 Robert Wilton Ballot approval text was generated
2021-09-29
12 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-12.txt
2021-09-29
12 (System) New version approved
2021-09-29
12 (System) Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Oscar de Dios , Qin WU , samier barguil
2021-09-29
12 Mohamed Boucadair Uploaded new revision
2021-09-23
11 (System) Removed all action holders (IESG state changed)
2021-09-23
11 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2021-09-23
11 Zaheduzzaman Sarker
[Ballot comment]
The version -11 of this document addresses, my discuss points. Thanks for addressing the issue.


Thanks to the authors for working on this …
[Ballot comment]
The version -11 of this document addresses, my discuss points. Thanks for addressing the issue.


Thanks to the authors for working on this specifications and addressing TSVART review comments. Thanks Wesley Eddy for your TSVART reviews.

Comments -

* In this specification, UDP match criteria is described and claimed that the model can be augmented to include more L4 transport protocols. QUIC (RFC9000) is a new L4 transport protocol and uses UDP as substrate. For such L4 transport protocols, it might be ambiguous to apply qos classification policy based on what is defined here. In case of QUIC, it needs to identify from other UDP traffic that is traversing the network. Read more on QUIC traffic identification here ( https://quicwg.org/ops-drafts/draft-ietf-quic-manageability.html#name-identifying-quic-traffic).

I think this specification should consider such potential substrate usage of L4 protocols (specially UDP) and hint on the potential augmentations (there might be several ways to do that) or scope it down to not support such cases.

* May be the commented text in the section 4 for protocol identifiers should be updated to reflect what is describes in the section 3 for "underlay-transport". Section 3 talks about underlay transports and how they are set.
2021-09-23
11 Zaheduzzaman Sarker [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from Discuss
2021-09-23
11 Michelle Cotton IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-09-23
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-09-23
11 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-11.txt
2021-09-23
11 (System) New version approved
2021-09-23
11 (System) Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Oscar de Dios , Qin WU , samier barguil
2021-09-23
11 Mohamed Boucadair Uploaded new revision
2021-09-23
10 Adrian Farrel
> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of …
> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of RFC indicated in the title page header?

This draft is requested for publication as a Proposed Standard.
This is appropriate for a YANG model that will be implemented and must
interoperate.
The status is properly indicated on the title page.

> (2) The IESG approval announcement includes a Document Announcement
>    Write-Up.
>
> Technical Summary:

This document defines a common YANG module that is available for reuse
by various VPN-related modules such as the Layer 3 VPN and Layer 2 VPN
network models.  The intention is to save re-documenting identical
YANG fragments and to provide a common and consistent approach.  It is
intended that possible future revisions of RFC 8299 and RFC 8466 will
also be able to use this model.

> Working Group Summary:

There was no controversy.

The idea of this model arose in the OPSAWG quite late in the development
of the L2NM and L3NM models, but the authors were quickly able to
identify the common components and build this model.

It is worth noting that, while the L2NM may need a little more work,
this common model and the L3NM are advancing together.

> Document Quality:

The current version of draft-ietf-opsawg-l3sm-l3nm records four
implementations of that model.  By implied inheritence, those
implementations must include implementations of this model. They are
by Nokia, Huawei, Infinera, Ribbon-ECI.

The document shepherd is aware of one other commercial implementation
and one prototype implementation.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Rob Wilton (rwilton@cisco.com) iss 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, please explain why the document is being
>    forwarded to the IESG.

I reviewed this draft in detail during WG last call and all of the
issues I raised have been addressed. I have done a quick review of the
most recent version mainly focused on the changes. This version is
ready for publication.

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

No concerns. Indeed, the number of implementers participating has
resulted in a deep and broad review.

> (5) Do portions of the document need review from a particular or from
>    broader perspective? If so, describe the review that took place.

This document contains a YANG model and so review by YANG specialists
is in order.

An early YANG Doctor review was conducted on -02 by Radek Krejci and
the issues raised were fixed.

A subsequent YANG Doctor review on -06 at WG last call was also done by
Radek Krejci. It found only nits, and those have been fixed in the
current version.

> (6) Describe any specific concerns or issues that the Document
>    Shepherd has with this document that the Responsible Area Director
>    and/or the IESG should be aware of?

No issues.

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

All authors and contributors have so confirmed.

IPR protestations can be found on the thread at
https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/

This records no known IPR from the full set of:
  Authors: Oscar Gonzalez de Dios, Mohamed Boucadair,
          Samier Barguil Giraldo, Qin Wu
  Contributors: Victor Lopez, Italo Busi

The final Contributor (Luis Angel Munoz) noted no IPR on the thread
https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/

> (8) Has an IPR disclosure been filed that references this document?

No IPR disclosed.

> (9) How solid is the WG consensus behind this document? Does it
>    represent the strong concurrence of a few individuals, with others
>    being silent, or does the WG as a whole understand and agree with
>    it?

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.

While the design teams were well-attended, they left some visibility
holes concerning the work and failed to report back to the broader WG.
This has been corrected with regular readouts on the mailing list, as
well as requests to the mailing list for input on decisions.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
>      discontent?

No discontent voiced.

> (11) Identify any ID nits the Document Shepherd has found in this
>      document.

idnits is clean. The warnings have been checked and found to be benign.

> (12) Describe how the document meets any required formal review
>      criteria.

See (5) for YANG Doctor reviews.
YANG validation (in the datatracker) shows 0 errors, 0 warnings

> (13) Have all references within this document been identified as
>      either normative or informative?

Yes. Both normative and informative references are present.

> (14) Are there normative references to documents that are not ready
>      for advancement or are otherwise in an unclear state?

All normative references are to RFCs.

> (15) Are there downward normative references references (see
>      RFC 3967)? If so, list these downward references to support the
>      Area Director in the Last Call procedure.

No downrefs.

> (16) Will publication of this document change the status of any
>      existing RFCs?

No status changes.

> (17) Describe the Document Shepherd's review of the IANA
>      considerations section, especially with regard to its consistency
>      with the body of the document. Confirm that all protocol
>      extensions that the document makes are associated with the
>      appropriate reservations in IANA registries. Confirm that any
>      referenced IANA registries have been clearly identified. Confirm
>      that newly created IANA registries include a detailed
>      specification of the initial contents for the registry, that
>      allocations procedures for future registrations are defined, and
>      a reasonable name for the new registry has been suggested (see
>      RFC 8126).

The IANA section is simple.
It requests assignments from two clearly identified registries in
accordance with the allocation procedures for those registries.
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.

The datatracker 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
>      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for
>      syntax and formatting validation?
>      Does the YANG module comply with the Network Management Datastore
>      Architecture (NMDA) as specified in RFC8342?

The YANG validation results are clean.
To the best of my knowledge, the model complies with the NMDA.
2021-09-22
10 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-09-22
10 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-09-22
10 Éric Vyncke
[Ballot comment]
As I am abroad on vacations, I had not time to review in depth this document, hence I am trusting the Internet directorate …
[Ballot comment]
As I am abroad on vacations, I had not time to review in depth this document, hence I am trusting the Internet directorate Last-Call review by Suresh:
https://datatracker.ietf.org/doc/review-ietf-opsawg-vpn-common-09-intdir-lc-krishnan-2021-08-30/

I was about to post similar comments as Erik Kline's ones about the lack of IPv6 terminology in the classification but Med's reply is OK. May I suggest though to clearly reference RFC 8519 (which should be updated) where this topic is discussed ? I also appreciate the reuse of the (incomplete) ACL YANG modules.

Regards

-éric
2021-09-22
10 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-09-21
10 Benjamin Kaduk
[Ballot comment]
I have a bold proposal for consideration: since we are defining a new
common set of groupings for VPN and, in some cases, …
[Ballot comment]
I have a bold proposal for consideration: since we are defining a new
common set of groupings for VPN and, in some cases, proposing to rename
existing terminology already, can we consider moving away from the term
"VPN" itself?  The word "private" is ambiguous as to what level of
privacy is being provided (e.g., network routing vs cryptographic) and
who the conveyed content is to be private from.  A term like "virtual
network" removes that ambiguity, and lets us use the explicit attributes
to convey whether encryption is in use when appropriate.

There is no particular triggering point (at least, not yet) at which it
becomes clearly correct to make a breaking change like this, so we may
end up just having to pick a time somewhat arbitrarily, if we are to
make such a change at all.  Perhaps now is that time; perhaps not.

Section 3

          grouping vpn-profile-cfg
            +-- valid-provider-identifiers
              +-- external-connectivity-identifier* [id]
              |      {external-connectivity}?
              |  +-- id?  string

Presumably I am just misreading RFC 8340, but I thought that the list
key was implicitly mandatory, so it would appear as just "id" (as
opposed to "id?").  (Many instances.)

  'vpn-route-targets':
      *  A YANG grouping that defines Route Target (RT) import/export
        rules used in a BGP-enabled VPN (e.g., [RFC4364][RFC4664]).

On very quick skim, it's not clear what motivates the RFC 4664
reference -- "route target" does not appear, for example, nor does
"import" or "export".

Section 4

    identity pim-proto {
      if-feature "pim";
      base routing-protocol-type;

This is in the section with the group-management-protocols; is
"routing-protocol-type" really the intended base?

    identity embb {
    [...]
    identity urllc {
    [...]
    identity mmtc {

Similar to Roman's comment, a reference seems useful for these.
If we intend to implicitly rely on RFCs 8299 and/or 8466 for
terminology, we should say so in the terminology section.

      leaf vpn-id {
        type vpn-common:vpn-id;
        description
          "A VPN identifier that uniquely identifies a VPN.
            This identifier has a local meaning, e.g., within
            a service provider network.";

Thank you for indicating the scope of validity of the identifier!
(Elsewhere as well.)

    grouping service-status {
      [...]
          leaf last-change {
            type yang:date-and-time;
            description
              "Indicates the actual date and time of the service status
                change.";

What's the motiviation behind leaving this as "config true"?  When would
it be useful to set it manually?

      list vpn-target {
        [...]
        leaf id {
          type int8;
          description
            "Identifies each VPN Target.";

I wasn't able to find the motivation for limiting to int8 in RFC 4364,
though I mostly assume I'm just looking in the wrong place.
(But why *signed* int8?)

Section 5

While there may be no direct security considerations from what is
effectively just defining some new compound types for reuse, I think we
may want to consider some privacy considerations.  For example, we have
the "customer-name" field in the vpn-description, and it is sometimes
the case that customers want to remain confidential.  Thus, any
instantiations of the grouping would incur a potential need for
confidentiality and minimizing the scope of distribution.

NITS

Section 4

    feature bearer-reference {
      description
        "Indicates support for the bearer reference access constraint.
          That is, the reuse of a network connection that was already
          ordered to the service provider apart from the IP VPN site.";

I echo Roman's comment that this feature would benefit from a reference
or further discussion; the current description leaves me unclear on what
is meant and with no recourse for learning more.  (RFCs 4026 and 4176
are presented as generic references for VPN-related terms, but do not
cover the concept of "bearer reference".)

      reference
        "I-D.ietf-teas-ietf-network-slice-framework:
            Framework for IETF Network Slices";

draft-ietf-teas-ietf-network-slice-framework is replaced by
draft-ietf-teas-ietf-network-slices.

    identity rsvp-te {
      base protocol-type;
      description
        "Transport is based on RSVP-TE.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";

Is the transport itself RSVP-TE, or is it that RSVP-TE is used to
provision the tunnels used as transport?  (Similar question for bgp-lu?)

    identity dot1q {
      if-feature "dot1q";
      base encapsulation-type;
      description
        "Dot1q encapsulation.";

I suppose the feature declaration does so, but maybe some "802" is in
order here as well?

    identity ethernet-type {
      base encapsulation-type;
      description
        "Ethernet encapsulation type.";
    }

    identity vlan-type {
      base encapsulation-type;
      description
        "VLAN encapsulation.";
    }

    identity untagged-int {
      base encapsulation-type;
      description
        "Untagged interface type.";
    [...]

Should we be more consistent about whether the description ends in
"type"?

    identity lag-int {
      if-feature "lag-interface";
      base encapsulation-type;
      description
        "LAG interface type.";
      reference
        "IEEE Std. 802.1AX: Link Aggregation";

lag-int is the only encapsulation-type identify element that has a
reference stanza.  We did mention LAG in the context of 802.1AX earlier,
so maybe it's not needed?

    identity web {
      base customer-application;
      description
        "Web applications (e.g., HTTP, HTTPS).";
    [...]
    identity file-transfer {
      base customer-application;
      description
        "File transfer application (e.g., FTP, SFTP).";

Maybe we could just list HTTPS and SFTP as the (respective) examples, in 2021?

      leaf vpn-name {
        type string;
        description
          "A name used to refer to the VPN.";

Should we say a little more about how the name differs from the id,
given that both are "type string"?

        leaf import-policy {
          type string;
          description
            "Defines the 'import' policy.";
        }
        leaf export-policy {
          type string;
          description
            "Defines the 'export' policy.";

Does it "define" or merely "identify" the policy?  Naively, a
"definition" would be a rather long string...

    grouping vpn-components-group {
      [...]
      container groups {
        description
          "Lists the groups to which a VPN node,a site, or a network

space after comma.
2021-09-21
10 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-09-21
10 Zaheduzzaman Sarker
[Ballot discuss]
I would like to discuss the extensibility of the model as described in section 3 regarding 'qos-classification-policy' when UDP is used as substrate. …
[Ballot discuss]
I would like to discuss the extensibility of the model as described in section 3 regarding 'qos-classification-policy' when UDP is used as substrate. See more in my comments bellow.
2021-09-21
10 Zaheduzzaman Sarker
[Ballot comment]
Thanks to the authors for working on this specifications and addressing TSVART review comments. Thanks Wesley Eddy for your TSVART reviews.

Comments - …
[Ballot comment]
Thanks to the authors for working on this specifications and addressing TSVART review comments. Thanks Wesley Eddy for your TSVART reviews.

Comments -

* In this specification, UDP match criteria is described and claimed that the model can be augmented to include more L4 transport protocols. QUIC (RFC9000) is a new L4 transport protocol and uses UDP as substrate. For such L4 transport protocols, it might be ambiguous to apply qos classification policy based on what is defined here. In case of QUIC, it needs to identify from other UDP traffic that is traversing the network. Read more on QUIC traffic identification here ( https://quicwg.org/ops-drafts/draft-ietf-quic-manageability.html#name-identifying-quic-traffic).

I think this specification should consider such potential substrate usage of L4 protocols (specially UDP) and hint on the potential augmentations (there might be several ways to do that) or scope it down to not support such cases.

* May be the commented text in the section 4 for protocol identifiers should be updated to reflect what is describes in the section 3 for "underlay-transport". Section 3 talks about underlay transports and how they are set.
2021-09-21
10 Zaheduzzaman Sarker [Ballot Position Update] New position, Discuss, has been recorded for Zaheduzzaman Sarker
2021-09-20
10 Erik Kline
[Ballot comment]
[S3, question]

* Should "ipv6/ttl" actually be "ipv6/hoplimit"?

  I'm not sure what might have been defined in other YANG documents
  elsewhere, …
[Ballot comment]
[S3, question]

* Should "ipv6/ttl" actually be "ipv6/hoplimit"?

  I'm not sure what might have been defined in other YANG documents
  elsewhere, but "ttl" is not the term normally associated with IPv6
  (8200s3).

* Should "ipv6/protocol" actually be "ipv6/nextheader"?

  The field in the header is actually "Next Header" (8200s3), but
  is the intention here to identify the next "logical higher-layer
  protocol", i.e. skipping over other headers that might be in
  between the IPv6 header and, say, a TCP header?

* How does "private or public cloud" count as "external connectivity"?

  Seems like the referenced 4364s11 is primarily concerned with
  Internet access.  I guess it seems odd to me to consider a VPN
  endpoint in a cloud instance especially different from any other
  (e.g., physical) endpoint...
2021-09-20
10 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-09-20
10 Warren Kumari [Ballot comment]
Thank you for this document.

Also thanks to Tim for the OpsDir review.
2021-09-20
10 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2021-09-20
10 Lars Eggert
[Ballot comment]
Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "traditional"; alternatives might be "classic", "classical", …
[Ballot comment]
Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "traditional"; alternatives might be "classic", "classical",
  "common", "conventional", "customary", "fixed", "habitual", "historic",
  "long-established", "popular", "prescribed", "regular", "rooted",
  "time-honored", "universal", "widely used", "widespread".

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

Section 3. , paragraph 62, nit:
> or the QinAny encapsulation. The outer outer VLAN tag is set to a specific va
>                                  ^^^^^^^^^^^
Possible typo: you repeated a word.

Document references draft-ietf-opsawg-l3sm-l3nm-10, but -11 is the latest
available revision.

Document references draft-ietf-opsawg-l2nm-04, but -06 is the latest available
revision.

Document references draft-ietf-teas-ietf-network-slice-framework-00, but -04 is
the latest available revision.
2021-09-20
10 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-09-18
10 Roman Danyliw
[Ballot comment]
** The following YANG items would benefit from references:

-- Section 6.  feature qinany.
-- Section 6.  feature bearer-reference.  Perhaps RFC8049?
-- …
[Ballot comment]
** The following YANG items would benefit from references:

-- Section 6.  feature qinany.
-- Section 6.  feature bearer-reference.  Perhaps RFC8049?
-- Section 6.  feature fast-reroute.  Perhaps RFC6714?
-- Section 6.  identity control-mode.

** Section 6.  identity customer-application.  It is unclear what taxonomy is guiding this list or how this will be used.  A few common user applications that didn’t seem to fit into the existing categories included: printing, version control,  proxies, name/directory/auth services (e.g., DNS, LDAP, Kerberos, AD; is that network management?),

** Section 6.  identity embb, urllc and mmtc.  These appear to be the 5G key words.  If that’s the intent, cite it as such.  The current text of “… demands network performance with a  wide variety of characteristics, such as data rate, latency,  loss rate, reliability, and many other parameters” doesn’t explain anything.

** Section 6.  feature rtg-isis.  Typo. s/routeing/routing/
2021-09-18
10 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-09-17
10 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-09-15
10 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-09-10
10 Cindy Morgan Placed on agenda for telechat - 2021-09-23
2021-09-10
10 Robert Wilton Ballot has been issued
2021-09-10
10 Robert Wilton [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton
2021-09-10
10 Robert Wilton Created "Approve" ballot
2021-09-10
10 Robert Wilton IESG state changed to IESG Evaluation from Waiting for Writeup
2021-09-10
10 Robert Wilton Ballot writeup was changed
2021-09-09
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-09-09
10 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-10.txt
2021-09-09
10 (System) New version accepted (logged-in submitter: Mohamed Boucadair)
2021-09-09
10 Mohamed Boucadair Uploaded new revision
2021-08-30
09 Suresh Krishnan Request for Last Call review by INTDIR Completed: Ready. Reviewer: Suresh Krishnan. Sent review to list.
2021-08-24
09 Victoria Pritchard Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Victoria Pritchard. Sent review to list.
2021-08-13
09 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Victoria Pritchard
2021-08-13
09 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Victoria Pritchard
2021-08-06
09 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-08-04
09 Tim Wicinski Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tim Wicinski. Sent review to list.
2021-07-30
09 Wesley Eddy Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Wesley Eddy. Sent review to list.
2021-07-30
09 Joel Halpern Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Joel Halpern. Sent review to list.
2021-07-27
09 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK from Reviews assigned
2021-07-27
09 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2021-07-27
09 Sabrina Tanamal IANA Experts State changed to Reviews assigned
2021-07-27
09 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2021-07-27
09 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-opsawg-vpn-common-09. 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-vpn-common-09. 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 two 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/

a new namespace will be registered as follows:

ID: yang:ietf-vpn-common
URI: urn:ietf:params:xml:ns:yang:ietf-vpn-common
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/

a new YANG module will be registered as follows:

Name: ietf-vpn-common
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-vpn-common
Prefix: vpn-common
Module:
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.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

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.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2021-07-23
09 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2021-07-23
09 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2021-07-21
09 Magnus Westerlund Request for Last Call review by TSVART is assigned to Wesley Eddy
2021-07-21
09 Magnus Westerlund Request for Last Call review by TSVART is assigned to Wesley Eddy
2021-07-19
09 Carlos Jesús Bernardos Request for Last Call review by INTDIR is assigned to Suresh Krishnan
2021-07-19
09 Carlos Jesús Bernardos Request for Last Call review by INTDIR is assigned to Suresh Krishnan
2021-07-19
09 Ron Bonica Assignment of request for Last Call review by RTGDIR to Ron Bonica was rejected
2021-07-19
09 Éric Vyncke Requested Last Call review by INTDIR
2021-07-19
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tim Polk
2021-07-19
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tim Polk
2021-07-19
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2021-07-19
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2021-07-16
09 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Ron Bonica
2021-07-16
09 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Ron Bonica
2021-07-16
09 Alvaro Retana Requested Last Call review by RTGDIR
2021-07-16
09 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-07-16
09 Amy Vezza
The following Last Call announcement was sent out (ends 2021-08-06):

From: The IESG
To: IETF-Announce
CC: adrian@olddog.co.uk, draft-ietf-opsawg-vpn-common@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com …
The following Last Call announcement was sent out (ends 2021-08-06):

From: The IESG
To: IETF-Announce
CC: adrian@olddog.co.uk, draft-ietf-opsawg-vpn-common@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A Layer 2/3 VPN Common YANG Model) 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 Layer 2/3
VPN Common YANG Model'
  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 2021-08-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a common YANG module that is meant to be reused
  by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN
  network models.

Editorial Note (To be removed by RFC Editor)

  Please update these statements within the document with the RFC
  number to be assigned to this document:

  o  "This version of this YANG module is part of RFC XXXX;"

  o  "RFC XXXX: A Layer 2/3 VPN Common YANG Model";

  o  reference: RFC XXXX

  Also, please update the "revision" date of the YANG module.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/



No IPR declarations have been submitted directly on this I-D.




2021-07-16
09 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-07-16
09 Amy Vezza Last call announcement was changed
2021-07-16
09 Robert Wilton Last call was requested
2021-07-16
09 Robert Wilton Ballot approval text was generated
2021-07-16
09 Robert Wilton Ballot writeup was generated
2021-07-16
09 Robert Wilton IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-07-16
09 Robert Wilton Last call announcement was generated
2021-07-15
09 (System) Changed action holders to Robert Wilton (IESG state changed)
2021-07-15
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-07-15
09 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-09.txt
2021-07-15
09 (System) Forced post of submission
2021-07-15
09 (System) Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Oscar de Dios , Qin WU , samier barguil
2021-07-15
09 Mohamed Boucadair Uploaded new revision
2021-07-12
09 (System) Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Oscar de Dios , Qin WU , samier barguil
2021-07-12
09 Mohamed Boucadair Uploaded new revision
2021-07-12
08 (System) Changed action holders to Oscar de Dios, Qin Wu, Mohamed Boucadair, Robert Wilton, samier barguil (IESG state changed)
2021-07-12
08 Robert Wilton IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2021-05-19
08 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-08.txt
2021-05-19
08 (System) New version approved
2021-05-19
08 (System) Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Oscar de Dios , Qin WU , samier barguil
2021-05-19
08 Mohamed Boucadair Uploaded new revision
2021-05-03
07 Joe Clarke
> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of …
> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of RFC indicated in the title page header?

This draft is requested for publication as a Draft Standard.
This is appropriate for a YANG model that will be implemented and must
interoperate.
The status is properly indicated on the title page.

> (2) The IESG approval announcement includes a Document Announcement
>    Write-Up.
>
> Technical Summary:

This document defines a common YANG module that is available for reuse
by various VPN-related modules such as the Layer 3 VPN and Layer 2 VPN
network models.  The intention is to save re-documenting identical
YANG fragments and to provide a common and consistent approach.  It is
intended that possible future revisions of RFC 8299 and RFC 8466 will
also be able to use this model.

> Working Group Summary:

There was no controversy.

The idea of this model arose in the OPSAWG quite late in the development
of the L2NM and L3NM models, but the authors were quickly able to
identify the common components and build this model.

It is worth noting that, while the L2NM may need a little more work,
this common model and the L3NM are advancing together.

> Document Quality:

The current version of draft-ietf-opsawg-l3sm-l3nm records four
implementations of that model.  By implied inheritence, those
implementations must include implementations of this model. They are
by Nokia, Huawei, Infinera, Ribbon-ECI.

The document shepherd is aware of one other commercial implementation
and one prototype implementation.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Rob Wilton (rwilton@cisco.com) iss 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, please explain why the document is being
>    forwarded to the IESG.

I reviewed this draft in detail during WG last call and all of the
issues I raised have been addressed. I have done a quick review of the
most recent version mainly focused on the changes. This version is
ready for publication.

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

No concerns. Indeed, the number of implementers participating has
resulted in a deep and broad review.

> (5) Do portions of the document need review from a particular or from
>    broader perspective? If so, describe the review that took place.

This document contains a YANG model and so review by YANG specialists
is in order.

An early YANG Doctor review was conducted on -02 by Radek Krejci and
the issues raised were fixed.

A subsequent YANG Doctor review on -06 at WG last call was also done by
Radek Krejci. It found only nits, and those have been fixed in the
current version.

> (6) Describe any specific concerns or issues that the Document
>    Shepherd has with this document that the Responsible Area Director
>    and/or the IESG should be aware of?

No issues.

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

All authors and contributors have so confirmed.

IPR protestations can be found on the thread at
https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/

This records no known IPR from the full set of:
  Authors: Oscar Gonzalez de Dios, Mohamed Boucadair,
          Samier Barguil Giraldo, Qin Wu
  Contributors: Victor Lopez, Italo Busi

The final Contributor (Luis Angel Munoz) noted no IPR on the thread
https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/

> (8) Has an IPR disclosure been filed that references this document?

No IPR disclosed.

> (9) How solid is the WG consensus behind this document? Does it
>    represent the strong concurrence of a few individuals, with others
>    being silent, or does the WG as a whole understand and agree with
>    it?

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.

While the design teams were well-attended, they left some visibility
holes concerning the work and failed to report back to the broader WG.
This has been corrected with regular readouts on the mailing list, as
well as requests to the mailing list for input on decisions.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
>      discontent?

No discontent voiced.

> (11) Identify any ID nits the Document Shepherd has found in this
>      document.

idnits is clean. The warnings have been checked and found to be benign.

> (12) Describe how the document meets any required formal review
>      criteria.

See (5) for YANG Doctor reviews.
YANG validation (in the datatracker) shows 0 errors, 0 warnings

> (13) Have all references within this document been identified as
>      either normative or informative?

Yes. Both normative and informative references are present.

> (14) Are there normative references to documents that are not ready
>      for advancement or are otherwise in an unclear state?

All normative references are to RFCs.

> (15) Are there downward normative references references (see
>      RFC 3967)? If so, list these downward references to support the
>      Area Director in the Last Call procedure.

No downrefs.

> (16) Will publication of this document change the status of any
>      existing RFCs?

No status changes.

> (17) Describe the Document Shepherd's review of the IANA
>      considerations section, especially with regard to its consistency
>      with the body of the document. Confirm that all protocol
>      extensions that the document makes are associated with the
>      appropriate reservations in IANA registries. Confirm that any
>      referenced IANA registries have been clearly identified. Confirm
>      that newly created IANA registries include a detailed
>      specification of the initial contents for the registry, that
>      allocations procedures for future registrations are defined, and
>      a reasonable name for the new registry has been suggested (see
>      RFC 8126).

The IANA section is simple.
It requests assignments from two clearly identified registries in
accordance with the allocation procedures for those registries.
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.

The datatracker 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
>      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for
>      syntax and formatting validation?
>      Does the YANG module comply with the Network Management Datastore
>      Architecture (NMDA) as specified in RFC8342?

The YANG validation results are clean.
To the best of my knowledge, the model complies with the NMDA.
2021-05-03
07 Joe Clarke Responsible AD changed to Robert Wilton
2021-05-03
07 Joe Clarke IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-05-03
07 Joe Clarke IESG state changed to Publication Requested from I-D Exists
2021-05-03
07 Joe Clarke IESG process started in state Publication Requested
2021-05-03
07 Adrian Farrel
> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of …
> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of RFC indicated in the title page header?

This draft is requested for publication as a Draft Standard.
This is appropriate for a YANG model that will be implemented and must
interoperate.
The status is properly indicated on the title page.

> (2) The IESG approval announcement includes a Document Announcement
>    Write-Up.
>
> Technical Summary:

This document defines a common YANG module that is available for reuse
by various VPN-related modules such as the Layer 3 VPN and Layer 2 VPN
network models.  The intention is to save re-documenting identical
YANG fragments and to provide a common and consistent approach.  It is
intended that possible future revisions of RFC 8299 and RFC 8466 will
also be able to use this model.

> Working Group Summary:

There was no controversy.

The idea of this model arose in the OPSAWG quite late in the development
of the L2NM and L3NM models, but the authors were quickly able to
identify the common components and build this model.

It is worth noting that, while the L2NM may need a little more work,
this common model and the L3NM are advancing together.

> Document Quality:

The current version of draft-ietf-opsawg-l3sm-l3nm records four
implementations of that model.  By implied inheritence, those
implementations must include implementations of this model. They are
by Nokia, Huawei, Infinera, Ribbon-ECI.

The document shepherd is aware of one other commercial implementation
and one prototype implementation.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Rob Wilton (rwilton@cisco.com) iss 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, please explain why the document is being
>    forwarded to the IESG.

I reviewed this draft in detail during WG last call and all of the
issues I raised have been addressed. I have done a quick review of the
most recent version mainly focused on the changes. This version is
ready for publication.

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

No concerns. Indeed, the number of implementers participating has
resulted in a deep and broad review.

> (5) Do portions of the document need review from a particular or from
>    broader perspective? If so, describe the review that took place.

This document contains a YANG model and so review by YANG specialists
is in order.

An early YANG Doctor review was conducted on -02 by Radek Krejci and
the issues raised were fixed.

A subsequent YANG Doctor review on -06 at WG last call was also done by
Radek Krejci. It found only nits, and those have been fixed in the
current version.

> (6) Describe any specific concerns or issues that the Document
>    Shepherd has with this document that the Responsible Area Director
>    and/or the IESG should be aware of?

No issues.

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

All authors and contributors have so confirmed.

IPR protestations can be found on the thread at
https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/

This records no known IPR from the full set of:
  Authors: Oscar Gonzalez de Dios, Mohamed Boucadair,
          Samier Barguil Giraldo, Qin Wu
  Contributors: Victor Lopez, Italo Busi

The final Contributor (Luis Angel Munoz) noted no IPR on the thread
https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/

> (8) Has an IPR disclosure been filed that references this document?

No IPR disclosed.

> (9) How solid is the WG consensus behind this document? Does it
>    represent the strong concurrence of a few individuals, with others
>    being silent, or does the WG as a whole understand and agree with
>    it?

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.

While the design teams were well-attended, they left some visibility
holes concerning the work and failed to report back to the broader WG.
This has been corrected with regular readouts on the mailing list, as
well as requests to the mailing list for input on decisions.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
>      discontent?

No discontent voiced.

> (11) Identify any ID nits the Document Shepherd has found in this
>      document.

idnits is clean. The warnings have been checked and found to be benign.

> (12) Describe how the document meets any required formal review
>      criteria.

See (5) for YANG Doctor reviews.
YANG validation (in the datatracker) shows 0 errors, 0 warnings

> (13) Have all references within this document been identified as
>      either normative or informative?

Yes. Both normative and informative references are present.

> (14) Are there normative references to documents that are not ready
>      for advancement or are otherwise in an unclear state?

All normative references are to RFCs.

> (15) Are there downward normative references references (see
>      RFC 3967)? If so, list these downward references to support the
>      Area Director in the Last Call procedure.

No downrefs.

> (16) Will publication of this document change the status of any
>      existing RFCs?

No status changes.

> (17) Describe the Document Shepherd's review of the IANA
>      considerations section, especially with regard to its consistency
>      with the body of the document. Confirm that all protocol
>      extensions that the document makes are associated with the
>      appropriate reservations in IANA registries. Confirm that any
>      referenced IANA registries have been clearly identified. Confirm
>      that newly created IANA registries include a detailed
>      specification of the initial contents for the registry, that
>      allocations procedures for future registrations are defined, and
>      a reasonable name for the new registry has been suggested (see
>      RFC 8126).

The IANA section is simple.
It requests assignments from two clearly identified registries in
accordance with the allocation procedures for those registries.
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.

The datatracker 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
>      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for
>      syntax and formatting validation?
>      Does the YANG module comply with the Network Management Datastore
>      Architecture (NMDA) as specified in RFC8342?

The YANG validation results are clean.
To the best of my knowledge, the model complies with the NMDA.
2021-04-13
07 Adrian Farrel
> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of …
> (1) What type of RFC is being requested
>    Why is this the proper type of RFC?
>    Is this type of RFC indicated in the title page header?

This draft is requested for publication as a Draft Standard.
This is appropriate for a YANG model that will be implemented and must
interoperate.
The status is properly indicated on the title page.

> (2) The IESG approval announcement includes a Document Announcement
>    Write-Up.
>
> Technical Summary:

This document defines a common YANG module that is available for reuse
by various VPN-related modules such as the Layer 3 VPN and Layer 2 VPN
network models.  The intention is to save re-documenting identical
YANG fragments and to provide a common and consistent approach.  It is
intended that possible future revisions of RFC 8299 and RFC 8466 will
also be able to use this model.

> Working Group Summary:

There was no controversy.

The idea of this model arose in the OPSAWG quite late in the development
of the L2NM and L3NM models, but the authors were quickly able to
identify the common components and build this model.

It is worth noting that, while the L2NM may need a little more work,
this common model and the L3NM are advancing together.

> Document Quality:

The current version of draft-ietf-opsawg-l3sm-l3nm records four
implementations of that model.  By implied inheritence, those
implementations must include implementations of this model. They are
by Nokia, Huawei, Infinera, Ribbon-ECI.

The document shepherd is aware of one other commercial implementation
and one prototype implementation.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Rob Wilton (rwilton@cisco.com) iss 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, please explain why the document is being
>    forwarded to the IESG.

I reviewed this draft in detail during WG last call and all of the
issues I raised have been addressed. I have done a quick review of the
most recent version mainly focused on the changes. This version is
ready for publication.

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

No concerns. Indeed, the number of implementers participating has
resulted in a deep and broad review.

> (5) Do portions of the document need review from a particular or from
>    broader perspective? If so, describe the review that took place.

This document contains a YANG model and so review by YANG specialists
is in order.
An early YANG Doctor review was conducted on -02 by Radek Krejci and
the issues raised were fixed.
A subsequent YANG Doctor review on -06 at WG last call was also done by
Radek Krejci. It found only nits, and those have been fixed in the
current version.

> (6) Describe any specific concerns or issues that the Document
>    Shepherd has with this document that the Responsible Area Director
>    and/or the IESG should be aware of?

No issues.

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

All authors and contributors have so confirmed.

IPR protestations can be found on the thread at
https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/

This records no known IPR from the full set of:
  Authors: Oscar Gonzalez de Dios, Mohamed Boucadair,
          Samier Barguil Giraldo, Qin Wu
  Contributors: Victor Lopez, Italo Busi

The final Contributor (Luis Angel Munoz) noted no IPR on the thread
https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/

> (8) Has an IPR disclosure been filed that references this document?

No IPR disclosed.

> (9) How solid is the WG consensus behind this document? Does it
>    represent the strong concurrence of a few individuals, with others
>    being silent, or does the WG as a whole understand and agree with
>    it?

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 discontent voiced.

> (11) Identify any ID nits the Document Shepherd has found in this
>      document.

idnits is clean. The warnings have been checked and found to be benign.

> (12) Describe how the document meets any required formal review
>      criteria.

See (5) for YANG Doctor reviews.
YANG validation (in the datatracker) shows 0 errors, 0 warnings

> (13) Have all references within this document been identified as
>      either normative or informative?

Yes. Both normative and informative references are present.

> (14) Are there normative references to documents that are not ready
>      for advancement or are otherwise in an unclear state?

All normative references are to RFCs.

> (15) Are there downward normative references references (see
>      RFC 3967)? If so, list these downward references to support the
>      Area Director in the Last Call procedure.

No downrefs.

> (16) Will publication of this document change the status of any
>      existing RFCs?

No status changes.

> (17) Describe the Document Shepherd's review of the IANA
>      considerations section, especially with regard to its consistency
>      with the body of the document. Confirm that all protocol
>      extensions that the document makes are associated with the
>      appropriate reservations in IANA registries. Confirm that any
>      referenced IANA registries have been clearly identified. Confirm
>      that newly created IANA registries include a detailed
>      specification of the initial contents for the registry, that
>      allocations procedures for future registrations are defined, and
>      a reasonable name for the new registry has been suggested (see
>      RFC 8126).

The IANA section is simple.
It requests assignments from two clearly identified registries in
accordance with the allocation procedures for those registries.
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.

The datatracker 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
>      (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for
>      syntax and formatting validation?
>      Does the YANG module comply with the Network Management Datastore
>      Architecture (NMDA) as specified in RFC8342?

The YANG validation results are clean.
To the best of my knowledge, the model complies with the NMDA.
2021-04-08
07 Joe Clarke IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-04-08
07 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-07.txt
2021-04-08
07 (System) New version approved
2021-04-08
07 (System) Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Oscar de Dios , Qin WU , samier barguil
2021-04-08
07 Mohamed Boucadair Uploaded new revision
2021-04-07
06 Adrian Farrel
IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/
This records no known IPR from the full set of:
Authors: Oscar Gonzalez de Dios, Mohamed …
IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/
This records no known IPR from the full set of:
Authors: Oscar Gonzalez de Dios, Mohamed Boucadair, Samier Barguil Giraldo, Qin Wu
Contributors: Victor Lopez, Italo Busi
With the final Contributor (Luis Angel Munoz) noting no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/
2021-04-07
06 Adrian Farrel
IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/
This records no known IPR from the full set of:
Authors: Oscar Gonzalez de Dios, Mohamed …
IPR protestations can be found on the thread https://mailarchive.ietf.org/arch/msg/opsawg/ajoTnvgF5YuYtnUk1Li5BdnBJxQ/
This records no known IPR from the full set of:
Authors: Oscar Gonzalez de Dios, Mohamed Boucadair, Samier Barguil Giraldo, Qin Wu
Contributors: Victor Lopez
With the final Contributor (Luis Angel Munoz) noting no IPR on the thread https://mailarchive.ietf.org/arch/msg/opsawg/3U-FxleAm739Zx4gMAHw3eWLIdw/
2021-04-05
06 Ron Bonica Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Ron Bonica. Sent review to list.
2021-03-31
06 Min Ye Request for Last Call review by RTGDIR is assigned to Ron Bonica
2021-03-31
06 Min Ye Request for Last Call review by RTGDIR is assigned to Ron Bonica
2021-03-31
06 Min Ye Assignment of request for Last Call review by RTGDIR to Matthew Bocci was rejected
2021-03-31
06 Min Ye Request for Last Call review by RTGDIR is assigned to Matthew Bocci
2021-03-31
06 Min Ye Request for Last Call review by RTGDIR is assigned to Matthew Bocci
2021-03-31
06 Min Ye Assignment of request for Last Call review by RTGDIR to Dave Sinicrope was marked no-response
2021-03-30
06 Wesley Eddy Request for Last Call review by TSVART Completed: Almost Ready. Reviewer: Wesley Eddy. Sent review to list.
2021-03-29
06 Joe Clarke Notification list changed to adrian@olddog.co.uk because the document shepherd was set
2021-03-29
06 Joe Clarke Document shepherd changed to Adrian Farrel
2021-03-28
06 Radek Krejčí Request for Last Call review by YANGDOCTORS Completed: Ready with Nits. Reviewer: Radek Krejčí. Sent review to list.
2021-03-23
06 Magnus Westerlund Request for Last Call review by TSVART is assigned to Wesley Eddy
2021-03-23
06 Magnus Westerlund Request for Last Call review by TSVART is assigned to Wesley Eddy
2021-03-22
06 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Radek Krejčí
2021-03-22
06 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Radek Krejčí
2021-03-22
06 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Dave Sinicrope
2021-03-22
06 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Dave Sinicrope
2021-03-22
06 Joe Clarke Requested Last Call review by YANGDOCTORS
2021-03-22
06 Joe Clarke Requested Last Call review by TSVART
2021-03-22
06 Joe Clarke Requested Last Call review by RTGDIR
2021-03-22
06 Joe Clarke IETF WG state changed to In WG Last Call from WG Document
2021-02-22
06 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-06.txt
2021-02-22
06 (System) New version approved
2021-02-22
06 (System) Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Oscar de Dios , Qin WU , samier barguil
2021-02-22
06 Mohamed Boucadair Uploaded new revision
2021-02-21
05 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-05.txt
2021-02-21
05 (System) New version approved
2021-02-21
05 (System) Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Oscar de Dios , Qin WU , samier barguil
2021-02-21
05 Mohamed Boucadair Uploaded new revision
2021-02-12
04 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-04.txt
2021-02-12
04 (System) New version approved
2021-02-12
04 (System) Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Oscar de Dios , Qin WU , samier barguil
2021-02-12
04 Mohamed Boucadair Uploaded new revision
2021-01-14
03 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-03.txt
2021-01-14
03 (System) New version approved
2021-01-14
03 (System) Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Oscar de Dios , Qin WU , samier barguil
2021-01-14
03 Mohamed Boucadair Uploaded new revision
2020-12-18
02 Radek Krejčí Request for Early review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Radek Krejčí. Sent review to list.
2020-11-18
02 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Radek Krejčí
2020-11-18
02 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Radek Krejčí
2020-11-18
02 Joe Clarke Requested Early review by YANGDOCTORS
2020-10-29
02 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-02.txt
2020-10-29
02 (System) New version approved
2020-10-29
02 (System) Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Oscar de Dios , samier barguil , Qin WU
2020-10-29
02 Mohamed Boucadair Uploaded new revision
2020-10-19
01 Joe Clarke Changed consensus to Yes from Unknown
2020-10-19
01 Joe Clarke Intended Status changed to Proposed Standard from None
2020-09-16
01 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-01.txt
2020-09-16
01 (System) New version approved
2020-09-16
01 (System) Request for posting confirmation emailed to previous authors: samier barguil , Oscar de Dios , Mohamed Boucadair , Qin WU
2020-09-16
01 Mohamed Boucadair Uploaded new revision
2020-09-02
00 Mohamed Boucadair This document now replaces draft-bgbw-opsawg-vpn-common instead of None
2020-09-02
00 Mohamed Boucadair New version available: draft-ietf-opsawg-vpn-common-00.txt
2020-09-02
00 (System) New version accepted (logged-in submitter: Mohamed Boucadair)
2020-09-02
00 Mohamed Boucadair Uploaded new revision