Re: [Coin] Comments re. draft-irtf-coinrg-use-cases (was: Re: Cancelling the COINRG meeting at IETF113)

[Ike Kunze <[e-mail]>]

Dirk, Toerless, all,

@Toerless: Thanks for your comments. I appreciate the input! It’s always good to get some more “outside” perspective so as to not get too focused on the (sometimes echoing) opinion of the author group + COINRG!
Let me add my two cents to some of your and Dirk’s comments inline. 

Best,
Ike

> On 14. Mar 2022, at 09:12, Dirk Trossen <dirk.trossen=[e-mail]> wrote:
> 
> Instead, we were looking for use cases that may help us formulate challenges and research questions for COIN at large. We then later decided to frame some of those 'COIN aspects' with those prefixed words you can find in the document. The prefixing is not meant to introduce new terms (nor eliminate important differences) but to delimit the challenges and questions to the aspects of COIN that may matter while there are, of course, large-than-COIN aspects that we may not (want to) care about in order to scope discussions. It may not be the best approach of doing this but it felt like a good one at the time of doing so. But again, 'coining' new words is not really what this is about.

[IKE] I would like to emphasize that adding the “COIN” prefixes is really only intended to make it absolutely clear that we focus on COIN-specific challenges, questions, etc.
As Dirk says, there are also “larger-than-COIN” aspects, but we have tried to gradually turn their volume within the document down.
See also Dirk’s last comment regarding “calling it anything…”.

> This is unlikely a perfect view of looking at use cases but one that is driven by outlining those areas of research that may be impacted by those use cases or where those (existing) use case may be impacted by COIN solutions. For this reason, we also (for now) adopted the categorization of research questions outlined in Section 7, i.e., those RQs going at the heart of COIN (visions and enabling technologies) but also those related to 'applicability areas' (sticking to this word for now until we find a better one or will like it), i.e., areas that may be impacted by COIN (one of which is routing, which showed up early in the history of this work in one of my use cases); you may recognize those categories as largely being those I discussed in my contribution to the interim, derived from my understanding of COIN (charter and discussions so far over the past 3 years or so). 

[IKE] Just to add on here: Our goal is to find common research questions, challenges and requirements for COIN and we chose to do this in a use-case-driven way so that we do not end up with some set of artificial RQs, etc. that no one cares about.
As a consequence, our current findings are, of course, tied to the underlying use cases and, thus, also somewhat influenced by them, e.g., in the form of how we align the use cases.
However, all of this additional ordering, be it in Sections 3-6 or in our analysis in Section 7, is only intended to help us make sense of commonalities between the use cases.
In short: we are aware that this is possibly not the best way to do things, but the one that we felt most comfortable with and the one we chose to get started with this.
Based on our findings, we might later choose a different way.

> So this is not about what may be 'in' or 'not in' network (an interesting question though but I would expect that answer from some sort of vision work on COIN) or the difference to 'just distributed apps' (since COIN will execute distributed apps so it is of interest what, if any, will change for those distributed apps if COIN was made reality). 

[IKE] Yep, we do not aim to answer any of those questions, but actually want to raise questions :)

> From my perspective, key of this work but also the wider work in COIN is to find out what the scope and extent of 'COIN' really is when we write 'COIN system' or similar in use cases like that. It may be a lot, or rather little or simply something rather specific (hopefully) that we can put our finger on once the research progresses. It is not about coining terms though; I'm happy to call it anything one wants if that will make you accept the work better but I find a name discussion before a content discussion to always be a slippery slope.

[IKE] I fully agree. Our goal is to raise questions that help in finding out the scope/extent of COIN. Our goal is not to propose new terms. In fact, we have only introduced them to better align the different use cases so that we can analyze them easier. Thus, for me, renaming them in our document is on the table and I actually advocate for having one central place where we define general “COIN”-related terms.

> -----Original Message-----
> From: Toerless Eckert [mailto:[e-mail]] 
> Sent: 13 March 2022 08:33
> To: Sharon Barkai <[e-mail]>
> Cc: Schooler, Eve M <[e-mail]>; Marie-Jose Montpetit <[e-mail]>; coinrg-chairs <[e-mail]>; Dirk Trossen <[e-mail]>; coin <[e-mail]>
> Subject: Comments re. draft-irtf-coinrg-use-cases (was: Re: [Coin] Cancelling the COINRG meeting at IETF113)
> 
> As a very high-level observation, i find it less than ideal to prefix everything in that document equally just with "COIN" because it eliminates important differences and attaches unnecessary a new term to something that already is well known. It would also be good to remember that just because an RG has a particular name, it is not necessary for all technical classiciations to re-use that RGs name.

[IKE] See Dirk’s and my comments above.

> To me, the mayority of use-cases presented is really "just" distributed applications, which in my view just "use" the network, but which are not "in" the network. Aka:

[IKE] This is the interesting point of this RG. Your view of “using" the network vs “in” the network is different from mine which is different from Dirk’s which is different from …
I think that one of the main goals of this RG is to make sense of all these views and discuss which of them might make the most sense.
For this, the use cases present different scenarios that some of us believe to be “in” the network and now it is up to the RG to discuss about this.
In this context, our draft is intended to support this discussion by bringing out similarities, differences, nuances, etc.

> Now, my understanding of what's in and whats not in the network might be different from what the RG mayority wants, but at least it would be great to spend more time with a somewhat longer list of examples and explain for each of them whether why and how its considered to be in or out, if in and out is really what the RG wants to define.

[IKE] I don’t believe that there is an RG majority on all the different things that might be in/out. If that would be the case we would not be needing the discussions.
Regarding the “longer list of examples”: We had several calls for use cases and those that we have at the moment are those that we got. At the moment, we analyze this (incomplete) list of examples as detailed by Dirk and myself above.
In this context, we will also consider whether some of the use cases might actually be out-of-scope, but we have not gotten that far, yet.
Thus, for the moment, our list of use cases is fixed so that we can make progress with the analysis, but at later stages we would be happy to include additional examples to enrich the discussion and/or see whether they bring new RQs, challenges, etc. to the table.

> IMHO, it would be more productive to come up with a more differentiated set of classifications.
> Distributed applications and their needs for better network services do not become less important by NOT giving them a new name COIN.

[IKE] If you still have this opinion following Dirk’s and my comments, I would be happy to hear what kind of “more differentiated set of classifications” you have in mind.