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

From: "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Mon, 6 Jan 2020 01:42:09 +0000

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

---

From: Ben Campbell <[email-masked]>
Date: Sun, 5 Jan 2020 21:11:35 -0600

One clarification (as co-chair):

There was consensus to recommend the formation of a mini wg to the ADs. The IESG makes the final decision about wg formation. It’s a subtle but important distinction :-)

(I have not yet reviewed the charter proposal itself.)

Thanks!

Ben.

> On Jan 5, 2020, at 7:42 PM, Kaustubh Inamdar (kinamdar) <[email-masked]> wrote:
> 
> All,
> Following the presentation of SIP Auto Peer at IETF 106, Singapore (https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-01 <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.
>  
>  
> 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.
> 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:
> 
>  
> 
> _______________________________________________
> dispatch mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>

---

From: "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Mon, 6 Jan 2020 05:17:09 +0000

Slight modification to the proposed charter…

PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

·         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.

·         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:

Thanks,
Kaustubh

From: Kaustubh Inamdar <[email-masked]>
Date: Monday, 6 January 2020 at 07:12
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Cullen Jennings <[email-masked]>
Subject: PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

All,

The group will produce

Milestones:

Thanks,
Kaustubh

---

From: Adam Roach <[email-masked]>
Date: Mon, 6 Jan 2020 12:11:26 -0600

On 1/5/20 11:17 PM, Kaustubh Inamdar (kinamdar) wrote:
>
> 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:
>

A quick comment on the first milestone -- while this is probably a 
worthwhile document to develop inside the working group to ensure that 
the solution does what it sets out to do, it may not make sense to send 
it to the IESG for publication. Read and consider the text at 
<https://ietf.org/about/groups/iesg/statements/support-documents/>; if 
you still believe that the architecture document needs to be published 
as an RFC, please explain why as part of the charter.

/a

---

From: Richard Shockey <[email-masked]>
Date: Mon, 06 Jan 2020 15:16:50 -0500

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

From: dispatch <[email-masked]> on behalf of Adam Roach <[email-masked]>
Date: Monday, January 6, 2020 at 1:11 PM
To: "Kaustubh Inamdar (kinamdar)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

The group will produce

RS> This would be very helpful.

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

 

Milestones:

A quick comment on the first milestone -- while this is probably a worthwhile document to develop inside the working group to ensure that the solution does what it sets out to do, it may not make sense to send it to the IESG for publication. Read and consider the text at <https://ietf.org/about/groups/iesg/statements/support-documents/>; if you still believe that the architecture document needs to be published as an RFC, please explain why as part of the charter.

/a

_______________________________________________ dispatch mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dispatch

---

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Jan 2020 17:13:06 -0600

(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) <[email-masked]> wrote:
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Jan 2020 17:31:24 -0600

(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 <[email-masked]> wrote:
> 
>> 	• 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.
>> 	• 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:
>> 
>>  
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Jan 2020 23:08:32 +0000

Hi,

Shouldn't the charter also mention why existing feature- and extension indication mechanisms would not work? The way the text is written now one could think that SIP does not providing mechanisms for indicating support of features and extensions...

Regards,

Christer

________________________________
From: dispatch <[email-masked]> on behalf of Ben Campbell <[email-masked]>
Sent: Wednesday, January 8, 2020 1:31 AM
To: Kaustubh Inamdar (kinamdar) <[email-masked]>
Cc: [email-masked] <[email-masked]>; Cullen Jennings <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

(still individual)

Thanks!

Ben.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Jan 2020 16:30:25 -0700

> On Jan 8, 2020, at 4:08 PM, Christer Holmberg <christer.holmberg=[email-masked]> wrote:
> 
> Hi,
> 

Thoughts on how to clear up this text? As sip does provide indication of support of some types of things, we should certainly not say it does not. This should meet the truth in advertising.  I think there are some types of configuration that is pretty hard to do in SIP. For example, where to send the SIP message too.

---

From: "Kaustubh Inamdar (kinamdar)" <[email-masked]>
Date: Wed, 15 Jan 2020 16:34:23 +0000

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…

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" <[email-masked]> wrote:

    (still individual)

    Thanks!

    Ben.