Re: [Patient] [EXT] Re: the IETF participant choice

[Brian Witten <[e-mail]>]

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


[phone]

________________________________
From: Tony Rutkowski <[e-mail]>
Sent: Tuesday, March 20, 2018 4:09:48 AM
To: Brian Witten; Ted Lemon
Cc: [e-mail]
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


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.


Please LMK if I can help more -


Best,

Brian

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


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.