Ballot for charter-ietf-asap
Yes
No Objection
Note: This ballot was opened for revision 00-01 and is now closed.
Ballot question: "Is this charter ready for external review?"
** 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.
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
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
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.
Removing my Block, as the 00-03 is sufficiently improved to be reviwable. That said, I still feel like I'm missing something in the first paragraph: The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks has been gradually increasing over the last few years. Consequently, direct IP peering between enterprise and service provider networks is replacing traditional methods of interconnection between these networks, such as analog lines and time-division multiplexing (TDM)-based digital circuits. in that it sounds like "communication networks" is being used as a term of art, but I don't have enough context to know what it should mean. Just reading the words in their normal English meanings, this sounds like it would apply to any sort of communication, including both human-focused and computer-focused communication, and all IP-based networking. Is this supposed to be focusing on voice (or maybe voice+video) communication? (There also could maybe be a stronger link between SIP usage and IP peering, in that SIP runs over IP and so IP peering allows for direct SIP trunking(?).)
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.
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?
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?