TSVWG IETF-81, Quebec City, Canada WG Chairs: James Polk Gorry Fairhurst Note taker:Will Ivancic Document status and accomplishments were reviewed. IESG FEEDBACK * Applicability of Keying Methods for RSVP Security draft-ietf-tsvwg-rsvp-security-groupkeying-10.txt https://datatracker.ietf.org/ipr/988/ Discussions on Cisco IPR statement. Since the document is informational, there is a question as whether the submitted IPR declaration applies or not to a Informational RFC. The situation is being addressed. Dave Harrington: Originally the document had key works in it that had normative references. Those are no longer not there. IPR is not actually unacceptable. It is the working groups responsibility to accept or reject such declarations. This discussion is to alert people to the existence of these claims. Scott Bradner: It depends on the specific company if the term standard means a standard or any RFC. In this case Cisco is not explicit. Bob Briscoe: It does not appear to be a real problem. Conclusion: Work group may comment privately or on the list. But do so quickly, so we can close the issue. Cisco may be able to provide clarification. WGLC FEEDBACK * SCTP Socket API (James to Shepherd) draft-ietf-tsvwg-sctpsocket The document was with the Chairs awaiting a write-up. * SCTP Reset (James to Shepherd) draft-ietf-tsvwg-sctpstrrst A discussion at the previous meeting had focussed on the possibility of an in-band mechanism. The WG concluded there was no other candidate methods and that therefore the current proposal was OK. There was one final issue to be resolved. The authors would then issue a new revision. Chairs: This seems like consensus. Does anyone have any issues with this conclusion? (No issues) Conclusion: The authors were asked to wait until next Friday to see if there was any further responses to the remaining issue and then submit the document. The Chairs said this would conclude the WGLC. WG DRAFTS * Integrated Services Extension to Allow Multiple TSPECs draft-ietf-tsvwg-intserv-multiple-tspec - formerly draft-polk-tsvwg-intserv-multiple-tspec Since WG adoption there had been a proposal from Lou Berger on an alternative format for the RSVP information. James was still evaluating which was best, and would continue this discussion on the list. Francois: I think there are two things being defined here: how to carry the messages (RSVP) and how to process them (INTSERV). Scott: Would the container have a field to say what it contains? - Yes. Bruce: Pre-emption seems a plus when within the TSpec. The byte overhead of the new alternate method seems small enough to not be of concern. Bruce: Lou seems to have come up with a nice way to handle the Tspec. Georgias: Would the extra TSpec in the list be ignored? - Yes Conclusion: Discussion would continue via the WG list. * Chairs - Source Quench (taken earlier, no presentation) draft-ietf-tsvwg-source-quench There was discussions on whether the draft wording ought to be "SHOULD NOT" or "MUST NOT" send an ICMP source quench. Scott Bradner: I think it ought to be "MUST NOT". Randle Stewart: I agree, "MUST NOT". Bob Briscoe: Do we need justifications for all SHOULDs and MUSTs? Scott: Not really necessary for MUSTs providing the document as a whole motivates the need for SHOULDs. Gorry: I would hope somewhere in the draft to see a few lines on why each decision was made. Conclusion: Chairs would ask editor to prepare a new copy of the draft to include these decisions. * Bob - Byte and Packet Congestion Notification draft-ietf-tsvwg-byte-pkt-congest The current work item was given an Informational status. Gorry asked Dave Harrington if the RFC 2219 language was acceptable in an Information document. Scott: RFC 2119 usage does not distinguish between standards- track and informational. Dave: Informational use would raise issues with the present IESG. The Chairs said the document made recommendations for usage and was based on experience, hence it was eligible for publication as a BCP. Scott said this looked like it could be BCP. Dave agreed to look at this. He noted there was lots of informational content. Gorry also noted that after reorganisation this was all placed in one clear section and that he thought the document would be OK for publication as a BCP. Fred Baker and David Black had agreed to review the next version of this document. Conclusion: It was agreed the Chairs would discuss the intended status with the AD. * SCTP Network Address Translation Support draft-ietf-natsupp-tsvwg The NAT code had been implemented in BSD. Chair: How many people had read the document? (2) Michael: There had also been work done by student, in a MSc thesis.I will try to make the thesis available to people who would like to read this. Conclusion: We need reviewers and comments on this document. * SCTP UDP encapsulation draft-ietf-tsvwg-sctp-udp-encaps-00 - formerly draft-tuexen-sctp-udp-encaps-07 An implementation exists for the endpoint. Conclusion: Editors please add recommendations on ECN tunnels and then ask WG for review. NON-WG DRAFTS * Will - Saratoga Transport Protocol draft-wood-tsvwg-saratoga This document is scheduled for experimental Individual submission, and is here to receive advice from the WG. Randall: Have you considered the issue that the UDP checksum is itself week, and could be an issue for long transfers? Maybe a stronger packet CRC is better? See 2000 discussion by J.Stone for reliably detect loss of a packet without an error, if you really care about large files - this is worth doing. Gorry: Strong packet checksums do not imply lots of processing, you could use a weak check per packet, combined with a strong transfer check, and only worry about processing strong per-packet check values when the transfer files. Scott: Why is congestion control not an issue in any protocol that could be used over the Internet? - There is only one link, there are no competing flows. Michael: Adding CC can be hard afterwards! Gorry: Have you considered RFC 5405, Unicast UDP Usage Guidelines for Application Designers? - : No. Gorry: The draft does contain some CC methods, a comparison with the requirements would be good. Chairs: How many people have read this draft? (3) Conclusion: Authors will continue work as an Individual submission, but would welcome WG feedback. * Chairs - Recommendations for Transport Port Uses draft-touch-tsvwg-port-use This document was brought to the WG to provide a reference on how to use transport ports. Chairs: Who has read this? (0) The Chairs said they need to see feedback from WG to make this happen as a WG work item - is it needed? Do we want to do this? are there people willing to contribute/review/etc? Please let us know. Conclusion: Not enough people had read the draft to make any decision in the meeting, The Chairs will start the process of asking for WG feedback on this. * Chairs - Update on SCTP Failover/multipath Chairs noted that these 2 drafts had received good support at the previous IETF meeting, and this had since been discussed on the list specifically there appeared to be consensus that both drafts were needed. * SCTP Failover (not presented) draft-nishida-tsvwg-sctp-failover The authors have suggested that these proceed separately. Jana: I've said this before, I think multipath should progress independently Chairs: Who thinks this should be separate drafts? (no objection) Chairs: How many people support work on this draft? (hum for) (none against) Conclusion: Chairs will confirm adoption on the list and agree a milestone with the AD. * Randy - SCTP Multipath draft-tuexen-tsvwg-sctp-multipath-00 Jana - Multipath work has been implemented since 2006 (not built on mptcp), it has been deployed in a number of places, but not turned on by default Michael: Completely right, CMT is in there for years, the question is what combination of stuff you need (non-renegable SACKs, etc) CMT was not brought to IETF because coupled congestion control was missing; now we have it from mptcp. Chairs: How many people support work on this topic? (7) (none against) Conclusion: There is consensus to do work in this area. We encourage the authors to proceed, and to discuss on the list exactly what the work item would contain. * Michael - SACK-IMMEDIATELY extension for SCTP draft-tuexen-tsvwg-sctp-sack-immediately There were questions on performance relative to acking every packet, had these been addressed in the recent revision? Michael: Yes. Jana: Can you indicate some uses and where you may turn this on? Michael: Yes Chairs: How many people had read this or a recent version of this document? (10) Chairs: How many people were willing to review this document? (5) Chairs: How many people support work on this draft? (hum for) (none against) Chairs: How much work is needed to complete? Michael: Minimal. Conclusion: Chairs will confirm adoption on the list and agree a milestone with the AD. * Randy - draft-stewart-tsvwg-sctp-ecn: draft-stewart-tsvwg-sctp-ecn This document is in a work in progress. Conclusion: Discussion to the list - we need more people to feedback. * Georgios - Generic aggregation RSVP over PCN draft-karagiannis-pcn-tsvwg-rsvp-pcn-01 Chairs: How many had read the draft? (3) note it was also presented in the PCN WG. Chairs: Is this a suitable work item and where should this be done? Ken Carlberg: a little of both, it satisfies a PCN need, and should go forward and last-call in PCN with subsequent (not parallel) with TSVWG James (as individual): I have made comments on the last revision. I think 60/40 TSVWG/PCN. Scott: In any case, it's the RSVP directorate who has to look at it ... TSVWG will just send to them; PCN could do that, it should be last called here, whether it's done sequentially or in parallel does not matter Dave: If done in PCN, has to go through RSVP DIR and go through last call in TSVWG. Dave: The milestone is already on PCN charter, would be happy to transfer it. Conclusion: Chairs will talk to ADs to figure out the WG to place this piece of work. * James - RSVP Application ID Profiles for RT Classification draft-polk-tsvwg-rsvp-app-id-vv-profiles draft-polk-mmusic-traffic-class-for-sdp Dave Harrington: Are you also standardizing behavior on a proprietary delimiter? - Yes Ken Carlberg: Is there a registry? - Yes. Definitions are in section 2 of the RSVP document. Conclusion: Please read and revise this draft. Gorry (as Chair) would discuss with the MMUSIC WG Chairs to see the best way forward. The meeting closed 11:35