Re: [L3sm] Followup of RFC8049bis

"Ogaki, Kenichi" <ke-oogaki@kddi.com> Fri, 14 July 2017 08:15 UTC

Return-Path: <ke-oogaki@kddi.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 E1278126B6D for <l3sm@ietfa.amsl.com>; Fri, 14 Jul 2017 01:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nscqqVafwUDw for <l3sm@ietfa.amsl.com>; Fri, 14 Jul 2017 01:15:35 -0700 (PDT)
Received: from post-send.kddi.com (athena2.kddi.com [27.90.165.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3001E1200C1 for <l3sm@ietf.org>; Fri, 14 Jul 2017 01:15:34 -0700 (PDT)
Received: from LTMC2121.kddi.com (LTMC2121.kddi.com [10.206.0.61]) by post-send.kddi.com (KDDI Mail) with ESMTP id E39F4E0055; Fri, 14 Jul 2017 17:15:33 +0900 (JST)
Received: from LTMC2146.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2121.kddi.com with ESMTP; Fri, 14 Jul 2017 17:15:33 +0900
Received: from LTMC2146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id B137530005D; Fri, 14 Jul 2017 17:15:33 +0900 (JST)
Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2146.kddi.com (Postfix) with ESMTP id A5EC0300051; Fri, 14 Jul 2017 17:15:33 +0900 (JST)
Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id v6E8FXwO017555; Fri, 14 Jul 2017 17:15:33 +0900
Received: from LTMC2152.kddi.com.mid_23547935 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id v6E85SJI002720; Fri, 14 Jul 2017 17:05:28 +0900
X-SA-MID: 23547935
Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Fri, 14 Jul 2017 17:05:28 +0900
From: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
To: 'David Ball' <daviball@cisco.com>, 'Qin Wu' <bill.wu@huawei.com>, l3sm@ietf.org
Cc: "'Benoit Claise (bclaise)'" <bclaise@cisco.com>, adrian@olddog.co.uk
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>
In-Reply-To: <a274ee4a-f51a-201f-a8ff-a45a5e0a5ac3@cisco.com>
Date: Fri, 14 Jul 2017 17:05:28 +0900
Message-ID: <00a001d2fc77$f4a53060$ddef9120$@kddi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFt7Pfdo0zsTznSH6gPl8UfrToyiwF/DcMJAdAfHcMBM/6/AAFtjpOvAswpt5EBwG0YnwFr5HoFor2eJCA=
Content-Language: ja
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/v5gdLURAbaRpkd994WY6uAXT0RU>
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: Fri, 14 Jul 2017 08:15:37 -0000

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> <mailto:daviball@cisco.com>