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

[John Scudder <[e-mail]>]

Hi Zahed,

Comments inline.

> On Feb 16, 2023, at 9:04 AM, Zaheduzzaman Sarker via Datatracker <[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://urldefense.com/v3/__https://datatracker.ietf.org/doc/charter-ietf-can/__;!!NEt6yMaO-gk!AYfiywlMi7YSAdXB6JiyRJHo74jnWUAG1KJvKFIf_j72saKsdoVlGSqJMxxjWQtnGMqLf2TZVL37$
> 
> 
> 
> ----------------------------------------------------------------------
> 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.”

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. 

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.

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

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

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

Thanks,

—John