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 protected]> 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:[email protected]] > Sent: Saturday, September 22, 2018 3:49 PM > To: Linda Dunbar <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > 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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
