Yingzhen,
Lots of thanks!
Regards,
Sasha
Get Outlook for Android<https://aka.ms/AAb9ysg>
From: Yingzhen Qu
Sent: Saturday, November 23, 2024 5:53:25 AM
To: Alexander Vainshtein
Cc: rtgwg@ietf.org
Subject: Re: [rtgwg] Re: [EXTERNAL] Re: Charter updat
t; *From:* Yingzhen Qu
> *Sent:* Wednesday, November 20, 2024 3:39 AM
> *To:* rtgwg@ietf.org
> *Subject:* [rtgwg] Re: [EXTERNAL] Re: Charter updates
>
>
>
> Hi all,
>
>
>
> Thanks for the review and comments.
>
> Please see the updated charter below this email, hi
: [EXTERNAL] Re: Charter updates
Hi all,
Thanks for the review and comments.
Please see the updated charter below this email, highlighting the changes:
Incubating new routing-related technologies by developing and discussing
problem statements prior to reaching consensus, which can encourage
: Yingzhen Qu
Sent: 20 November 2024 01:39
To: rtgwg@ietf.org
Subject: [rtgwg] Re: [EXTERNAL] Re: Charter updates
Hi all,
Thanks for the review and comments.
Please see the updated charter below this email, highlighting the changes:
Incubating new routing-related technologies by developing
Hi all,
Thanks for the review and comments.
Please see the updated charter below this email, highlighting the changes:
*I**ncubating new routing-related technologies by developing and discussing
problem statements prior to reaching consensus, which can encourage
proponents to request a BoF or rec
My preference is to simply remove the requirements work, and focus on
informational problem statements. If the work is well enough understood
to meaningfully do requirements, it is probably clear enough to
dispatch. And the dispatch destination can decide whether there is a
need for a require
Hi Joel,
The requirements meant to be high level function requirements, e.g.
covering certain use cases, instead of protocol extension requirements.
Should this be considered as part of the problem statement? But I agree
with your point of deferring detail protocol requirements to working groups
I wonder if the dispatch and incubation function would be clearer if
RTGWG allowed for work on problem statements, but explicitly deferred
requirements development to wherever the work is dispatched? If the
expertise is e.g. in IDR, SPRING, LSR, it seems they should do the
requirements develop
Hi Sasha, Adrian and Greg,
Thanks for the comments. Totally agree that the WG can't decide the
creation of a new WG, it really meant to say recommendation of a BoF or to
the ADs about creation of a WG.
The following text is from the current charter. RTGWG has been doing
dispatch and incubation wo
Procrastinators (like me) are saved from writing more words, as others may
be the first to formulate it more clearly. Thank you, Adrian!
I was trying to put my finger on that "consensus determination of the new
WG formation" as it seems not to be within the powers of a WG. I like the
latter formula
I agree that this is a whole lot better. Thanks.
I think, however, that RTGWG doesn’t determine consensus (or not) for the
creation of a working group. Working groups are created by ADs according to
arcane science.
We could have “consensus to ask the ADs to form a new working group” and we
Yingzhen and all,
From my POV the latest proposed text:
Incubating new routing-related technologies by developing and discussing
problem statements and requirements documents, prior to determining whether
there is consensus or not for the creation of a new working group. If the
working group agr
12 matches
Mail list logo
