Re: Spin bit as a negotiated option

["Brian Trammell (IETF)" <[e-mail]>]

> On 5 Oct 2018, at 15:43, Kazuho Oku <[e-mail]> wrote:
> 
> 2018年10月5日(金) 21:32 <[e-mail]>:
>> 
>> On 10/05/18 14:22, Brian Trammell (IETF) wrote:
>>> 
>>> I'm less happy about the complexity implied:
>>> 
>>> - in any (non-VEC) implementation of a negotiated spin bit, the negotiation
>>> code will dwarf the code for the signal it's negotiating, which seems wrong.
>> 
>> The version negotiation code is a one-shot investment for all extensions. Not a
>> single extra line when the set moves from {v1,v1s} to {v1,v1s,v1svv,v1sqr?...}.
> 
> +1.
> 
> I would also argue that having explicit negotiation using the version
> number field helps both the endpoints and the middleboxes, because it
> ensures us of having the freedom to evolve.
> 
> Having one bit (or several bits) tied forever to the behavior we
> define in v1 would be a loss for everybody.

Okay, I buy that argument. That probably tips me into the "let's do this with VN" camp.

Cheers,

Brian

> 
>>> - if we decide to support other client behaviors for other measurement goals
>>> in the future, it pushes the complexity of deciding what to measure to the
>>> endpoints, as opposed to placing that complexity at the midpoint.
>> The one thing that pushes the burden onto the endpoints is not negotiation but
>> enforcement. I don't think enforcement is a good idea, for this very reason.
>> Since these extensions are only for observers and may easily be opted out by
>> either endpoint, it makes sense to honor them in a best-effort way, no more.
> 
> I would also argue that the endpoints must be given the freedom to
> choose the signals they would expose, because there could be privacy
> implications based on how the endpoints are deployed.
> 
> FWIW, I am not opposed to the idea of middlebox suggesting a signal it
> wants to see, possibly by injecting a long header packet into the
> flow.
> 
>> 
>> _________________________________________________________________________________________________________________________
>> 
>> 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.
>> 
> 
> 
> --
> Kazuho Oku