CONGestion RESponse and Signaling
charter-ietf-congress-00-01

[Ballot comment]
As the ballot has moved to CCWG, this DISCUSS is no more a useful/sensible ballot (also most of my points have been discussed and addressed).

# BLOCK (kept for archiving)

Indeed, the world has changed since TCP is no more *the* protocol, so this work is welcome.

Thanks for addressing one of my previous BLOCK issue about the rechartering.

alas, the other previous BLOCK point still stands: it is about the mismatch of the unique deliverable of this WG with the very broad scope ? The current charter appears to be more suited for a directorate (doing reviews of WG documents) than for a WG (publishing documents).

# COMMENT

Thank you for partly addressing my previous comment about `empirical evidence of safety` as "safety" was rather vague (now it is clear). "Empirical" is still rather vague, should it rather be "experimental" ?

[Ballot comment]
I'll broadly supportive of chartering this WG, and doing the congestion work in a central place makes sense to me.

I found this charter hard to read on my tablet, so would suggest formatting it to a slightly shorter line width, 72 cols maybe?

I would suggest deleting "CONGRESS will not remain open simply because “in case” further work comes along."

[Ballot block]
Indeed, the world has changed since TCP is no more *the* protocol, so this work is welcome.

Thanks for addressing one of my previous BLOCK issue about the rechartering.

alas, the other previous BLOCK point still stands: it is about the mismatch of the unique deliverable of this WG with the very broad scope ? The current charter appears to be more suited for a directorate (doing reviews of WG documents) than for a WG (publishing documents).

[Ballot comment]

Thank you for partly addressing my previous comment about `empirical evidence of safety` as "safety" was rather vague (now it is clear). "Empirical" is still rather vague, should it rather be "experimental" ?

[Ballot comment]
I concur with several of the BLOCK positions, mainly about the name and the apparent open-ended nature of the charter.  There's only one milestone, but I get the feeling after reading the whole thing that there might be many more.

[Ballot block]
I found the final paragraph to be odd:

```
CONGRESS will not remain open simply because “in case” further work comes along.
```

(Nit, the "because" in that sentence isn't quite grammatical, I think you can delete it without harm.)

Do you mean something like this?

NEW:
CONGRESS will close once all of its milestones have been completed.

If you don't mean that, what *do* you mean?

[Ballot comment]
- A number of unfortunate linebreaks look to have been introduced in version 01. Please fix these before releasing for IETF review.

- I agree with Paul that the WG acronym seems likely to lead to future confusion. I encourage you to find another; my recent experience with CAN -> CATS is that it's not that hard to make this change even late in the game.

- Is there some specific reason for the use of the weak "can" instead of the more intentional "will" in this paragraph?

```
The CONGestion RESponse and Signaling working group (CONGRESS) can review some
of the impediments to early congestion control work occurring in the IETF, and
can generalize transport in this area from TCP to all of the relevant transport
protocols.
```

This is your charter, after all. It seems to me that the word should be "will". The same applies to

```
The working group
should consider a revision
```

ISTM "should" should be "will".

[Ballot comment]
** The scoping text is broad and seems to redundantly reiterated that.

(a) “CONGRESS is authorized to adopt work relating to Congestion Control and AQM without rechartering.”

(b) Later there is a list of items that are “specifically in scope”.  Practically, I don’t find that they narrow anything.  Given the statements of:

==[ snip ]==

* Algorithms mature enough for standardization. CONGRESS may consider not
only the open Internet, but also algorithms focused on other deployment models
(e.g. datacenters and other controlled environments, reduced resource
deployments such as IoT, and so on).

* Algorithms proposed for Experimental status
==[ snip ]==

It seems almost any congestions control is in scope.  The subsequent list items of “multi-path congestions control, etc.” seems like specific items that were already permitted by the first two bullets.

Per (a), most of what was referenced in (b) would have been in scope.

** I applaud the sentiment of “CONGRESS will not remain open simply because ‘in case’ further work comes along.”  What is the mechanism that will be used to realize this principle?  As noted above, the charter scope is extremely broad, however, the milestones don’t reflect a large backlog of work that needs to get done.

** Editorial.  The paragraph starting with “CONGRESS is chartered to conduct …” has several unneeded line breaks.

[Ballot comment]
I agree with Paul's point about the lack of correlation between the in-scope work and the (one) milestone.  Is the expectation that proposals for other work will come up if the WG is chartered?

[Ballot block]
I see a lot of bullet points in the charter, but none of that matches up to the milestones, which isn't a real milestone as it is 1 entry predicting when everything should be completed. Can this be split up better?

I think the name "congress" is very misleading and will cause needless confusion with being about venue / meeting issues. Can this still be changed?

[Ballot block]
Indeed, the world has changed since TCP is no more *the* protocol, so this work is welcome.

I think that this text needs a rewrite:
`However, if the working group has
adopted further work in accordance with the guidelines above, it can recharter,
add milestones for them, and continue until that work is complete.`

Isn't the above putting the cart before the horses ? I.e., why not doing the usual process of rechartering *before* adopting an IETF draft ? (this of course does not prevent the WG to work/discuss an individual draft)

Another point is about what will be the deliverables of this WG ? The current charter appears to be more suited for a directorate (doing reviews of WG documents) than for a WG (publishing documents).

[Ballot block]
Indeed, the world has changed since TCP is no more *the* protocol, so this work is welcome.

I think that this text needs a rewrite.

`However, if the working group has
adopted further work in accordance with the guidelines above, it can recharter,
add milestones for them, and continue until that work is complete.`

Isn't the above putting the cart before the horses ? I.e., why not doing the usual process of rechartering *before* adopting an IETF draft ? (this of course does not prevent the WG to work/discuss an individual draft)

Another point is about what will be the deliverables of this WG ? The current charter appears to be more suited for a directorate (doing reviews of WG documents) than for a WG (publishing documents).

[Ballot comment]

One comment about `empirical evidence of safety` as safety is rather vague (or do you mean information security or network stability ?). "Empirical" is also rather vague, should it rather be "experimental" ?

I second Erik Kline's comment on ### P7/Bullet 1.

The charter is also rather long, but this is a matter of taste.

[Ballot comment]
# Internet AD comments for charter-ietf-congress-00-00
CC @ekline

## Comments

### P1

* I'm not sure the charter needs to capture this comment/tone about prior
  era research groups.  Perhaps just trim it down a bit, maybe:

  "and proposals seldom emerged having passed Internet-scale testing"

  or something?

### P7/Bullet 1

* What is the basis for requiring AD approval for application of an algorithm
  to a restricted deployment environment?

### _general_

* Are detection and adaption to other changes in path characteristics that
  might appear like congestion also be in scope?

  I'm thinking of networks of wireless links where the topology changes that
  can result in changes in latency/RTT, packet reordering, and of course
  packet drops that are handover-related but not necessary congestion-related
  (though I think might perhaps appear as congestion?).

  (See also 18m:45s of the presentation video at:
    https://dl.acm.org/doi/10.1145/3286062.3286075)