Subject: [Taps] Another significant detail: status of RFCs

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Aug 2014 11:35:11 +0200

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:

***
* M9: Submit to the IESG an Informational document defining a set of services provided by IETF transport protocols and congestion control mechanisms.
* M15: Submit to the IESG an Informational document recommending a minimal set of Transport Services that end systems should support.
***

Minor change? I think not. Might be okay or not - I just don't like this happening without people noticing and commenting.

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Tue, 19 Aug 2014 12:07:35 +0200

hi Michael,

> * 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

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Aug 2014 13:25:12 +0200

> 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…

Indeed, not a charter suggestion but a good plan I think.

> 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…

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 sele…

Me too...   sounds like we should go back to PS on this one, then.

Cheers,
Michael

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 19 Aug 2014 11:31:48 +0000

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 [[email-masked]] on behalf of Michael Welzl [[email-masked]]
Sent: Tuesday, August 19, 2014 7:25 AM
To: Brian Trammell
Cc: [email-masked]
Subject: Re: [Taps] Another significant detail: status of RFCs

ACK.

Cheers,
Michael

_______________________________________________
Taps mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/taps