Hi! Below:
On 20. aug. 2014, at 05:30, Spencer Dawkins at IETF wrote: > 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. 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 _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
