First, apologies to the group for not explaining the reasoning for the changes
in the last draft.
On Aug 20, 2014, at 3:15 AM, Michael Welzl <[email protected]> wrote:
> On 20. aug. 2014, at 05:30, Spencer Dawkins at IETF wrote:
>
>>
>> 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!
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.
>
>
>> 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.
>
>
>> 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.
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 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.
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
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
