Re: [dispatch] SIPCORE Rechartering

["Ben Campbell" <[e-mail]>]

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

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

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.



>
> Keith
>
> From: dispatch [mailto:[e-mail]] On Behalf Of Ben 
> Campbell
> Sent: 07 November 2016 22:37
> To: Robert Sparks
> Cc: [e-mail]
> 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.
>
> 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:[e-mail]] On Behalf Of Adam 
> Roach
> Sent: 04 November 2016 21:28
> To: 'SIPCORE'; [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> 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.
>
> 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
>
> _______________________________________________
>
> dispatch mailing list
>
> [e-mail]<mailto:[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dispatch


> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch