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

Michael Welzl <michawe@ifi.uio.no> Mon, 24 September 2018 19: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 0443213102A; Mon, 24 Sep 2018 12:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Xd4XG3BAKamm; Mon, 24 Sep 2018 12:23:35 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 BCB3D131011; Mon, 24 Sep 2018 12:23:34 -0700 (PDT)
Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1g4WSB-0000RU-8B; Mon, 24 Sep 2018 21:23:31 +0200
Received: from 58.116.34.95.customer.cdi.no ([95.34.116.58] helo=[10.0.0.7]) by mail-mx06.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1g4WS9-0007bu-B1; Mon, 24 Sep 2018 21:23:31 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B14B579@sjceml521-mbs.china.huawei.com>
Date: Mon, 24 Sep 2018 21:25: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: <968CD0C8-0435-4D82-AF9B-8A9E8F2A1637@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.3273)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 95.34.116.58 is neither permitted nor denied by domain of ifi.uio.no) client-ip=95.34.116.58; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.7];
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: AD05D1CFEEEFEC0B6B3705FAC04BFE1210CFEBA3
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/E52ENSep_QHUZZiBAyE1swJ5NOI>
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: Mon, 24 Sep 2018 19:23:38 -0000

Hi,

I’m answering in line:

> On Sep 24, 2018, at 8:34 PM, 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 agree with this, but I also don’t think that the minset draft (or anything else in the TAPS charter, for that matter) would disagree with this.
The intention is just to break the static binding between applications and protocols - not between applications and the OS they would run on.


> 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. 

I can imagine it being useful in such an environment, yes…


> Therefore, I think the draft need a section on "Who" is requesting the "Transport Services”.

Hm; I propose to add a paragraph to the introduction about this - to clarify what I write below, plus mention the Cloud Environment example that you give above.


> 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.  

….  but here, I believe that we have a disconnect. In the TAPS model, applications still statically request a service - much like it’s already happening today, when I use a library that, e.g., would give me nothing but reliable data transfer. I can only run my application on OSes that support this library, and we’re not changing that. The implementation of the library could already replace TCP with SCTP or QUIC today - but the benefits would be rather limited, because certain services are not exposed, and hence never used. We can’t give an application out-of-order message delivery unless it asks for it - but, if the application would be ok with that service, e.g. SCTP could do more efficient job; yet, if an application says “out of order is fine”, we can still use TCP to send it in order.

That’s the kind of flexibility this is about - not applications that would behave differently based on what they find available.

I think there’s a misunderstanding here, and I wonder which text should be improved to avoid this...


> 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. 

I see this as another possibility - worth mentioning, but not the main intended use case.

I hope I was able to clear up the misunderstanding?!

Cheers,
Michael


> 
> 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
>