IETF-79, Beijing, China *DRAFT MINUTES* TSVWG -- Valley Ballroom A 0900-1130 Wednesday, November 10th, 2010 WG Chairs: James Polk Gorry Fairhurst (absent this time) Randy Stewart and Magnus Westerlund minute takers this meeting. Scott Bradner jabber scribe. Chairs Agenda Bashing (15 min) NOTE WELL Document Status and Accomplishments Milestones Review Scott - audio not working for several minutes, but was fixed. WGLC Feedback (0 min) Probably Ready for WGLC (0 min) draft-ietf-tsvwg-sctp-strrst draft-ietf-tsvwg-sctpsocket Randall Stewart promised to provide a WG version of the SCTP NAT document before Prague. WG Drafts * Jukka - Byte and Packet Congestion Notification (10 min) 2 draft-ietf-tsvwg-byte-pkt-congest - but not many comments on the list. - Presented a summary list of changes. - Authors want more feedback!! Document CAN NOT progress without feedback. o Asked for volunteers to review the document. - Colin, Martin and Mia have agreed to review the document. * Randy - SCTP API (10 min) 3 draft-ietf-tsvwg-sctpsocket Requesting WGLC and hope that reviewers will step up and do reviews. James: asked if anyone felt the document was not ready for last call? - No one spoke up James: need positive comments to move to WGLC. Randy said he'd get them. AFTER THE MEETING CHAIRS COMMENT - we need reviewers, not just positive comments to get this to WGLC. * Randy - SCTP Reset (10 min) 4 draft-ietf-tsvwg-sctpstrrst Randal: Ready for WGLC, received comment on race condition. James: Request that Randy respin the document with the fix. James: chairs would talk about when to issue the WGLC, but not before the race condition text was fixed. No other comments from the room. Non-WG Drafts (if time allows) * James - Integrated Services Extension to Allow Multiple TSPECs 6 draft-polk-tsvwg-intserv-multiple-TSPEC (10 min) James: Went over two changes in this version (added Multicast support and a new error code for when an intermediate router tried all TSPECs within a RSVP, and not just the original one). Scott Bradner: Done a review, and thinks it is a good document. Ken Carlberg: Certain that I have done a review, it is on the mailing list. James: listed the 5 reviewers (Bruce, Lixia, Scott, Francois and Ken) needed to consider this for WG item. Dave McDyson will get back to us with another review (he wanted ID to add support for RSVP-TE, if possible). Dave Harrington: Okay, talk to your co-chair about WG adoption. * James - RSVP Application ID Profiles for Real-Time Classification 7 draft-polk-tsvwg-rsvp-app-id-vv-profiles (10 min) Scott Bradner: What do you mean with profile? James: This is how to populate the fields in RFC 2872 (e.g., for real-time interactive) as an IANA registry. Scott: ok Dave: If you have another version, what is the impact? James: Changes would likely result in another GUID. But some uncertainty on how to use the "ver" field. Scott: it's only a few bits to save - but could be extremely useful if and when the time comes to need it. Open issue: Do we create a new P-Type as Francois recommends, or keep using an existing one? Francois: do not feel strongly either way. James: if I create a new P-Type, this is no longer just a IANA registry doc. I'll look for further comment from the WG on this Scott: this ID is good to go. AD (Dave) confirmed James as chair and presenter can orchestrate a Hum of the room. James: Does the WG agree to take this ID on as a WG item? Doing a hum: Supportive: approx 8, against 0. * Fernando - Deprecation of ICMP Source Quench messages (10 min) 8 draft-gont-tsvwg-source-quench - Deprecating SOURCE QUENCE. - Information RFC on security implications of ICMP (RFC 5927). - Knows of no TCP implementation that currently honors SQ. - Wants to bring document as a WG item. - Only protocol formally documented to use SQ was TCP. Scott B: As we don't have meta documents saying what is important and not, this should have been done a long time ago. Randall: There is likely implementation hanging around that honors SQ. It would be good to make it clear. James as chair: Real question - is it in TCPM or TSVWG? Since TCP is the only one effected currently. Dave: was not sure and does not have an opinion. Magnus: behind them and advocates that it be in TSVWG. James: asked Dave (AD) if this should happen in this WG or in TCPM? Dave H: isn't sure, as he doesn't know what Lars' opinion is. Lars is sick during this session. Magnus W: Yes, I think TSVWG is the right place - as there might be other protocol usage, like for UDP. Borman: (TCPM chair) A tossup which WG, Magnus had a point that there might be other usage. Dave H: This is not an AD decision, it is more have the chair judge consensus and have the AD provide input. James: chairs will discuss and get back to WG on the proper direction for this effort. Last comment from Scott Bradner: why does it say SHOULD ignore and not MUST ignore? Fernando: feels it should be moved into a MUST ignore. James: How many people have read it? (none) - How many paying attention during preso? (15) - Strong support to taking this on somewhere * Lei Zhu - ROHC profile for GTP-U compression (10 min) 9 draft-lei-tsvwg-gtpu-compression Magnus asked if there was agreement in 3GPP for using ROHC to compress GTP-U? Lei: LTE-A under development in 3GPP Ran 1/2/3 - Release 10 which is close to being finished (end of this year). Magnus and Scott: What are the reasons to do it in IETF rather than 3GPP. GTP-U is a 3GPP protocol so why define the compression profile in this WG? Lei: Intended to bring this when done in IETF. Magnus: From an IANA perspective 3GPP can define new ROHC profiles and request a profile ID from IANA when the specification does exist. Lei: Some difficulties due to inter SDO dependencies. Dave as AD: recommends taking this to the list. It is either a miscommunication or more complex than can be resolved in this meeting. James as Chair: It's premature in making this to a WG item. Must be discussed on the list to see if we can progress this document. * Magnus - IANA Procedures for the Management of the Transport Protocol Port Number and Service Name Registry 10 draft-ietf-tsvwg-iana-ports (10 min) o Document does - Update registration procedures. o Unifies registries and updates RFC. o Document does NOT provide guidance to app writers. o TCP/UDP, DCCP, SCTP ports and SRV names (UDP-lite as well). o Unify Syntax of require 1 alpha. o changes since last IETF presented. o Document in WG last call. Scott Bradner: flip back to Doc Summary - Deregister and reuse - How practical is that? Magnus: It puts procedures in place for the future. It's not expected that we will hit this. So we are learning from v4 run-out. Scott was somewhat bothered about it unless its gun-in-drawer never to be used (maybe 50 years out). Scott: Does it change the rules on what process is required? Magnus: Yes it does unify the rules for what you need for registering. Scott: What is the processes required to get a port? Stuart Cheshire: Was not intended to change the rules just document the current procedures. Michelle Cotton: We do get requests to de-register a port and IANA was at a loss on how to do that so they can get a process in place for deregistering. Scott: will you reassign? They will not allocate it until all other are gone. The document specifies give-back port is reserved. Magnus: Cross posted and is being discussed with TLS and lots of folks. Want feedback! Magnus: Discussed issues on the mailing list. Stuart C: So he feels strongly that what the doc says now is correct. Paul is raising a issue in one particular case. And that was difficult for that one not necessarily to future protocols. Within TLS it can negotiate different encrypt algorithms. Do we need to ask for ports about things. Sees that this is inconsistent to assign 2 ports. Magnus: agrees and recommends keeping the same assignment. Scott channeling Joe Touch: It talks about an expert team and the last text focus on what Stuart has been saying. The expert review team can document their considerations. James as chair: Several folks disagree. Ultimately it will show up in IETF-LC. SecDir is disagreeing about what to do this week during SecDir lunch. i.e. its under discussion. Paul has one position, its not 2 positions, it several positions. One of the questions is do we fix it before or in IETF-LC. Or wait until IESG-LC? Magnus: we need to try to fix it before hand with a rough consensus. Dave as AD: My recommendation is to try to resolve it. If you cannot then take it to IESG and let it resolve there. It will be a DISCUSS. Paul: channeled via Chair - he has offered to write a 3-5 page security section as a second document. And then he can address it that way. Magnus: This is more to do with how the expert reviewers act not in the actual IANA's rules. Alex: I suggest that you point out that the issue was discussed and thought about in some sort of complimentary message. Scott channeling and not: Joe's original suggestion to leave out text if its controversial - its a TSVWG issue if ports imply security -- Resolving before LC would be useful. His opinion the security doc is to be an issue. James goes to the mic: There does not seem to be much or text about expert team can override recommendations. So this document has MUSTs and SHOULDs but the expert team can override. The MUSTs is how we do the registration and the document is to the expert review. Magnus: thinks the experts cannot override the review team. Stuart: the text in the doc that talks about MUSTs. Joe: there are no MUST/SHOULD - this is not about the expert review team and what they do. Dave H: His impression is that the document describes the use of expert teams to define the requirements but they are not binding on the expert team. But someone with a more lawyer bent may be able to define that better. Joe T: There is a separate user guidelines doc maybe the security must be in there. Stuart C: The issue of I want 3 ports. How many ports do I want to do at a time.. What if a App wants 60 ports? Magnus: debate to the mailing list... Continue the debate there. Plan is to get to rough consensus and then update the doc and head for IETF LC. Michelle C: If any one is interested in ports expert reviewer, drop an email so we can know about it. They are looking for new folks every so often. Drop email to iana/iana.org attn Michelle. Magnus: agreed still need to get rough consensus. * Dan - Happy Eyeballs: Trending Towards Success (IPv6 and SCTP) 5 draft-wing-tsvwg-happy-eyeballs-sctp (15 min) No slides from Dan. o Move applications from supporting not only just TCP but to use SCTP as well. We looked at some ideas and discussed how do we do it. We thought lets have a way in DNS to indicate that a web server does indicate web server does support it. o So it tends to we need to do something different. How do we also solve the V6 and V4. How about probing for both? Doing it at the same time (probing) we don't make folks unhappy waiting for time outs.. o We don't like to do that with v6 nor SCTP. We need to be able to more aggressively send probes to find out if path is viable for SCTP. And then learn that the path is working and viable. That way you don't need to re-probe. o Avoid constant double probing. o Thoughts - SRV records do not solve the problem. Scott B: Dan said good things, about not screwing the user. What happens if there are changes and connections start or stop working? Dan: Don't expect paths to change in file transfer. Put up a screen on the web; wait 10 min and then there is a non-zero chance that may have a path change. Especially with v4 or Vv6. Scott: It would seem that you would be proposing a set of functions for v4/v6 and TCP/SCTP cases.. Do you want to have 3 docs? Dan: one base, and two individual for the cases so things are consistent. Randall: For SCTP there is heartbeat that will tell when the path fails. Scott B: When are you retrying SCTP if you get a failure. Dan: We are trying behind the covers. Jonathan Lennox: What if some 3rd dimension wants to use this. Now you have 2 transport protocols. Risk for combination explosion. Dan: Yes the risk exists, but currently we don't know anything more. James: Where are you moving this forward? Dan: Taking the part about v4 vs. v6 to v6ops. But a general problem We're interested to do it here. Scott B: Is this something you want one underlying mechanism and two different usage explanations in different places? James as chair: How many have read? 3 James as chair: How many where familiar with it before: 10 James as chair: How many think this is interesting enough for going forward: 20 Dan to get more discussion on the mailing list.