Ballot for charter-ietf-spring
Block
Yes
No Objection
Abstain
No Record
Summary: Has a BLOCK. Has enough positions to pass once BLOCK positions are resolved.
Ballot question: "Is this charter ready for external review?"
(3) What is the new work to be done and what are the bounds? The charter seems extremely open-ended. With this new charter text and absence of milestones, it isn’t clear what new work the WG will pursue or even what the bounds are to judge that a given topic is in/out of scope (beyond being SR related). The primary bounding text I see is "The SPRING WG is responsible for defining new applications for, and specifying extensions to, Segment Routing technologies. It also serves as a forum to discuss the operational aspects of deploying and managing SR-MPLS networks." What is an example of an application the WG will work on right now? What are the extensions? Am I correct in assuming there is a maintenance role for extensions? What are the first several that need to be worked on known now to motivate this WG? Can those be added as milestones? When is the WG “done”? Can this need for latitude be further explained?
Thank you to Alvaro Retana for his explanation on trust domains. Thank you for the revision which clarified how new work would be accepted.
I also agree with Roman/Gunter's blocks and John's comments. Para 2: I did find the discussion of working groups involved, data plane, management plane verbiage to be difficult to follow. At the very least, there should be guardrails or milestones (or both).
Thank you for addressing my concern with the line "The SPRING WG will manage its specific work items based on WG engagement and successful adoption."
Thanks for addressing one of my previous BLOCK point and the non-blocking COMMENT. After discussions with the SPRING WG chairs, I am balloting ABSTAIN because the current charter is also open (i.e., the scope is mostly unlimited) :-( , so there is no ground to justify a BLOCK for the proposed draft charter, whose scope is also open. Happy to change my ballot to a YES if the WG scope becomes more defined. Side note: I am trusting the current SPRING WG chairs and AD for applying common sense during adoption calls & WGLC.
Thanks for updating the charter based on the comments/feedbackc. The current charter addresses my blocking comments well.
This sentence makes my brain hurt, simply because the syntax requires way too much parsing: Any modification of -or extension to- existing architectures, data planes, or control or management plane protocols should be carried out in the WGs responsible for the architecture, data plane, or control or management plane protocol being modified and in coordination with the SPRING WG, but may be done in SPRING WG after agreement with all the relevant WG chairs and responsible Area Directors. (Also, the "-or extension to-" thing is just wrong, turn those dashes into commas, if that text is kept. There are some definite articles missing and stuff, too.) I don't have a fantastic rewrite to offer, but a first attempt might be to break it into several smaller sentences, as in, Any modification of, or extension to, existing architectures, data planes, or control or management plane protocols should be carried out in the WGs responsible for the same. The responsible WG should coordinate with the SPRING WG. Alternatively, the work may be done in the SPRING WG after agreement with all the relevant WG chairs and responsible Area Directors. I'll be interested in the response to Roman's BLOCK, and I want to echo his implicit "why aren't any milestones listed?"
I support Roman's BLOCK and John's comments.