RE: Initial draft of mux WG charter

From: Jim Whitehead (
Date: Mon, Feb 08 1999

From: Jim Whitehead <>
To: Mike Spreitzer <>
Date: Mon, 8 Feb 1999 13:43:19 -0800
Message-ID: <002801be53ac$0af10300$>
Subject: RE: Initial draft of mux WG charter

> > Some items which were missing... A discussion of what is in
> scope, and out of scope.
> I had a hard time thinking of scope questions that weren't
> already answered (well, at least, quesitons that I *thought*
> weren't already answered) by the existing text.  In particular,
> can you suggest items for an "out of scope" list?

No, but I attributed this to my lack of deep understanding of mux. I don't
know muxing well enough to know how someone could twist the meaning of
muxing to be something other than what you intended.  But, for example, I
suspect that one out-of-scope item is muxing across multiple simultaneous
TCP connections between the same endpoints.

> > A list of deliverables.
> Ah, interesting.  I was thinking of a 1-item list, containing the
> protocol.  I had thought that goals documents were not always
> involved in IETF work; that they were needed when the scope was
> sufficiently large and/or contentious that a separate document
> was warranted.  For the mux WG, I thought that it had been
> sufficiently thrashed out and agreed upon at IETF-43 that the
> goals statement in the charter would be sufficient.  Before
> IETF-43 I heard enough uncertainty about the desirability of a
> mux layer that we were thinking of a separate Applicability
> Statement (or something like that).  If the Transport people say
> they still want it, I'd be quite amenable to adding that.

A goals document still makes sense to me, even if it is a thin document. If
the goals are well-understood, then the goals document will be easy to
write, and will be non-contentious.  If the goals aren't as well understood
as people thought, then the goals document will expose this, and save time.
It seems to me the existing WebMUX I-D has a good start on the goals
document -- you'd just need to add rationale for each of the goals items.

It also looks like the existing WebMUX I-D has, near the end, a good start
towards a design rationale document.  Hopefully this design rationale will
be captured, either in the protocol document, or in a separate document.  A
description of the MEMUX specification deliverable would help me know ahead
of time what to expect to find within the protocol specification.

- Jim