Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

Hi Ben & Adam,

Thanks for taking the time to go through the charter.

There doesn't need to be a separate architecture draft, perhaps sections on the reference architecture, use-cases etc. can be embedded in the draft that contains the actual specification.

>>I assume from the fact that SIP extensions are not in scope that doing this over HTTP(s) is a foregone conclusion. If so, the charter needs to say that. Also, is the scope limited to enterprise use cases?

Will do. The scope of this effort is concentrated between the enterprise and service provider SIP networks. However, the draft that contains the specification will talk about general applicability of the framework for different use cases, for example, between ITSPs or between SIP application servers (e.g. a SIP call agent a SIP-based Voicemail Server)

> > When you say the wg will not provide a mechanism for a enterprise network, do you mean that it must not be possible to use the mechanism(s) that way, or that such uses are simply out-of-scope? I suspect the second, in which case I suggest the statement that "The group will not…" be reformulated along the lines of "The following is out of scope…"

Will do.

>> Oops, I forgot a question: Is discovery in scope? I assume so, from the TBD section in draft-kinamdar-dispatch-sip-auto-peer-01. If so, it's worth mentioning in the charter.

Wil do.

Will standby for a while for any further comments before making modifications to the charter…

--Kaustubh

On 08/01/2020, 05:01, "Ben Campbell" <ben@nostrum.com> wrote:

    (still individual)

    Oops, I forgot a question: Is discovery in scope? I assume so, from the TBD section in draft-kinamdar-dispatch-sip-auto-peer-01. If so, it’s worth mentioning in the charter.

    Thanks!

    Ben.

    > On Jan 7, 2020, at 5:13 PM, Ben Campbell <ben@nostrum.com> wrote:

    >

    > (as individual participant)

    >

    > Hi,

    >

    > I think this is generally on the right track, but I do have some comments.

    >

    > I agree with Adam’s comment about an architecture draft going to the IESG. There’s been a lot of pushback from the IESG on publishing such documents as RFCs without a good argument about it’s archival value.

    >

    > Further along those lines, I’d suggest leaving flexibility so any resulting WG can decide how to structure the remaining documents. That is, rather than saying sending a “ protocol specification draft” to the IESG, you can talking about sending the “protocol specification”. The work group could later decide to organize that as one or more drafts as they see fit.

    >

    > I assume from the fact that SIP extensions are not in scope that doing this over HTTP(s) is a foregone conclusion. If so, the charter needs to say that. Also, is the scope limited to enterprise use cases?

    >

    > When you say the wg will not provide a mechanism for a enterprise network, do you mean that it must not be possible to use the mechanism(s) that way, or that such uses are simply out-of-scope? I suspect the second, in which case I suggest the statement that “The group will not…” be reformulated along the lines of “The following is out of scope…”

    >

    > Thanks!

    >

    > Ben.

    >

    >

    >> On Jan 5, 2020, at 11:17 PM, Kaustubh Inamdar (kinamdar) <kinamdar@cisco.com> wrote:

    >>

    >> Slight modification to the proposed charter…

    >>

    >> PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

    >>

    >>

    >> The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks is increasing at a rapid pace. Consequently, direct IP peering between enterprise and service provider networks is quickly replacing traditional methods of interconnection between enterprise and service provider networks.

    >> Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often not clear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful peering with a SIP service provider network. This lack of context often leads to interoperability issues between enterprise and service provider SIP networks resulting in a large number of support cases being opened with enterprise equipment manufacturers and SIP service providers. Subsequently, deployment times for SIP trunking between enterprise and service provider networks increase significantly.

    >> This work would define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an enterprise network, provides the enterprise network with sufficient information to setup SIP trunking with the SIP service provider. Such a capability set would not only result in SIP trunking deployment times being drastically scaled down, but also would result in a significant decrease in interoperability issues between enterprise and service provider network. Additionally, operational costs for service providers and enterprise equipment manufactures would likely decrease as a result of fewer support cases.

    >>

    >> The scope of activity includes:

    >>

    >> ·         Define a robust capability set which encapsulates sufficient information to ensure smooth IP peering between enterprise and service provider SIP networks.

    >> ·         Define a data model for the capability set.

    >> ·         Extensibility of the data model to allow proprietary parameters to be encoded.

    >> ·         A transport mechanism using which the capability set is communicated from the service provider network to the enterprise network.

   >> This working group will not:

    >> ·         Define any extensions to SIP.

    >> ·         Provide a workflow/mechanism that allows service providers to directly configure devices in the enterprise network.

    >>

    >> The group will produce

    >>

    >> ·         Requirements, Use Cases and Architecture draft.

    >> ·         Specification for SIP Auto Peer.

    >>

    >> This workgroup will co-ordinate with the SIP Core workgroup and the SIPConnect efforts carried out by the SIP Forum.

    >>

    >> Milestones:

    >>

    >> <Date TBD> Send architecture draft to IESG

    >> <Date TBD> Send protocol specification draft to IESG

    >>

    >>

    >> Thanks,

    >> Kaustubh

    >>

    >>

    >> From: Kaustubh Inamdar <kinamdar@cisco.com>

    >> Date: Monday, 6 January 2020 at 07:12

    >> To: "dispatch@ietf.org" <dispatch@ietf.org>

    >> Cc: "dispatch-chairs@ietf.org" <dispatch-chairs@ietf.org>, Cullen Jennings <fluffy@iii.ca>

    >> Subject: PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

    >>

    >> All,

    >> Following the presentation of SIP Auto Peer at IETF 106, Singapore (https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-01) , there was consensus to form a mini workgroup to take this effort forward. To that end, we are looking to build consensus on a charter. The prosed charter can be found below. Comments, reviews, suggestions are welcome.

    >>

    >>

    >> PRPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

    >>

    >>

    >> The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks is increasing at a rapid pace. Consequently, direct IP peering between enterprise and service provider networks is quickly replacing traditional methods of interconnection between enterprise and service provider networks.

    >>

    >> Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often not clear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful peering with a SIP service provider network. This lack of context often leads to interoperability issues between enterprise and service provider SIP networks resulting in a large number of support cases being opened with enterprise equipment manufacturers and SIP service providers. Subsequently, deployment times for SIP trunking between enterprise and service provider networks increase significantly.

    >>

    >> This work would define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an enterprise network, provides the enterprise network with sufficient information to setup SIP trunking with the SIP service provider. Such a capability set would not only result in SIP trunking deployment times being drastically scaled down, but also would result in a significant decrease in interoperability issues between enterprise and service provider network. Additionally, operational costs for service providers and enterprise equipment manufactures would likely decrease as a result of fewer support cases.

    >>

    >>

    >>

    >> The scope of activity includes:

    >>

    >>

    >>

    >>       • Define a robust capability set which encapsulates sufficient information to ensure smooth IP peering between enterprise and service provider SIP networks.

    >>       • Define a data model for the capability set.

    >>       • Extensibility of the data model to allow proprietary parameters to be encoded.

    >>       • A transport mechanism using which the capability set is communicated from the service provider network to the enterprise network.

    >> This working group will not:

    >>

    >>       • Define any extensions to SIP.

    >>       • Provide a workflow/mechanism that allows service providers to directly configure devices in the enterprise network.

    >>

    >>

    >> The group will produce

    >>

    >>

    >>

    >>       • Requirements, Use Cases and Architecture draft.

    >>       • Specification for SIP Auto Peer.

    >>

    >>

    >> Milestones:

    >>

    >>

    >>

    >> <Date TBD> Send architecture draft to IESG

    >>

    >> <Date TBD> Send protocol specification draft to IESG

    >>

    >>

    >> Thanks,

    >> Kaustubh

    >>

    >>

    >> _______________________________________________

    >> dispatch mailing list

    >> dispatch@ietf.org

    >> https://www.ietf.org/mailman/listinfo/dispatch