RTP Media Congestion Avoidance Techniques
charter-ietf-rmcat-01
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-03-10
|
01 | Amy Vezza | Responsible AD changed to Zaheduzzaman Sarker from Martin Duke |
2020-03-25
|
01 | Cindy Morgan | Responsible AD changed to Martin Duke from Spencer Dawkins |
2015-09-14
|
01 | Spencer Dawkins | Responsible AD changed to Spencer Dawkins from Wesley Eddy |
2012-09-21
|
01 | Cindy Morgan | New version available: charter-ietf-rmcat-01.txt |
2012-09-21
|
01 | Cindy Morgan | State changed to Approved from IESG review |
2012-09-21
|
01 | Cindy Morgan | IESG has approved the charter |
2012-09-21
|
01 | Cindy Morgan | Closed "Approve" ballot |
2012-09-21
|
01 | Cindy Morgan | Closed "Ready for external review" ballot |
2012-09-21
|
00-09 | Cindy Morgan | WG action text was changed |
2012-09-21
|
00-08 | Cindy Morgan | WG action text was changed |
2012-09-21
|
00-08 | Cindy Morgan | Edited to move milestones from charter text into Secretariat milestone tool so that they don't appear on the charter page twice. |
2012-09-21
|
00-09 | Cindy Morgan | New version available: charter-ietf-rmcat-00-09.txt |
2012-09-13
|
00-08 | Wesley Eddy | New version available: charter-ietf-rmcat-00-08.txt |
2012-09-13
|
00-07 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to Yes from Block |
2012-09-13
|
00-07 | Wesley Eddy | New version available: charter-ietf-rmcat-00-07.txt |
2012-09-13
|
00-06 | Robert Sparks | [Ballot block] (I expect to be able to move to Yes after a short discussion on the call) There is a milestone that doesn't appear … [Ballot block] (I expect to be able to move to Yes after a short discussion on the call) There is a milestone that doesn't appear to align with the charter text. The charter text holds the group to pass requirements for extensions to RTP/RTCP to avtcore. There's a milestone that has the group publishing an RTCP extension directly. What's the real intent? |
2012-09-13
|
00-06 | Robert Sparks | [Ballot Position Update] New position, Block, has been recorded for Robert Sparks |
2012-09-13
|
00-06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-09-13
|
00-06 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-09-12
|
00-06 | Wesley Eddy | New version available: charter-ietf-rmcat-00-06.txt |
2012-09-12
|
00-05 | Wesley Eddy | New version available: charter-ietf-rmcat-00-05.txt |
2012-09-12
|
00-04 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-09-12
|
00-04 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-09-12
|
00-04 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-09-11
|
00-04 | Pete Resnick | [Ballot comment] Small wordsmith: - For each of the Experimental algorithms that have not been selected for the Standards Track, the … [Ballot comment] Small wordsmith: - For each of the Experimental algorithms that have not been selected for the Standards Track, the working group will review the algorithm and determine whether the RFC should be moved to Historic status via a document that briefly describes the issues encountered. Please change "determine" to "recommend". Procedurally, I believe the WG recommends to the IESG to make the document Historic. |
2012-09-11
|
00-04 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2012-09-11
|
00-04 | Pete Resnick | [Ballot comment] Small wordsmith: - For each of the Experimental algorithms that have not been selected for the Standards Track, … [Ballot comment] Small wordsmith: - For each of the Experimental algorithms that have not been selected for the Standards Track, the working group will review the algorithm and determine whether the RFC should be moved to Historic status via a document that briefly describes the issues encountered. Please change "determine" to "recommend". Procedurally, I believe the WG recommends to the IESG to make the document Historic. |
2012-09-11
|
00-04 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-09-10
|
00-04 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-09-10
|
00-04 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-09-10
|
00-04 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-09-10
|
00-04 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2012-09-10
|
00-04 | Adrian Farrel | [Ballot comment] No objection, but noting that in discussions the IESG was nervous about the scoping for "more than one algorithm" and I said... > … [Ballot comment] No objection, but noting that in discussions the IESG was nervous about the scoping for "more than one algorithm" and I said... > Can I suggest that the "there may be more than one algorithm" could > be enhanced as "The working group may develop more than one > algorithm in this space if . in this case it will be one of the > objects of the experimentation to determine the applicabilities and > relative merits of the algorithms." |
2012-09-10
|
00-04 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2012-09-10
|
00-04 | Adrian Farrel | [Ballot comment] No objection, but noting that in discussions the IESG was nervous about the scoping for "more than one algorithm" and I said... > … [Ballot comment] No objection, but noting that in discussions the IESG was nervous about the scoping for "more than one algorithm" and I said... > Can I suggest that the "there may be more than one algorithm" could be enhanced > as "The working group may develop more than one algorithm in this space if > . in this case it will be one of the objects of the experimentation to > determine the applicabilities and relative merits of the algorithms." |
2012-09-10
|
00-04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-09-09
|
00-04 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-09-06
|
00-04 | Wesley Eddy | [Ballot Position Update] New position, Yes, has been recorded for Wesley Eddy |
2012-09-06
|
00-04 | Amy Vezza | Created "Approve" ballot |
2012-09-06
|
00-04 | Amy Vezza | State changed to IESG review from External review |
2012-09-05
|
00-04 | Amy Vezza | WG review text was changed |
2012-09-05
|
00-04 | Amy Vezza | WG review text was changed |
2012-09-03
|
00-04 | Wesley Eddy | State changed to External review from Internal review |
2012-09-03
|
00-04 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2012-08-30
|
00-04 | Cindy Morgan | WG action text was changed |
2012-08-30
|
00-04 | Cindy Morgan | WG review text was changed |
2012-08-30
|
00-04 | Cindy Morgan | State changed to Internal review from External review |
2012-08-30
|
00-04 | Cindy Morgan | State changed to External review from Internal review |
2012-08-30
|
00-04 | Cindy Morgan | WG review text was changed |
2012-08-30
|
00-04 | Cindy Morgan | Telechat date has been changed to 2012-09-13 from 2012-08-30 |
2012-08-30
|
00-04 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to Yes from Block |
2012-08-30
|
00-04 | Wesley Eddy | New version available: charter-ietf-rmcat-00-04.txt |
2012-08-30
|
00-03 | Wesley Eddy | New version available: charter-ietf-rmcat-00-03.txt |
2012-08-30
|
00-02 | Barry Leiba | [Ballot comment] [Updated for version -02] Version -02 takes care of my earlier concerns. Some wordsmithing on the new (last) work item: Can we make … [Ballot comment] [Updated for version -02] Version -02 takes care of my earlier concerns. Some wordsmithing on the new (last) work item: Can we make sure we don't limit it to "harmful"? There might be other reasons they'd want to make them Historic -- perhaps one simply doesn't work, perhaps they chose two similar ones initially and picked one of the two to move to PS, or whatever. I also want to make sure they don't just lightly say, "None of them are harmful, so we can skip this," and I'd like to make sure they at least have a brief look at each and think about it. May I suggest this?: - For each of the Experimental algorithms that have not been selected for the Standards Track, the working group will review the algorithm and determine whether the RFC should be moved to Historic status via a document that briefly describes the issues encountered. This step is particularly important for any algorithms with significant flaws, such as ones that turn out to be harmful to flows using or competing with them. |
2012-08-30
|
00-02 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2012-08-30
|
00-02 | Pete Resnick | [Ballot comment] Thanks for addressing the bulk of my comments. The only thing I think could still use some consideration, but needn't stop external review: … [Ballot comment] Thanks for addressing the bulk of my comments. The only thing I think could still use some consideration, but needn't stop external review: - Techniques to detect, instrument or diagnose failing to meet RT schedules as an Informational RFC Depending on what the WG ends up with here, I could see a standards track RFC coming out of the above. No need to limit the WG to Informational in the charter. |
2012-08-30
|
00-02 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Block |
2012-08-30
|
00-02 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-08-30
|
00-02 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-08-29
|
00-02 | Wesley Eddy | New version available: charter-ietf-rmcat-00-02.txt |
2012-08-29
|
00-01 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-08-29
|
00-01 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-08-29
|
00-01 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from No Record |
2012-08-29
|
00-01 | Barry Leiba | [Ballot comment] I agree with Pete's comment about making dependencies and prerequisites in the work list clearer. --- I agree with Pete's comment about allowing … [Ballot comment] I agree with Pete's comment about making dependencies and prerequisites in the work list clearer. --- I agree with Pete's comment about allowing the WG to decide that certain of the documents don't need to live as RFCs, beyond their use to the WG. --- - Once an algorithm has been found or developed that meets the evaluation criteria, and has a satisfactory amount of documented experience on the Internet, publish this algorithm as a Standards Track RFC. There may be more than one such algorithm. This implies that there are likely to be other algorithms that were defined as Experimental RFCs, which have NOT been chosen to move to Standards Track. I'd also like it to be part of the WG's job to review those RFCs, determine whether they should be moved to Historic, and move them there. --- It will also liaise closely with other Transport area groups working on congestion control, Nit: This just comes from the part of me that *hates* the verbing "liaise". Can we change this to "It will also work closely..." ? --- The last deliverable: - A recommended congestion control algorithm for interactive real time media - Standards-track RFC That should be "One or more recommended congestion control algorithms", or perhaps, to make it similar to the experimental ones two bullet up, add "(possibly more than one)" at the end. |
2012-08-29
|
00-01 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2012-08-29
|
00-01 | Barry Leiba | [Ballot comment] I agree with Pete's comment about making dependencies and prerequisites in the work list clearer. --- I agree with Pete's comment about allowing … [Ballot comment] I agree with Pete's comment about making dependencies and prerequisites in the work list clearer. --- I agree with Pete's comment about allowing the WG to decide that certain of the documents don't need to live as RFCs, beyond their use to the WG. --- - Once an algorithm has been found or developed that meets the evaluation criteria, and has a satisfactory amount of documented experience on the Internet, publish this algorithm as a Standards Track RFC. There may be more than one such algorithm. This implies that there are likely to be other algorithms that were defined as Experimental RFCs, which have NOT been chosen to move to Standards Track. I'd also like it to be part of the WG's job to review those RFCs, determine whether they should be moved to Historic, and move them there. --- It will also liaise closely with other Transport area groups working on congestion control, Nit: This just comes from the part of me that *hates* the verbing "liaise". Can we change this to "It will also work closely..." ? --- The last deliverable: - A recommended congestion control algorithm for interactive real time media - Standards-track RFC That should be "One or more recommended congestion control algorithms", or perhaps, to make it similar to the experimental ones two bullet up, add "(possibly more than one)" at the end. |
2012-08-29
|
00-01 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2012-08-29
|
00-01 | Barry Leiba | [Ballot comment] I agree with Pete's comment about making dependencies and prerequisites in the work list clearer. --- I agree with Pete's comment about allowing … [Ballot comment] I agree with Pete's comment about making dependencies and prerequisites in the work list clearer. --- I agree with Pete's comment about allowing the WG to decide that certain of the documents don't need to live as RFCs, beyond their use to the WG. --- - Once an algorithm has been found or developed that meets the evaluation criteria, and has a satisfactory amount of documented experience on the Internet, publish this algorithm as a Standards Track RFC. There may be more than one such algorithm. This implies that there are likely to be other algorithms that were defined as Experimental RFCs, which have NOT been chosen to move to Standards Track. I'd also like it to be part of the WG's job to review those RFCs, determine whether they should be moved to Historic, and move them there. --- It will also liaise closely with other Transport area groups working on congestion control, Nit: This just comes from the part of me that *hates* the verbing "liaise". Can we change this to "It will also work closely..." ? --- The last deliverable: - A recommended congestion control algorithm for interactive real time media - Standards-track RFC That should be "One or more recommended congestion control algorithms", or perhaps, to make it similar to the experimental ones two bullet up, add "(possibly more than one)" at the end. |
2012-08-29
|
00-01 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2012-08-29
|
00-01 | Barry Leiba | [Ballot comment] I agree with Pete's comment about making dependencies and prerequisites in the work list clearer. --- I agree with Pete's comment about allowing … [Ballot comment] I agree with Pete's comment about making dependencies and prerequisites in the work list clearer. --- I agree with Pete's comment about allowing the WG to decide that certain of the documents don't need to live as RFCs, beyond their use to the WG. --- - Once an algorithm has been found or developed that meets the evaluation criteria, and has a satisfactory amount of documented experience on the Internet, publish this algorithm as a Standards Track RFC. There may be more than one such algorithm. This implies that there are likely to be other algorithms that were defined as Experimental RFCs, which have NOT been chosen to move to Standards Track. I'd also like it to be part of the WG's job to review those RFCs, determine whether they should be moved to Historic, and move them there. --- It will also liaise closely with other Transport area groups working on congestion control, Nit: This just comes from the part of me that *hates* the verbing "liaise". Can we change this to "It will also work closely..." ? --- The last deliverable: - A recommended congestion control algorithm for interactive real time media - Standards-track RFC That should be "One or more recommended congestion control algorithms", or perhaps, to make it similar to the experimental ones two bullet up, add "(possibly more than one)" at the end. |
2012-08-29
|
00-01 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2012-08-29
|
00-01 | Russ Housley | [Ballot comment] This portion of the charter needs editing for consistency: The following topics are out of scope of this working group, on the assumption … [Ballot comment] This portion of the charter needs editing for consistency: The following topics are out of scope of this working group, on the assumption that work on them will proceed elsewhere: - Circuit-breaker algorithms for stopping media flows when network conditions render them useless; this work is done in AVTCORE; - Media flows for non-interactive purposes like stored video playback; those are not as delay sensitive as interactive traffic; - Defining active queue management; modifications to TCP of any kind; and - Multicast congestion control (common control of multiple unicast flows is in scope). - Topologies other than point-to-point connections. Implications on multi-hop connections will be considered at a later stage. Some bullets end in periods, and others in semicolons. Some bullets have two semicolons, and others use a parenthetical. |
2012-08-29
|
00-01 | Russ Housley | Ballot comment text updated for Russ Housley |
2012-08-29
|
00-01 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-08-28
|
00-01 | Robert Sparks | [Ballot block] One suggested change and a question for discussion before proceeding to external review: The suggested change: - Determine if there is … [Ballot block] One suggested change and a question for discussion before proceeding to external review: The suggested change: - Determine if there is an appropriate means to define standard RTP/RTCP extensions for carrying congestion control feedback, similar to how DCCP defines congestion control mechanisms, and if so, document such extensions as standards-track RFCs. What does "appropriate means to define an extension" mean? I suggest replacing that bullet with: - Determine if extensions to RTP/RTCP are needed for carrying congestion control feedback, using DCCPs congestion control mechanism as a model. If so, provide the requirements for such extension to the AVTCORE working group for standardization. For discussion on the call: - Develop a mechanism for identifying and controlling groups of flows. Please provide more detail. Are you talking about congestion control mechanisms that take information from more than one flow into account and applies it to all or some subset of them? Or is this bigger? One of the contentious topics in AVTCORE and RTCWEB is how to group media streams, particularly whether/how to combine them onto a single transport flow. That's related, but the answer to that larger question shouldn't be this working group's responsibility. |
2012-08-28
|
00-01 | Robert Sparks | [Ballot comment] Nits: Would changing Define to Identify be more correct in this? - Define interactions between applications and RTP flows to enable … [Ballot comment] Nits: Would changing Define to Identify be more correct in this? - Define interactions between applications and RTP flows to enable specifying requirements such as per-packet priorities. Please insert "congestion control" between "proposed" and "mechanisms" here: - Define evaluation criteria for proposed mechanisms, and publish these as an Informational RFCs. |
2012-08-28
|
00-01 | Robert Sparks | [Ballot Position Update] New position, Block, has been recorded for Robert Sparks |
2012-08-28
|
00-01 | Pete Resnick | [Ballot block] [Updating after comments from Wes, and after bug fixed by Robert and Henrik.] [I don't know if we have good criteria established for … [Ballot block] [Updating after comments from Wes, and after bug fixed by Robert and Henrik.] [I don't know if we have good criteria established for what should block external review and what should just be a comment. If folks think I've missed the mark, I'm happy to back off on these and make them just comments.] "The working group will:"... Several things in this section seem to be strictly ordered, and in some cases I think there are pre-requisites before the WG can move on to the next step. I'd like to see this section make those orderings and dependencies a bit clearer before heading out for external review. In the above, there is: - Define interactions between applications and RTP flows to enable specifying requirements such as per-packet priorities. And in the deliverables, there is: - Interactions between applications and RTP flows - Informational RFC I'd like this to be nailed down a bit more before external review. This could be read as either a requirements document, or it could be read to mean that the WG is defining an API. If you simply change the latter to "Requirements for interactions between...", that would make it clear that you're not intending them to work on an API document. (Which is not to say that they *can't* work on an API document, but if that's what you mean, I'd want that mentioned before external review too.) Either way, I think it's necessary to be clear what kind of thing you expect the WG to be working on. |
2012-08-28
|
00-01 | Pete Resnick | Ballot discuss text updated for Pete Resnick |
2012-08-28
|
00-01 | Pete Resnick | [Ballot block] [I don't know if we have good criteria established for what should block external review and what should just be a comment. If … [Ballot block] [I don't know if we have good criteria established for what should block external review and what should just be a comment. If folks think I've missed the mark, I'm happy to back off on these and make them just comments.] "The working group will:"... Several things in this section seem to be strictly ordered, and in some cases I think there are pre-requisites before the WG can move on to the next step. I'd like to see this section make those orderings and dependencies a bit clearer. - Interactions between applications and RTP flows - Informational RFC What's that? An API document? I see no other mention of this in the rest of the charter. |
2012-08-28
|
00-01 | Pete Resnick | [Ballot comment] A couple of minor things, certainly non-blocking, and you may feel free to decide otherwise. - Define evaluation criteria for proposed … [Ballot comment] A couple of minor things, certainly non-blocking, and you may feel free to decide otherwise. - Define evaluation criteria for proposed mechanisms, and publish these as an Informational RFCs. This seems like it might only be useful during the lifetime of the WG. Is there the possibility that the WG could get the criteria list but decided that it can dispose of that list instead of publishing as an Informational RFC? I'd rather leave this to the discretion of the WG. - Defining active queue management; modifications to TCP of any kind; and Is there something missing after the "and" in the first bullet above, or is this just a formatting error? Deliverables - Requirements for congestion control algorithms for interactive real time media - Informational RFC - Evaluation criteria for congestion control algorithms for interactive real time media - Informational RFC Same question as above: Can the WG decide that the above two documents might be disposable and therefore not publish as RFCs? - Techniques to detect, instrument or diagnose failing to meet RT schedules - Informational RFC Depending on what the WG ends up with here, I could see a standards track RFC coming out of the above. Why is this required to be Informational? |
2012-08-28
|
00-01 | Pete Resnick | Ballot comment and discuss text updated for Pete Resnick |
2012-08-28
|
00-01 | Pete Resnick | [Ballot comment] **NOTE** - Bug in the tracker. These comments should be in the "Block" section, but the tracker seems not to be saving that … [Ballot comment] **NOTE** - Bug in the tracker. These comments should be in the "Block" section, but the tracker seems not to be saving that text at the moment. Robert on the case. Comments in this box for the time being. [I don't know if we have good criteria established for what should block external review and what should just be a comment. If folks think I've missed the mark, I'm happy to back off on these and make them just comments.] "The working group will:"... Several things in this section seem to be strictly ordered, and in some cases I think there are pre-requisites before the WG can move on to the next step. I'd like to see this section make those orderings and dependencies a bit clearer. - Define evaluation criteria for proposed mechanisms, and publish these as an Informational RFCs. This seems like it might only be useful during the lifetime of the WG. Is there the possibility that the WG could get the criteria list but decided that it can dispose of that list instead of publishing as an Informational RFC? I'd rather leave this to the discretion of the WG. - Defining active queue management; modifications to TCP of any kind; and - Multicast congestion control (common control of multiple unicast flows is in scope). Is there something missing after the "and" in the first bullet above, or is this just a formatting error? Deliverables - Requirements for congestion control algorithms for interactive real time media - Informational RFC - Evaluation criteria for congestion control algorithms for interactive real time media - Informational RFC Same question as above: Can the WG decide that the above two documents might be disposable and therefore not publish as RFCs? - Interactions between applications and RTP flows - Informational RFC What's that? An API document? I see no other mention of this in the rest of the charter. - Techniques to detect, instrument or diagnose failing to meet RT schedules - Informational RFC Depending on what the WG ends up with here, I could see a standards track RFC coming out of the above. Why is this required to be Informational? |
2012-08-28
|
00-01 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2012-08-28
|
00-01 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2012-08-28
|
00-01 | Pete Resnick | [Ballot comment] Test |
2012-08-28
|
00-01 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2012-08-28
|
00-01 | Pete Resnick | [Ballot Position Update] New position, Block, has been recorded for Pete Resnick |
2012-08-27
|
00-01 | Sean Turner | [Ballot comment] This is probably a ploy to get me to bite on something easy and miss something evil ;) I thought the 1st sentence … [Ballot comment] This is probably a ploy to get me to bite on something easy and miss something evil ;) I thought the 1st sentence needs some tweaking. Might I suggest: OLD: In today's current Internet, part of the traffic is delivery of interactive real time media, often in the form of sets of media flows using RTP over UDP. NEW: Today's Internet traffic includes interactive real time media, which is often in the form of sets of media flows using RTP over UDP. Time Frames? |
2012-08-27
|
00-01 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-08-27
|
00-01 | Cindy Morgan | Responsible AD changed to Wesley Eddy |
2012-08-22
|
00-01 | Wesley Eddy | [Ballot Position Update] New position, Yes, has been recorded for Wesley Eddy |
2012-08-22
|
00-01 | Wesley Eddy | WG action text was changed |
2012-08-22
|
00-01 | Wesley Eddy | WG review text was changed |
2012-08-22
|
00-01 | Wesley Eddy | Created "Ready for external review" ballot |
2012-08-22
|
00-01 | Wesley Eddy | State changed to Internal review from Informal IESG review |
2012-08-22
|
00-01 | Wesley Eddy | Placed on agenda for telechat - 2012-08-30 |
2012-08-22
|
00-01 | Wesley Eddy | Initial review time expires 2012-08-29 |
2012-08-22
|
00-01 | Wesley Eddy | State changed to Informal IESG review from Not currently under review |
2012-08-22
|
00-01 | Wesley Eddy | New version available: charter-ietf-rmcat-00-01.txt |
2012-08-22
|
00-01 | Wesley Eddy | New version available: charter-ietf-rmcat-00-01.txt |
2012-08-22
|
00-01 | Wesley Eddy | New version available: charter-ietf-rmcat-00-01.txt |
2012-08-22
|
00-00 | Wesley Eddy | New version available: charter-ietf-rmcat-00-00.txt |
2012-08-15
|
00-00 | Wesley Eddy | New version available: charter-ietf-rmcat-00-00.txt |
2012-08-15
|
00-00 | Wesley Eddy | New version available: charter-ietf-rmcat-00-00.txt |
2012-01-02
|
00 | (System) | New version available: charter-ietf-rmcat-00.txt |