RE: pppcn

> From: James Carlson <[email protected]>

> ...
> > True, but could there be some value in such a draft, if only to avoid future
> > unnecessary proposed protocol extensions such as this one?
>
> I've resisted the idea in the past, only because I think it's outside
> of the IETF's proper domain. ...

> Moreover, using the IETF to specify such things (as is unfortunately
> sometimes done) only encourages more of the same grot in the future.
> I don't think we need any more "here's how you use HTML+HTTP+TCP+IP+
> PPP+CDMA for the FooBar product line" sorts of Informational drafts
> floating around.  These really aren't all that informational, and
> serve no lasting purpose other than as low-cost advertising.

I agree.

> However, if this issue, despite all of the previous discussion
> stretching back years in the ietf-ppp archives, is going to keep
> coming back to life like an extra from a Cesar Romero movie, then I
> guess a preemptive "please try something else" document is the only
> way out.

Searching the mailing archives is very hard.  If its title were
sufficiently enticing in the index, an RFC might help.


> (I'd still question the usefulness of that document somewhat, since I
> don't quite see why such an Informational RFC would necessarily be any
> more likely to be seen and read than are the existing working group
> archives.  But perhaps it's worth a shot.)

There are a couple other reasons to be skeptical.  One is that the
idea is obvious, common in many fields (e.g. "speculative execution"
in CPUs), and old.  Would people who don't think of it independently
pay attention to an RFC?

Another reason is whether it would address the motives for the continuing
proposals for fast PPP (re)connection.  I don't want to offend anyone,
but when I'm trying to solve a technical problem, I might post questions
in likely mailing lists, but my questions are unlikely to look like
formal proposals complete with bibliographies.  The substantial effort
of writing an Internet-Draft seems like a good the first step only if
the primary goals including writing an RFC.

An RFC wouldn't replace or amend the "Link Layer Enhancements for
TCP/IP over GSM" in the Proceedings of IEEE INFOCOM, March 1999 that
may have been the inspiration or instigation for this cycle.

It's also not as if your book is out of print (I hope).

On the third hand, an RFC might save the IESG some time if we
ever get tired of being wet blankets.


Vernon Schryver    [email protected]