Re: [Taps] Opsdir last call review of draft-ietf-taps-minset-10

Michael Welzl <michawe@ifi.uio.no> Thu, 27 September 2018 14:23 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87062130E23; Thu, 27 Sep 2018 07:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 sWo5Ne74sagC; Thu, 27 Sep 2018 07:23:21 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596CD120072; Thu, 27 Sep 2018 07:23:20 -0700 (PDT)
Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1g5XCH-00044z-5A; Thu, 27 Sep 2018 16:23:17 +0200
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1g5XCG-000Bzu-8S; Thu, 27 Sep 2018 16:23:17 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B14B579@sjceml521-mbs.china.huawei.com>
Date: Thu, 27 Sep 2018 16:23:14 +0200
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "draft-ietf-taps-minset.all@ietf.org" <draft-ietf-taps-minset.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "taps@ietf.org" <taps@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F5A358ED-399C-4915-9C7A-EC2990BBBE8E@ifi.uio.no>
References: <153755698602.7385.1208927554172233101@ietfa.amsl.com> <7C959283-AFBA-4C24-839A-C6FCBC3EF4BB@ifi.uio.no> <4A95BA014132FF49AE685FAB4B9F17F66B14B579@sjceml521-mbs.china.huawei.com>
To: Linda Dunbar <linda.dunbar@huawei.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: C069F1EB350B14ECDB4FC85EDDCCDB4950AD3518
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/RgiYgdvH5hnGdxabVD3p4CEJ0Dc>
Subject: Re: [Taps] Opsdir last call review of draft-ietf-taps-minset-10
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2018 14:23:24 -0000

Hi again Linda,

In my last reply, I wrote that I'd add a paragraph about the Cloud scenario and the question of who is requesting the service into the introduction. After giving this some more careful thought, today I decided against doing this. Here's why:
1) The vision of asking for a "service" and then being dynamically bound to it in the right place seems nice. However, if an application is statically bound to a set of protocols instead of services, the App Orchestration System would look for this set of protocols instead of the set of services. That's not very different - the difference is just that, because the minset document identifies fall-backs, things would potentially become more flexible. For example, seeing that the app requests "unordered message delivery", the Orchestration System would know that the app could benefit from running in a place where there's SCTP - still, it could also run at a place where there's TCP.
2) Seeing that all of this would need to be explained, I fear that this would add confusion, not clarity to the document - in particular because of the document role problem below:
3) Even if this would be a useful thing to explain, I doubt that the "minset" document really is the right one for it. E.g., maybe it would fit better in the implementation doc?

Cheers,
Michael


> On 24 Sep 2018, at 20:34, Linda Dunbar <linda.dunbar@huawei.com> wrote:
> 
> 
> Michael, 
> 
> All the Applications I know are developed with specific requirement of the needed Transport Services. 
> 
> The App developers have to find the platforms (Guest OS) that support the needed Transport Services before the Apps can be instantiated on the platforms. 
> 
> I think the proposed method in your draft would be useful for Cloud Environment where Apps need to be instantiated on 3rd party environment with unknown capabilities. For example the App Orchestration system may need to inquire the minimum Transport Services before instantiating the Apps in the environment, or has to search for the right environment to instantiate the Apps. 
> 
> Therefore, I think the draft need a section on "Who" is requesting the "Transport Services". I don't think it is between Apps and the Guest OS, unless you can show some sample Apps that actually behave differently based on the Transport Services provided.  
> I think it is more likely that the Apps Orchestration System needs to request the supported "Transport Services" to determine if the Apps can be running in the environment. 
> 
> Linda
> 
> -----Original Message-----
> From: Michael Welzl [mailto:michawe@ifi.uio.no] 
> Sent: Saturday, September 22, 2018 3:49 PM
> To: Linda Dunbar <linda.dunbar@huawei.com>
> Cc: ops-dir@ietf.org; draft-ietf-taps-minset.all@ietf.org; ietf@ietf.org; taps@ietf.org
> Subject: Re: [Taps] Opsdir last call review of draft-ietf-taps-minset-10
> 
> Dear Linda,
> 
> Thanks for your feedback!
> I’d like to address your last comment, but I’m not sure how. I agree with what you say, but it sounds as if you felt provoked by a specific sentence or paragraph - could you please point me at the text that you think needs changing?
> 
> Thanks!
> 
> Cheers,
> Michael
> 
> 
>> On Sep 21, 2018, at 9:09 PM, Linda Dunbar <ldunbar@huawei.com> wrote:
>> 
>> Reviewer: Linda Dunbar
>> Review result: Ready
>> 
>> Hi,
>> 
>> I have reviewed this document as part of the Operational directorate's 
>> ongoing effort to review all IETF documents being processed by the 
>> IESG.  These comments were written with the intent of improving the 
>> operational aspects of the IETF drafts. Comments that are not 
>> addressed in last call may be included in AD reviews during the IESG 
>> review.  Document editors and WG chairs should treat these comments just like any other last call comments.
>> 
>> Reviewer: Linda Dunbar
>> Review result: Almost Ready,  with comments
>> 
>> During my review period, the authors have updated the drafts twice, 
>> which have addressed many of  my previous comments well.
>> 
>> Only one more comment: Can you provide some sample "Applications" that 
>> actually do differently depending on the Host OS'  Transport 
>> capability? All the "Applications" I know of usually finalize on which 
>> Transport Protocols to use and which transport layer capability is 
>> necessary and can only be placed on the Host OS that meet the requirement.
>> 
>> Thank you.
>> 
>> Linda Dunbar
>> 
>> 
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>