Summary: Has a BLOCK. Has enough positions to pass once BLOCK positions are resolved.
Ballot question: "Is this charter ready for external review?"
I think there have been enough points raised (by everyone) where the text is unclear on scope and/or meaning that it is not ready for external review yet. In particular, I'm only mostly sure that the primary deliverable is an HTTP-based protocol for conveying SIP configuration information.
Barry already noted a lot of things that bothered me, as well. The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks has been increasing gradually over the last few years. Consequently, direct IP peering between enterprise and service provider networks is replacing traditional methods of interconnection between enterprise and service provider networks. I don't think I understand this. I'm reading it as "people use SIP, both in X networks and Y networks. Therefore, X networks and Y networks are getting direct IP peering." Is there some missing step about how SIP-based communications are being used across the different groups and the IP peering gets them better SIP call quality? Over the long run, operational costs for service providers and enterprise equipment manufactures would likely decrease as a result of fewer support cases. I don't see a particular need to mention this in the charter. This work would make use of HTTPS based framework that allows a SIP service provider to offload a detailed capability set to the enterprise network. Is "offload" really the right word? To me it implies that some work previously done by the service provider is now being done by the interprise, as opposed to what the context seems to suggest, a mere transfer of information. HTTPS is used in favor of SIP for the following reasons: I only see one reason? The scope of activity includes: Define a robust capability set [...] What makes a capability set "robust"?
** Per "Requirements, Use Cases and Architecture draft", since draft is singular, is this really going to be one document? ** Per "Specification for SIP Auto Peer", contextually, I think this means a capability set data model, and extension, service discovery and transport guidance, but the phrase "SIP Auto Peer" is used only this one time. It might be helpful to expand this language.
As I am now certain of the intent of the text, my DISCUSS is addressed. I would suggest s/This work would make use of HTTPS based framework/This work would make use of a framework based on HTTPS, independent of HTTP version, to make it crystal clear. Nits: Para 3: s/manufactures/manufacturers Para 4: s/in favor of/instead of Para 4 promises “the following reasons” but there’s only one reason! Could it be rewritten to say “ instead of SIP because...” and then explain why?
Editorial points: Subsequently, deployment times for SIP trunking between enterprise and service provider networks increase. Is “subsequently” really the right word here? Maybe “As a result”? This work would define a descriptive capability set, Make it, “The ASAP working group will define...” with sufficient information to setup SIP trunking “set up”, two words between enterprise and service provider network. This needs either an article or two, or the plural “networks”. I think the latter. This work would make use of HTTPS based framework that allows “The working group will develop an HTTPS-based framework that will allow” Extensibility of the data model to allow proprietary parameters to be encoded. This is not a complete sentence; please reword it. Alternatively, you could remove “define” from the first two items, and turn the list into bullets rather than a paragraph of text. That fix might work better, and avoids the need to make the subsequent sentences complete also. A HTTPS-based transport mechanism using which the capability set The HTTP specs use “an”, rather than “a”, and we should be consistent with that, non-US pronunciation of “h” notwithstanding. In addition, this sentence doesn’t make sense and needs a fix: what does “using which” mean? The “out of scope” list should also be turned into bullets, or else the sentences need to be completed.
Are the support documents (use cases, requirements) intended to be published as RFCs? I ask because the milestone only talks about the protocol specification. Personally, I don't think it is necessary to publish support documentation -- it would be nice to clarify the intention at this time. https://www.ietf.org/about/groups/iesg/statements/support-documents/ [editorial nits] s/Consequently, direct IP peering between enterprise and service provider networks is replacing traditional methods of interconnection between enterprise and service provider networks./Consequently, direct IP peering between enterprise and service provider networks is replacing traditional methods of interconnection between them. s/produce.Any/produce. Any
Please find below some comments, nothing blocking but I strongly suggest that the charter is improved before going outside of the IESG. Here are some comments on this very LONG and sometimes convoluted charter (with a touch a marketing sometimes -- it looks like a BoF advertisement poster). "replacing traditional methods" should probably be more specific to "voice interconnection" ? is it about "automated" (per WG acronym) or just facilitated "provides the enterprise network with sufficient information to setup SIP trunking with the SIP service provider" About "operational costs for service providers and enterprise equipment manufactures would likely decrease as a result of fewer support cases." What about the opex of the actual enterprise/SMB customers ? May I also suggest s/manufactures/manufacturers/ ? Unsure whether a justification of using HTTPS is required in the charter... Should it be defined by the WG itself? With the usual (albeit slow) process of requirements then solutions ? I also second Alvaro's remark about whether requirements will be published. Hope this helps -éric
I will not put in a block as there appears others that have substantial issues with the text and I think as there need to address things the below can be considered and addressed. I react to how the scope of work section is structured and framed: The scope includes - X, Y and Z The following is excluded - V and W Implying that there could be other things that are in scope but not mentioned. I really would prefer a scope description that contain all the high level areas the WG will work on. No fuzziness that there might be additional things. Simply not using "includes" would help this. Simply stating that the work scope is: would improve things.
Should there be more description on what format the intended data model is defined in? Should there be more constraints on an HTTPS solution? E.g. I'm wondering whether it would be in scope to solve this with a YANG data model served by a RESTCONF server that only published operational data describing the capabilities?