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
- Callback Option of PPP Michael Zheng
- Re: Callback Option of PPP Yoshinobu Inoue