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 |