On 5 Nov 2019, at 00:09, Aaron Falk <[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
draft-ietf-taps-interface-05
draft-ietf-taps-implementation-05
IETF last call comments on draft-ietf-taps-security-09 (30m)
Ref [from Ekr] [from Christian]
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]> wrote:
AVE!
Philipp S. Tiesel
--
Philipp S. Tiesel
https://philipp.tiesel.net/
On 4. Nov 2019, at 19:18, Kyle Rose <[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 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 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,
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
On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk <[email protected]>
wrote:
Ok, gang, what should we discuss in Singapore?
--aaron
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
