Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
On 7/8/2013 7:39 AM, l.w...@surrey.ac.uk wrote: But if it's not expected to have any effect on IETF outputs, why bother presenting it at TSVAREA to the IETF? FWIW, Martin and I have chatted privately about possible reasons to have a presentation about a technology which isn't described in a draft, in TSVAREA. I came away from that discussion thinking that it's really hard to know that an idea won't affect IETF outputs in the future. I wasn't there, but I believe a similar question came up most recently from the audience during a non-draft presentation to SAAG - is there IPR on the fascinating topic you're presenting? Without regard to anything else, what I heard was that the question pretty much derailed the conversation, because IETF participants require little prompting to hypothesize about IPR instead of talking about a technology. So, at least one reason for me to ask now, is to avoid someone else asking the same question in a roomful of people when we could be learning from someone who cared enough to share with us. Spencer p.s. Scott, I'm more than somewhat sympathetic to your point of view, but after the IRSG decided to require disclosures just in case someone contributed something in a research group that was interesting enough to take it to the IETF eventually, I'm having a hard time being less curious in what is, after all, an IETF working group. Oh wait, QUIC isn't in an internet-draft, so it won't have any effect on IETF outputs. We don't need IPR disclosures. We're good. Lloyd Wood http://sat-net.com/L.Wood/dtn/http-dtn has previously presented to TSVAREA to zero effect. From: tsv-area-boun...@ietf.org [tsv-area-boun...@ietf.org] On Behalf Of Scott Brim [s...@internet2.edu] Sent: 08 July 2013 13:37 To: Spencer Dawkins; ietfdbh Cc: tsv-area@ietf.org Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded On 07/07/13 23:39, Spencer Dawkins spencerdawkins.i...@gmail.com allegedly wrote: The notes I've read in this thread have been very helpful to me. Thank you for sharing. At this point, the only thing I'm obsessing about is that we get decent IPR declarations when IPR exists. Our BCPs define a contribution broadly enough to include presentations. The *IRTF* now has an IPR policy that's roughly equivalent to the IETF's policy; if people can't talk about research without disclosing, we should have the same stance for presentations on engineering topics. Spencer, we don't need IPR disclosures if a contribution is not expected to affect IETF outputs. Participants who realize that the IPR will be or has been incorporated into a submission to be published in an Internet Draft, or is seriously being discussed in a working group, are strongly encouraged to make at least a preliminary disclosure.
RE: Draft agenda for the IETF-87 TSV Area meeting uploaded
Hi, The IETF has always stressed a bottom-up approach, taking ideas and running code contributed by the community for new networking functionality, ranging from disruptive to purely maintenance, and deciding whether there was IETF consensus to work on standardizing the functionality. Typically contributed functionality is described in Internet-drafts so the IETF community can better understand the technology being proposed. This approach also helps to ensure the IETF doesn't become a forum for marketing press releases or other inappropriate usage of scarce IETF face-to-face time. Originally, BOFs were simply side meetings, often in bars, for an informal discussion of a new idea. There were no IPR rules, no requirements for an internet-draft first, and so on. Meeting in a bar allowed people to discuss *ideas* without the formality of requesting an IETF session. But there is a practical limit to the size of audience who can meet in a bar, to exchange ideas on bar-napkins. To supplement bar-bofs [rfc6771], the IETF standardized BOFs explicitly designed to allow the presentation of new ideas to the community, permitting larger audiences to gather in a room and have their meeting announced. BOFs, however, grew very quickly to meetings that might include food and alcohol provided by the idea proponents, and became more formal over time, with officially scheduled sessions, BOF chairs, microphones, and the whole shebang. Internet-drafts are typically required before a BOF session will be approved. Area directors realized there was a real downside to the increasing formality of BOFs - interesting ideas in the real world were not being brought into the IETF because the requirements to get a BOF session had become a hurdle. The IETF ignores what is happening around it in the real world at its own peril. Ignoring important new relevant technologies, especially potentially disruptive technologies, risks the IETF being overtaken by events. If we want to stay relevant to the industry we support, we must be willing to listen to new ideas even if they do not come in the form of internet-drafts. Area meetings then became a venue for what some directors refer to as mini-BOFs - a larger audience than the bar-napkin discussions afford, but less formal than BOFs. An internet-draft would be nice so people knew where to look to find a discussion of the technology. However, the real goal is to get the industry to come into the IETF to talk about interesting and relevant technologies they have been working on outside the IETF. David Harrington ietf...@comcast.net +1-603-828-1401 -Original Message- From: tsv-area-boun...@ietf.org [mailto:tsv-area-boun...@ietf.org] On Behalf Of Wesley Eddy Sent: Saturday, July 06, 2013 10:11 PM To: l.w...@surrey.ac.uk Cc: tsv-area@ietf.org Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded On 7/6/2013 5:52 PM, l.w...@surrey.ac.uk wrote: IETF transport focuses on maintaining its existing standards; that's my point. It's not really set up for experimental work not directly related to those standards. I'm not really sure how TSV could be setup any better to do this type of work. It could be a matter of opinion how directly related the experimental work is. For instance, CONEX is built on ECN, MPTCP is built on TCP, and RMCAT is building on RTP ... but all are such significant developments that they can't be classed as simply maintenance. In Berlin, TSV has 2 BoFs planned in Berlin which are not jst maintenance of existing standards (TCMTF and AQM). Clearly, there are also important existing protocols (TCP, SCTP, etc) that a lot of TSV energy goes into maintaining, but that's certainly not all that we do. The community focuses on what it chooses to, by individuals (and companies sponsoring them) investing time and energy into the WGs and drafts that they have shared interests in. For some experimental things, that can be difficult because it requires a critical mass, and people have to be willing to work together at whatever pace the group adapts. Larger groups will have slower paces. The hope is that we wind up with better specs, less flaws, and stronger interop between multiple codebases as a result of working together, and create a better Internet. Those are not the priority for every protocol development effort, and a lot of people have good reasons for doing things on their own. This does not signal a problem with the IETF. -- Wes Eddy MTI Systems
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
The notes I've read in this thread have been very helpful to me. Thank you for sharing. At this point, the only thing I'm obsessing about is that we get decent IPR declarations when IPR exists. Our BCPs define a contribution broadly enough to include presentations. The *IRTF* now has an IPR policy that's roughly equivalent to the IETF's policy; if people can't talk about research without disclosing, we should have the same stance for presentations on engineering topics. If the presenters are clear on that, I'm over the biggest hurdle. Spencer On 7/7/2013 12:52 PM, ietfdbh wrote: Hi, The IETF has always stressed a bottom-up approach, taking ideas and running code contributed by the community for new networking functionality, ranging from disruptive to purely maintenance, and deciding whether there was IETF consensus to work on standardizing the functionality. Typically contributed functionality is described in Internet-drafts so the IETF community can better understand the technology being proposed. This approach also helps to ensure the IETF doesn't become a forum for marketing press releases or other inappropriate usage of scarce IETF face-to-face time. Originally, BOFs were simply side meetings, often in bars, for an informal discussion of a new idea. There were no IPR rules, no requirements for an internet-draft first, and so on. Meeting in a bar allowed people to discuss *ideas* without the formality of requesting an IETF session. But there is a practical limit to the size of audience who can meet in a bar, to exchange ideas on bar-napkins. To supplement bar-bofs [rfc6771], the IETF standardized BOFs explicitly designed to allow the presentation of new ideas to the community, permitting larger audiences to gather in a room and have their meeting announced. BOFs, however, grew very quickly to meetings that might include food and alcohol provided by the idea proponents, and became more formal over time, with officially scheduled sessions, BOF chairs, microphones, and the whole shebang. Internet-drafts are typically required before a BOF session will be approved. Area directors realized there was a real downside to the increasing formality of BOFs - interesting ideas in the real world were not being brought into the IETF because the requirements to get a BOF session had become a hurdle. The IETF ignores what is happening around it in the real world at its own peril. Ignoring important new relevant technologies, especially potentially disruptive technologies, risks the IETF being overtaken by events. If we want to stay relevant to the industry we support, we must be willing to listen to new ideas even if they do not come in the form of internet-drafts. Area meetings then became a venue for what some directors refer to as mini-BOFs - a larger audience than the bar-napkin discussions afford, but less formal than BOFs. An internet-draft would be nice so people knew where to look to find a discussion of the technology. However, the real goal is to get the industry to come into the IETF to talk about interesting and relevant technologies they have been working on outside the IETF. David Harrington ietf...@comcast.net +1-603-828-1401 -Original Message- From: tsv-area-boun...@ietf.org [mailto:tsv-area-boun...@ietf.org] On Behalf Of Wesley Eddy Sent: Saturday, July 06, 2013 10:11 PM To: l.w...@surrey.ac.uk Cc: tsv-area@ietf.org Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded On 7/6/2013 5:52 PM, l.w...@surrey.ac.uk wrote: IETF transport focuses on maintaining its existing standards; that's my point. It's not really set up for experimental work not directly related to those standards. I'm not really sure how TSV could be setup any better to do this type of work. It could be a matter of opinion how directly related the experimental work is. For instance, CONEX is built on ECN, MPTCP is built on TCP, and RMCAT is building on RTP ... but all are such significant developments that they can't be classed as simply maintenance. In Berlin, TSV has 2 BoFs planned in Berlin which are not jst maintenance of existing standards (TCMTF and AQM). Clearly, there are also important existing protocols (TCP, SCTP, etc) that a lot of TSV energy goes into maintaining, but that's certainly not all that we do. The community focuses on what it chooses to, by individuals (and companies sponsoring them) investing time and energy into the WGs and drafts that they have shared interests in. For some experimental things, that can be difficult because it requires a critical mass, and people have to be willing to work together at whatever pace the group adapts. Larger groups will have slower paces. The hope is that we wind up with better specs, less flaws, and stronger interop between multiple codebases as a result of working together, and create a better Internet. Those are not the priority for every protocol development effort, and a lot of people have good reasons
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
Hi, On Jul 5, 2013, at 2:37, Joe Touch to...@isi.edu wrote: A slot should not be granted if there isn't a draft. when Magnus and me started TSVAREA, the intent was that it be an information dissemination session, and that IDs were not going to be published through TSVAREA. (We have TSVWG for that.) That's different from other area meetings, such as INTAREA, that do push drafts. We had many presentations such as QUIC which did not come with drafts at the time (SMT, SPDY, RTFMP, etc.) Lars
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
Thanks - the area vs wg distinction makes sense. Joe On Jul 6, 2013, at 3:00 PM, Eggert, Lars l...@netapp.com wrote: Hi, On Jul 5, 2013, at 2:37, Joe Touch to...@isi.edu wrote: A slot should not be granted if there isn't a draft. when Magnus and me started TSVAREA, the intent was that it be an information dissemination session, and that IDs were not going to be published through TSVAREA. (We have TSVWG for that.) That's different from other area meetings, such as INTAREA, that do push drafts. We had many presentations such as QUIC which did not come with drafts at the time (SMT, SPDY, RTFMP, etc.) Lars
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
s/drone/someone/ set autocorrect=false :-) On Jul 6, 2013, at 4:03 PM, Joe Touch to...@isi.edu wrote: On Jul 6, 2013, at 12:15 PM, l.w...@surrey.ac.uk wrote: First deploy, then tell the IETF about it, and let the IETF put the documentation into the preferred 1970s ASCII format. Unless drone revoked RFC 2780, that's the wrong sequence. First develop and test, then tell the IETF in a standards- track RFC, then get that RFC approved, then get a transport number, then deploy. I don't mind general info about stuff in the area meetings, but feedback requires participation, which requires a draft. And deployment of transports requires approved standards to get assigned numbers. Joe
RE: Draft agenda for the IETF-87 TSV Area meeting uploaded
Well, that's the wrong sequence, too. IANA can allocate numbers at draft stage long before RFC - as it did for Saratoga http://saratoga.sf.net But even your sequence says 'tell the IETF', not 'participate in an IETF WG with all the drones'. Since QUIC is already deployed worldwide, I am reminded of King Canute. Lloyd Wood http://sat-net.com/L.Wood/ From: Joe Touch [to...@isi.edu] Sent: 06 July 2013 08:03 To: Wood L Dr (Electronic Eng) Cc: swm...@swm.pp.se; tsv-area@ietf.org Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded On Jul 6, 2013, at 12:15 PM, l.w...@surrey.ac.uk wrote: First deploy, then tell the IETF about it, and let the IETF put the documentation into the preferred 1970s ASCII format. Unless drone revoked RFC 2780, that's the wrong sequence. First develop and test, then tell the IETF in a standards- track RFC, then get that RFC approved, then get a transport number, then deploy. I don't mind general info about stuff in the area meetings, but feedback requires participation, which requires a draft. And deployment of transports requires approved standards to get assigned numbers. Joe
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
On 7/6/2013 5:52 PM, l.w...@surrey.ac.uk wrote: IETF transport focuses on maintaining its existing standards; that's my point. It's not really set up for experimental work not directly related to those standards. I'm not really sure how TSV could be setup any better to do this type of work. It could be a matter of opinion how directly related the experimental work is. For instance, CONEX is built on ECN, MPTCP is built on TCP, and RMCAT is building on RTP ... but all are such significant developments that they can't be classed as simply maintenance. In Berlin, TSV has 2 BoFs planned in Berlin which are not jst maintenance of existing standards (TCMTF and AQM). Clearly, there are also important existing protocols (TCP, SCTP, etc) that a lot of TSV energy goes into maintaining, but that's certainly not all that we do. The community focuses on what it chooses to, by individuals (and companies sponsoring them) investing time and energy into the WGs and drafts that they have shared interests in. For some experimental things, that can be difficult because it requires a critical mass, and people have to be willing to work together at whatever pace the group adapts. Larger groups will have slower paces. The hope is that we wind up with better specs, less flaws, and stronger interop between multiple codebases as a result of working together, and create a better Internet. Those are not the priority for every protocol development effort, and a lot of people have good reasons for doing things on their own. This does not signal a problem with the IETF. -- Wes Eddy MTI Systems
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
On 07/05/2013 09:24 AM, Jose Saldana wrote: Hi, Martin. Regarding the Online Games Tutorial, Mirko and I are adjusting the presentation in order to spend just 45 minutes. We have received some interesting suggestions after announcing it in the IETF87attendees mailing list. We think we will show and capture the traffic of 3 different games: - A UDP-based First person shooter - A UDP-based car racing game, including a 2-minutes car race in which some people in the room (and some remote ones) will be able to participate. - A TCP-based Massively Multiplayer Online Role Play Game (MMORPG) One question: the tutorial is scheduled at 10.35. It lasts 45 minutes. Should we understand that from 11.20 to 11.30 we will have some time for questions and answers? The 10 minutes are the end are reserved as buffer and you should not plan this for QA. Martin Thanks! Jose -Mensaje original- De: tsv-area-boun...@ietf.org [mailto:tsv-area-boun...@ietf.org] En nombre de Martin Stiemerling Enviado el: jueves, 04 de julio de 2013 8:48 Para: tsv-area@ietf.org Asunto: Draft agenda for the IETF-87 TSV Area meeting uploaded Hi, Here is the draft agenda for the IETF-87 TSV Area meeting: Transport Area Open Meeting (tsvarea) -- IETF-87 THURSDAY, August 1, 2013 09:00-11:30 Draft Agenda: 09:00 Note Well and agenda bashing (5 minutes) 09:05 TSV/NOMCOM (15 minutes) 09:20 MPTCP Update (30 minutes) 09:50 QUIC protocol introduction (45 minutes) -- tentative 10:35 Online Games Tutorial (45 minutes) The link to the current version: http://www.ietf.org/proceedings/87/agenda/agenda-87-tsvarea Let Spencer and me know if you have something that should be on the agenda. Martin -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
Hi Joe, On 07/05/2013 02:37 AM, Joe Touch wrote: A link to a draft would be useful. There is no draft but this is of interest to the transport community at large. And it is tentative right now as we do not know if there will be this presentation, i.e., waiting for the confirmation. A slot should not be granted if there isn't a draft. That's true for working groups, but area meetings should have the possibility to talk about topics that are not (yet) documented in an Internet draft. This has also been done in the past, e.g., at IETF-77 for the RTMFP protocol: http://www.ietf.org/proceedings/77/slides/tsvarea-1.pdf Martin Joe On 7/4/2013 8:10 AM, Mikael Abrahamsson wrote: On Thu, 4 Jul 2013, ietfdbh wrote: Hi, What is QUIC? Is there a draft? https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true http://blog.chromium.org/2013/06/experimenting-with-quic.html http://en.wikipedia.org/wiki/QUIC -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014
RE: Draft agenda for the IETF-87 TSV Area meeting uploaded
Joe's assertion is wrong. The IETF is not the place where new transport protocols are developed. Transport is recognised as an underresourced area; David Harrington's Thoughts from a past experimental Nomcom selection for TSV Area Director http://www.ietf.org/mail-archive/web/ietf/current/msg77880.html discusses that, but did not at any point mention new protocols. The IETF has no time for them, as it's too busy maintaining and finetuning and documenting the existing ones. First deploy, then tell the IETF about it, and let the IETF put the documentation into the preferred 1970s ASCII format. draft-ietf-http-v10-spec-00 being the classic case in point, written up several years after global web domination. Setting up httpbis to tweak http, after spdy et al were developed outside the IETF and proven successful, is where the IETF is at - and httpbis isn't even in the transport area, despite http increasingly looking like a transport and protocol hourglass waist. The IETF should be grateful that Google wants to tell it about a new transport protocol that it has deployed worldwide. Demanding that it be written up as an internet-draft beforehand is unreasonable, and arguably a waste of effort. imho. Lloyd Wood http://sat-net.com/L.Wood/ From: tsv-area-boun...@ietf.org [tsv-area-boun...@ietf.org] On Behalf Of Joe Touch [to...@isi.edu] Sent: 05 July 2013 01:37 To: Mikael Abrahamsson Cc: tsv-area@ietf.org Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded A link to a draft would be useful. A slot should not be granted if there isn't a draft. Joe On 7/4/2013 8:10 AM, Mikael Abrahamsson wrote: On Thu, 4 Jul 2013, ietfdbh wrote: Hi, What is QUIC? Is there a draft? https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true http://blog.chromium.org/2013/06/experimenting-with-quic.html http://en.wikipedia.org/wiki/QUIC
RE: Draft agenda for the IETF-87 TSV Area meeting uploaded
Hi, What is QUIC? Is there a draft? David Harrington ietf...@comcast.net +1-603-828-1401 -Original Message- From: tsv-area-boun...@ietf.org [mailto:tsv-area-boun...@ietf.org] On Behalf Of Martin Stiemerling Sent: Thursday, July 04, 2013 2:48 AM To: tsv-area@ietf.org Subject: Draft agenda for the IETF-87 TSV Area meeting uploaded Hi, Here is the draft agenda for the IETF-87 TSV Area meeting: Transport Area Open Meeting (tsvarea) -- IETF-87 THURSDAY, August 1, 2013 09:00-11:30 Draft Agenda: 09:00 Note Well and agenda bashing (5 minutes) 09:05 TSV/NOMCOM (15 minutes) 09:20 MPTCP Update (30 minutes) 09:50 QUIC protocol introduction (45 minutes) -- tentative 10:35 Online Games Tutorial (45 minutes) The link to the current version: http://www.ietf.org/proceedings/87/agenda/agenda-87-tsvarea Let Spencer and me know if you have something that should be on the agenda. Martin -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014
RE: Draft agenda for the IETF-87 TSV Area meeting uploaded
On Thu, 4 Jul 2013, ietfdbh wrote: Hi, What is QUIC? Is there a draft? https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true http://blog.chromium.org/2013/06/experimenting-with-quic.html http://en.wikipedia.org/wiki/QUIC -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
On Thu, 4 Jul 2013, Joe Touch wrote: A slot should not be granted if there isn't a draft. Why? Is there some really important principle I'm missing here? https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true Yes, I'm sure this document could be reformatted into a draft without excessive work and it must be if the work is to take place in an IETF WG, but do you really want to deny the presentation on this (I guess formal?) requirement? I am not in any way affiliated with QUIC development, I have just read the document and find it interesting. -- Mikael Abrahamssonemail: swm...@swm.pp.se
