RE: pppcn

Jonathan Goodchild writes:
> Yes, but for "Fast Reconnect" (or whatever it's called) to have any value,
> everyone needing to use it would have to do it in the same way - it's a
> different level of agreement than just how a secret is configured.  (And
> even if they don't use CHAP, they still have to know how the PPP Identifier
> fields will be generated by the peer for LCP and IPCP.)

Agreed.  I suppose I wasn't clear enough in what I was saying: I don't
think it has sufficient lasting value to bother writing it up in an
RFC.  It seems to me to be harmless if a handful of vendors choose to
implement such hacks^Wfeatures on their own.  The underlying issue
(long RTTs and slow links) seems to me to be at best a temporary
problem, and not something that needs to be etched into stone by the
IETF, or warrants assigning new protocol IDs or option numbers in PPP.

In other words, if it were just a local usage convention within the
CDMA2000 community, I'd be happier.  This would be in keeping all the
other sorts of wackiness we've seen over the years -- for example,
IS-835, which *requires* ACCM set to 0, use of reduced-functionality
IPCP when authentication is rejected, use of Mobile IP without RFC
2290 negotiation, and all sorts of restrictions on the use of peer
names.  (In fact, it goes so far to mandate that implementations must
not support Proposed Standard RFC 2290.)  (And those are just the
PPP-related parts.)

I agree that this proposal doesn't quite rise to that level in terms
of harm, but I guess I'm having trouble determining exactly where the
line between "domain specific private arrangements" and "public
standards" should lie here, assuming there is such a line.  (Along
with a nagging fear that this is just the start of a flood ...)

-- 
James Carlson, IP Systems Group                <[email protected]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677