Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> (YANG Data Model for L3VPN Service Delivery) to Proposed Standard
Benoit Claise <bclaise@cisco.com> Sat, 14 October 2017 06:55 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C5913263F; Fri, 13 Oct 2017 23:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 n_aeR6EeXIhi; Fri, 13 Oct 2017 23:55:19 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F95E124B17; Fri, 13 Oct 2017 23:55:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9230; q=dns/txt; s=iport; t=1507964118; x=1509173718; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=yxxMxuMjX7j+N5nZGp7nIOJrP0MymiSWMXV19WLcnZI=; b=BczoViPzbIuxCE3dUC+h3k9qISa+9hamzwr3Xgbjrtpe/AhwTMW4ob6H 0xphgbYY2+ltE6eBNchQOgw+/Lm8VgaGCDXoSLqnryfRrgv1N8GdsbKrk zeL97PA+EhNfYhhr/v2Jm2OJkwrMavpJ9L4kqO6NWWISPx2Wnie7CESUd Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B1AQBNtOFZ/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBhENuJ4N6ixOhJIU/EIIECiOFGAKFFhcBAgEBAQEBAQFrKIUeBiNLCxALOwcCAkYRBgEMBgIBAYoZEKp7gicmixABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMtg1iBaiuCf4MygRcEEYM6gmEFkUaQAYdfg1wMiSSCFIV2g1qHMI4Ph2CBOSABNoFZNCEIHRVJglQBD4JhFxmBUD42AYhBgkQBAQE
X-IronPort-AV: E=Sophos;i="5.43,374,1503360000"; d="scan'208,217";a="658075399"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2017 06:55:13 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9E6tBuM027283; Sat, 14 Oct 2017 06:55:12 GMT
Subject: Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> (YANG Data Model for L3VPN Service Delivery) to Proposed Standard
To: ietf@ietf.org, IETF-Announce <ietf-announce@ietf.org>
Cc: adrian@olddog.co.uk, draft-wu-l3sm-rfc8049bis@ietf.org, Jan Lindblad <janl@tail-f.com>
References: <150531137507.30405.6179845967838123305.idtracker@ietfa.amsl.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <3d65a756-fe9b-19de-fd94-40f4618d729b@cisco.com>
Date: Sat, 14 Oct 2017 08:55:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <150531137507.30405.6179845967838123305.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------695E72A641E10EBED46D5A00"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/f4xmJk651EYzIlGi2bgDxAWQkWU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Oct 2017 06:55:21 -0000
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 obsoletesRFC 8049 <https://tools.ietf.org/html/rfc8049> 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: The YANG module described in [RFC8049 <https://tools.ietf.org/html/rfc8049>] cannot be implemented because of issues around the use of XPATH. This document obsoletes [RFC8049 <https://tools.ietf.org/html/rfc8049>] by creating a new module with the same name that is not backward compatible (in the sense described in YANG 1.1 [RFC7950 <https://tools.ietf.org/html/rfc7950>]). The changes (listed in full inSection 1.4 <https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-07#section-1.4>) are small in scope, but include fixes to the module to make it possible to implement. Changes are highlighted here: https://tools.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-07.txt 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@ietf.org mailing lists by 2017-10-11. 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 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) > > > > . >
- Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> … Benoit Claise
- Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> … Randy Presuhn
- Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> … Benoit Claise
- Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> … Randy Presuhn
- RE: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> … Adrian Farrel
- Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> … Randy Presuhn