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

From: Linda Dunbar <[email-masked]>
Date: Fri, 21 Sep 2018 12:09:46 -0700

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

---

From: Michael Welzl <[email-masked]>
Date: Sat, 22 Sep 2018 22:48:42 +0200

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 <[email-masked]> wrote:
> 
> Reviewer: Linda Dunbar
> Review result: Ready
> 
> Hi,
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 24 Sep 2018 18:34:34 +0000

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:[email-masked]] 
Sent: Saturday, September 22, 2018 3:49 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Taps] Opsdir last call review of draft-ietf-taps-minset-10

Dear Linda,

Thanks!

Cheers,
Michael

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

---

From: Michael Welzl <[email-masked]>
Date: Mon, 24 Sep 2018 21:25:14 +0200

Hi,

I’m answering in line:

> On Sep 24, 2018, at 8:34 PM, Linda Dunbar <[email-masked]> wrote:
> 
> 
> Michael, 
> 

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

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

---

From: Michael Welzl <[email-masked]>
Date: Thu, 27 Sep 2018 16:23:14 +0200

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 <[email-masked]> wrote:
> 
> 
> Michael, 
>