Subject: [Patient] the IETF participant choice

From: Tony Rutkowski <[email-masked]>
Date: Mon, 19 Mar 2018 16:01:27 -0400

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.

In a sense, the outcome today is their right.  Technical collaborative 
bodies are substantially homes to communities who create and maintain 
them to do work they believe necessary.  There are also many other 
collaborative bodies that can undertake the same work, and arguably do a 
better job because the participants are more motivated in getting the 
work done.  It is not apparent what purpose is served in forcing a 
collaborative community - whether it be the IETF or any other standards 
body - to do work they do not want to undertake.

ETSI TC CYBER spent more than a year studying the "visibility" 
ecosystem, the requirements, venues, and technologies across a swath of 
industries worldwide - including what was occurring in academic research 
and published patents.  It published what is still the most 
comprehensive technical report on the subject.  And, it has moved ahead 
with four visibility technical specifications, a workshop, and a 
hackathon.  (Frankly, controls for levels of "observability" and 
"granularity" seem like better choices for capabilities being sought.

The proposed ETSI TC CYBER technical specifications address both network 
based and data center based requirements - both in-band and out-of- band 
- with techniques that are arguably best of breed and drawn from 
existing R&D.  To the extent there are omissions or failings, the ETSI 
processes are entirely open and the work will evolve and institute 
corrections.

Lastly, the ETSI rapporteurs have reached out to every other 
identifiable "visibility" collaborative and standards activity, 
including the IETF.  Going forward, it is hoped that IETF participants 
will help improve the ETSI standards for capabilities that forever 
reason, cannot be pursued in the IETF.

--tony

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Mar 2018 20:07:57 +0000

On Mar 19, 2018, at 8:01 PM, Tony Rutkowski <[email-masked]> 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.

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 19 Mar 2018 16:38:12 -0400

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 <[email-masked] 
> <mailto:[email-masked]>> 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 list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/patient

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Mar 2018 21:23:51 +0000

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" <[email-masked]> 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.
>
> 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 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.
>
>
> 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 [email-masked]://www.ietf.org/mailman/listinfo/patient
>
>
>

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 19 Mar 2018 17:42:18 -0400

Almost every venue does things pretty much this way.

No fora exists to solve all the world's network operational problems.  
"Sorry, not our problem" is an acceptable answer. Those venues that 
don't have that option, when appropriate, are probably best avoided.

--tony

On 19-Mar-18 5:23 PM, Ted Lemon wrote:
> 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.
>

---

From: Brian Witten <[email-masked]>
Date: Mon, 19 Mar 2018 23:57:13 +0000

Hi Tony,

Thank you for your note!  I very much empathize with the pains of remote participation, and it's very unfortunate that the dates conflicted for SG 17 this week as we clearly both have colleagues and friends at both events.  I personally applaud the work in both ETSI TC Cyber and ITU SG 17, along with the work in the IETF TLS WG.

In person, here at the IETF, I got a bit of a different feeling than you described from remote participation.  In person, I heard more emphasis on the valid technical concerns which were raised, concerns which focused on the proposed protocol, not the use-cases.  We heard additional requirements not yet factored into a design.  Of course, the "passive-listener / off-line decrypt" challenges which rhrd (tonight's hum) attempted to address are not the same as the "in-line, actively acknowledged proxy," challenges which PATIENT has been discussing.  Still, I was glad to see Steve Fenter's use cases received "better than at least I had expected," even if the proposed draft protocol design was not accepted.

I believe that the authors have the option to either (a) propose directly to the Security Area Directors a new protocol better addressing the requirements emphasized in discussion tonight, so that the AD's can decide whether TLS WG discussion of a third design is the right best next step, or (b) consider pursuing formation of a new WG such as through a BOF process.  I'm not sure which they'll do, but I look forward to learning that from the SAAG and/or TLS WG lists.

Please LMK if I can help more -

Best,

Brian

________________________________
From: Tony Rutkowski <[email-masked]>
Sent: Monday, March 19, 2018 2:42:18 PM
To: Ted Lemon
Cc: [email-masked]; Brian Witten
Subject: [EXT] Re: [Patient] the IETF participant choice

No fora exists to solve all the world's network operational problems.  "Sorry, not our problem" is an acceptable answer.  Those venues that don't have that option, when appropriate, are probably best avoided.

--tony

On 19-Mar-18 5:23 PM, Ted Lemon wrote:
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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Mar 2018 18:58:22 -0500

(Why is discussion of the TLS WG's [in]action occurring on PATIENT?)

> initiatives sought in the IETF over the past several decades.

Need is hardly the only prerequisite.  The (rough) consensus process
is clear that work should not be published in the presence of known,
unaddressed, technical issues.

I agree with Kathleen's assessment of the session that there are
indeed outstanding unresolved technical issues, and do not believe
that path(s) towards resolving those issues have been proposed.  In
the absence of a route to resolve such issues, adopting such
proposed work as a WG item seems premature.

-Benjamin

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 20 Mar 2018 10:00:02 +0000

Hi,

On 2018-3-19, at 20:01, Tony Rutkowski <[email-masked]> wrote:
> ETSI TC CYBER spent more than a year studying the "visibility" ecosystem, the requirements, venues, and technologies across a swath of industries worldwide - including what was occurring in academic research and published patents.  It published what is still the most comprehensive technical report on the subject.  And, it has moved ahead with four visibility technical specifications, a workshop, and a hackathon.  (Frankly, controls for levels of "observability" and "granularity" seem like better choices for capabilities being sought.
> 
> The proposed ETSI TC CYBER technical specifications address both network based and data center based requirements - both in-band and out-of- band - with techniques that are arguably best of breed and drawn from existing R&D.  To the extent there are omissions or failings, the ETSI processes are entirely open and the work will evolve and institute corrections.

if ETSI TC CYBER is seriously embarking on a path that modifies IETF-originated standards without the IETF's explicit prior agreement, they are setting themselves up for a very visible and politically embarrassing failure.

We had the same type of conflict with the ITU-T serval times in the past. ETSI TC CYBER might want to check how well that went for the ITU-T.

Lars

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 20 Mar 2018 06:44:30 -0400

Hi Lars,

Whatever ETSI does will be fully compliant with IPR law.  I am also a 
lawyer and well aware of the IETF's assertions and complaints over the 
years.  The irony here is that TLS is actually an ITU-ISO standard.  
Perhaps we can all just collaborate here on urgently needed 
specifications rather than making threats.

--tony

ps. In the early 90s, as ISOC Executive Director, I also helped set up 
the IETF's own rather unique IPR arrangements because of its lack of 
legal existence, and effected the purchase of considerable liability 
insurance for IETF decision makers. Presumably that still exists. :-)

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 20 Mar 2018 07:09:48 -0400

Hi Brian,

The entire world resonated with those use cases. :-)    Of course, that 
was foregone.  The Use Case Annex to the ETSI MSP draft spec has about 
six sub-sections running five pages!  That took some careful editing 
given the several thousand published materials that articulate the use 
cases, as well as ongoing work in other bodies.

The challenge has been sifting through the dozens of different 
techniques that have already been published in research papers, 
standards bodies, and patent applications for accomplishing the required 
observability with the desired granularity controls.

The ancillary challenge has been the proactive outreach of continually 
discovering and engaging with the numerous diverse communities who want 
the observability capabilities ASAP.  They are ultimately the customers 
for the specifications, and will likely produce derivative versions to 
meet their own industry or sector needs.  When there is this kind of 
demand, it is race against time before the existing proprietary 
solutions extensively proliferate.

The initial stable versions of the network specs will be available 
shortly in preparation for the June workshop and hackathon.  The data 
centre specs will follow shortly afterwards.

--tony

On 19-Mar-18 7:57 PM, Brian Witten wrote:
>
> Hi Tony,
>
>
> Thank you for your note!  I very much empathize with the pains of 
> remote participation, and it's very unfortunate that the dates 
> conflicted for SG 17 this week as we clearly both have colleagues and 
> friends at both events.  I personally applaud the work in both ETSI TC 
> Cyber and ITU SG 17, along with the work in the IETF TLS WG.
>
>
> In person, here at the IETF, I got a bit of a different feeling than 
> you described from remote participation.  In person, I heard more 
> emphasis on the valid technical concerns which were raised, concerns 
> which focused on the proposed protocol, not the use-cases.  We heard 
> additional requirements not yet factored into a design. Of course, the 
> "passive-listener / off-line decrypt" challenges which rhrd (tonight's 
> hum) attempted to address are not the same as the "in-line, actively 
> acknowledged proxy," challenges which PATIENT has been discussing. 
>  Still, I was glad to see Steve Fenter's use cases received "better 
> than at least I had expected," even if the proposed draft protocol 
> design was not accepted.
>
>
> I believe that the authors have the option to either (a) 
> propose directly to the Security Area Directors a new protocol better 
> addressing the requirements emphasized in discussion tonight, so that 
> the AD's can decide whether TLS WG discussion of a third design is the 
> right best next step, or (b) consider pursuing formation of a new WG 
> such as through a BOF process.  I'm not sure which they'll do, but I 
> look forward to learning that from the SAAG and/or TLS WG lists.
>
>
> ------------------------------------------------------------------------
> *From:* Tony Rutkowski <[email-masked]>
> *Sent:* Monday, March 19, 2018 2:42:18 PM
> *To:* Ted Lemon
> *Cc:* [email-masked]; Brian Witten
> *Subject:* [EXT] Re: [Patient] the IETF participant choice
>

---

From: Brian Witten <[email-masked]>
Date: Tue, 20 Mar 2018 11:20:03 +0000

Hi Tony,

Thanks for the info as usual, but I'd like to keep the PATIENT list focused on PATIENT, so let's connect on ETSI & RHRD separately.  Happy to connect 1:1 anytime -

Brian

+1 571 215 8224

________________________________
From: Tony Rutkowski <[email-masked]>
Sent: Tuesday, March 20, 2018 4:09:48 AM
To: Brian Witten; Ted Lemon
Cc: [email-masked]
Subject: Re: [EXT] Re: [Patient] the IETF participant choice

Hi Brian,

The entire world resonated with those use cases. :-)    Of course, that was foregone.  The Use Case Annex to the ETSI MSP draft spec has about six sub-sections running five pages!  That took some careful editing given the several thousand published materials that articulate the use cases, as well as ongoing work in other bodies.

The challenge has been sifting through the dozens of different techniques that have already been published in research papers, standards bodies, and patent applications for accomplishing the required observability with the desired granularity controls.

The ancillary challenge has been the proactive outreach of continually discovering and engaging with the numerous diverse communities who want the observability capabilities ASAP.  They are ultimately the customers for the specifications, and will likely produce derivative versions to meet their own industry or sector needs.  When there is this kind of demand, it is race against time before the existing proprietary solutions extensively proliferate.

The initial stable versions of the network specs will be available shortly in preparation for the June workshop and hackathon.  The data centre specs will follow shortly afterwards.

--tony

Hi Tony,

Best,

Brian

________________________________
From: Tony Rutkowski <[email-masked]><mailto:[email-masked]>
Sent: Monday, March 19, 2018 2:42:18 PM
To: Ted Lemon
Cc: [email-masked]<mailto:[email-masked]>; Brian Witten
Subject: [EXT] Re: [Patient] the IETF participant choice

--tony

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 20 Mar 2018 07:27:57 -0400

Hello Tony,

This list is to be used for discussions of possible work in the IETF.
Right now, the people on this list are interested in discussing use
cases, requirements, and current obstacles to determine a fruitful
forward direction.  These messages are a distraction towards those
goals and I'd like to see the conversation restarted in a new thread
when participants are ready, which may require some time and analysis
from the outcomes and discussions that have taken place so far.

Messages off track of the goals of this list will be moderated if
needed to assist with the productivity of this effort..

On Tue, Mar 20, 2018 at 6:44 AM, Tony Rutkowski <[email-masked]> wrote:
> Hi Lars,
>
> Whatever ETSI does will be fully compliant with IPR law.  I am also a lawyer
> and well aware of the IETF's assertions and complaints over the years.  The
> irony here is that TLS is actually an ITU-ISO standard.  Perhaps we can all
> just collaborate here on urgently needed specifications rather than making
> threats.

The IETF currently holds copyright and change control on the TLS protocol.

>
> --tony
>
> ps. In the early 90s, as ISOC Executive Director, I also helped set up the
> IETF's own rather unique IPR arrangements because of its lack of legal
> existence, and effected the purchase of considerable liability insurance for
> IETF decision makers.  Presumably that still exists. :-)

IPR has been updated considerably in the past 25 years and I suggest
you consult the current revisions to better understand IETF policies.
BCP78 and BCP79 would be a good start.

Best regards,
Kathleen

> ETSI TC CYBER spent more than a year studying the "visibility" ecosystem,
> the requirements, venues, and technologies across a swath of industries
> worldwide - including what was occurring in academic research and published
> patents.  It published what is still the most comprehensive technical report
> on the subject.  And, it has moved ahead with four visibility technical
> specifications, a workshop, and a hackathon.  (Frankly, controls for levels
> of "observability" and "granularity" seem like better choices for
> capabilities being sought.
>
> based and data center based requirements - both in-band and out-of- band -
> with techniques that are arguably best of breed and drawn from existing R&D.
> To the extent there are omissions or failings, the ETSI processes are
> entirely open and the work will evolve and institute corrections.
>
> if ETSI TC CYBER is seriously embarking on a path that modifies
> IETF-originated standards without the IETF's explicit prior agreement, they
> are setting themselves up for a very visible and politically embarrassing
> failure.
>
> We had the same type of conflict with the ITU-T serval times in the past.
> ETSI TC CYBER might want to check how well that went for the ITU-T.
>
> Lars
>
>
>

-- 

Best regards,
Kathleen