If none of the authors wants to moderate -security, I can do that. AVE! Philipp S. Tiesel
> On 7. Nov 2019, at 16:48, Aaron Falk <[email protected]> wrote: > > Thanks, Tommy. > > Who will talk about -architecture & -security? > > --aaron > > On 6 Nov 2019, at 19:53, Tommy Pauly wrote: > > I can lead the discussion around implementation issues, as Anna will be > remote. > > Best, > Tommy > >> On Nov 6, 2019, at 2:54 PM, Aaron Falk <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks, Brian. >> >> We need discussion leads for -architecture, -implementation, and -security. >> >> --aaron >> >> On 5 Nov 2019, at 0:58, Brian Trammell (IETF) wrote: >> >> I can do the issue scrub for -interface. >> >> Sent from my iPhone >> >> On 5 Nov 2019, at 00:09, Aaron Falk <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Draft agenda based on what I’ve heard. Putting the security draft last as >>> I’m uncertain at this point whether the discussion will converge. Also, >>> rather than Philipp’s list of topics, I suggest someone should scrub the >>> open issues. Who should drive the discussion? Other comments? >>> >>> Administrivia (10m) - Chairs >>> Issue review for (50m) >>> draft-ietf-taps-architecture-05 >>> <https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-05> >>> draft-ietf-taps-interface-05 >>> <https://datatracker.ietf.org/doc/html/draft-ietf-taps-interface-05> >>> draft-ietf-taps-implementation-05 >>> <https://datatracker.ietf.org/doc/html/draft-ietf-taps-impl-05> >>> IETF last call comments on draft-ietf-taps-security-09 >>> <https://tools.ietf.org/html/draft-ietf-taps-transport-security-09> (30m) >>> Ref [from Ekr >>> <https://mailarchive.ietf.org/arch/msg/taps/R4zjHu8FN7A_3Lvs4TOyuF7kvL8>] >>> [from Christian >>> <https://mailarchive.ietf.org/arch/msg/saag/43g1LfmbbL1F5BoUHTwyOleHJU0#>] >>> What are our next steps? >>> --aaron >>> >>> On 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote: >>> >>> hi Philipp, all, >>> >>> parachuting-into-the-thread comments inline below. >>> >>> On 4 Nov 2019, at 21:36, Philipp S. Tiesel <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> AVE! >>> Philipp S. Tiesel >>> >>> -- >>> Philipp S. Tiesel >>> https://philipp.tiesel.net/ <https://philipp.tiesel.net/> >>> On 4. Nov 2019, at 19:18, Kyle Rose <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Evidently, the transport security document. >>> >>> Yes, we need to discuss next steps there. I still hope there will be some >>> discussion >>> on the list this and next week so we do not need to spend too much precious >>> face time >>> with this issue. >>> >>> I also see the state of the three other documents as agenda Items: >>> - Architecture >>> - Should be nearly finished, but for those you have not read one of the >>> last two versions, >>> please do so and give feedback! >>> >>> IIRC we'd said we wanted to hold this until at least interface was done. >>> But yes, please read this :) (I should re-read, actually). >>> >>> - Interface >>> >>> I think you've identified the three pending discussions correctly on this >>> doc... >>> >>> - Framers >>> >>> I need to dig into this a bit (and hope to before Singapore, but I also >>> hoped to have cycles before the interim that didn't happen so MMMV) but I'm >>> a lot happier with the general arrangement in -05 with the bulk of the >>> framer detail in -impl. >>> >>> - Errors >>> >>> I continue to think that something along the lines of the present >>> underspecification is not wrong here. But we should probably have more text >>> about the shape of that underspecification. >>> >>> - Multicast >>> >>> ...continues to be the swamp into which all transport efforts wade and >>> subsequently get eaten by rodents of unusual size. :) >>> >>> Practically speaking, this boils down to two issues AFAICT: >>> >>> - We have https://github.com/ietf-tapswg/api-drafts/issues/303 >>> <https://github.com/ietf-tapswg/api-drafts/issues/303> on multicast >>> transport properties. This is marked Ready For Text and assigned to >>> tfpauly, so I'm inclined to let Tommy write some text here (or assign >>> someone else if they'd like to take a crack at it). >>> >>> - We have https://github.com/ietf-tapswg/api-drafts/issues/150 >>> <https://github.com/ietf-tapswg/api-drafts/issues/150> which has a long and >>> varied history which you should go read if you're not familiar with it (or >>> if, like me, you'd forgotten it): >>> >>> - dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170 >>> <https://github.com/ietf-tapswg/api-drafts/issues/170>, which was closed by >>> PR on 6 Jun 2018 >>> - reopened to explictly address multicast interaction, languished without >>> discussion for six months >>> - tagged ready for text in January with an assigned volunteer (Jake) but no >>> discussion or guidance otherwise >>> >>> I propose we come to a decision on this in Singapore: commit to text soon >>> (end 2019) or ship without. >>> >>> Cheers, >>> >>> Brian >>> >>> - Implementation >>> - Are we satisfied with the structure >>> - Proxies/Tor/etc… >>> - Multicast >>> -- Philipp S. Tiesel https://philipp.tiesel.net/
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
