Re: [quicwg/base-drafts] Merge normative -spin-exp text into -transport (#2369)

[hardie <[e-mail]>]

On Fri, Jan 25, 2019 at 6:50 PM Jana Iyengar <[e-mail]>
wrote:

> So, to be clear, the document split is an entirely editorial decision;
> let's not conflate that with discussions about whether spin is PS or not.
> Of course, if spin is not PS, then the answer is clear, but even if spin is
> PS, whether it remains in a separate document or not is still an editorial
> discussion.
>
> So I went back to the recording on this (
https://youtu.be/s3aiyJI1xdU?t=5644) and the rough consensus was "to
include the spin bit in the specification".  To my mind, I think that is
clear that the consensus declared there and confirmed on the list was to
have it at the same level as the spec (so, PS).

Amusingly, if you listen past the negotiation section which follows, Mirja
asks whether that means spin bit should get merged into the transport
document.  Not to spoil the ending,  Lars answered yes and then immediately
back tracked to make this an editorial decision, which got general approval.

I'm happy to have this discussion in Tokyo, but we need to clearly separate
> the two discussions.
>
> I really don't want to discuss the question of PS vs. experimental in
Tokyo.  I am happy to express my preferences to the editors of the draft on
which I would prefer as a reader, but I think that this is an editorial
decision was settled back in Bangkok.


> Please note that the recovery draft is standards track, but it is a
> separate document. Being in a separate document is meaningful for things
> that can modularly be separated, esp since the transport document is
> already quite long at the moment.
>
> And I think that is the crux of the discussion.  Having decided that we
are doing this for version one, I don't think it is useful to call out the
behavior of this bit as separate enough to require an independent doc, any
more than I would suggest doing that for address validation or connection
migration, each of which also could be carved out.

Ted


> On Thu, Jan 24, 2019 at 10:30 AM hardie <[e-mail]> wrote:
>
> > On Thu, Jan 24, 2019 at 2:18 AM Kazuho Oku <[e-mail]>
> > wrote:
> >
> > > I am not sure if "including spin-bit in the specification" means
> > including
> > > it in the transport draft, considering the fact that we already have
> > > multiple documents that specify the QUIC protocol: invariants,
> transport,
> > > TLS, recovery. Having another document seems to be a natural way of
> > > integrating a specific feature.
> > >
> > > Among the documents, I think it might be natural to assume that the
> > > transport document would have the shortest lifetime, while there is
> fair
> > > chance that TLS and recovery documents will be reused in QUIC v2. I'd
> > also
> > > assume the spin-bit draft to have a longer lifetime, because I do not
> > think
> > > we want to change the definition of the spin bits for each QUIC
> version.
> > >
> > > That seems to be one reason to prefer having spin bit as a separate
> draft
> > > regardless of the status of the document. Is there a specific reason to
> > > incorporate the spin-bit specification into the transport draft?
> > >
> > The transport draft is the logical place to say that the bit is taken and
> > to give a pointer to what it is taken for. I think keeping the normative
> > text on how to exercise the bit in the transport draft is cleaner. It may
> > change in some later version, but this is the v1 meaning of that bit and
> > its states.
> >
> > It is not an invariant, in other words, but a v1 feature that may not be
> > continued in later versions. That's not quite experimental in the usual
> > sense--a change to the meaning would occur in later versions. (You could,
> > of course, later have a security draft say that even v1 ought to refrain
> > from spinning, should some issue occur, but that wouldn't change what
> > spinning meant)
> >
> > Ted
> >
> >
> > > —
> > > You are receiving this because you are subscribed to this thread.
> > > Reply to this email directly, view it on GitHub
> > > <
> > https://github.com/quicwg/base-drafts/issues/2369#issuecomment-457144113
> >,
> > > or mute the thread
> > > <
> >
> https://github.com/notifications/unsubscribe-auth/ABVb5KjEzrC9dqRFyQi9wXsKCS6IRQD6ks5vGYh7gaJpZM4aQb9w
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <
> https://github.com/quicwg/base-drafts/issues/2369#issuecomment-457305764>,
> > or mute the thread
> > <
> https://github.com/notifications/unsubscribe-auth/AKjg1DoiyxpWo39ZPTuM5ehu8LC7EZh6ks5vGfvFgaJpZM4aQb9w
> >
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2369#issuecomment-457794896>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5DXIJKqqH6qVtI20dkmVvSZiMWzBks5vG8J7gaJpZM4aQb9w>
> .
>


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2369#issuecomment-457959473