Subject: [Taps] So, catching back up on the charter

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 19 Aug 2014 22:30:11 -0500

If I might make a couple of observations, and ask a question ...

Obs: document status:

This is actually not as nailed down as you might think. The IESG can, and
sometimes does, discuss the proper status for a document as late as IESG
Evaluation (I've been involved in one of those conversations today for a
document on this Thursday's telechat, although that doesn't happen every
telechat). It's good to start out with a goal in mind, but you actually
have some flexibility.

Obs: milestones in general:

Some folks might understand this better than I did when I became an AD, so
I apologize if I'm boring anyone, but the food chain works like this:

The charter text, and this doesn't include the milestones, is a matter for
the IESG, in consultation with the community. Rechartering goes back to the
IESG and to the community.

The milestone text is a matter for the AD, in consultation with the working
group. Additions, changes and deletions that are within scope of the agreed
charter don't go back to the IESG. We often stick document status
in milestones, and that doesn't go back to the IESG, either.

Milestone dates are a matter for the chairs, in consultation with the
working group. An AD might have opinions about how fast a working group
should be moving, but we don't approve milestone date changes.

The high-order bit is, you really want work described in the charter text
unless you want to go back to the IESG, but a working group can
add/change/remove milestones for work that's described in the charter at
whatever time seems appropriate. So, please look most carefully at the
non-milestone charter text, because that's what's most difficult to change.

I would expect TAPS to add milestones when TAPS is ready to adopt an
individual draft (the draft name is one of the milestone attributes), and
work on it as a group. After that, the draft needs to reflect the editor's
understanding of what the working group thinks.

Q: So, my question:

How important is it for the working group to begin work on the third
deliverable immediately?

Thanks,

Spencer, as AD

---

From: Michael Welzl <[email-masked]>
Date: Wed, 20 Aug 2014 09:15:38 +0200

Hi!

Below:

On 20. aug. 2014, at 05:30, Spencer Dawkins at IETF wrote:

> This is actually not as nailed down as you might think. The IESG can, and sometimes does, discuss the proper status for a document as late as IESG Evaluation (I've been involved in one of those conversations today for a document on this Thursday's telechat, although that doesn't happen every telechat). It's good to start out with a goal in mind, but you actually have some flexibility.
> 
> Some folks might understand this better than I did when I became an AD, so I apologize if I'm boring anyone, but the food chain works like this:
> 
> The charter text, and this doesn't include the milestones, is a matter for the IESG, in consultation with the community. Rechartering goes back to the IESG and to the community.
> 
> The milestone text is a matter for the AD, in consultation with the working group. Additions, changes and deletions that are within scope of the agreed charter don't go back to the IESG. We often stick document status in milestones, and that doesn't go back to the IESG, either.
> 
> Milestone dates are a matter for the chairs, in consultation with the working group. An AD might have opinions about how fast a working group should be moving, but we don't approve milestone date changes.

Thanks a lot for all this information!

> The high-order bit is, you really want work described in the charter text unless you want to go back to the IESG, but a working group can add/change/remove milestones for work that's described in the charter at whatever time seems appropriate. So, please look most carefully at the non-milestone charter text, because that's what's most difficult to change.

There were some smaller changes to it in the last proposal that I suggested to undo in my previous email, because we do want to write that third document. Note that "undo" means "back to the version that was at IETF open review. I guess we should avoid semantic changes to that version unless we have very strong reasons.

> I would expect TAPS to add milestones when TAPS is ready to adopt an individual draft (the draft name is one of the milestone attributes), and work on it as a group. After that, the draft needs to reflect the editor's understanding of what the working group thinks.
> 
> Q: So, my question: 
> 
> How important is it for the working group to begin work on the third deliverable immediately?

I can't speak to "immediately" - logically, that work follows the first two items. Some people may be eager to start some of this work straight away, perhaps - I really don't know, this is for others to answer.

What I think is important to members of this group is that there is a dedication there that this document will be written. What you say above about milestones reflects their "internal" meaning, but I think there is another side to this: as someone external who *might* be interested in contributing to TAPS, I go to the IETF web site, click on TAPS, see e.g. the first two milestones and think "ah, these two lists is all they really develop". The most interesting bit is missing - so it's a boring, possibily useless group and I don't get involved.

Flexibility regarding how services really are provided is a key feature of TAPS, so it's absolutely natural for that third item to be experimental - but if we don't document an example way of implementing this, we really just have an empty shell. Similarly, if we don't put the milestone there now, we have an obviously boring group. That would be a bit like defining what DiffServ services do for the application without even hinting at how they could be implemented.

That's how I see things, at least...

Cheers,
Michael

---

From: Aaron Falk <[email-masked]>
Date: Wed, 20 Aug 2014 10:16:21 -0400

First, apologies to the group for not explaining the reasoning for the changes in the last draft.  

> Thanks a lot for all this information!

Connecting the dots a bit here to make things more explicit: the removal of the 3rd milestone was at Spencer’s request and in response to repeated IAB guidance that work on the third deliverable was a possible distraction from completing the 1st two.  The AD & IESG are the 'work managers' for the IETF so their opinion counts on this topic.

> There were some smaller changes to it in the last proposal that I suggested to undo in my previous email, because we do want to write that third document. Note that "undo" means "back to the versio…

I’ll address that in the relevant thread. Keep in mind that the charter is now being reviewed by folks outside the group so it is not surprising that there are new questions coming up (particularly about clarity).  My experience is that this broader review is often important for making explicit some implied context.  I’ve tried to add detail in my changes but maybe I’ve gotten it wrong.  If so, that’s useful to getting us all on the same page.

> What I think is important to members of this group is that there is a dedication there that this document will be written. What you say above about milestones reflects their "internal" meaning, but…

The charter modification that included the description of the third doc without scheduling the milestone was intended to address just that point.  This is planned work but won’t be scheduled yet. 

> Flexibility regarding how services really are provided is a key feature of TAPS, so it's absolutely natural for that third item to be experimental - but if we don't document an example way of imple…

I’m a little concerned that “flexibility”, “experimental”, and “interesting” are indicators that there’s research to be done here.  And the IETF doesn’t have a good track record for research in working groups.  (That is a role for the IRTF, as I’m sure you know.)  Working groups seem to function best when there are one or more well-worked out proposals (or, better, running code) that the group can reconcile.  So, I can understand the concern about this being a distraction from the ‘boring but useful’ work.

—aaron

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 20 Aug 2014 14:46:58 +0000

I may talk for myself but yes running code is one reason I am interested in this. I have worked and still am working on architectures for this. But the proof is in the pudding. As long as we cannot show a approach that works, scales and is reliable we are doing research not engineering. And after 15 years of research I am ready for engineering :-)

/mjm
________________________________
From: Taps [[email-masked]] on behalf of Aaron Falk [[email-masked]]
Sent: Wednesday, August 20, 2014 10:16 AM
To: Michael Welzl
Cc: Spencer Dawkins at IETF; [email-masked]
Subject: Re: [Taps] So, catching back up on the charter

On Aug 20, 2014, at 3:15 AM, Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:

Q: So, my question:

—aaron

---

From: Michael Welzl <[email-masked]>
Date: Wed, 20 Aug 2014 23:28:18 +0200

> Connecting the dots a bit here to make things more explicit: the removal of the 3rd milestone was at Spencer’s request and in response to repeated IAB guidance that work on the third deliverable wa…

IESG: is this indeed their opinion? If so, why didn't they say that during IESG review?
AD: in his email, Spencer essentially said that milestones don't matter much; I tried to explain why I think this milestone matters to us.
IAB: All I know is that IAB member Brian Trammell has written, to the list, yesterday: "Per the third point of the charter, I think we want to add the third milestone back, but make clear that the effort is experimental; something like:"

...add to this the fact that we're after IETF Open review, where this charter has been looked at and agreed upon by a lot of folks who might no longer agree if we do a significant content change, then this seems just weird to me.

> The charter modification that included the description of the third doc without scheduling the milestone was intended to address just that point.  This is planned work but won’t be scheduled yet. 

Why not scheduled? We wanted it to be scheduled, we wanted a dedication that this will be done when we put it in the charter about a year ago and when we kept it there all this time.

> I’m a little concerned that “flexibility”, “experimental”, and “interesting” are indicators that there’s research to be done here.  And the IETF doesn’t have a good track record for research in wor…

I don't understand. It's perfectly normal, and good design, to standardize only what's needed and keep things open. That's all over IETF standards - as you know from DCCP, which is a framework for "interesting" "experimental" new CCIDs. That's what I'm talking about. We do want a well-worked out proposal and running code, just not prescribe it as the only possible implementation.

Plus, for a more general answer to the standard "isn't this research, shouldn't this be IRTF work?" question, see our FAQ  ;-)
A1.2.2 at https://sites.google.com/site/transportprotocolservices/questions-that-we-need-to-answer

Cheers,
Michael

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 21 Aug 2014 03:09:36 -0500

Not particularly to Michael, but replying to this note because he 
eloquently phrased some questions that other folk on this mailing list 
almost certainly share ...

On 08/20/2014 04:28 PM, Michael Welzl wrote:
>
> On 20. aug. 2014, at 16:46, Marie-Jose Montpetit <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> I may talk for myself but yes running code is one reason I am 
>> interested in this. I have worked and still am working on 
>> architectures for this. But the proof is in the pudding. As long as 
>> we cannot show a approach that works, scales and is reliable we are 
>> doing research not engineering. And after 15 years of research I am 
>> ready for engineering :-)
>>
>> /mjm
>> ------------------------------------------------------------------------
>> *From:*Taps [[email-masked] <mailto:[email-masked]>] on 
>> behalf of Aaron Falk [[email-masked] <mailto:[email-masked]>]
>> *Sent:*Wednesday, August 20, 2014 10:16 AM
>> *To:*Michael Welzl
>> *Cc:*Spencer Dawkins at IETF; [email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [Taps] So, catching back up on the charter
>>
>>>> The milestone text is a matter for the AD, in consultation with the 
>>>> working group. Additions, changes and deletions that are within 
>>>> scope of the agreed charter don't go back to the IESG. We often 
>>>> stick document status in milestones, and that doesn't go back to 
>>>> the IESG, either.
>>>>
>>>> Milestone dates are a matter for the chairs, in consultation with 
>>>> the working group. An AD might have opinions about how fast a 
>>>> working group should be moving, but we don't approve milestone date 
>>>> changes.
>>>
>> Connecting the dots a bit here to make things more explicit: the 
>> removal of the 3rd milestone was at Spencer’s request and in response 
>> to repeated IAB guidance that work on the third deliverable was a 
>> possible distraction from completing the 1st two.  The AD & IESG are 
>> the 'work managers' for the IETF so their opinion counts on this topic.
>

This charter isn't actually to IESG Review yet. 
https://datatracker.ietf.org/doc/charter-ietf-taps/ shows the charter in 
External Review. If you click on the Charter State hyperlink, you get 
https://datatracker.ietf.org/doc/help/state/charter/, which shows that 
IESG Review happens next.

I've already talked to the rest of the IESG about how bleeding confusing 
it is that we ballot the charter for External Review (for the purposes 
of this conversation, "to send it to the IETF for External Review"), and 
ballot the charter again for approval. You can see the first ballot if 
you click on version 00-00 of the charter - that was the one that went 
through Internal Review, and was approved for External Review).

For basically ever, balloting to send a charter for External Review 
happened in a closet. No one outside the IESG and IAB saw what was 
happening. The IAB sees what's happening because they're chartered to 
look at all BOFs, as part of their duty for architectural oversight, as 
described in http://tools.ietf.org/html/rfc2850#section-2.1. But no one 
else was involved.

Recently, and by recently I mean within the past year, we've started 
putting the relevant mailing list as one of the notification targets. 
That means what's happening is more transparent than what was happening 
previously, but almost no one (including the IESG and IAB) is used to 
that yet. So, it's still confusing to get ballot notifications during 
Internal Review. My apologies for that, of course.

> AD: in his email, Spencer essentially said that milestones don't 
> matter much; I tried to explain why I think this milestone matters to us.

If I said that, I misspoke. Let me try again.

Milestones don't matter during the charter discussions, but they do 
matter when the working group is actually working on a document. The 
intention is, that they tell the working group (and people outside the 
working group) what's on the plate *now*.

The charter describes what's in scope, not the milestones. The 
milestones are to help the working group manage its work to accomplish 
what's in the charter.

People can work on anything they like, and if they're working on 
something that's within scope for the working group, they can talk about 
it on the mailing list, and if there's time after discussion of work on 
the current milestones, the chairs can make time for it in meetings. But 
the purpose of milestones is to focus work.

It may be that this should change, but that's the way our process works 
today.

> IAB: All I know is that IAB member Brian Trammell has written, to the 
> list, yesterday: "Per the third point of the charter, I think we want 
> to add the third milestone back, but make clear that the effort is 
> experimental; something like:"

So, it's possible that not everyone is familiar with 
http://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-member-roles-in-evaluating-new-work-proposals/, 
but it might be helpful to mention this extract:

>
>       A note about IAB member roles
>
> In providing architectural oversight and guidance for a BOF, IAB 
> members are rarely speaking for the IAB, because the IAB has rarely 
> determined an IAB consensus position on new work being proposed. 
> Individual IAB members do not have a privileged role in determining 
> whether a BOF will result in a chartered working group. IAB members 
> providing architectural oversight must ensure that their role is not 
> misunderstood by BOF proponents or by the larger community of interest.
>
> The IESG is requested to give comments from IAB members the same 
> weight the comments would be given if those persons were not serving 
> on the IAB — no more, and no less.
>

So, it doesn't actually matter that Brian is on the IAB (I'm glad that 
he is, but that has nothing to do with this charter discussion).

I held the pen for that IAB document, so I actually believe what it says.

> ...add to this the fact that we're after IETF Open review, where this 
> charter has been looked at and agreed upon by a lot of folks who might 
> no longer agree if we do a significant content change, then this seems 
> just weird to me.

So the thing to remember here is that working group charters are IETF 
community property. Yes, there can be a tension between what the broader 
community thinks should happen and what the people who actually do the 
work are willing to do. That's why we're talking now.

I should also note that the WG Review announcement at 
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13052.html 
points to the IESG (the exact text says this:

> A new IETF working group has been proposed in the Transport Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2014-07-31.

This is true for all WG Reviews. It's good that there's been a lot of 
discussion in public, and that should shorten the conversation we're 
having now, but private feedback to the IESG (not just from IAB members, 
but from anyone) is fine.

Again, it may be that this should change, but that's the way our process 
works today.

>
>>>> The high-order bit is, you really want work described in the 
>>>> charter text unless you want to go back to the IESG, but a working 
>>>> group can add/change/remove milestones for work that's described in 
>>>> the charter at whatever time seems appropriate. So, please look 
>>>> most carefully at the non-milestone charter text, because that's 
>>>> what's most difficult to change.
>>>
>>> There were some smaller changes to it in the last proposal that I 
>>> suggested to undo in my previous email, because we do want to write 
>>> that third document. Note that "undo" means "back to the version 
>>> that was at IETF open review. I guess we should avoid semantic 
>>> changes to that version unless we have very strong reasons.
>>
>> I’ll address that in the relevant thread. Keep in mind that the 
>> charter is now being reviewed by folks outside the group so it is not 
>> surprising that there are new questions coming up (particularly about 
>> clarity).  My experience is that this broader review is often 
>> important for making explicit some implied context.  I’ve tried to 
>> add detail in my changes but maybe I’ve gotten it wrong.  If so, 
>> that’s useful to getting us all on the same page.
>>

Right about here, it's helpful for me to mention that you folk are still 
talking, and I'm still listening :-)

I hope this note has been useful in navigating unfamiliar territory. 
Most of the people who aren't on the IESG aren't involved in the charter 
process often enough to pick up all the subtleties (see the p.s. below).

And thanks for the questions.

Spencer

p.s. Speaking not as the responsible AD, but as Spencer, and candidly - 
I was involved in the charter process for three working groups I 
co-chaired, I spent more than three years watching the IESG up close as 
one of their scribes, I spent just over three years on the IAB, and 
chartering new work is STILL the least obvious thing to me that I'm 
responsible for. If other people are also confused, or would like it to 
work differently, that could be an excellent open mike topic for the 
IETF 91 plenaries (for both the IAB and the IESG, I'd say).

Please don't be shy. We (the IESG) want the way we charter new work to, 
well, "work".