Re: [Can] Zaheduzzaman Sarker's Block on charter-ietf-can-00-04: (with BLOCK and COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

> On 16 Feb 2023, at 15:31, John Scudder <[e-mail]> wrote:
> 
> Hi Zahed,
> 
> Comments inline.
> 
>> On Feb 16, 2023, at 9:04 AM, Zaheduzzaman Sarker via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Zaheduzzaman Sarker has entered the following ballot position for
>> charter-ietf-can-00-04: Block
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-6752378b09e9a397&q=1&e=b1e283c7-6813-416b-889e-89735feb92c0&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-can%2F__%3B%21%21NEt6yMaO-gk%21AYfiywlMi7YSAdXB6JiyRJHo74jnWUAG1KJvKFIf_j72saKsdoVlGSqJMxxjWQtnGMqLf2TZVL37%24
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> BLOCK:
>> ----------------------------------------------------------------------
>> 
>> I have two easy to fix block comments which I believe needed to be discussed
>> and would clarify the charter better if addressed -
>> 
>> # it says -
>> 
>>  "Exposure of network and compute conditions to applications
>> is not in the scope of CAN. As part of its work, the CAN WG will seek
>> advice and expertise from the ART and TSV areas."
>> 
>> I am confused, if the advice and expertise is for the exposure of the network
>> and compute condition and which is out of the scope, then what would the
>> advice for? This need to clarified.
> 
> I believe I was responsible for introducing that sentence so let me say a few words about it. During the most recent BoF there was feedback from several different people that broadly speaking, the load-balancing problem has been worked in ART and TSV as well. The paragraph you’re quoting is generally a “prior and related work” paragraph; it acknowledges this prior work and identifies what’s different in the scope of CAN vs the other work. The specific sentence you’re asking about is a way of saying “we acknowledge that there may be learnings from this prior work that could apply to CAN, we also acknowledge that we should seek review to make sure CAN isn’t inadvertently overlapping work that’s already been taken care of.”

yes, I call that summery as well. But I was into that state of acking previous work until the last two sentences, specially the last one where we seek advice. I was assuming the intention was different that no point on seeking advice on some thing that is out of scope, but the last sentence make if feel like that. 

I am was expecting more like - as the expertise lays in ART and TSV area any work needed related to exposure to endpoint will be done there.

> 
> I’m not sure why you think the sentence in question is specific to “exposure of the network and compute condition”, but I note that you left you two critical words there: “to applications”. Exposure of network and compute to the overlay edge (or whatever the right term is, the steering function) is squarely IN scope. It’s out of scope to expose these to applications, this is in contrast to ALTO. 

hmm, I this the problem is here - “Specific
characteristics that may distinguish CAN from other work include the
desire to integrate both network and compute conditions in the 
optimization function”

there is no clear indication here that the optimizatiion funtions are on the overlay edge, it can actually reside on number of places like in the server, or on some proxy etc. I think we can clearly say the  -

"Specific
characteristics that may distinguish CAN from other work include the
desire to integrate both network and compute conditions in the 
steering function in the edge over 

> 
> In any case, I think the sentence is not critical to the charter, and we could address your concern in several different ways, including —
> 
> - Delete the sentence.
> - Expand it to capture more detail such as what I’ve written above.
> - If the concern arises from the non-sequitur between "Exposure of network and compute conditions to applications is not in the scope of CAN” and "the CAN WG will seek advice and expertise from the ART and TSV areas” we could insert a paragraph break between them to clarify that these are not closely-related thoughts.
> 
> Of these, I have a bias toward cutting things out, so I kind of like the first option, but I would like to know what you think.

I think we can be specific about the steering function resides in the edge overlay (as I suggested above… yeah thats just an editorial suggestion, use your flavour). and be clear that we are seeking advice on the exposure of network and compute condition to edge overlay.

> 
>> # it says -
>> 
>>   "The CAN WG will initially focus on single domain models."
>> 
>>  Does this mean CAN will under this charter will eventually work on multi
>>  domain models? will there be a rechartering needed to work on multi domain
>>  models? This is going to impact the architecture I guess whether the
>>  solution is for single domain or multiple domains.
> 
> This text was introduced to respond to Martin’s BLOCK, where he asked, "Is cross-domain routing in scope, or is this charter limited to steering within a certain provider's network?” The subsequent discussion (https://mailarchive.ietf.org/arch/msg/can/cVTeMtHy_rnqUbNSi7cuRGJbyn4/) had the consensus that current interest is single-domain but that nobody saw a specific need to rule out multi-domain in the charter. 
> 
> As a practical matter if you think it’s important to exclude it in the charter, and require a recharter in order to work on this, nobody wants to die on this hill, we can make the change.

I think it is better to be specific. Lets focus on single domain. so if you remove the word “initially” then we are fine here.

> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> And one comment to clarify the service examples -
>> 
>> # can we change the service examples? it says - "for some services (for
>> example, VR/AR, intelligent transportation)". I don't really know what the
>> intelligent transportation service is, may be that is because my lack of
>> knowledge, hence very hard to see what requirements it puts that requires
>> compute awareness.  AR/VR as a technology is mostly deployed in the user
>> devices now and the network assisted AR/VR application is kind of still in
>> research, hence may not be best examples for the CAN work.
> 
> I think the reason these examples were used was that they are thought to require both minimization of latency and maximization of certain kinds of compute resources, and of course because they were top-of-mind for whoever crafted that example (it’s been in the draft charter for a long time). 

Sure, but as I wrote these example does not automatically translate to the CAN’s focus use cases, unless there are explanation.

> 
> FWIW I take “intelligent transportation” to mean (without getting too picky about the details), autonomous vehicles.

I would then write autonomous vehicles or connected vehicle 

> 
> Thanks,
> 
> —John