Subject: [dispatch] SIPCORE Rechartering

From: Adam Roach <[email-masked]>
Date: Fri, 4 Nov 2016 16:28:00 -0500

[as SIPCORE chair]

Back when we transitioned from the SIPPING/SIP working group structure 
to SIPCORE, we put relatively tight limits on the SIPCORE charter. This 
was a recognition of the fact that the volume of SIP-related work at the 
time was too large for any one working group to reasonably handle. 
Instead, the intention was that the DISPATCH model of creating small, 
short-lived working groups for specific topics would be a better way to 
manage the relatively heavy workload.

Fast forward seven years to today. SIP is a much more mature protocol, 
and the inflow of new work is significantly smaller than it was back 
then. At the same time, we have had several small, self-contained work 
items show up in DISPATCH that were deemed too small to create a new 
working group for, but precluded from being dispatched to SIPCORE by its 
charter. This has led to unnecessary delays as we determined the best 
disposition for these items.

We, the SIPCORE chairs and area director, seek to fix that. We would 
like to amend the SIPCORE charter to allow it to take on small, 
self-contained protocol extensions in addition to changes to the core 
SIP protocol. This is a relatively minor update to the existing charter, 
which expands the scope as described above, and adds back in two of the 
architectural principles from the SIP charter which are applicable only 
to protocol extensions.

Please provide feedback on the proposed charter by sending email to the 
SIPCORE mailing list. We will also discuss this briefly during the 
DISPATCH session in Seoul.

The proposed charter text follows.

> The Session Initiation Protocol Core (SIPCore) working group is
> chartered to maintain and continue the development of the SIP protocol,
> currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and
> 6665.
>
> The SIPCore working group will concentrate on specifications that update
> or replace the core SIP specifications named above as well as
> specifications pertaining to small, self-contained SIP protocol
> extensions. The process and requirements for new SIP extensions are
> documented in RFC5727, "Change Process for the Session Initiation
> Protocol".
>
> Throughout its work, the group will strive to maintain the basic model
> and architecture defined by SIP. In particular:
>
> 1. Services and features are provided end-to-end whenever possible.
>
> 2. Reuse of existing Internet protocols and architectures and
> integrating with other Internet applications is crucial.
>
> 3. Standards-track extensions and new features must be generally
> applicable, and not applicable only to a specific set of session
> types.
>
> 4. Simpler solutions that solve a given problem should be favored
> over more complex solutions.
>
> The primary source of change requirements to the core SIP specifications
> (enumerated above) will be a) interoperability problems that stem from
> ambiguous, or under-defined specification, and b) requirements from
> other working groups in the ART Area. The primary source of new protocol
> extensions is the DISPATCH working group, which will generally make the
> determination regarding whether new SIP-related work warrants a new
> working group or belongs in an existing one.

For ease of reference, the existing SIPCORE charter is at 
https://datatracker.ietf.org/doc/charter-ietf-sipcore/

Thanks!

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 4 Nov 2016 21:47:39 -0400

I think this will be a helpful change.

	Thanks,
	Paul

On 11/4/16 5:28 PM, Adam Roach wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Sun, 6 Nov 2016 13:47:41 +0000

Perhaps you couild elaborate on how you now see the relationship between SIPCORE and DISPATCH. It is not clear to me what the criteria are for submitting something new to DISPATCH, versus SIPCORE directly.

Would everything go to DISPATCH first and the change here is to allow SIPCORE to take on work that has been dispatched, or would SIPCORE be the first point of entry for material, and if so, to what scope.

Finally, some stuff from DISPATCH has gone direct to AD sponsored – would you now see those becoming WG items of SIPCORE, or would that route still be envisaged, and if so, would the “dispatch” occur from DISPATCH or SIPCORE.

Maybe you could use some recent drafts and RFCs as examples of where you think things will change.

Keith

From: dispatch [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 04 November 2016 21:28
To: 'SIPCORE'; [email-masked]
Cc: [email-masked]
Subject: [dispatch] SIPCORE Rechartering

[as SIPCORE chair]

Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload.

Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items.

We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul.

For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charter-ietf-sipcore/

Thanks!

/a

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 7 Nov 2016 10:02:26 +0100

> On 05 Nov 2016, at 02:47, Paul Kyzivat <[email-masked]> wrote:
> 
Fully agree. This is a change that I like.

/O

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Nov 2016 11:42:37 -0600

The dispatch process has always allowed new work to go directly to a 
working group without going through dispatch if the work fit clearly in 
that working group's charter.

On 11/6/16 7:47 AM, Drage, Keith (Nokia - GB) wrote:
>
> Perhaps you couild elaborate on how you now see the relationship 
> between SIPCORE and DISPATCH. It is not clear to me what the criteria 
> are for submitting something new to DISPATCH, versus SIPCORE directly.
>
> Would everything go to DISPATCH first and the change here is to allow 
> SIPCORE to take on work that has been dispatched, or would SIPCORE be 
> the first point of entry for material, and if so, to what scope.
>
> Finally, some stuff from DISPATCH has gone direct to AD sponsored – 
> would you now see those becoming WG items of SIPCORE, or would that 
> route still be envisaged, and if so, would the “dispatch” occur from 
> DISPATCH or SIPCORE.
>
> *From:*dispatch [mailto:[email-masked]] *On Behalf Of *Adam 
> Roach
> *Sent:* 04 November 2016 21:28
> *To:* 'SIPCORE'; [email-masked]
> *Cc:* [email-masked]
> *Subject:* [dispatch] SIPCORE Rechartering
>
> [as SIPCORE chair]
>
> to SIPCORE, we put relatively tight limits on the SIPCORE charter. 
> This was a recognition of the fact that the volume of SIP-related work 
> at the time was too large for any one working group to reasonably 
> handle. Instead, the intention was that the DISPATCH model of creating 
> small, short-lived working groups for specific topics would be a 
> better way to manage the relatively heavy workload.
>
> working group for, but precluded from being dispatched to SIPCORE by 
> its charter. This has led to unnecessary delays as we determined the 
> best disposition for these items.
>
> SIP protocol. This is a relatively minor update to the existing 
> charter, which expands the scope as described above, and adds back in 
> two of the architectural principles from the SIP charter which are 
> applicable only to protocol extensions.
>
> Please provide feedback on the proposed charter by sending email to 
> the SIPCORE mailing list. We will also discuss this briefly during the 
> <https://datatracker.ietf.org/doc/charter-ietf-sipcore/>
>
> Thanks!
>
> /a
>
>
>

---

From: "Vijay K.Gurbani" <[email-masked]>
Date: Mon, 7 Nov 2016 11:59:24 -0600

> DISPATCH session in Seoul.

The change to the charter sounds reasonable.

Having been a beneficiary of one of the first mini-WGs to be
dispatch'ed (sipclf), the model of dispatch'ing has worked.  However, in
its trajectory, as Adam states, SIP is now a more mature protocol and I
suspect the itches that need to be scratched have more to do with
operational issues with SIP than core modifications to the protocol
itself.  Seems reasonable to perform such tweaks in sipcore.

Cheers,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: [email-masked] / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 07 Nov 2016 16:36:41 -0600

What Robert said. Additionally, new work still requires working group 
consensus and AD agreement, so there's a lot of backstops to avoid 
getting this horribly wrong.

Do people read the "Primary source of requirements" language to prevent 
that? I read "primary" to suggest that there may be non-enumerated 
"secondary" sources.

Ben.

On 7 Nov 2016, at 11:42, Robert Sparks wrote:

> working group without going through dispatch if the work fit clearly 
> in that working group's charter.
>
>> route still be envisaged, and if so, would the “dispatch” occur 
>> from DISPATCH or SIPCORE.
>>
>> *From:*dispatch [mailto:[email-masked]] *On Behalf Of 
>> *Adam Roach
>> Back when we transitioned from the SIPPING/SIP working group 
>> structure to SIPCORE, we put relatively tight limits on the SIPCORE 
>> charter. This was a recognition of the fact that the volume of 
>> SIP-related work at the time was too large for any one working group 
>> to reasonably handle. Instead, the intention was that the DISPATCH 
>> model of creating small, short-lived working groups for specific 
>> topics would be a better way to manage the relatively heavy workload.
>>
>> Fast forward seven years to today. SIP is a much more mature 
>> protocol, and the inflow of new work is significantly smaller than it 
>> was back then. At the same time, we have had several small, 
>> self-contained work items show up in DISPATCH that were deemed too 
>> small to create a new working group for, but precluded from being 
>> dispatched to SIPCORE by its charter. This has led to unnecessary 
>> delays as we determined the best disposition for these items.
>>
>> the SIPCORE mailing list. We will also discuss this briefly during 
>> the DISPATCH session in Seoul.
>>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 07 Nov 2016 17:05:06 -0600

The proposed new SIPCORE charter text is now available at 
https://datatracker.ietf.org/doc/charter-ietf-sipcore/ . It's identical 
to the text from Adam's email, other than some potential formatting 
differences.

Thanks!

Ben.

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 8 Nov 2016 00:34:41 +0000

I don’t think Robert has answered the questions I asked.

And I am also not particularly worried about the backstops.

I am worried about the number of cycles it gets to get something discussed in what the recipients consider to be the right working group, so I am interested in whether the distinction in what goes to DISPATCH versus what goes to SIPCORE is absolutely clear.We do not need documents going to DISPATCH and being bounced to SIPCORE and vice-versa, particularly if that takes two or three meeting cycles to go round that loop.

Further does the criteria of what might be AD sponsored now change because this extra route has now been created / emphasised? And does SIPCORE have the mandate to ask an AD to do this for an input draft in the same way as DISPATCH might have done?

Keith

From: dispatch [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: 07 November 2016 22:37
To: Robert Sparks
Cc: [email-masked]
Subject: Re: [dispatch] SIPCORE Rechartering

What Robert said. Additionally, new work still requires working group consensus and AD agreement, so there's a lot of backstops to avoid getting this horribly wrong.
Do people read the "Primary source of requirements" language to prevent that? I read "primary" to suggest that there may be non-enumerated "secondary" sources.
Ben.
On 7 Nov 2016, at 11:42, Robert Sparks wrote:

The dispatch process has always allowed new work to go directly to a working group without going through dispatch if the work fit clearly in that working group's charter.
On 11/6/16 7:47 AM, Drage, Keith (Nokia - GB) wrote:
Perhaps you couild elaborate on how you now see the relationship between SIPCORE and DISPATCH. It is not clear to me what the criteria are for submitting something new to DISPATCH, versus SIPCORE directly.

Keith

From: dispatch [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 04 November 2016 21:28
To: 'SIPCORE'; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [dispatch] SIPCORE Rechartering

[as SIPCORE chair]

Thanks!

/a

dispatch mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 07 Nov 2016 20:19:45 -0600

On 7 Nov 2016, at 18:34, Drage, Keith (Nokia - GB) wrote:

> I am worried about the number of cycles it gets to get something 
> discussed in what the recipients consider to be the right working 
> group, so I am interested in whether the distinction in what goes to 
> DISPATCH versus what goes to SIPCORE is absolutely clear.We do not 
> need documents going to DISPATCH and being bounced to SIPCORE and 
> vice-versa, particularly if that takes two or three meeting cycles to 
> go round that loop.

I don't think we can make bright lines here. The best we can do is give 
guidance. But In general, I expect things that are entirely SIP, 
relatively small and self-contained, and don't propose or imply material 
changes to the SIP architecture would go to SIPCORE. Work where this is 
not the case, or where it's simply not clear if it's the case, would go 
to DISPATCH.

If someone takes work to DISPATCH that could have simply gone to 
SIPCORE, I expect that the participants (and chairs and ADs) will be 
quick to recommend the work be moved over with minimal red-tape.

The kind of work that can take several meeting cycles (and we should 
remember that DISPATCH, like any other WG, has a mailing list and need 
not wait for meetings) is usually the sort of thing that either does not 
have sufficient interest, spans multiple technologies, or is otherwise 
not obvious how to address. That sort of thing shouldn't start out in 
sipcore.

>
> Further does the criteria of what might be AD sponsored now change 
> because this extra route has now been created / emphasised? And does 
> SIPCORE have the mandate to ask an AD to do this for an input draft in 
> the same way as DISPATCH might have done?

The criteria for AD sponsored is that an AD agrees to sponsor it. That 
being said, any working group can suggest that a piece of work be AD 
sponsored.

Will this impact what ADs agree to sponsor? I think it might in a few 
cases. Speaking only for myself, I have sponsored a few drafts that I 
probably would have suggested go to SIPCORE if the proposed charter had 
been in effect. For a recent example (not intending to pick on 
Christer): draft-holmberg-dispatch-received-realm.

> Do people read the "Primary source of requirements" language to 
> prevent that? I read "primary" to suggest that there may be 
> non-enumerated "secondary" sources.
> Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Nov 2016 14:38:07 +0900

Hi,

The proposed charter (at the link below) will be reviewed by the IESG at 
the Dec 1 Telechat. If people have further comments, please make them as 
soon as possible.

Thanks!

Ben.

On 8 Nov 2016, at 8:05, Ben Campbell wrote:

> https://datatracker.ietf.org/doc/charter-ietf-sipcore/ . It's 
> identical to the text from Adam's email, other than some potential 
> formatting differences.
>
> Thanks!
>
> Ben.
>

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