[L3sm] Next steps with draft-wu-l3sm-rfc8049bis-03.txt

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 06 September 2017 11:16 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 395C5132710; Wed, 6 Sep 2017 04:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 6c-PfJGG0I9J; Wed, 6 Sep 2017 04:16:10 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E2613202D; Wed, 6 Sep 2017 04:16:09 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v86BG4qg030820; Wed, 6 Sep 2017 12:16:04 +0100
Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v86BG2qp030811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Sep 2017 12:16:03 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-wu-l3sm-rfc8049bis@ietf.org>, "'David Ball'" <daviball@cisco.com>, "Jan Lindblad \(jlindbla\)" <jlindbla@cisco.com>
Cc: "'Benoit Claise \(bclaise\)'" <bclaise@cisco.com>, "'l3sm'" <l3sm@ietf.org>
Date: Wed, 6 Sep 2017 12:16:00 +0100
Message-ID: <07bb01d32701$85de8640$919b92c0$@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: AdMnALKJ5ROrY5xkSrKr7O/S04YrYw==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23306.006
X-TM-AS-Result: No--27.335-10.0-31-10
X-imss-scan-details: No--27.335-10.0-31-10
X-TMASE-MatchedRID: a5GL+Yxi3LGaTvR1/wQOTxes/RxhysDbUAjrAJWsTe9rH7R0RhorDOfQ ukOt100SPjRMCudn1tx/1ESOim43skj+bWNtFbsnYD9XTRdaMO1u/Xr6CKXiN8Lk9ZplaJOMTrX 2zJAY4u6NWH3MgdMzZTNvu0+lyu1bnaXB2D7HJHGVOwZbcOalSyHAogh2SU5XMRYwbEmgAkGW9v TNbx/R7197C1v9Aaj5W6eSoQerThXXFDY6Be2LlQUkbxmZfIp1GbJMFqqIm9y4u8jA2YTmnNs1C HzkaGoi0e+MIg7zZb6VrHVyyclsFWm9EZ0V6jiDaqa/YVBLYUkITdx0fxCcBdOwk6TvElPUp7w8 lBHFpo/WQWNR4E9ekGXz5iibTJbmk0+dL0YVVKAo0OKLHX2pgfx3eAlFiEvxr57t38RBizZPmRf uVx1UBDFn1ScbWur/1HinZFrgJn7/3pF4wGrfyBcqpH7D1rtQxBgaBynd2vna+IH8mvgPVGyyOl EFJ1wq16im8aWNj2tb03Ivm92AseBX8Ypq0C8lBEfU2vugRF06En2bnefhoDERi1haWZ7IPlAWw fVA2w7uX/km0O1YYB5hmP6OM/PJv1l2Uvx6idrQLMMjQrtwDPoA9r2LThYYKrauXd3MZDUD/dHy T/Xh7Q==
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/VZ6o8rbRerueJqnV0MXk7Nt20ek>
Subject: [L3sm] Next steps with draft-wu-l3sm-rfc8049bis-03.txt
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: Wed, 06 Sep 2017 11:16:13 -0000

All,

We don't have a working group that has to come to consensus, and we will have an IETF last call that the AD can use to gauge wider consensus.
We also have to recall that the scope of this work is to "fix up" RFC 8049 not to make any radical changes to what that RFC does.

I see quite a lot of discussion over the last few revisions collecting and addressing review comments from Jan and David. On the whole it seems to me that most of the comments have resulted in text changes and positive progress with the document. I note that in a small minority of cases the comments resulted in the authors saying something like "No, that's not what we were trying to do with this work," and as far as I am concerned, this is OK within the spirit of RFC 7282 - the comments have been addressed and if we had a WG we would be able to claim *rough* consensus.

I'd like to thank all involved for what has been a great example of pragmatic cooperation advancing this work.

My plan now is to send a document write-up to Benoit and ask him to advance the publication process.

Best,
Adrian

> -----Original Message-----
> From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu
> Sent: 06 September 2017 11:25
> To: l3sm; David Ball
> Cc: Benoit Claise (bclaise); adrian
> Subject: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-03.txt
> 
> We have incorporated additional comments from David in v-(03).
> https://www.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-03
> Thank David, thanks for L3SM design team help complete this.
> 
> -Qin
> -----邮件原件-----
> 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> 发送时间: 2017年9月6日 18:18
> 收件人: Qin Wu; Luis Tomotaki; Kenichi Ogaki; Stephane Litkowski
> 主题: New Version Notification for draft-wu-l3sm-rfc8049bis-03.txt
> 
> 
> A new version of I-D, draft-wu-l3sm-rfc8049bis-03.txt has been successfully
> submitted by Qin Wu and posted to the IETF repository.
> 
> Name:		draft-wu-l3sm-rfc8049bis
> Revision:	03
> Title:		YANG Data Model for L3VPN Service Delivery
> Document date:	2017-09-06
> Group:		Individual Submission
> Pages:		181
> URL:            https://www.ietf.org/internet-drafts/draft-wu-l3sm-rfc8049bis-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/
> Htmlized:       https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-03
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-wu-l3sm-rfc8049bis-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-03
> 
> 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.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> L3sm mailing list
> L3sm@ietf.org
> https://www.ietf.org/mailman/listinfo/l3sm