MIDTAX Monday, March 19, 2001 15:30
Chairs: Rob Austein <email@example.com>, Brian Carpenter <firstname.lastname@example.org>
Reported by Matt Holdrege <email@example.com>
Archive: yes, but web access not yet available
Brian Carpenter firstname.lastname@example.org
Slides presenting the draft submitted to IETF minutes.
Q1: Is this work useful?
Many yes's. But some random warnings about what we should NOT be doing. Eliot said it would be useful to provide a way for end systems to discover middle boxes and provide diagnostic tools for end-systems to discover the source of problems when middle boxes crash.
Eliot asked if a taxonomy document is important. Matt said it is very important since middle boxes are being built by people of all different walks of life, many of who are outside the IETF. That's why we need a common, referenceable taxonomy document. But we need to take care that we not produce anything like a Host Requirements document.
Jon Crowcroft said that it would be nice to insert notification or discovery requirements in middle boxes.
It was asked if we will produce a document that states which RFC's are broken by middle boxes.
It was asked if standard track documents should contain a section on "end-to-end assumption"? Scott Bradner said it was suggested to the IESG already, but how to do that is unresolved.
Q2: Are any important types of middle box missing from the list?
VPN's and tunnel endpoints.
Q3: Are there any types of middle box needing IETF attention that are outside the scope of existing WG's?
Matt said that there is clearly a history of groups outside the IETF designing protocols and architectures that could have benefited from IETF documents describing middle boxes. So there will likely be a future need as well.
Jim Kempf said that 3GPP now is looking for an IETF document that describes what a proxy is.
Scott B said that when MIDCOM was formed, the question of discovery was explicitly excluded. Eliot has since written a draft on the subject and we are discussing what to do about it.
Q4: What protocol design principles help us deal with such a wide diversity of middle boxes?
- How do we achieve e2e robustness (scalability), security and efficiency?
- How can we limit complexity?
- Do the different types of middle box demand different answers to these questions?
Could the IETF design middle box solutions to address scalability? Yes in fact SMTP and NTP do exactly that.
Should IETF protocols be resistant to middle boxes reordering packets?
Should we separate the middle boxes that are good and the ones that are evil? That would be good, but it wouldn't make the evil boxes go away. Yet it would provide clues to people who want to build evolvable yet initially evil middle boxes.
Q5: Do we need the routing system to export topology information to an application level "routing" framework, so that application level middle boxes don't have to cheat?
Matt said that this might be seen as a layer violation in certain scenarios. SIP is an example. Others (Rob and Scott Brim) said that multi-homing and (C-CAMP?) can benefit from this scheme.
Melinda said we should be concerned about security implications with this idea.
Lixia said that the info that the application middle box wants may not be extractable from the routing layer.
Rob said that this something we should adhere to as an architectural principle. Perhaps we got some of the architectural principles wrong and we need to reassess.
Should Brian re-rev the draft? The group said yes. There were no objections.
Should the IESG charter a working group on this topic. Scott B said that there isn't yet enough clarity on what we need to do.
Eliot said the middle-box architecture draft should be re-reved in a couple of weeks. Melinda noted that we will spend time on definitional issues in the MIDCOM working group? Eliot has an email list (email@example.com, or subscribe at firstname.lastname@example.org) dedicated to his MARCH draft.
Should we fold this work into the MIDCOM working group? Melinda is concerned about MIDCOM going through very disparate and disjointed schemes and she is concerned about further confusing the issues. We will take it off-line to see what best to do.