Re: [L3sm] Followup of RFC8049bis

David Ball <daviball@cisco.com> Thu, 13 July 2017 11:30 UTC

Return-Path: <daviball@cisco.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 5D1B512EC15 for <l3sm@ietfa.amsl.com>; Thu, 13 Jul 2017 04:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 fgWbOwIbXixX for <l3sm@ietfa.amsl.com>; Thu, 13 Jul 2017 04:30:02 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F03112EAFF for <l3sm@ietf.org>; Thu, 13 Jul 2017 04:30:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4748; q=dns/txt; s=iport; t=1499945401; x=1501155001; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=TrMflxz3J8EhMkitUYD28qIuh7kgVRvcvU+2jWu0JZg=; b=VMEYRkRMIBPi2XjGvm2d+66oVsqqqsEwGbu9Qa+BYrU9UPltPjwoFpS1 AQjjL80rqDxh6B0g/XLI09XZlno5mUWAakTFs5MWN61FRIkasXSXPwVKc SQMN5CcrY+Dytcz0ui0j56GEfOJbbZePZupM363zZXqD3NGFtgqX3t8cz A=;
X-IronPort-AV: E=Sophos;i="5.40,353,1496102400"; d="scan'208,217";a="653217027"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2017 11:29:59 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6DBTroU009135; Thu, 13 Jul 2017 11:29:54 GMT
To: "Ogaki, Kenichi" <ke-oogaki@kddi.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>
From: David Ball <daviball@cisco.com>
Message-ID: <a274ee4a-f51a-201f-a8ff-a45a5e0a5ac3@cisco.com>
Date: Thu, 13 Jul 2017 12:29:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <00e601d2fbc5$04470ce0$0cd526a0$@kddi.com>
Content-Type: multipart/alternative; boundary="------------410D9C476592B0A028F6253E"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/STlQjok3rlIOpG08udSBq_L8gO8>
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, 13 Jul 2017 11:30:04 -0000

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>