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

[Ballot comment]
Repeating my comment from internal review: 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(?).)

[Ballot comment]
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(?).)

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot block]
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.

[Ballot comment]
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"?

[Ballot comment]
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

[Ballot block]
I hope this is a quick one.

In my circles many people think HTTPS has the connotation of HTTP/1. Is that the intent here? If so, why? If not, can we make it a little clearer by saying “All versions of HTTP with TLS” or something to that effect?

[Ballot comment]
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?

[Ballot comment]
** 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.

[Ballot comment]
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

[Ballot block]
I would like to discuss the two paragraphs that specify using HTTP rather than SIP, and that explain why.  I have no argument with what’s said here, but these sorts of details are usually worked out in the working group rather than specified in the charter.  As it stands, discussion of this point would be out of scope, and those who have other views would not be welcome to air them.  Please explain why that’s he right way to charter this work.

[Ballot comment]
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.