Re: [Patient] the IETF participant choice

[Ted Lemon <[e-mail]>]

There are individuals who show up here to talk about why they need stuff
and use their own operational problems as examples. That's how we always do
this. It's really a process of successive approximation.

On Mar 19, 2018 20:38, "Tony Rutkowski" <[e-mail]> wrote:

> The concern here begs the question, "whose" systems analysis?  The IETF is
> not some kind of Land of Oz where a wizard has the answers to all manner of
> complex systems requirements.  There are many competing requirements across
> all manner of data centres, architectures, providers, and user
> communities.  Meaningful implementations will also require acceptance and
> adoption by an equally broad array of communities.
>
> There are no solution singularities here, and multiple tailored
> specifications are certain to emerge.  The academic and patent literature
> evidences several dozen of them. Indeed, whatever any standards body does
> will be competing with a large number of proprietary solutions.  The only
> certainty is the demand for effective solutions.
>
> In TC CYBER, we are moving ahead with our own and evolving them in light
> of this reality - hopefully with essential reflection and criticism from
> IETF participants.
>
> --tony
>
>
> On 19-Mar-18 4:07 PM, Ted Lemon wrote:
>
> On Mar 19, 2018, at 8:01 PM, Tony Rutkowski <[e-mail]> wrote:
>
> In participating remotely, it was apparent that although the proponents of
> the data centre visibility proposal did an excellent job in articulating
> the need, the solution was not going to be undertaken by the IETF.  The
> result in consonant with countless other similar initiatives sought in the
> IETF over the past several decades.
>
>
> The thing is, at least from my perspective, we haven't done a systems
> analysis yet, and so it was just premature to try to get the TLS working
> group to weaken TLS in order to solve the problem.   For example, the claim
> was made that it would be "too expensive" to do anything _other_ than
> modify TLS, but where's the analysis to support that position?   Too
> expensive to use middleboxes, but where's the analysis there?
>
> This is really an ops problem.   IETF can do ops work, but ops isn't about
> changing protocols—it's about figuring out good solutions to problems.
> Sometimes the answer to an ops problem is "we need some protocol work
> done," but that's not the starting point.
>
> As a consequence, I feel like some very well-meaning people came to the
> IETF with hat in hand and didn't get what they'd hoped for, and probably
> have the impression that people here don't care about their problem, when
> that's not actually the case.   Lots of people I talked to who were against
> the proposed solution care very much about the problem.
>
>
>
> _______________________________________________
> PATIENT mailing [e-mail]://www.ietf.org/mailman/listinfo/patient
>
>
>