From owner-ietf-ppp@merit.edu  Fri Sep  6 14:44:23 2002
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17340
	for <pppext-archive@lists.ietf.org>; Fri, 6 Sep 2002 14:44:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 1956991323; Fri,  6 Sep 2002 14:42:45 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id D8D9E91320; Fri,  6 Sep 2002 14:42:44 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 69D1E91324
	for <ietf-ppp@trapdoor.merit.edu>; Fri,  6 Sep 2002 14:41:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 57BF25DE69; Fri,  6 Sep 2002 14:41:51 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from kff (unknown [208.57.187.120])
	by segue.merit.edu (Postfix) with ESMTP id 75BD95DDE1
	for <ietf-ppp@merit.edu>; Fri,  6 Sep 2002 14:41:50 -0400 (EDT)
Received: from [127.0.0.1] by kff
  (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Fri, 6 Sep 2002 14:41:22 -0400
Message-Id: <5.1.1.6.2.20020906143304.0408d1f0@pop-server.columbus.rr.com>
X-Sender: karlfox@pop-server.columbus.rr.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Fri, 06 Sep 2002 14:41:20 -0400
To: ietf-ppp@merit.edu
From: Karl Fox <karlfox@columbus.rr.com>
Subject: PPP Bridging Control Protocol (BCP) - Working Group Last Call
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

This is last call.  I will advise the area directors that we want to recycle 
PPP Bridging Control Protocol (BCP) (draft-ietf-pppext-rfc2878bis-01.txt) at 
Proposed Standard on September 21, 2002 unless there is substantive comment 
raised on the list.

Karl




From owner-ietf-ppp@merit.edu  Tue Sep 10 05:34:14 2002
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08220
	for <pppext-archive@lists.ietf.org>; Tue, 10 Sep 2002 05:34:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 0B5F291253; Tue, 10 Sep 2002 05:35:13 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id B22119122F; Tue, 10 Sep 2002 05:35:12 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 0AFDE91253
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 10 Sep 2002 05:35:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C8D195DDFF; Tue, 10 Sep 2002 05:35:09 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from emily.fle.fujitsu.com (unknown [193.122.18.249])
	by segue.merit.edu (Postfix) with SMTP
	id B939F5DDFA; Tue, 10 Sep 2002 05:35:08 -0400 (EDT)
Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Tue, 10 Sep 2002 10:36:09 +0100
Received: by fle2.fleblue.fujitsu.com with Internet Mail Service (5.5.2656.59)
	id <S1AA4HAR>; Tue, 10 Sep 2002 10:32:48 +0100
Message-ID: <E9978DD405A2D611913500047583E37A03710D@fle2.fleblue.fujitsu.com>
From: Xin Chen <x.chen@fle.fujitsu.com>
To: "'ietf-ppp@merit.edu'" <ietf-ppp@merit.edu>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: Question on EAP
Date: Tue, 10 Sep 2002 10:32:40 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/mixed;
	boundary="----=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C258AD.01FD9E20"

------_=_NextPart_001_01C258AD.01FD9E20
Content-Type: text/plain

Dear all,
 
Sorry for those who get this twice. I am a starter of PPP and related
extentions. I have a question based on the case below,
 
An authenticator in a WLAN link uses EAP to authenticate terminals. The
authenticator uses AAA (radius or Diameter) to communicate with
authentication server. The authentication server is not only providing
authentication service but registration services. Once the authentication is
successful, the terminal will be considered registered with the network, and
services can be provided.
 
And the registration service of the authentication server needs to know the
user's status in the network (registered or not). Therefore, it relys on
some sort of information reported by the authenticator which is close to the
terminals
 
When the terminal powers off, we want the authenticator to detect this and
report to the authenitcation server that user is not registered anymore
(becuase user has turned off its terminal).
 
The question is does the current WLAN technologies and EAP protocol support
this operation. 
 
Regards
 
Xin Chen
Mobile Network Architecture
Fujitsu Laboratories of Europe LTD
Tel: +44 (0) 2086064453
Mobile: +44 (0)7775741020
 

------_=_NextPart_001_01C258AD.01FD9E20
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2719.2200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=375421409-10092002><FONT face=Arial size=2>Dear 
all,</FONT></SPAN></DIV>
<DIV><SPAN class=375421409-10092002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=375421409-10092002><FONT face=Arial size=2>Sorry for those who 
get this twice. I am a starter of PPP and related extentions. I have a question 
based on the case below,</FONT></SPAN></DIV>
<DIV><SPAN class=375421409-10092002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=375421409-10092002><FONT face=Arial size=2>An authenticator in 
a WLAN link uses EAP to authenticate terminals. The authenticator uses AAA 
(radius or Diameter) to communicate with authentication server. The 
authentication server is not only providing authentication service but 
registration services. Once the authentication is successful, the terminal will 
be considered registered with the network, and services can be 
provided.</FONT></SPAN></DIV>
<DIV><SPAN class=375421409-10092002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=375421409-10092002><FONT face=Arial size=2>And the registration 
service of the authentication server needs to know the user's status in the 
network (registered or not). Therefore, it relys on some sort of information 
reported&nbsp;by the authenticator which is close to the 
terminals</FONT></SPAN></DIV>
<DIV><SPAN class=375421409-10092002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=375421409-10092002><FONT face=Arial size=2>When the terminal 
powers off, we want the authenticator to detect this and report to the 
authenitcation server that user is not registered anymore (becuase user has 
turned off its terminal).</FONT></SPAN></DIV>
<DIV><SPAN class=375421409-10092002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=375421409-10092002><FONT face=Arial size=2>The question is does 
the current WLAN technologies and EAP protocol support this operation. 
</FONT></SPAN></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=375421409-10092002><FONT face=Arial 
size=2>Regards</FONT></SPAN></DIV>
<DIV><SPAN class=375421409-10092002></SPAN>&nbsp;</DIV>
<DIV align=left><FONT face=Arial size=2>Xin Chen</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>Mobile Network Architecture</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>Fujitsu Laboratories of Europe 
LTD</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>Tel: +44 (0) 2086064453</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>Mobile: +44 (0)7775741020</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C258AD.01FD9E20--


------=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410
Content-Type: text/plain;
	name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit

This e-mail has been scanned by Trend InterScan Software.

This e-mail (and its attachment(s) if any) is intended for the named 
addressee(s) only. It may
contain information which is privileged and confidential within the 
meaning of the applicable law.
Unauthorised use, copying or disclosure is strictly prohibited and may 
be unlawful.

If you are not the intended recipient please delete this email and 
contact the sender via email return.

Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility 
for changes made to this email after
it was sent. The views expressed in this email may not necessarily be 
the views held by FLE.

Unless expressly stated otherwise, this email does not form part of a 
legally binding contract
or agreement between the recipient and FLE.

------=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410--



From owner-ietf-ppp@merit.edu  Thu Sep 12 02:53:26 2002
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14626
	for <pppext-archive@lists.ietf.org>; Thu, 12 Sep 2002 02:53:25 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id CA920913E0; Thu, 12 Sep 2002 02:54:50 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 5CDF3913DF; Thu, 12 Sep 2002 02:54:50 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id CC706913DC
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 12 Sep 2002 02:54:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 97D2F5DE37; Thu, 12 Sep 2002 02:54:48 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by segue.merit.edu (Postfix) with ESMTP
	id E7FC35DD95; Thu, 12 Sep 2002 02:54:47 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8C6sjRb029568;
	Thu, 12 Sep 2002 08:54:46 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <S4WQJJJ0>; Thu, 12 Sep 2002 08:51:48 +0200
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF5274E1@esealnt630.al.sw.ericsson.se>
From: "Jari Arkko (LMF)" <Jari.Arkko@lmf.ericsson.se>
To: "'Xin Chen'" <x.chen@fle.fujitsu.com>,
        "'ietf-ppp@merit.edu'" <ietf-ppp@merit.edu>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: Question on EAP
Date: Thu, 12 Sep 2002 08:51:41 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

This does not seem to be an EAP related function as such.
If the given link layer technology gives you an indication of "power
off" in some manner, then the access network or the authenticator
can send a RADIUS accounting stop or similar message to the
home network. So, I don't think EAP is involved. Both RADIUS
accounting and DIAMETER should be able to support such
notifications in the AAA space. I'm not sure how well WLAN
allows you to detect the power-off of a terminal and distinguish
it from temporary radio disturbances.

Jari
-----Original Message-----
From: Xin Chen [mailto:x.chen@fle.fujitsu.com]
Sent: 10. syyskuuta 2002 12:33
To: 'ietf-ppp@merit.edu'; 'aaa-wg@merit.edu'
Subject: Question on EAP


Dear all,

Sorry for those who get this twice. I am a starter of PPP and related extentions. I have a question based on the case below,

An authenticator in a WLAN link uses EAP to authenticate terminals. The authenticator uses AAA (radius or Diameter) to communicate with authentication server. The authentication server is not only providing authentication service but registration services. Once the authentication is successful, the terminal will be considered registered with the network, and services can be provided.

And the registration service of the authentication server needs to know the user's status in the network (registered or not). Therefore, it relys on some sort of information reported by the authenticator which is close to the terminals

When the terminal powers off, we want the authenticator to detect this and report to the authenitcation server that user is not registered anymore (becuase user has turned off its terminal).

The question is does the current WLAN technologies and EAP protocol support this operation. 

Regards

Xin Chen
Mobile Network Architecture
Fujitsu Laboratories of Europe LTD
Tel: +44 (0) 2086064453
Mobile: +44 (0)7775741020


From owner-ietf-ppp@merit.edu  Thu Sep 12 21:23:03 2002
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12497
	for <pppext-archive@lists.ietf.org>; Thu, 12 Sep 2002 21:23:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 411D0912E5; Thu, 12 Sep 2002 21:24:19 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 085F5912E7; Thu, 12 Sep 2002 21:24:18 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 06CEA912E5
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 12 Sep 2002 21:24:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D639C5DE94; Thu, 12 Sep 2002 21:24:17 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from kff (dhcp93127046.columbus.rr.com [24.93.127.46])
	by segue.merit.edu (Postfix) with ESMTP id 38B595DE89
	for <ietf-ppp@merit.edu>; Thu, 12 Sep 2002 21:24:17 -0400 (EDT)
Received: from [127.0.0.1] by kff
  (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 12 Sep 2002 21:24:07 -0400
Message-Id: <5.1.1.6.2.20020912134307.0378c260@pop-server.columbus.rr.com>
X-Sender: karlfox@pop-server.columbus.rr.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 12 Sep 2002 21:24:04 -0400
To: ietf-ppp@merit.edu
From: Karl Fox <karlfox@columbus.rr.com>
Subject: Implementation Survey for LCP MIB (RFC 1471)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

Thanks to Mike MacFaden <mrm@riverstonenet.com> for developing this survey, 
and my apologies to him for letting it sit on the shelf for so long.

Thanks also to Bernard Aboba <aboba@internaut.com> from whom I lifted most 
of the introductory text.

                        LCP MIB Implementation Survey

Please fill this out and return it to karlfox@columbus.rr.com by October 27, 
2002.

For the LCP MIB (RFC 1471) to advance to Draft Standard, every feature must 
have at least two independent implementations, or must be cut from the 
draft.  Please read these directions carefully and email your answers to me 
directly, not to the list.

I only need a reply to this if your implementation is INDEPENDENT, that is, 
not based on another implementation. If you started out once upon a time 
with another code base and eventually replaced all the code with fresh code, 
that counts as independent.  If you did your implementation from scratch, 
better yet.

Please provide contact information and fill out the Company, Product and 
Version fields following their colons, and mark the features with a Y or N 
*before* the feature, and keep the spelling and order exactly as they are 
here (so I can automate processing the results). Lines starting with __ and 
blank lines should not be marked.  Lines starting with a # take a numeric or 
other non-binary response; if you have a number to respond with, put your 
number before the # sign.

Y means you support that feature in your implementation NOW, N means you do 
not.  No fair saying that you'll be adding it later; it has to be in your 
implementation that's already done and is being used somewhere, although 
beta or experimental software counts as in use, as long as its actually 
running.

If you make different kinds of devices but they use the same LCP MIB 
implementation, you only need to send me an entry for one.

Thank you,

Karl Fox <karlfox@columbus.rr.com>
PPPEXT Working Group Chair

----------------------------------------

__                        LCP MIB Implementation Survey

Contact name:
Contact email address:
Contact phone number:
Company name:
Product Name:
Product Version:

__ Tables Supported
pppLinkStatusTable supported
pppLinkConfigTable supported read-write
pppLinkConfigTable supported, but read-only
pppLqrTable supported
pppLqrConfigTable supported read-write
pppLqrConfigTable supported, but read-only
pppLqrExtnsTable supported

__ IF-MIB Table behavior
For any PPP rows created in the PPP-LCP-MIB do you populate the ifTable 
__ with ifEntries of ifType ppp(23)?

# If you answered N to the previous question, what does your agent return to 
__ a get of pppLinkStatusPhysicalIndex?




From owner-ietf-ppp@merit.edu  Thu Sep 12 21:25:24 2002
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12551
	for <pppext-archive@lists.ietf.org>; Thu, 12 Sep 2002 21:25:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 789BF912E7; Thu, 12 Sep 2002 21:26:42 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 419E4912E8; Thu, 12 Sep 2002 21:26:42 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 52966912E7
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 12 Sep 2002 21:26:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 452FF5DE94; Thu, 12 Sep 2002 21:26:41 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from kff (dhcp93127046.columbus.rr.com [24.93.127.46])
	by segue.merit.edu (Postfix) with ESMTP id CFDD35DE89
	for <ietf-ppp@merit.edu>; Thu, 12 Sep 2002 21:26:40 -0400 (EDT)
Received: from [127.0.0.1] by kff
  (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 12 Sep 2002 21:26:39 -0400
Message-Id: <5.1.1.6.2.20020912141322.03b14d90@pop-server.columbus.rr.com>
X-Sender: karlfox@pop-server.columbus.rr.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 12 Sep 2002 21:26:36 -0400
To: ietf-ppp@merit.edu
From: Karl Fox <karlfox@columbus.rr.com>
Subject: Implementation Survey for PPP Security MIB (RFC 1472)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

Thanks to Mike MacFaden <mrm@riverstonenet.com> for developing this survey, 
and my apologies to him for letting it sit on the shelf for so long.

Thanks also to Bernard Aboba <aboba@internaut.com> from whom I lifted most 
of the introductory text.

                        PPP Security MIB Implementation Survey

Please fill this out and return it to karlfox@columbus.rr.com by October 27, 
2002.

For the PPP SEC MIB (RFC 1472) to advance to Draft Standard, every feature 
must have at least two independent implementations, or must be cut from the 
draft.  Please read these directions carefully and email your answers to me 
directly, not to the list.

I only need a reply to this if your implementation is INDEPENDENT, that is, 
not based on another implementation. If you started out once upon a time 
with another code base and eventually replaced all the code with fresh code, 
that counts as independent.  If you did your implementation from scratch, 
better yet.

Please provide contact information and fill out the Company, Product and 
Version fields following their colons, and mark the features with a Y or N 
*before* the feature, and keep the spelling and order exactly as they are 
here (so I can automate processing the results). Lines starting with __ and 
blank lines should not be marked.  Lines starting with a # take a numeric or 
other non-binary response; if you have a number to respond with, put your 
number before the # sign.

Y means you support that feature in your implementation NOW, N means you do 
not.  No fair saying that you'll be adding it later; it has to be in your 
implementation that's already done and is being used somewhere, although 
beta or experimental software counts as in use, as long as its actually 
running.

If you make different kinds of devices but they use the same PPP Security MIB 
implementation, you only need to send me an entry for one.

Thank you,

Karl Fox <karlfox@columbus.rr.com>
PPPEXT Working Group Chair

----------------------------------------

__                        PPP Security MIB Implementation Survey

Contact name:
Contact email address:
Contact phone number:
Company name:
Product Name:
Product Version:

__ Tables Supported
pppSecurityConfigTable supported read-write
pppSecurityConfigTable supported, but read-only
pppSecuritySecretsTable supported read-write
pppSecuritySecretsTable supported, but read-only

__ Which OIDs are supported for pppSecuritySecretsProtocol?  List them.
# OID 1
# OID 2
# OID 3




From owner-ietf-ppp@merit.edu  Thu Sep 12 21:32:27 2002
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12653
	for <pppext-archive@lists.ietf.org>; Thu, 12 Sep 2002 21:32:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 429BA912EA; Thu, 12 Sep 2002 21:33:46 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 09EDC912E8; Thu, 12 Sep 2002 21:33:45 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 3F7F4912EC
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 12 Sep 2002 21:33:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 20E8B5DE94; Thu, 12 Sep 2002 21:33:09 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from kff (dhcp93127046.columbus.rr.com [24.93.127.46])
	by segue.merit.edu (Postfix) with ESMTP id A89875DE89
	for <ietf-ppp@merit.edu>; Thu, 12 Sep 2002 21:33:08 -0400 (EDT)
Received: from [127.0.0.1] by kff
  (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 12 Sep 2002 21:32:59 -0400
Message-Id: <5.1.1.6.2.20020912141315.03b13de0@pop-server.columbus.rr.com>
X-Sender: karlfox@pop-server.columbus.rr.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 12 Sep 2002 21:32:57 -0400
To: ietf-ppp@merit.edu
From: Karl Fox <karlfox@columbus.rr.com>
Subject: Implementation Survey for IP NCP MIB (RFC 1473)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

Thanks to Mike MacFaden <mrm@riverstonenet.com> for developing this survey, 
and my apologies to him for letting it sit on the shelf for so long.

Thanks also to Bernard Aboba <aboba@internaut.com> from whom I lifted most 
of the introductory text.

                        IP NCP MIB Implementation Survey

Please fill this out and return it to karlfox@columbus.rr.com by October 27, 
2002.

For the IP NCP MIB (RFC 1473) to advance to Draft Standard, every feature 
must have at least two independent implementations, or must be cut from the 
draft.  Please read these directions carefully and email your answers to me 
directly, not to the list.

I only need a reply to this if your implementation is INDEPENDENT, that is, 
not based on another implementation. If you started out once upon a time 
with another code base and eventually replaced all the code with fresh code, 
that counts as independent.  If you did your implementation from scratch, 
better yet.

Please provide contact information and fill out the Company, Product and 
Version fields following their colons, and mark the features with a Y or N 
*before* the feature, and keep the spelling and order exactly as they are 
here (so I can automate processing the results). Lines starting with __ and 
blank lines should not be marked.  Lines starting with a # take a numeric or 
other non-binary response; if you have a number to respond with, put your 
number before the # sign.

Y means you support that feature in your implementation NOW, N means you do 
not.  No fair saying that you'll be adding it later; it has to be in your 
implementation that's already done and is being used somewhere, although 
beta or experimental software counts as in use, as long as its actually 
running.

If you make different kinds of devices but they use the same IP NCP MIB 
implementation, you only need to send me an entry for one.

Thank you,

Karl Fox <karlfox@columbus.rr.com>
PPPEXT Working Group Chair

----------------------------------------

__                        IP NCP MIB Implementation Survey

Contact name:
Contact email address:
Contact phone number:
Company name:
Product Name:
Product Version:

__ Tables Supported
pppIpTable supported
pppIpConfigTable supported read-write
pppIpConfigTable supported, but read-only

# What value is returned for pppIpLocalMaxSlotId when 
__ pppIpLocalToRemoteCompressionProtocol is vj-tcp(2)?

# What value is returned for pppIpLocalMaxSlotId when 
__ pppIpRemoteToLocalCompressionProtocol is vj-tcp(2)?

# What value is returned when both of the above are vj-tcp(2)?

# What value is returned when none of the above are vj-tcp(2) 




From owner-ietf-ppp@merit.edu  Fri Sep 13 11:25:21 2002
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08984
	for <pppext-archive@lists.ietf.org>; Fri, 13 Sep 2002 11:25:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id BF7AC91205; Fri, 13 Sep 2002 11:26:40 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 8F60991315; Fri, 13 Sep 2002 11:26:40 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 811F991205
	for <ietf-ppp@trapdoor.merit.edu>; Fri, 13 Sep 2002 11:26:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6B04E5DF02; Fri, 13 Sep 2002 11:26:39 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from tx1.wvinternetservices.com (tx1.wvinternetservices.com [66.118.65.5])
	by segue.merit.edu (Postfix) with ESMTP id E7BA65DE07
	for <ietf-ppp@merit.edu>; Fri, 13 Sep 2002 11:26:38 -0400 (EDT)
Received: from a (63-144-68-101.citynet.net [63.144.68.101])
	by tx1.wvinternetservices.com (8.12.6/8.12.6=Outbound) with SMTP id g8DFW3qO026303
	for <ietf-ppp@merit.edu>; Fri, 13 Sep 2002 11:32:04 -0400
Message-ID: <000701c25b39$baa16cc0$6544903f@a>
From: "Bill Cunningham" <billcu@citynet.net>
To: <ietf-ppp@merit.edu>
Subject: PPTP
Date: Fri, 13 Sep 2002 11:25:00 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu
Content-Transfer-Encoding: 7bit

Does the PPTP offer a secure layer from spam and people being able to read
your e-mail over a search engine only by knowing your email address?



From owner-ietf-ppp@merit.edu  Fri Sep 13 11:56:29 2002
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09962
	for <pppext-archive@lists.ietf.org>; Fri, 13 Sep 2002 11:56:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 0998191319; Fri, 13 Sep 2002 11:57:56 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id C6E0A9131A; Fri, 13 Sep 2002 11:57:55 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id BD53791319
	for <ietf-ppp@trapdoor.merit.edu>; Fri, 13 Sep 2002 11:57:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9E6AD5DF02; Fri, 13 Sep 2002 11:57:54 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 1248F5DE07
	for <ietf-ppp@merit.edu>; Fri, 13 Sep 2002 11:57:54 -0400 (EDT)
Received: from eastmail1.East.Sun.COM ([129.148.1.240])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02866;
	Fri, 13 Sep 2002 09:57:53 -0600 (MDT)
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15238;
	Fri, 13 Sep 2002 11:57:52 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1])
	by phorcys.east.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g8DFvejT071347;
	Fri, 13 Sep 2002 11:57:41 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.12.5+Sun/8.12.5/Submit) id g8DFvec8071344;
	Fri, 13 Sep 2002 11:57:40 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15746.2803.445721.819877@gargle.gargle.HOWL>
Date: Fri, 13 Sep 2002 11:57:39 -0400
From: James Carlson <james.d.carlson@east.sun.com>
To: "Bill Cunningham" <billcu@citynet.net>
Cc: <ietf-ppp@merit.edu>
Subject: Re: PPTP
In-Reply-To: Bill Cunningham's message of 13 September 2002 11:25:00
References: <000701c25b39$baa16cc0$6544903f@a>
X-Mailer: VM 7.01 under Emacs 21.2.1
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu
Content-Transfer-Encoding: 7bit

Bill Cunningham writes:
> Does the PPTP offer a secure layer from spam and people being able to read
> your e-mail over a search engine only by knowing your email address?

PPTP is the Point-to-Point Tunneling Protocol, a proprietary Microsoft
mechanism for carrying PPP across an internet.

PPP is a link layer protocol that can carry IP datagrams, among other
things.  The features of PPTP and PPP have no effect whatsoever on
email applications.

So, the answer would have to be "no."

PPTP is often used with MPPE, Microsoft's proprietary encryption
scheme.  This encrypts the datagrams as they go over the internet.
This affects only the packets between the two nodes speaking PPTP, and
has no effect at all on the packets once they leave that tunnel on
their way to some an email server, search engine, or other node.

(On top of all that, if people can read your email on any search
engine, then you have much bigger problems than any protocol could
ever hope to solve.)

Good luck.

-- 
James Carlson, Solaris Networking         <james.d.carlson@east.sun.com>
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


From owner-ietf-ppp@merit.edu  Tue Sep 17 08:02:13 2002
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11411
	for <pppext-archive@lists.ietf.org>; Tue, 17 Sep 2002 08:02:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 8DADE91239; Tue, 17 Sep 2002 08:03:36 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 2102D91247; Tue, 17 Sep 2002 08:03:02 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 10E5291239
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 17 Sep 2002 08:02:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id CAD7B5DDD3; Tue, 17 Sep 2002 08:02:16 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from ietf.org (unknown [132.151.1.176])
	by segue.merit.edu (Postfix) with ESMTP id 50D1B5DDB0
	for <ietf-ppp@merit.edu>; Tue, 17 Sep 2002 08:02:16 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11317;
	Tue, 17 Sep 2002 08:00:26 -0400 (EDT)
Message-Id: <200209171200.IAA11317@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-ppp@merit.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pppext-rfc2284bis-06.txt
Date: Tue, 17 Sep 2002 08:00:26 -0400
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title		: Extensible Authentication Protocol (EAP)
	Author(s)	: L. Blunk, J. Vollbrecht, B. Aboba
	Filename	: draft-ietf-pppext-rfc2284bis-06.txt
	Pages		: 31
	Date		: 2002-9-16
	
This document defines the Extensible Authentication Protocol (EAP), an
authentication protocol which supports multiple authentication
mechanisms. EAP typically runs directly over the link layer without
requiring IP and therefore includes its own support for in-order
delivery and retransmission. Fragmentation is not supported within EAP
itself; however, individual EAP methods may support this.  While EAP was
originally developed for use with PPP, it is also now in use with IEEE
802.

This document obsoletes RFC 2284.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pppext-rfc2284bis-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-9-16152020.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pppext-rfc2284bis-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-9-16152020.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-ppp@merit.edu  Wed Sep 25 11:31:37 2002
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29530
	for <pppext-archive@lists.ietf.org>; Wed, 25 Sep 2002 11:31:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 45DAE912C4; Wed, 25 Sep 2002 11:32:22 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 429DA912C2; Wed, 25 Sep 2002 11:32:15 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 7EAF0912C5
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 25 Sep 2002 11:32:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 68DEB5DE43; Wed, 25 Sep 2002 11:32:09 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from kff (dhcp93127046.columbus.rr.com [24.93.127.46])
	by segue.merit.edu (Postfix) with ESMTP id D1A1D5DDB4
	for <ietf-ppp@merit.edu>; Wed, 25 Sep 2002 11:32:08 -0400 (EDT)
Received: from [127.0.0.1] by kff
  (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Wed, 25 Sep 2002 09:48:14 -0400
Message-Id: <5.1.1.6.2.20020925094531.03ccee80@pop-server.columbus.rr.com>
X-Sender: karlfox@pop-server.columbus.rr.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Wed, 25 Sep 2002 09:48:11 -0400
To: Thomas Narten <narten@us.ibm.com>, Erik Nordmark <erik.nordmark@sun.com>
From: Karl Fox <karlfox@columbus.rr.com>
Subject: PPP Bridging Control Protocol (BCP) recycled at Proposed
  Standard
Cc: ietf-ppp@merit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

Thomas and Erik,

The PPPEXT Working Group recommends that PPP Bridging Control Protocol 
(BCP), draft-ietf-pppext-rfc2878bis-01.txt, be recycled at Proposed Standard.

Karl




From owner-ietf-ppp@merit.edu  Wed Sep 25 14:06:35 2002
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05101
	for <pppext-archive@lists.ietf.org>; Wed, 25 Sep 2002 14:06:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 6F108912B1; Wed, 25 Sep 2002 14:08:12 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 3AA49912B3; Wed, 25 Sep 2002 14:08:12 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 4B11E912B1
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 25 Sep 2002 14:08:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3A1C85DE69; Wed, 25 Sep 2002 14:08:11 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from kff (dhcp93127046.columbus.rr.com [24.93.127.46])
	by segue.merit.edu (Postfix) with ESMTP id 9F91F5DE61
	for <ietf-ppp@merit.edu>; Wed, 25 Sep 2002 14:08:10 -0400 (EDT)
Received: from [127.0.0.1] by kff
  (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Wed, 25 Sep 2002 14:07:38 -0400
Message-Id: <5.1.1.6.2.20020925140628.00ace6d0@pop-server.columbus.rr.com>
X-Sender: karlfox@pop-server.columbus.rr.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Wed, 25 Sep 2002 14:07:35 -0400
To: Thomas Narten <narten@us.ibm.com>, Erik Nordmark <erik.nordmark@sun.com>
From: Karl Fox <karlfox@columbus.rr.com>
Subject: PPP Bridging Control Protocol (BCP) recycled at Proposed 
  Standard
Cc: ietf-ppp@merit.edu, iesg-secretary@ietf.org
In-Reply-To: <Roam.SIMC.2.0.6.1032971763.29588.nordmark@bebop.france>
References: <"Your message with ID" <5.1.1.6.2.20020925094531.03ccee80@pop-server.columbus.rr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

Thomas and Erik,

The PPPEXT Working Group recommends that PPP Bridging Control Protocol 
(BCP), draft-ietf-pppext-rfc2878bis-01.txt, be recycled at Proposed Standard.

Karl