On 20. aug. 2014, at 16:46, Marie-Jose Montpetit <[email protected]> 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 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]> 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. 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 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. 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. >> 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. 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
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
