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 protected]] on behalf of Aaron Falk [[email protected]] Sent: Wednesday, August 20, 2014 10:16 AM To: Michael Welzl Cc: Spencer Dawkins at IETF; [email protected] Subject: Re: [Taps] So, catching back up on the charter 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]<mailto:[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
