Automatic SIP trunking And Peering
charter-ietf-asap-01

** 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?