Re: Callback Option of PPP

Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp> Fri, 14 July 1995 01:50 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14669; 13 Jul 95 21:50 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14665; 13 Jul 95 21:50 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa26308; 13 Jul 95 21:50 EDT
Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA03502; Thu, 13 Jul 1995 21:44:02 -0400
Resent-Date: Thu, 13 Jul 1995 21:44:02 -0400
Date: Fri, 14 Jul 1995 10:42:20 +0900
Message-Id: <199507140142.KAA04803@chisato.nd.net.fujitsu.co.jp>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
To: michael@combinet.com, listproc@lists.pipex.com, ietf-ppp@merit.edu
Mime-Version: 1.0
Subject: Re: Callback Option of PPP
Content-Type: text/plain; charset=iso-2022-jp
X-Mailer: Winbiff [version 1.07 (On Trial)]
Resent-Message-ID: <"kZIyj.0.Us.VlS1m"@merit.edu>
Resent-From: ietf-ppp@merit.edu
X-Mailing-List: <ietf-ppp@MERIT.EDU> archive/latest/572
X-Loop: ietf-ppp@MERIT.EDU
Precedence: list
Resent-Sender: ietf-ppp-request@merit.edu

Hello.

My comments about following issues.

michael>     1. The use of conf-nak for callback:
michael>     
michael>        If an implementation doesn't like the "operation" in a callback 
michael>     confreq, presumably it confnak's it with the desired operation and 
michael>     leaves the "message" portion blank.  Can anybody confirm this?

I can't confirm but I agree.
May be, only "operation" has meaning in negotiation, and "message" is a kind 
of advisory information. The side who don't know the adequate value of the
"message" will leave it blank.

michael>     2. The use of conf-rej for callback:
michael>     
michael>        Some of the operations (e.g., 0 and 2) are designed to work with 
michael>     the authentication information, which is available only after the 
michael>     authentication phase finishes.  Therefore, the validity of the 
michael>     callback request is not determined till the authentication is done.  
michael>     As a result, those confreq should always be ack'd.  And later on, 
michael>     depending on whether the callback is authorized or not, the callback 
michael>     may or may not happen.  

I agree. And I also think that there should be some conceptual time period between 
authentication phase and network layer protocol phase where it is decided if 
callback should happen or not as the obtained information.

michael>        Some other operations (e.g, 1, 3 and 4) contains complete 
michael>     information to determine the validity of the request.  If those 
michael>     requests are invalid (e.g., operation 1 contains unknown syntax to the 
michael>     called unit), should a confrej be sent right away?  Notice that this 
michael>     behavior is different than the one above.

IMHO, it is a burden for usual machine to check syntax of the dialing string.
It will be simpler if every dialing string error (including syntax error,
wrong dialing number, etc) is checked on actual callback. Requester of callback
will notice there is some problem if it is not called back at last.   

michael>     3. Could someone please provide a little more information about 
michael>     operations 2 and 4?  How is operation 4 intended to be used?

RFC1700's PPP protocol number portion includes more clear difinition about 
those numbers.

Regards,
--
Yoshinobu Inoue    shin@nd.net.fujitsu.co.jp
Architecture Department  Network Division
Fujitsu Limited