hi Michael, On 19 Aug 2014, at 11:35, Michael Welzl <[email protected]> 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. (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.) > * 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? 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. Cheers, Brian
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
