Architectural Issues
Carl-Uno Manros <manros@cp10.es.xerox.com> Mon, 06 July 1998 21:04 UTC
Delivery-Date: Mon, 06 Jul 1998 17:04:31 -0400
Return-Path: manros@cp10.es.xerox.com
Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00780 for <ietf-archive@ietf.org>; Mon, 6 Jul 1998 17:04:26 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA05353 for <ietf-archive@ns.cnri.reston.va.us>; Mon, 6 Jul 1998 17:06:48 -0400 (EDT)
Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA00777 for <iesg@ietf.org>; Mon, 6 Jul 1998 17:04:24 -0400 (EDT)
Received: from norman.cp10.es.xerox.com ([13.240.124.12]) by alpha.xerox.com with SMTP id <55629(5)>; Mon, 6 Jul 1998 14:04:24 PDT
Received: from garfield.cp10.es.xerox.com (garfield.cp10.es.xerox.com [13.240.124.50]) by norman.cp10.es.xerox.com (8.8.5/8.8.5) with ESMTP id OAA01129; Mon, 6 Jul 1998 14:04:34 -0700 (PDT)
Received: from dellcp-9 (csg122-29 [13.240.122.29]) by garfield.cp10.es.xerox.com (8.8.5/8.8.5) with SMTP id OAA11154; Mon, 6 Jul 1998 14:05:13 -0700 (PDT)
Message-Id: <3.0.5.32.19980706140405.00b90830@garfield>
X-Sender: cmanros@garfield
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 06 Jul 1998 14:04:05 -0700
To: iesg@ietf.org, brian@hursley.ibm.com
From: Carl-Uno Manros <manros@cp10.es.xerox.com>
Subject: Architectural Issues
Cc: ipp@pwg.org, http-wg@cuckoo.hpl.hp.com, w3c-http-ng@w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Dear Members of the IESG, In recent discussions with Keith Moore in his role as Applications Area Director, a couple of rather fundamental questions about Internet protocol architecture have come up. As chair of one of the Application Area WGs, I have had some difficulty to understand the current policy within the IESG and the IAB on the following two aspects, and might have given my WG wrong advice on the acceptability of certain technical solutions vs. others from an IESG/IAB perspective. Issue 1 - Firewalls =================== Although I have been unable to find much said about firewalls in the IETF RFCs (RFC1579 and RFC2356 are the only references that come up), there seems to be some undocumented views within the IESG about what is appropriate and what is not when it comes to distinguishing different applications in firewalls. If such criteria are indeed used by the IESG, I think it is urgently needed to document them. They should distinguish between outgoing vs. incoming firewalls and should clearly state on which, and how many "parameters", filtering must be possible (such as TCP/IP address, scheme, port, method, content-type). Issue 2 - Layering of Applications ================================== It has also been discussed whether layering one application on another is allowed, and if so, which kind of things can be layered on what, and which combinations would be disallowed. This has resulted in debates such as if HTTP is specific to web traffic or a more generic transport protocol. I think it is particularly important to answer this question in anticipation of the HTTP-NG protocol, which is planned for introduction in the IETF later this year. To my knowledge, the designers of that protocol have explicitly wanted to make a protocol that is a more genereric than the current HTTP. Would that be in conflict with the IESGs ideas about what is allowed or not over that protocol? Again, any criteria that the IESG will be using for this kind of layering decisions should be clearly documented, so the WGs have a reasonable chance to stay within the boundaries of what the IESG considers to be "correct" design. Thankful for your feedback on this, Carl-Uno Manros Chair of IETF WG on IPP Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com
- Architectural Issues Carl-Uno Manros