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 requirements document.  Trying to distinguish high level from low level requirements seems to invite confusion.

Yours,

Joel

On 11/12/2024 11:34 AM, Yingzhen Qu wrote:
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 such as IGR, LSR. Any suggestions to make this clearer?

On the other hand, when the WG decides to work on the problem statement and requirements document, we need to add them to the milestones, so we should have a clear understanding of the scope of the requirements document. A new topic may have only a problem statement document.

Thanks,
Yingzhen

On Tue, Nov 12, 2024 at 7:12 AM Joel Halpern <j...@joelhalpern.com> wrote:

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

    Yours,

    Joel

    On 11/12/2024 7:44 AM, Yingzhen Qu wrote:
    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 work, and we want to have the
    incubation function more clear stated in the charter:

    Options for handling new work include:

      * Directing the work to an existing WG (including RTGWG)
      * Developing a proposal for a BoF.
      * Developing a charter and establishing consensus for a new WG.
        This
        option will primarily be used with fairly mature and/or
        well-defined efforts.
      * Careful evaluation, leading to deferring or rejecting work.


    How about:
    */Incubating new routing-related technologies by developing and
    discussing problem statements and requirements documents prior to
    reaching consensus, which can encourage proponents to request a
    BoF or recommend the formation of a new working group to the ADs.
    If the working group agrees to pursue a problem statement or
    requirements document, it will be added to the group’s milestones./*
    */
    /*
    Thanks,
    Yingzhen


    On Tue, Nov 12, 2024 at 4:19 AM Greg Mirsky
    <gregimir...@gmail.com> wrote:

        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 formulation
        proposed by Adrian, but I can live with the former, too.
        Alternatively, it could be "consensus to encourage the
        proponents to use IETF processes and procedures to advance
        the formation of a new working group."

        Regards,
        Greg

        On Tue, Nov 12, 2024 at 12:34 PM Adrian Farrel
        <adr...@olddog.co.uk> wrote:

            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 might have “consensus to encourage
            the proponents to request a BoF to attempt to form a new
            working group.”

            Cheers,

            Adrian

            *From:*Alexander Vainshtein <alexander.vainsht...@rbbn.com>
            *Sent:* 12 November 2024 06:31
            *To:* Yingzhen Qu <yingzhen.i...@gmail.com>
            *Cc:* rtgwg-cha...@ietf.org; rtgwg@ietf.org;
            adr...@olddog.co.uk
            *Subject:* RE: [EXTERNAL] [rtgwg] Re: Charter updates

            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 agrees to pursue a
            problem statement or requirements document, it will be
            added to the group's milestones/*

            disambiguates (to the degree possible😊) “incubation” and
            links it to the IETF process in a reasonable way.

            I support adding this text to the new Charter.

            Regards,

            Sasha

            *From:*Yingzhen Qu <yingzhen.i...@gmail.com>
            *Sent:* Tuesday, November 12, 2024 1:04 AM
            *To:* adr...@olddog.co.uk
            *Cc:* rtgwg-cha...@ietf.org; rtgwg@ietf.org
            *Subject:* [EXTERNAL] [rtgwg] Re: Charter updates

            Hi Adrian,

            Sorry for the late reply. Please see my answers below inline.

            Thanks,

            Yingzhen

            On Wed, Nov 6, 2024 at 3:38 AM Adrian Farrel
            <adr...@olddog.co.uk> wrote:

                Hey, Yingzhen.

                [snip]

                    I am happy with the concept of providing an
                    initial discussion venue for such topics, but:

                    ·What does “incubation” mean in practice? I think
                    this needs to be spelled out in the charter text
                    because, as it stands, it is unclear where you
                    would draw the line. Why would this not result in
                    tens of documents being pushed to RFC on the
                    topic of (for example) wet-string routing? How
                    would the WG handle requests to discuss 12 new
                    I-Ds on a new topic at an IETF? How would the WG
                    protect the other chartered work of the working
                    group against being swamped?
                    I’d suggest that “particularly focusing on
                    problem statements” be made more limiting such
                    as, “by developing and discussing problem
                    statement and requirements documents”, and that
                    “prior to achieving consensus” be end-limited as
                    “prior to determining whether there is consensus
                    or not for the creation of a new working group.”

                [Yingzhen]:

                The "incubation" means to provide a venue for initial
                discussion which RTGWG has been doing already.
                Ideally we may give a new proposal/work one or two
                opportunities to present, and based on the feedback
                of the community we'll decide whether to continue.
                Use your wet-string routing example, if we really get
                tens of documents on the topic, and assuming they're
                not from the same author, I'd say most likely the
                community is interested in the topic. We should help
                to define the problem scope and recommend for a BoF
                before there are tens of documents on this topic.

                As for agenda building, we will always put WG
                documents on higher priority. Meanwhile we can always
                make use of interims and side meetings. I'm actually
                not too worried about getting too much work. It's way
                better than having nothing to work on.

                Regarding the charter update, I merged your
                suggestion. So how about something like:

                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. Initial topics include, but are not
                limited to, satellite routing, data center routing,
                and networking for AI clusters.

                [AF] This is all good stuff, and I don’t see anything
                I disagree with substantially.

                But… :-)

                The way to think about charter text is not just about
                how to guide the current (wise and competent) chairs,
                but how to guide the future (evil or dumb) chairs,
                and how to guide the highly-excitable and inventive
                WG participants.

                So, probably, we just need to cook some words that
                not rely on a single key word, but sets the scope and
                process and priority.

            [Yingzhen]: thanks for this "But". This is what we need.

            I agree with you that the charter of a WG should be
            specific, but not so specific that it may go out of date
            in a week of recharter.

                    ·The text “This includes, but is not limited to”
                    is, I think intended to say “The initial list of
                    candidate topics is,” with an addition of “other
                    topics may be added after discussion with the WG
                    chairs”. But…

                    oWhat does this initial list actually add?

                    oWill you track those other topics? How do the
                    chairs decide? What happens when an idea won’t go
                    away, or keeps coming back?

                [Yingzhen]:

                Are you suggesting we shouldn't include this initial
                list? The "not limited to" meant to say we may also
                work on other topics. We can't predict the topics
                that may pop up, and recharter does have some
                overhead and take some time. Of course, if there is a
                topic that the community thinks RTGWG should work on,
                we can always recharter to include it.

                [AF] If you are saying that further topics will be
                added to the charter before they can be discussed (I
                don’t think you are saying that) then having the list
                would be fine.

                But otherwise, I think you are just making a list
                that will be out of date by the end of the week.

                So, how about, “A list of topics currently under
                consideration by the WG for incubation will be
                maintained on the WG Wiki page”?

            [Yingzhen]: A new topic may pop up in RTGWG any time, so
            it's not possible for us to make a complete list of
            topics that the WG will be working on. How about if the
            WG agrees to work on the problem statement of a topic,
            for example the problem statement of wet-string routing,
            we will add this to the milestones of the WG.

            How about the following text for charter update:

            */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 agrees to pursue a
            problem statement or requirements document, it will be
            added to the group's milestones./*

                    Since we just had the perceptive/adaptive routing
                    side meeting, and since we have the AIDC mailing
                    list, would you imagine that the day after
                    rechartering all of that work would immediately
                    move into RTGWG?

                [Yingzhen]:

                The preceptive/adaptive routing side meeting is
                actually a good example to show that efforts will
                also be made outside of RTGWG to figure out the
                problem space and whether there is something that the
                IETF can work on. Same for the AIDC side meetings and
                the mailing list where we also share the latest
                technology developments in the industry.

                [AF] Right. Two things should be clear.

                1.New topics can be spun up in the RTG Area without
                “incubating” them in RTGWG. Thus, side meetings,
                I-Ds, BoFs, WG formation do not need to use RTGWG.

                2.RTGWG is available as **an** option for airing new
                topics.

                However, in this particular case, when stuff has
                advanced on several fronts, I think there is a search
                for coordination advice….
                - If  perceptive/adaptive routing is already under
                RTGWG incubation, it would be helpful to know

                - If it is an option for the perceptive/adaptive
                routing proponents to incubate in RTGWG, then they
                need to self-organise to that end

                - If the AIDC list is the place to self-organise for
                perceptive/adaptive routing, this is **highly**
                non-obvious from the name of the list :-)

            [Yingzhen]: There are already drafts in RTGWG about
            different aspects of networking technologies in data
            centers for LLM training. I'm not sure whether you
            consider them related to perceptive/adaptive routing.
            These drafts are still at early stages and need further work.

            As for the AIDC mailing list, it was created to
            facilitate discussions related to the AIDC side meetings,
            where we discuss new technologies in DCs for AI. I
            thought the name was obvious, and it seems I'm mistaken. :)

                Cheers,

                Adrian

            *Disclaimer*

            This e-mail together with any attachments may contain
            information of Ribbon Communications Inc. and its
            Affiliates that is confidential and/or proprietary for
            the sole use of the intended recipient. Any review,
            disclosure, reliance or distribution by others or
            forwarding without express permission is strictly
            prohibited. If you are not the intended recipient, please
            notify the sender immediately and then delete all copies,
            including any attachments.

            _______________________________________________
            rtgwg mailing list -- rtgwg@ietf.org
            To unsubscribe send an email to rtgwg-le...@ietf.org


    _______________________________________________
    rtgwg mailing list --rtgwg@ietf.org
    To unsubscribe send an email tortgwg-le...@ietf.org
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org

Reply via email to