Skip to main content

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