Re: MP revisions

Daniel Brennan/US/3Com <Daniel_Brennan@3mail.3com.com> Wed, 03 July 1996 03:35 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00802; 2 Jul 96 23:35 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00797; 2 Jul 96 23:35 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa00625; 2 Jul 96 23:35 EDT
Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id XAA23877; Tue, 2 Jul 1996 23:29:02 -0400 (EDT)
Resent-Date: Tue, 2 Jul 1996 23:29:02 -0400 (EDT)
Message-Id: <9607030333.AA2946@hqsmtp2.ops.3com.com>
To: Gina DePlanche <Gina.Deplanche@proteon.com>
Cc: Tom Coradetti <70761.1664@compuserve.com>, ietf-ppp <ietf-ppp@merit.edu>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Daniel Brennan/US/3Com <Daniel_Brennan@3mail.3com.com>
Date: 2 Jul 96 13:29:59 EDT
Subject: Re: MP revisions
Mime-Version: 1.0
Content-Type: Text/Plain
Resent-Message-ID: <"rXAnl2.0.pq5.vZUsn"@merit.edu>
Resent-From: ietf-ppp@merit.edu
X-Mailing-List: <ietf-ppp@MERIT.EDU> archive/latest/1736
X-Loop: ietf-ppp@MERIT.EDU
Precedence: list
Resent-Sender: ietf-ppp-request@merit.edu

  
->On PFC. I disagree with Dan's comment. It must be stated that this option is
->prenegotiated. If it were
->not, the transmitter would be required to transmit 2 byte protocol fields, 
since
->there could be no
->presumption that the receiver could tolerate the compression.

But why assume prenegotiation? Why send 1 byte protocol fields? Just send 
two bytes. If it's not negotiated then an implementation shouldn't send PFC.
I forgot why we agreed to do this anyway? (Vern, flame here ->). I do highly
recommend that an implemenation be ready to accept it though.

->The RFC currently forbids NAKing the ED option.

I didn't say to NAK the ED option. I would like to see it become a mandatory
option though (maybe as an implementation note recommending that it SHOULD be 
sent).


->There is no requirement that Multilink use dial up or switched connections. 
->The links may be permanent, or otherwise well known to each endpoint. 
->That is why RFC 1717 requires neither authentication or ED.
->Some members of the list felt strongly that authentication would perform the 
->ED function satisfactorily.
->(As the author of the Endpoint Discriminator text, it is reasonable to 
->conclude that I did not share that view.)

Me too Tom. Dial into your favorite ISP on a busy day (when are they not 
busy?). I can get auth'ed
on two different MAX's. Without ED, I would never know it.

Dan Brennan
3Com