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
consistent.

  Brian

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.
> 
> ..Scott
> 
> > 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 mailing list