IETF-73, Minneapolis, MN, US TSVWG *Draft*Minutes* Monday Nov 17th, 2008 1300-1500 Chairs Agenda Bashing 1300-1315 NOTE WELL We have a scribe, Lars will relay jabber questions. Put -tsvwg- in your ID filename so we can track it. * Preethi HTTP over SCTP presentation not happening because Preethi missed his flight and isn't here (later - Fred volunteers to present). Document Status and Accomplishments * TSVWG accomplishments and status: 0 RFCs published since IETF 72 1 ID in RFC editor queue: UDP guidelines * Lars: we've ok'd changes this morning 4 IDs in IESG review (3 x RSVP stuff + EF DSCP ...) should be RFC'd for San Francisco. * Magnus: RSVP IDs have been tough in IESG, if interested come to routing area meeting, will discuss them there too. Are a bit in a holding pattern right now. * James No documents between WG and IETF last calls Nothing ready for publication, L3 VPN is the closest. Lots of milestones done Three not done, Jul, Oct, Dec 2008 Milestones Review We have new WG documents that aren't milestones * Agenda bashing? No? * Lars: Magnus and me are holding office hours * Fernando - Port Randomization 1315-1325 draft-ietf-port-randomization-02.txt Is a document WG but first time it's presented describes some approaches for port randomization survey about what real applications are doing Comments or questions? This doc will need another rev since there was list agreement that the doc name including "randomization" was determined to be incorrect, as the doc more accurately is about port obfuscation. * Lars calls for show of hands if ready for last call: yes. * Bruce - RSVP-over-L3VPNs 1325-1335 draft-ietf-tsvwg-rsvp-l3vpn-01.txt draft has been stable for 3 meetings, ready to move to WGLC * Lars: who has read, who thinks ready for LC? Apparently: yes. small changes for optimization ready for WGLC per authors * Lars: who has read - 6 read it, * Lars: who thinks ready for LC? all 6 believe this is ready for WGLC * Francois - Applicability of Keying Methods for RSVP Security draft-ietf-tsvwg-rsvp-security-groupkeying-02.txt 1335-1345 Framework for RSVP security using dynamic group keying Ran is not here, and has not commented on new version's changes as good. authors want to investigation another mode of IPsec tunneling. sent mail Nov 7th to CCAMP to review sections of this ID. agreed with Lars to get Ran's feedback. * Lars: we'll see an update in San Francisco? * Francois - yes * Joe - IANA Allocation Guidelines for TCP&UDP Port Numbers 1345-1400 draft-ietf-tsvwg-iana-ports-01 Joe knows there is a new rev coming We give out about 400 ports/year; can go on for 100+ years, so we won't be running out of ports soon. * Lars: what about < 1024 ports? About 100 left, but how fast are they used up? * Joe: can let you know later today (note: never heard an answer to this later) Are we going to stop having system ports special? * Lars: Well, if we require IETF consensus we pretty much stop giving them out. * Joe: Ok discussion on the list. Open question: if someone wants to do a new protocol that's really an existing protocol (like HTTP), what's the threshold for a new protocol vs reuse of an existing protocol? We can discuss this on the list. We're trying to merge DNS service discovery names that was maintained outside IANA with the service names. * Michelle Cotton: bring three documents into sync in a meeting with several of the port people. * Randy/Michael - DTLS for SCTP 1400-1410 draft-ietf-tsvwg-dtls-for-sctp-00.txt presenting for the first time as a working group document have an implementation running there is no security considerations section (yet) authors know there needs to be a new rev * Gory (missed the question) It would be good for the DCCP WG to know what we need to do when we update our spec. * Bob's - Layered Encapsulation of Congestion Notification 1410-1420 draft-ietf-tsvwg-ecn-tunnel-01.txt layered encapsulation of congestion notification also first time this is a working group item Added text that's outside original motivation for this becoming WG item, therefore there needs to be WG consensus if this is necessary in the first place, then WG needs to decide if this should remain in this ID or another ID * Matt - thinks this is 2 docs 1 - synchronizing IPSec and ECN 2 - rationalizing tunneling behaviors * Lars - thinks WG needs to decide if the two parts are needed, or the original motivation should remain, but be a much shorter ID than it is now need list traffic on this ID before it moves anywhere * Iljitsch van Beijnum: Why bother with checking and maybe dropping the packets if inner and outer ECN are incompatible? you would see the same problems if the packet wasn't tunneled, why extra protection for tunneled packets? * Bob: we want to change as little as possible, so leave this which was specified in older docs alone * Bob's - Byte and Packet Congestion Notification 1420-1430 draft-ietf-tsvwg-byte-pkt-congest-00 * Iljitsch: there is currently bias against small packets in TCP congestion control, we _may_ want to change that, can be done in routers or in transport, important to avoid that both happen because then small packets would get more speed, would be bad for the internet this ID needs reviews and list comments reviewers already signed up: Joe Touch, Wes Eddy, Jukka Manner * Matt Mathis: Come to ICCRG and see my presentation about this there * Fred Baker: SCTP as a transport for HTTP options for deciding TCP/SCTP: - try them both: * Matt - Rethinking the TCP-Friendly Paradigm 1430-1440 http://staff.psc.edu/mathis/unfriendly/ no slides just a heads up for when this preso is (next session) * Matt: talk to apps people for this * Iljitsch: DNS SRV records * Preethi - HTTP over SCTP 1440-1450 draft-natarajan-httpbis-sctp-00 * Fred presented to this * Anonymous: only use SCTP for non-initial element this is mostly a heads up because this is mostly going to end up in httpbis however, how SCTP is chosen (by the user, by the first response if more than one transport (e.g., TCP) is sent) any suggestion of URIs (httpsctp::...) needs to go by the APPS area (i.e., Lisa D.)