[L3sm] FW: RFC 8299 on YANG Data Model for L3VPN Service Delivery

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 20 January 2018 14:05 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA871273B1 for <l3sm@ietfa.amsl.com>; Sat, 20 Jan 2018 06:05:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HpIi9UTm9BJ for <l3sm@ietfa.amsl.com>; Sat, 20 Jan 2018 06:05:53 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C024126DEE for <l3sm@ietf.org>; Sat, 20 Jan 2018 06:05:52 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0KE5g2b012804; Sat, 20 Jan 2018 14:05:42 GMT
Received: from 950129200 ([193.57.120.8]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0KE5bYs012776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jan 2018 14:05:42 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'l3sm'" <l3sm@ietf.org>
Cc: "'Jan Lindblad'" <janl@tail-f.com>, <bclaise@cisco.com>, "Alissa Cooper" <alissa@cooperw.in>
References: <20180120003441.F0216B816CE@rfc-editor.org>
In-Reply-To: <20180120003441.F0216B816CE@rfc-editor.org>
Date: Sat, 20 Jan 2018 14:05:33 -0000
Message-ID: <022e01d391f7$bfd89c30$3f89d490$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLaVloQXBgg64B24U8WeLDmmUA+tqFvPw9g
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23610.000
X-TM-AS-Result: No--17.799-10.0-31-10
X-imss-scan-details: No--17.799-10.0-31-10
X-TMASE-MatchedRID: N84m3lauH1lCBQieSpAGz1aOpp/sV5nVGSqdEmeD/nUn+p552csI1Uit mFSENCSpnyPGReVObKv30M4BlQhibQ5G/b6aSGR82Hdvv/MGE3WrDPxf3LbqpH9PolLFiCCl/lA 8xyitUkJt1epbeYEZ7vFPDHhQkgxygtJ1kfzs6mB2IsPC9Z62GEdEl9TsJWRaSO/R4/CGPEjAdu QncIjXRrGK+VK0ehd9cAwOsowI+VJ+HQEHIpIaky0x8J2DopEN+q1Y+/eEArYsugxReYWqZuPkU bY9XEb71rAakX1NXfNp0oDM6nL2lvs6AFvEdeZf4RtSDjG+z7Dl+C/TtJPbax9c+XdX53q+T5kX 7lcdVAQxZ9UnG1rq/9R4p2Ra4CZ+/96ReMBq38gXKqR+w9a7UMQYGgcp3dr52viB/Jr4D1QJ/aH 0DaAUBWekWp5D93lmW0mM9XFuCEzyvcecKfVZZqDH6drx3JPV6Jj6zYvfFARElaZ44wdr5OUdbt dHBD0zadeJlthYEDo7V7UkL/lJoivXS/M8U4EcvHKClHGjjr1nLk6tQLcY6fiv0XqZ+vxQy8c6M Kvt/YF9xgmPIscKX5GleN/xU/tfV0ThOjwD9lyeAiCmPx4NwJwhktVkBBrQnbsRz8aH7zarusVR y4an8bxAi7jPoeEQftwZ3X11IV0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/aZMy2G-0CuwE_CdQSjfigyeRaC0>
Subject: [L3sm] FW: RFC 8299 on YANG Data Model for L3VPN Service Delivery
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jan 2018 14:05:56 -0000

Thanks to Qin and the other authors for their tireless (?) work to get this revision out.

Thanks, too, to Jan for his excellent and helpful reviews, and thanks to our two ADs (yes, it took two ADs!) for pushing to get this published this year.

We hope to apply all the lessons learned to the L2SM work that is approaching WG last call in the L2SM working group.

Best,
Adrian

> -----Original Message-----
> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of rfc-
> editor@rfc-editor.org
> Sent: 20 January 2018 00:35
> To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org
> Cc: drafts-update-ref@iana.org; rfc-editor@rfc-editor.org
> Subject: RFC 8299 on YANG Data Model for L3VPN Service Delivery
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>         RFC 8299
> 
>         Title:      YANG Data Model for L3VPN
>                     Service Delivery
>         Author:     Q. Wu, Ed.,
>                     S. Litkowski,
>                     L. Tomotaki,
>                     K. Ogaki
>         Status:     Standards Track
>         Stream:     IETF
>         Date:       January 2018
>         Mailbox:    bill.wu@huawei.com,
>                     stephane.litkowski@orange.com,
>                     luis.tomotaki@verizon.com,
>                     ke-oogaki@kddi.com
>         Pages:      188
>         Characters: 344738
>         Obsoletes:  RFC 8049
> 
>         I-D Tag:    draft-wu-l3sm-rfc8049bis-11.txt
> 
>         URL:        https://www.rfc-editor.org/info/rfc8299
> 
>         DOI:        10.17487/RFC8299
> 
> 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.
> 
> This document obsoletes RFC 8049; it replaces 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.
> 
> This is now a Proposed Standard.
> 
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
> standardization state and status of this protocol.  Distribution of this
> memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC