Subject: Re: [RAI] Dispatch Charter - draft B

From: "eburger" <[email-masked]>
Date: Tue, 3 Mar 2009 01:49:17 +0000

What bugs me about the charter is it does not describe a work group at all. Rather, the charter describes what I could best characterize as an advisory board to the RAI ADs. ALL of the "tasks" are jobs of the ADs: evaluating if we need to form a work group, assigning work to a work group, or declining work. 

Why not "say what we mean"? Let us not form a "work group" with no deliverables, no metrics, and no end. Rather, I would offer we form an RAI Directorate. Membership could be open or at the pleasure of the ADs (I could make strong arguments either way). In fact, a Directorate with a pair of Directors, assigned by the ADs, and a body of volunteers (i.e., open) has the qualities that we desire from a work group. It is open and public, yet has clear direction and metrics. 

With this structure, we do not talk about milestones. Rather, we talk about the quality of decisions, the percentage of quality proposals approved (with suggested disposition to the appropriate work group), and the time it takes the Directorate to process the proposals. 

Moreover, this would be a great venue to mix "old timers" with "new blood." In academia, we start researchers with reviewing papers for the professors on PCs. Likewise, we can pair old/new people on proposal reviews. 

Just a thought. 

------Original Message------
From: Dan Wing
Sender: [email-masked]
To: Dean Willis
To: Cullen Jennings
Cc: [email-masked]
Subject: Re: [RAI] Dispatch Charter - draft B
Sent: Mar 2, 2009 5:17 PM

> > The Dispatch working group is chartered to consider proposals for
> > new work in the RAI area and identify, or help create, an 
> > appropriate venue for the work. Options for handling new work 
> > include:
> >
> > - Assigning the work to an existing WG.
> > - Developing a proposal for a BOF.
> > - Developing a charter and establishing consensus for a new WG
> >   or Exploratory Group. This option will primarily be used with
> >   fairly mature and well-defined efforts.
> 
> One critical and insufficiently used option is the "gong". 
> That is, we  
> MUST be able to reject and defer work proposals. We might 
> want this in  
> the charter.

A gong is only useful if the principals understand why the
gong was struck.  On the famous television show, some people 
tried to get a gong -- it was funny.  At SIPPING (or DISPATCH),
I assure you that the principals are not trying to get a gong.

The charter should explain what sort of feedback is given to
principals for rejected submissions:  point to another WG
(ugh, that's what DISPATCH is trying to avoid, no?), another
standards organization (e.g., 3GPP), "no, we don't like that
idea", or whatever.  The DISPATCH charter should explain this
with some crispness.

-d

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

--
Eric Burger

Sent from my mobile device; sorry if terse. All mobile users need lemonade.  See <http://www.standardstrack.com/ietf/lemonade> for more information.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 5 Mar 2009 16:26:39 -0600

Hi, Cullen,

Just wondering - you seemed to be thinking that DISPATCH WOULD start out 
with deliverables, left over from SIPPING, but it wasn't clear to me whether 
DISPATCH might also function as (for example) TSVWG functions, as a home for 
new topics that don't justify the formation of a working group. From the 
TSVWG charter:

"The Transport Area receives occasional proposals for the development
and publication of RFCs dealing with transport topics that are not in
scope of an existing working group or do not justify the formation of
a new working group. TSVWG will serve as the forum for developing
such work items in the IETF."

If the answer is "no", I'd be inclined to agree with Eric's post below ("a 
working group with no deliverables is a strange working group"), but I'm 
hoping that your answer might be "yes", because there is, after all, a LOT 
of overhead and latency involved with going through the BOF/WG formation 
process, and we're chatting along in another thread about "reducing delays".

Thanks,

Spencer

> What bugs me about the charter is it does not describe a work group at 
> all. Rather, the charter describes what I could best characterize as an 
> advisory board to the RAI ADs. ALL of the "tasks" are jobs of the ADs: 
> evaluating if we need to form a work group, assigning work to a work 
> group, or declining work.
>
> Why not "say what we mean"? Let us not form a "work group" with no 
> deliverables, no metrics, and no end. Rather, I would offer we form an RAI 
> Directorate. Membership could be open or at the pleasure of the ADs (I 
> could make strong arguments either way). In fact, a Directorate with a 
> pair of Directors, assigned by the ADs, and a body of volunteers (i.e., 
> open) has the qualities that we desire from a work group. It is open and 
> public, yet has clear direction and metrics.
>
> With this structure, we do not talk about milestones. Rather, we talk 
> about the quality of decisions, the percentage of quality proposals 
> approved (with suggested disposition to the appropriate work group), and 
> the time it takes the Directorate to process the proposals.
>
> Moreover, this would be a great venue to mix "old timers" with "new 
> blood." In academia, we start researchers with reviewing papers for the 
> professors on PCs. Likewise, we can pair old/new people on proposal 
> reviews.
>
>
> Just a thought.
>
> Sent from my mobile device; sorry if terse. All mobile users need 
> lemonade.  See <http://www.standardstrack.com/ietf/lemonade> for more 
> information.

---

From: Dean Willis <[email-masked]>
Date: Thu, 5 Mar 2009 17:19:48 -0600

On Mar 5, 2009, at 4:26 PM, Spencer Dawkins wrote:

> Hi, Cullen,
>
> Just wondering - you seemed to be thinking that DISPATCH WOULD start  
> out with deliverables, left over from SIPPING, but it wasn't clear  
> to me whether DISPATCH might also function as (for example) TSVWG  
> functions, as a home for new topics that don't justify the formation  
> of a working group. From the TSVWG charter:
>

In working up a possible agenda using this model, Keith and Mary and I  
found it much easier to do a three-way split: SIPCORE, DISPATCH, and  
the chartered/mature stuff that was left over.

Here's the draft agenda split this way:

http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_74

However, I think it might be helpful to split the "chartered/mature  
stuff that is left over" class three ways:

1) Stuff that's basically "done" and just needs some final polishing  
to get out the door.

2) Stuff that's in-progress but homeless.

3) Stuff that probably ought to be deferred fro a while until we get a  
higher level of maturity on the basic specs.

Note that figuring out which stuff is #2 (and figuring out where its  
should go)  and declaring stuff to be #3 is the proper scope of  
DISPATCH. For example, what we do with  things like sip-saml, session- 
policy, and ISDN-uui can be decided by DISPATCH. This won't be easy:  
DISPATCH must learn to say "no" rather firmly. There are plenty of  
things to work on, and we must learn t oration our time towards the  
greatest benefit.

But what do we do with category #1 -- stuff that is basically done and  
just needs some polishing?

One proposal is to push these things as deliverables into SIPCORE or  
DISPATCH as one-off special-case not-quite-conformant-to-charter  
deliverables. I don't like this idea much. I'd much rather maintain a  
third working group that is chartered to finish these items WITHOUT  
TAKING ON ADDITIONAL WORK. This could reasonably be a recharter of SIP  
or SIPPING, or a new group (SIPDREGS, maybe, just for the pun value).

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 5 Mar 2009 19:42:58 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Spencer Dawkins
>

Yeah having to create a BOF/WG for some of these drafts would be humorous.  For example I submitted an I-D to delete the optional component in the ABNF for Call-ID - do I need to create a BOF and WG for deleting an ABNF token?  Maybe I should host an interim for this new WG, just to give us more time.
;)

(luckily in this particular case I'm proposing updating 3261, so it will be easier because SIPCORE already exists for that, i.e. updating 3261 will be easier than doing an extension. :)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Thu, 5 Mar 2009 19:08:26 -0600

On Mar 5, 2009, at 6:42 PM, Hadriel Kaplan wrote:
>
> Yeah having to create a BOF/WG for some of these drafts would be  
> humorous.  For example I submitted an I-D to delete the optional  
> component in the ABNF for Call-ID - do I need to create a BOF and WG  
> for deleting an ABNF token?  Maybe I should host an interim for this  
> new WG, just to give us more time.
> ;)
>
> (luckily in this particular case I'm proposing updating 3261, so it  
> will be easier because SIPCORE already exists for that, i.e.  
> updating 3261 will be easier than doing an extension. :)

Bingo. That's the acid test for SIPCORE: does the work in question  
update any of the core SIP documents? If so, and we have a consensus  
that the work needs doing, then it goes to SIPCORE.

And the prioritization is right on, too. It SHOULD be procedurally  
easier to fix an error in a current specification than it  is to  
extend it with new complications.

Many of the other drafts would be humorous to propose for a WG because  
you can just look at it and say "That's not gonna happen!". And that's  
pretty much the acid test for the set of things we have to learn say  
"No" to if we're ever going to get this spec family nailed down well  
enough that it can actually have certified interop.

Then there are a whole class of things that we can look at and say  
"That's just the tip of the iceberg -- it NEEDS a whole working group  
to get done, if we decide to do it." I think a prime example of this  
is the SAML work. Plumbing the extent of the usage of SAML and SIP is  
not  a one or two draft problem. It's a whole family of work, and it  
is deeply entwined with concepts like identity, role, SPIT, consent,  
and so on. But the SIP working group just doesn't have the headspace  
to wrap around that problem set. So it either needs a new working  
group, SAML needs to be pushed out as an experimental to get people  
thinking about a new working group, or needs to get put on a shelf  
someplace until it ripens up.

--
Dean

---

From: Eric Burger <[email-masked]>
Date: Thu, 5 Mar 2009 21:05:59 -0500

I would also offer that many, many, many work groups defer non- 
chartered work to Individual Drafts. Why must everything be stuffed  
into a Work Group? Either the work is germane and gets added to one of  
the existing (split-up) work groups, the work is big and germane and  
we do (sensibly!) go through the BOF process, or the work is a one-of  
that needs to be done but will never get enough interest to do in a  
work group (do it as Individual).

On Mar 5, 2009, at 8:08 PM, Dean Willis wrote:

>> component in the ABNF for Call-ID - do I need to create a BOF and  
>> WG for deleting an ABNF token?  Maybe I should host an interim for  
>> this new WG, just to give us more time.
>> ;)
>>
> Many of the other drafts would be humorous to propose for a WG  
> because you can just look at it and say "That's not gonna happen!".  
> And that's pretty much the acid test for the set of things we have  
> to learn say "No" to if we're ever going to get this spec family  
> nailed down well enough that it can actually have certified interop.
>
> "That's just the tip of the iceberg -- it NEEDS a whole working  
> group to get done, if we decide to do it." I think a prime example  
> of this is the SAML work. Plumbing the extent of the usage of SAML  
> and SIP is not  a one or two draft problem. It's a whole family of  
> work, and it is deeply entwined with concepts like identity, role,  
> SPIT, consent, and so on. But the SIP working group just doesn't  
> have the headspace to wrap around that problem set. So it either  
> needs a new working group, SAML needs to be pushed out as an  
> experimental to get people thinking about a new working group, or  
> needs to get put on a shelf someplace until it ripens up.
>
> --
> Dean
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 5 Mar 2009 21:55:09 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Burger
> Sent: Thursday, March 05, 2009 9:06 PM
>

Yeah I've been feeling that way myself lately.  I do worry though about the ambiguity from such docs.  I know this is an ancient topic in the IETF, but it's true that people see the acronym RFC and think "standard".  I just had a customer ask if we could do interworking to IAX2 (RFC 5456) now that it's a "Standard".  Blech.

-hadriel

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 25 Mar 2009 01:51:18 -0500

Again, since Jon asked for feedback on the proposed charters, I wanted to 
say that I agreed with a lot of what Eric said in his note below (and what 
Dan said in his note that Eric replied to).

To be clear - I'm sure that it's easier to call DISPATCH a working group 
than to create something that's not defined in 2026. Harald had bunches of 
issues when he created the EDU Team - did it get listed on the Working 
Groups page? could it request meeting slots? was the EDU Team Coordinator on 
the Working Group Chairs mailing list? Etc.

But we ought to be clear that people are going to think they know what a 
DISPATCH working group would do, based on what other working groups do, and 
they might not be correct about that.

Jon handwaved some general deliverable types during his presentation today 
(draft charters for a working group, problem-statements-00, and 
radioactivity assessments). It would be good for something like Jon's list 
to appear in the charter, even as examples.

I've posted a couple of times (admittedly once was earlier today) asking 
about a home for work items that are too small to justify even a small 
working group - I'd like to see some response to this (even if the response 
is "don't worry about it" posted to this mailing list) while the charter is 
still under consideration.

In addition - I know that we almost always send out proposed charters for 
comment with chairs listed as TBD, but it would help me to visualize 
DISPATCH if the ADs could clarify whether they will chair the working group 
(similar to TSVWG), or whether others would chair the working group (similar 
to SIPPING today).

Thanks,

Spencer