Re: [Can] Proposed CAN WG charter for discussion

[John Scudder <[e-mail]>]

Hi Linda,

I didn’t mean to say that the architecture would have to be completed to the point of RFC publication before that step could be started! But of course, anyone studying the applicability of a mechanism, has to be thinking, "applicable for what purpose"? So I think that studying applicability presupposes that the person doing the study has an architecture in mind. 

Your summary seems about right, and I think it demonstrates that those in the side discussion *do* have at least a rough architecture in mind. My point is,

a. It’s important to write that rough architecture down, to make the assumptions transparent to all WG participants, and
b. It’s important that when listing work items, we do not lose sight of the fact that this is one work item.

I don’t see the bullet list as comprising a strictly ordered list of tasks that have to be completed in the order listed, I’m sure some will be worked on in parallel or even out of order. 

I hope that helps?

—John

> On Jan 24, 2023, at 7:31 PM, Linda Dunbar <[e-mail]> wrote:
> 
> 
> John, 
>  
> Thank you very much for the extended explanation of the work items listed in the CAN Proposed Charter.
>  
> You said: 
> "The second major bullet item,  "Applicability of existing tools and mechanisms”, is work that (I think) can’t be done without an architecture and framework to refer to. So, there’s something missing in between."
>  
> I remember at the IETF 115 offline discussion inside the IESG office, the CAN proponents emphasized: what is needed is a mechanism for egress routers to send updates to the ingress routers of the availability and status of the resources attached to the egress routers, so that ingress routers can consider both network path conditions and resources availability attached to the egress router for selecting the optimal egress router to tunnel the packets to.
>  
> There were suggestions to study the applicability of using BGP to distribute the information, using LISP (by Dino), or using a new method, etc. My understanding of the work item of “Applicability of existing tools and mechanisms” is to study pros/cons of using, e.g. BGP/LISP/etc.”, for egress routers to distribute the information to the ingress routers. Is it necessary to have an architecture & framework to do this kind of applicability study? Or Maybe this kind applicability study is too narrow minded?
>  
> Thanks, 
> Linda 
>  
>  
>  
>  
> -----Original Message-----
> From: Can <[e-mail]> On Behalf Of John Scudder
> Sent: Tuesday, January 24, 2023 4:30 PM
> To: [e-mail]
> Subject: [Can] Proposed CAN WG charter for discussion
>  
> TL;DR:
>  
> What we need now, before we go forward with the WG formation process, is an active discussion of the proposed charter. In the unlikely event that the proposal is now perfect, the discussion could take the form of “looks good to me”, but I still need to see evidence of ongoing and diverse interest to form a WG to do the work described in the charter, before I take this to the rest of the IESG.
>  
> More details are below.
>  
>  
> Hi CAN Fans,
>  
> After further discussion with the proponents, I feel we’ve made enough progress on the draft charter to start wrapping up this phase of the discussion so we can move on to the next step of the WG chartering process. I’ve uploaded a proposed charter to the CAN BOF page, it is up for discussion by the CAN community. You can find it athttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-can%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C582d490c6c524ccd8e9a08dafe5a8c25%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638101962119845259%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DPu7pEWsNYeiHolQ4XonZSmUtgefvtZ%2Fojkf%2F79cMVQ%3D&reserved=0
>  
> As you’ll see, the proposed charter has been slimmed down by removing some of the historical content, rewriting other parts, and focusing the first-round deliverables on analysis and architecture rather than solutions. Depending on the WG’s output in that step, a future step might be to recharter to work on solutions, it might be to dispatch requests to other WGs to do extensions, or it might be a conclusion that existing protocols, cleverly used, might already be sufficient. 
>  
> One thing I think is missing in the current draft charter is that in the bulleted list following "The CAN WG is chartered to work on the following items”, we don’t have anything specific about architecture and framework. The first major bullet, “Groundwork”, as the name implies lists items that will lead to architecture and framework. The second major bullet item,  "Applicability of existing tools and mechanisms”, is work that (I think) can’t be done without an architecture and framework to refer to. So, there’s something missing in between. I think the introduction plus milestones makes it reasonably clear that framework + architecture are key WG outputs, but it seems to me we should fix this inconsistency in the bullet list. (Could be done by removing the bullet list, although that seems potentially useful for organizing the WG’s work plan.) If this is agreed upon, perhaps someone could propose text.
>  
> I’d also like to note a detail — major bullet 1 notes "Groundwork may be … not necessarily for publication as an RFC”. I support this approach — not every document a WG uses to do its work needs to end up as an RFC, some can be intermediate steps. There is also a milestone, "Adopt the CAN Problem Statement, Use Cases, gap analysis, and Requirements documents”. I think these two things are not in contradiction, because note there is not a corresponding “Submit the CAN Problem Statement, Use Cases, gap analysis, and Requirements documents for publication” milestone. I view this as a feature, and not an oversight, but wanted to make sure the (potential) WG is aware of it.
>  
> Let’s leave this thread open for discussion until at least February 3 before taking any further steps, to hopefully allow everyone who may now be on holiday a chance to see it and have an opportunity to comment and discuss. Once we converge on a proposed charter, we can begin the IESG review and then IETF review steps. The earliest opportunity for IESG review would be the February 16 IESG meeting.
>  
> Thanks,
>  
> —John
> -- 
> Can mailing list
> [e-mail]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcan&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C582d490c6c524ccd8e9a08dafe5a8c25%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638101962119845259%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OCVmlw3Dky5b65JbzZACLmjC3QOfT07F19pq5dSmM00%3D&reserved=0
>