Last Modified: 2005-10-12
IETF 64 APPS/TSV General Area Meeting ------------------------------------- Chairs Ted Hardie, Scott Hollenbeck, Allison Mankin, Jon Peterson Scribe: Andy Newton Eric Rescorla mentions hash functions. Mentions MD5 and SHA-1 theoretical weaknesses. Notes that most applications are not broken. Something new is coming, but we do not know when. Hash functions can be used to protect against downgrade attacks. Agenda Bashing - Scott No issues with the agenda APP Status - Scott NNTPEXT closed and completed work Interim - LEMONDADE (workshop with OMA MeM): Ted says that requirements still coming into LEMONADE. Lots of external reliance on LEMONADE. Appeals related to APPS: MMS/Mapping (LEMONADE) - resolved by draft returning to WG SenderID/SPF Experimentals (MARID) - Not yet resolved LTRU Note to RFC Editor - appeal to the IESG will be denied APP Working Groups, BOFs, and Docs of Interest WIDEX WG (Remote UI BoF in Paris) XML-Patch-Ops Lisa D. asks if anybody from NetConf is attending. Scott says a few. Lisa says that this came out of SIMPLE. Work is to change parts of an XML file. This has morphed into a generalized XML diff application Needs wide review. Dave Crocker: This doesn't seem like an IETF activity. Why here? Lisa: discuss at BoF Leslie D. : IETF has had discussions with W3C on this already Lisa: the intent is not to form a wg Internationalized EMAIL BoF John K.: Last phase of I18N work is non-ascii in local parts of addresses. This BoF is to discuss the drafts on this issue BoFs of Interest outside of APPS DKIM Monday at 1300 Dave C.: DKIM has been going outside the IETF for over a year. This is an outgrowth called MASS. Groups wants to get chartered. CallHome Tuesday 1850 Ted explains this came from Eliot Lear for a specific problem, but it may be much more general than that. TSV - Jon takes over TSVWG James Polk is joining as chair Recharter of TSVWG. Rework of RSVP and SCTP Two BoFs of note. VOIPEER -voice over IP -develop big picture FECFRAME -forward error correction for unreliable transport protocols -with a mind to real-time applications, RTP/RTCP TSVWG meeting -tcp extened mib -sctp auth/threats -ecn topics -tcp/ip quickstart The TSV and RAI Area Split - Allison Mankin TSV area has observed clustering of interest around RAI for some time -working set of people and topics -scheduling set of groups -affinity to several apps groups Continued to see benefit of closeness withing TSV until VOIPEER came along. Benefits of new TSV Area Description of TSV -some words now exist, sent to the nomcom -transport protocols (services offered to upper layers): dccp, rm protocols, dtls, maintaingin tcp, sctp, rsv, diffserv -congenstion control issues, QOS and * session issues that effacet endpoint services (e.g. BEHAVE). Potential Growth of TSV -framework for FEC -very high bandwidth congestion -transport elements of peer-to-peer including the overlay multicast elements Description of RAI Realtime Applications and Infrastructure Area Rule of thumb: work is needed to support real-time interpersonal apps No neat mathematical boundaries. Not going to be neat all the time. Flow between the areas. DCCP will work on voice related congestion control SIPPING will have transport work. No wall between the areas. Management footnotes Two open slots - two open slots in RAI. Allison is stepping down. So three open slots. PROTO can be used to help chairs make the transition work. Might be a few-bumps with the secretariat database Opening up Discussions Ted says APPS chairs are just as good as the chairs in TSV Ted: we hope the interconnections between APPS, TSV, and RAI will be strengthened by this. For apps, this is all part of longer effort to clean up things. Jonathan R.: something similar to TSVWG specific to RAI things. We have lacked fora for this. Particularly emergency services here. Keith M.: concern about putting IM in RAI. There are lots of different factions in the IM space. Some are more like apps, some like telephony. By putting SIMPLE in there you are causing a bit of an issues and bias. Jon P.: IM is related to presence, but also telephony is very tied to it as well. Certainly there are IM protos that are more familiar with apps and some are more familiar with RAI Ted H.: didn't want to start splitting working groups to do this, but that doesn't mean we won't be doing that in the future if we see the need. Keith M.: presence is very much an apps area thing. It isn't really delay sensitive, but interpacket or jitter sensitive where this divide should be. Allison: not topic defined but more worker set defined. there will never be a clean definition that matches everybody's expectation Keith M: cross area review is getting harder and harder. Dave Arand: what about groups not on either list Allison: oops. Dean: SIP related to IM, there are things we could have done better. the unvoiced concern it looks like RAI means we are turning over realtime communications to the SIP heads. Jon P: there is some validity to that concern, but we are not creating new working group but taking existing working groups... not giving any more working groups to sip heads. this is just the set of wgs we have at the moment. Open Mic: Ted: one idea for further comment, how to manage individual submissions. some wgs are closed but we still have individual docs. we need APPSWG similar to TSVWG to handle individual submissions. wg chairs would not be the ADs. Glen Parsons: is the intent that all individual subs be assigned to a wg? Ted: only AD sponsored. Glen: thinking about IMAP drafts. would IMAP individual subs. shouldn't they be put into IMAPEXT or LEMONADE. What about LDAP related? Ted: why would AD sponsored be preferable be to APPSWG. Glen: makes sense to put extra docs that are focused on a particular topic are better in a topci related wg. Ted: that relates to how we manage charters. Glen: yes Dave C: this isn't just about IMAP, sometimes it is an end-run is a good thing sometimes a bad thing. APPSWG can also be a pocket veto. Kurt: SASL gets the review work but doesn't do that work. Same should be for IMAP. Ted: does that make sense to people that APPSWG does review. moves it away from the ADs submissions. Kurt: how does this work with the directorates? Ted: what is your idea Kurt: I prefer APPSWG. Cullen: no downside. help close down existing working groups Randy G.: I see the appeal being it offloads work from the AD and makes individual sub of review more transparent. We don't want to dilute focus of working group. Just review of the doc by APPSWG is nebulous. Lisa: the thing about BoFs is that they get new people involved. Wouldn't like to see fewer BoFs because things are streamlined into APPSWG. What specific drafts if formed today. Ted: we didn't compile a list ??: new topic broadcast with abstract to broader community ??: what is the review time? 4 week, 2 week? directorate vs wg is ADs looking for more people to help twist arms. Where are the TSV and APPS going next? Allson: TSVWG has been good about keeping the individuals to a low Aron Faulk: the problem with TSVWG is that it only give 10 minutes to very broad subjects. Because of the heavy demand, it has created more cross-review. Two meetings at the IETF? The wg stuff gets pushed out for new stuff. Allison: TSV hasn't had two meetings because of lack of overhead. RAI now gives us the overhead. Ted: we have used apps open area for mini-bofs. Maybe schedule two meeting back to back but have a clear transition. Allison: Aaron says have lots more BoFs. It is important to apply a careful filter. Dont' be attracted by lots of open space to think just take on any work. Dean: we found that SIPPING filtered a lot of stuff for SIP. This is about getting review concentration on the documents. Not all work needs to be done. Some drafts need to die. There will still be AD oversight. Ted: much larger group of people act as the filter John K: this is worth trying experimentally. larger groups have much more trouble saying no. need low cost appeals procedure that is efficient because this could get out of control fast. Informational individual submissions vs. standards track? Ted: the rfc editor process would be separate from this. John K. 2821bis can go to this wg Kurt: concerned about this wg being a filter. good for review though. but the consensus of this wg should be required to get docs to the IESG. Allison: the notion of AD sponsored docs is implicit in 2026 but explicit in 3922. IETF process says that it can be taken to an AD. Blocking them by force to the wg maybe go against procedure. James Polk: we should not mandate that every document go through the IESG to become a document. Allison: that is not the issue. the issue is going through an area-wide group vs using the ADs. James P: TSVWG works well, so apps can probably do it. But I wouldn't want to be chair of a group that does not have the AD on it. Ted: there are a variety ways of making the work besides one of the AD being a chair such as area advisor. If it were just the ADs, then it wouldn't be worth running. There are scaling problems with just using the ADs. Allison: we are going to the experiment. watch our experiment. Leslie D: any working group has a charter, so its charter could be tailored to specify the purpose of the review and we need to have a draft charter on the table. Dave C: agree with Leslie. the charter needs to say what is forced into the working group vs what seeks the working group. Ted: asks for interest by hands. enough people for a chartering discussion New topics: Dave C: thanks to Scott for being AD (room claps) Scott: thanks to Allison as well (room claps) Scott closes meeting |