Re: Spin bit decision

[Ian Swett <[e-mail]>]

One piece of information related to the above discussion is whether
detecting who is and is not spinning is easy and reliable.

One of my concerns is unintentional mis-use of the signal, and if it can't
be detected reliably in a mixed environment, that means SHOULD is unwise
and argues for either not including it or making it a MUST.

On Tue, Oct 2, 2018 at 12:51 PM Mike Bishop <[e-mail]> wrote:

> I don’t think it’s a grim view, I think it’s a pragmatic view.  Our role
> is to specify the things which are fundamental to the protocol and have to
> happen for peers to interoperate.  Mis-using normative language for other
> things is an abuse of the process -- that's kind of the point of RFC 6919.
>
>
>
> RFC 2119 says:
>
> In particular, [normative language] MUST only be used where it is actually
> required for interoperation or to limit behavior which has potential for
> causing harm (e.g., limiting retransmisssions)  For example, they must not
> be used to try to impose a particular method on implementors where the
> method is not required for interoperability.
>
>
>
> Given that the spin bit is not “actually required for interoperation,” but
> is the very definition of “try to impose a particular method on
> implementors,” I’d say that RFC 2119 imperatives are unwarranted.
>
>
>
> -----Original Message-----
> From: QUIC <[e-mail]> On Behalf Of
> [e-mail]
> Sent: Tuesday, October 2, 2018 8:05 AM
> To: Lars Eggert <[e-mail]>
> Cc: IETF QUIC WG <[e-mail]>
> Subject: Re: Spin bit decision
>
>
>
> On 10/02/18 16:00, Lars Eggert wrote:
>
> >
>
> > The point I can't seem to be getting across is that irrespective of
>
> > what the WG decides to require, there is no penalty for individual
>
> > stacks at deployment time (or after) to do whatever they wish, since
>
> > the spin bit by design has no impact on protocol operation and interop.
>
>
>
> It is getting across, but it is a very grim view of the standardization
> process itself. Are there many examples of MUST in RFCs that turned out to
> be ignored by implementations just because they were not part of the core
> semantics and hence not enforced by other peers ?
>
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
>
> Thank you.
>
>
>