IESG proposed statement on the IETF mission
Brian E Carpenter
brc at zurich.ibm.com
Thu Nov 13 22:54:47 CET 2003
I don't think we can write this sort of text without weasel
words and leaving some room for interpretation. Therefore,
I don't worry too much about it being 100% complete and
Scott W Brim wrote:
> On Mon, Nov 03, 2003 05:19:01PM -0000, graham.travers at bt.com allegedly wrote:
> > Scott,
> > How are you interpreting "has to" ? Are you implying that IP can't run without MPLS (for example) ?
> I see the ambiguity. I meant, if this protocol (suite) is run at all,
> it needs to be run on all the intervening nodes at the IP layer. It
> isn't one that just establishes state in edge nodes, or proxies, via a
> TCP exchange. A protocol like that should be dealt with in the IETF
> because if it's used at all it needs to be part of the Internet
> infrastructure just as much as IP is.
> > On Wed, Oct 29, 2003 04:13:20PM +0100, Brian E Carpenter allegedly wrote:
> > > The IETF covers a wide range of technical areas and it is impossible
> > > to set fully objective boundaries that allow an algorithmic answer to
> > > the question whether a particular item is within the IETF's technical
> > > scope. However, it can be stated that IETF work items are always
> > > concerned with either the Internet Protocol layer itself (Layer 3 in
> > > the ISO/OSI Reference Model), with its management and routing, with
> > > transport protocols (Layer 4) that may seriously impact the correct
> > > functioning of the IP layer, or with direct uses of the transport
> > > layer that provide generic services. Security mechanisms for all of
> > > the above are also in scope.
> > >
> > > Transmission technologies below Layer 3, and upper layer protocols
> > > that are not generic in nature, are generally out of scope. Also,
> > > tightly integrated suites of generic upper layer protocols (for
> > > example, the Web Services protocols) may be more appropriately
> > > specified by a dedicated standards body.
> > Corollary: Anything that has to run everywhere IP runs. This pulls in
> > protocols which need to establish state at every IP hop, not just
> > waypoints (e.g. application proxies). The one that's on my mind is
> > MPLS.
More information about the Problem-statement