In my opnion the removal of the milestone and the move to "informational" is significant. If we want TAPS to have any impact of the standardization of a common approach to using alternative transport layers (and we all know eveyone seems to be disigning their own right now) then at least one "experimental" document is essential. If not the whole exercise may only provide another nice reading.
But I may be wrong. Marie-José Marie-José Montpetit, Ph.D. MIT ________________________________________ From: Taps [taps-boun...@ietf.org] on behalf of Michael Welzl [mich...@ifi.uio.no] Sent: Tuesday, August 19, 2014 7:25 AM To: Brian Trammell Cc: taps@ietf.org Subject: Re: [Taps] Another significant detail: status of RFCs On 19. aug. 2014, at 12:07, Brian Trammell wrote: > hi Michael, > > On 19 Aug 2014, at 11:35, Michael Welzl <mich...@ifi.uio.no> wrote: > >> Hi again, all, >> >> Did you notice that the two still existing milestones that we still have >> left also come with a status now? >> >> Before the London BOF, this bit was: >> >> *** >> * M7: Submit summary of the services provided by IETF transport protocols >> and congestion control mechanisms as well as requirements of common APIs to >> IESG as Informational >> * M10: Submit draft on how transport services are identified to IESG as >> Proposed Standard >> * M13: Submit set of services that a transport API should provide to IESG as >> Proposed Standard >> *** >> >> - before the Toronto BOF, I was told that there's no need for milestones to >> mention the status of documents, and I should just remove that. So we had, >> in the version of the charter that went to IETF open review, even after the >> Toronto BOF: >> >> *** >> * M9: Submit summary of the services provided by IETF transport protocols >> and congestion control mechanisms to IESG. >> * M15: Submit end system transport services to IESG. >> * M18: Submit specification of how the transport services can be provided to >> IESG. >> *** >> >> .... and now, all of a sudden, we have: > > So let's look at these one by one: > >> *** >> * M9: Submit to the IESG an Informational document defining a set of >> services provided by IETF transport protocols and congestion control >> mechanisms. > > I think this is pretty clearly Informational; it was also identified as such > pre-London, so I don't think this is particularly controversial as > Informational. ACK. > (Not really relevant to the charter, but on this point as we discussed in the > hallway in Toronto, I think the right way to do this is to solicit > contributions from people in the community who have deep knowledge of certain > transport protocols to specify these in terms of their behaviors in > individual I-Ds or I-D sections, then to have an editor pull these together > into a coherent whole.) Indeed, not a charter suggestion but a good plan I think. >> * M15: Submit to the IESG an Informational document recommending a minimal >> set of Transport Services that end systems should support. > > In my opinion, whether this is PS or Info comes down to two questions: (1) is > there an interoperability reason to specify a set of services that > must/should/may/must not be provided by end systems and (2) will there be > normative references to it from future PS documents? What you say makes sense to me. I actually don't remember who proposed to make this PS and why, and I can live with both. I just wanted to bring the question back to the group, as it is a change to how things were originally written. We had PS written there for a long time, went to "no status mentioned" because it was said that it needs no mention, and now it's Informational. > I don't really have an opinion here, though I think I'd lean toward PS just > for the sake of future utility. Note that if this milestone is PS it will > have to restate the salient points of each selected behavior / > service-in-terms-of-behaviors from the first milestone in normative language. > I'm okay with that too. Me too... sounds like we should go back to PS on this one, then. Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
