Minutes IETF111: tsvarea
minutes-111-tsvarea-00

TSVAREA IETF 111
Friday, 30 July 2021 23:00-01:00 UTC (+1) - Friday Session III

Where: Meetecho

Chairs: Martin Duke and Zaheduzzaman Sarker

Area Update

See slides.

Martin: The ROUTE talk today is meant to gather feedback as to whether the ISE is the correct track, instead of the IETF stream.

CoAP has been involving into more of a full-fledged transport, so we asked Carsten to update the area about these developments.

Waqar Zia: ROUTE

See slides.

Adrian Farrell: As ISE editor, I want to make clear that the point of this talk is to make sure that the Transport Area did not want to take this on as an IETF Stream document, instead of in the ISE.

Gorry Fairhurst: It's good to publish specs for the things they've made. I'm following the work in ATSC and DVB. There are people in TSVWG will be happy to review if you need it.

Waqar: Reviews would be great.

Lucas Pardue: +1 to Gorry. I did some DVB work a few years ago. ROUTE was really thorny to use, but an Information document would go along way. I wonder if a ROUTEv2 would be done in the IETF. Apple does their HLS specs independently and then brings each version to IETF. I'd be happy to review.

Jake Holland: Thanks. Would there be value in a standards-track service layer for the Internet at large, that is interoperable and deployable?

Waqar: Good idea, but what are the use cases? Who would be interested?

Jake: A good cross-domain standard for this kind of delivery would be useful. We're considering Lucas's work but the FEC stuff here would be valuable on more channels. Please follow up, and contact me. I sent a review to Adrian.

Waqar: Based on feedback, next steps are to get more reviews, integrate them, and then publish via the ISE.

David Black: Spencer on chat is saying that ISE publication is correct given that IETF can't have change control. I agree with that.

Zahed: I guess that's the answer Adrian was looking for.

Carsten Bormann: CoAP and Transport

See slides.

Martin Duke: The core-new-block proposal is what drove us to take this to the Area. I'm interested in thoughts about the state of this work and if we need to be involved as an Area.

Mirja Kuhlewind: This presentation makes it even more clear that CoAP was not the right choice for DOTS. CoAP was not designed for this, even if DOTS liked its features. I wish we'd looked at this earlier.

Carsten: They didn't find what they needed so they had to change CoAP. It probably wouldn't have looked different if they'd started with some other protocol.

Mirja: TCP would be a better option.

Carsten: But would it have worked?

Mirja: They would have had to design DOTS differently, which would have been better. But now it's too late.

Martin: Is the upcoming core work in the same theme of pushing the boundaries into transport topics, or is it a one-off?

Carsten: Maybe there will be more use cases? But this is meant for limited domains, not the general internet.

Martin: "Limited domains" is a hated term. The definition of a transport is expanding (see TAPS) and CoAP seems to fit in that definition.

Mirja: This is not a limited domain. DOTS is connected to the internet!

Carsten: Despite RFC8799, we do not agree on this definition. But I want to do things I wouldn't do on the general internet.

Mirja: This was part of the CoAP design space, but using it as a general transport is a problem. We should take it in transport, if so. But will there be more work?

Carsten: CoAP does work well on the general internet, though new-block does not.

Martin: I thought DOTS was not a limited domain? There's a server and a service which could be far apart? Anyway, the takeaway is that if there's additional work that pushes these boundaries please give the Transport Area or tsvwg an update. This will avoid the worst outcomes.

This IoT subject is very complicated and a high-level summary is valuable. Thanks.

Open Mic

Spencer Dawkins: Thanks to the ADs for keeping office hours. It's smart to do it outside IETF week. My workflow with calendars have meant I've missed those office hours. Could you do another during or after IETF week?

Martin Duke: We'll both be on vacation next week! But please email us and we can have a meeting at any time.

Also, please subscribe to tsv-area@ietf.org to get useful announcements. It's not that busy.

Spencer: To clarify, this is a suggestion to IETF 112. It's not a huge problem for me but it might be for others.

Martin: We have a weekly meeting that we would gladly offer up for people.

Zahed: Good suggestion, Spencer.

Gorry: How do we see interims going? We'll need some at tsvwg. Any thoughts on how to do it better?

Martin: The IESG is encouraging interims during the pandemic. Due to limited slots, we are limiting WGs to 2 hours. If you have more than 2 hours of material, some subjects are best done in interims and some really benefit from broader community exposure. We ask chairs to triage their agenda between these purposes.

I don't think things are so busy that we have to actively deconflict them, even though TAPS, tsvwg, and nfsv4 may have some (and quic and masque are a threat).

Al Morton: Can we have a meeting after to discuss a document?

Martin: Yes. See you at IETF 112.