|
Dear all,
Based on the feedback received, the authors produced version 7. I would like to highlight those two changes (the only two changes btw). In the abstract: This document obsoletes RFC 8049 to replace the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module, and some clarifications to the text.In section 1: Changes are highlighted here: https://tools.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-07.txtThe YANG module described in [RFC8049] cannot be implemented because of issues around the use of XPATH. This document obsoletes [RFC8049] by creating a new module with the same name that is not backward compatible (in the sense described in YANG 1.1 [RFC7950]). The changes (listed in full in Section 1.4) are small in scope, but include fixes to the module to make it possible to implement. Since RFC8049 is not implementable and therefore not implemented, keeping the same YANG module name seems about right. I'll collect feedback for a week. Note that this draft is on the IESG telechat on Oct 26th. Regards, Benoit The IESG has received a request from an individual submitter to consider the following document: - 'YANG Data Model for L3VPN Service Delivery' <draft-wu-l3sm-rfc8049bis-04.txt> 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 ietf@xxxxxxxx mailing lists by 2017-10-11. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document. If approved, this document obsoletes RFC 8049. The changes are a series of small fixes to the YANG module, and some clarifications to the text. The file can be obtained via https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ballot/ No IPR declarations have been submitted directly on this I-D. Working Group Summary RFC 8049 was the product of the L3SM working group, but that WG has been closed. No other WG covers this topic. However, the L3SM list remains open: changes and revisions were publicised and discussed there The document contains these normative downward references. See RFC 3967 for additional information: rfc3022: Traditional IP Network Address Translator (Traditional NAT) (Informational - IETF stream) . |