New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Two Loss bits (Q&R) #2594
Two Loss bits (Q&R) #2594
Conversation
Update draft-ietf-quic-lossbits-exp.md
Merge upstream
Refresh wrt transport ; clarify bidirectionality and negotiation
Clarification on benefits of the method
Unless I'm missing something, this seems more appropriate for an individual draft rather than a QUIC WG document in this repo? |
Quite possibly: what is the appropriate place ? |
@ferrieux: This draft is an individual draft and not a wg document. A couple of suggestions:
|
Unless I'm mistaken, the spin bit draft started its life in this exact place. The reasoning being similar (a proposed extension to the main drafts, without preconceptions about where it should eventually land), I assumed it would be fine to do the same. Why is it different ? |
@ferrieux: The spin bit document started here: https://tools.ietf.org/html/draft-trammell-quic-spin-00. It wasn't a part of the base-drafts repository. |
OK, will do so, then. Is there a way of somehow linking to there from within quicwg documentation, beyond a mention on the mailing list ? |
That's a question for the chairs. I would: (i) close this PR, (ii) submit an individual draft to the drafts repo, (iii) ask the chairs for how to proceed. |
IMO this is clearly beyond the scope of QUICv1. Not all work going on with QUIC deserves a link from the main repo. It is straightforward to set up a separate GitHub repo following MTs instructions if you want your document source to be available. I also recommend the above suggestions, post an Individual Draft and promote the work on the mailing list. The working group can, at the chairs discretion, give consideration on if there is support to adopt the document etc. |
So, I take it that the prerequisite to suggesting any new idea now amounts to writing a bona fide I-D, regardless of how incremental the idea is wrt existing wg material ? Isn't there a more lightweight approach, allowing to reuse the nice github workflow for new material, but in a separate "not approved yet" area ? |
Hi @ferrieux, creating a separate draft is pretty lightweight. Especially when you've already written it, all you need to do is submit it - there is no need for a GitHub to start the discussion. I personally have several individual drafts in this state. Once you've submitted your draft all you need to do is email the mailing list to get feedback on it. |
You've clearly put the effort in to write this draft, which is great. However, we should ensure we respect the chair's process; several QUIC drafts are now in the late stage process as described in CONTRIBUTING.md (https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#late-stage-process). I'd encourage you to file an issue that articulates the problem statement and the benefits of the proposal. |
Oh, the intent was not at all to hijack the v1 late-stage convergence. This draft is here to convey a simple idea that'd most appropriately be implemented in a post-v1, negotiated experimental version among those that are expected to proliferate after RFC publication. So I won't disrupt the already tight schedule with it. I'm mereley looking for an appropriate landing site for a simply formatted md file (as opposed to a full I-D with its constrained layout). |
I can see how maybe it seems easier to fork this repo and work in that but it is a bit confusing for the rest of us. Depending exactly what you're trying to achieve, you might find it easier to create a Wiki page. This is what the ECN work did: https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC. It would allow simple markup and collaboration. If you do want IETF-submission-compatible formats, these instructions for setting up your own separate repo don't take much time: https://github.com/martinthomson/i-d-template/blob/master/doc/REPO.md |
Thanks. Indeed those are options, but none comes close to the workflow efficiency of fork/commit/pullrequest/comment on github, right ? It would seem that just creating a separate "provisional" repo at the wg toplevel would solve the problem in one swell foop ; there, people could just take advantage of the tool suite, visibility & ease of collaboration without in any way claiming automatic community validation.... |
@ferrieux : It's perfectly fine to not submit a draft and to keep this on github -- that is entirely your prerogative. The reason you're getting these process comments is that you've generated a PR against the base-drafts repository for what is effectively a new draft. |
The suggested workflow is at odds with how this WG works. As a sample point, this PR has little context to explain itself without looking at all the text in unrendered markdown. I subscribe to this repo and I got multiple notifications for each commit made after the PR was opened. This is noisy and distracts the WG from focusing on delivering our chartered items. |
Hi @ferrieux. You need to submit new drafts to the datatracker and bring them to the attention of the Working Group for them to be discussed. As mentioned, this repo is for adopted drafts only; until then, it's best in your own repo. |
Understood; apologies for the noise. Now, if there was a separate repo (named "proposals", "extensions", "side orders", "ancillary drafts" or whatever), to which you obviously wouldn't subscribe, all new ideas would have a natural place to sit. Since the explicit intent is to have a wealth of new versions post-v1, such a place would come in handy, wouldn't it ? |
That is effectively the Internet-Drafts repository. I'm locking this discussion; if you have further questions, please take it up on-list or with the WG chairs directly. Thanks. |
Just two bits in clear to enable full on-path loss location