Re: [L3sm] Followup of RFC8049bis

Qin Wu <bill.wu@huawei.com> Thu, 20 July 2017 15:36 UTC

Return-Path: <bill.wu@huawei.com>
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 D43E812EC46 for <l3sm@ietfa.amsl.com>; Thu, 20 Jul 2017 08:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 M1wkuW6PY5Ey for <l3sm@ietfa.amsl.com>; Thu, 20 Jul 2017 08:36:40 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7E61252BA for <l3sm@ietf.org>; Thu, 20 Jul 2017 08:36:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRQ61258; Thu, 20 Jul 2017 15:36:38 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Jul 2017 16:36:37 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.9]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 20 Jul 2017 23:36:33 +0800
From: Qin Wu <bill.wu@huawei.com>
To: David Ball <daviball@cisco.com>, "Ogaki, Kenichi" <ke-oogaki@kddi.com>, "l3sm@ietf.org" <l3sm@ietf.org>
CC: "'Benoit Claise (bclaise)'" <bclaise@cisco.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Thread-Topic: [L3sm] Followup of RFC8049bis
Thread-Index: AdLz4gQczWlV+rrbRBePS8Ez8xfWvQBX1HKAAQwkggAAIE/cAAAtOxkAAAGv/IAANMiFAAABlSqAACsm+gAA0TnHgAB9Aari
Date: Thu, 20 Jul 2017 15:36:33 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AA284A9@nkgeml513-mbx.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA9A9956B2@nkgeml513-mbx.china.huawei.com> <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> <B8F9A780D330094D99AF023C5877DABA9A9A7FBD@nkgeml513-mbx.china.huawei.com> <4b5d80e8-147a-50b7-f78f-2eef9de6c231@cisco.com> <000301d2faeb$22864890$6792d9b0$@kddi.com> <42e2c5d8-05fa-65f2-52e4-ec2db62b0a6f@cisco.com> <00e601d2fbc5$04470ce0$0cd526a0$@kddi.com> <a274ee4a-f51a-201f-a8ff-a45a5e0a5ac3@cisco.com> <00a001d2fc77$f4a53060$ddef9120$@kddi.com>, <ea56932c-0055-fdd0-0f5b-159b12e37e53@cisco.com>
In-Reply-To: <ea56932c-0055-fdd0-0f5b-159b12e37e53@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.72.133]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5970CE06.020F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.9, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 669fe98d0a128425993887b2b2a47511
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/bgov_y3MbJDNgXkaLnOeqdOWn_4>
Subject: Re: [L3sm] Followup of RFC8049bis
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: Thu, 20 Jul 2017 15:36:42 -0000

In trip, will ping all other L2SM design team members for this, and get back to you.

-Qin
________________________________________
发件人: David Ball [daviball@cisco.com]
发送时间: 2017年7月18日 19:56
收件人: Ogaki, Kenichi; Qin Wu; l3sm@ietf.org
抄送: 'Benoit Claise (bclaise)'; adrian@olddog.co.uk
主题: Re: [L3sm] Followup of RFC8049bis

Qin, do you agree here?  Could we put some statement like this in section 5?

     David

On 14/07/2017 09:05, Ogaki, Kenichi wrote:
> Hi David,
>
>> Another way of looking at it: would it be correct to say that the way the model is intended to be used is that the SP's system is the server and the customer's
>> system is the client?
> [KO] This best describes the rational of this model.
>
>> In that case, any information intended to be passed from the SP to the customer could be modelled with "config false", meaning that the
>> SP could change it but the customer could not.
> [KO] Yes, "config false" or NACM is utilized for this purpose.
>
> Thanks,
> Kenichi
>
> -----Original Message-----
> From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball
> Sent: Thursday, July 13, 2017 8:30 PM
> To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org
> Cc: 'Benoit Claise (bclaise)'; adrian@olddog.co.uk
> Subject: Re: [L3sm] Followup of RFC8049bis
>
> Hi Kenichi,
>
>
> On 13/07/2017 11:44, Ogaki, Kenichi wrote:
>
>
>               Anyway, does the following paragraph in section 5 cover the rational?
>
>               The idea of the L3 IP VPN service model is to propose an abstracted
>                   interface between customers and network operators to manage
>                   configuration of components of an L3VPN service.  A typical scenario
>                   would be to use this model as an input for an orchestration layer
>                   that will be responsible for translating it to an orchestrated
>                   configuration of network elements that will be part of the service.
>
>       To me, this paragraph does not clearly express that the information that needs to be passed from the SP to the customer is not in scope.  I would like to see that stated explicitly, if that is indeed the intent.
>
>       [KO] I can't agree with that.
>       Even though the current model doesn't intend something, to exclude their future possibility only brings a disadvantage rather than an advantage.
>       I can't see any major advantage to state that explicitly.
>
> I agree, we do not want to preclude future enhancements.  However, I do think this is critical to help an unfamiliar reader understand and use the model we have today.  How about text like this:
>
> "The version of the model described in this document does not include information that is passed from the SP to the customer.  This could be added in a future extension or augmentation."
>
> Another way of looking at it: would it be correct to say that the way the model is intended to be used is that the SP's system is the server and the customer's system is the client?  In that case, any information intended to be passed from the SP to the customer could be modelled with "config false", meaning that the SP could change it but the customer could not.
>
>
>      David
>
>

--
David Ball
<daviball@cisco.com>