From owner-nasreq@kull.rutgers.edu Sun Feb 13 16:44:26 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13923; Sun, 13 Feb 2000 16:44:26 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id QAA23105 for nasreq-outgoing; Sun, 13 Feb 2000 16:16:49 -0500 (EST) Received: from smartt.com (ktk6.smartt.com [209.52.5.253]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA23062 for ; Sun, 13 Feb 2000 16:16:48 -0500 (EST) From: taxfree9567@yahoo.com Received: from your (vict-mx0100101.smartt.com [207.34.159.14]) by smartt.com (8.9.0/8.9.0) with SMTP id NAA23909; Sun, 13 Feb 2000 13:16:33 -0800 (PST) Date: Sun, 13 Feb 2000 13:16:33 -0800 (PST) Message-Id: <200002132116.NAA23909@smartt.com> Reply-To: taxfree9567@yahoo.com To: taxfree9567@yahoo.com Subject: nasreq Tired of the 9 to 5 yet? Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk Are you serious? Serious about finally working for yourself and not somebody else? Serious about having more time to do what you want when you want? Serious about taking control of your finances and having your money go to work for you? Do you want to work for your dreams, and quit building someone else’s? Are you serious about finally working from home? Are you serious about being truly free? Are you serious? I am looking for people who are willing to get to work and make it happen. This is not multi-level-marketing To find out more, call Toll Free. 1-800-636-6773 ext 3886. Serious inquiries only God Bless From owner-nasreq@kull.rutgers.edu Wed Feb 16 07:04:10 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23197; Wed, 16 Feb 2000 07:04:00 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id GAA09340 for nasreq-outgoing; Wed, 16 Feb 2000 06:40:35 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id GAA09269 for ; Wed, 16 Feb 2000 06:40:26 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22535; Wed, 16 Feb 2000 06:40:16 -0500 (EST) Message-Id: <200002161140.GAA22535@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nasreq@tdmx.rutgers.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-nasreq-ext-radiuspract-02.txt Date: Wed, 16 Feb 2000 06:40:14 -0500 Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Access Server Requirements Working Group of the IETF. Title : Network Access Servers Requirements: Extended RADIUS Practices Author(s) : D. Mitton Filename : draft-ietf-nasreq-ext-radiuspract-02.txt Pages : 17 Date : 15-Feb-00 This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The pur- pose of this effort is to give examples that show the need for address- ing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered. These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment. This document is a draft submission of the Network Access Server Requirements (NASREQ) Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mailing list nasreq@tdmx.rutgers.edu. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nasreq-ext-radiuspract-02.txt 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-nasreq-ext-radiuspract-02.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-nasreq-ext-radiuspract-02.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: <20000215124257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nasreq-ext-radiuspract-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nasreq-ext-radiuspract-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000215124257.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-nasreq@kull.rutgers.edu Thu Feb 17 15:12:56 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23316; Thu, 17 Feb 2000 15:12:56 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id OAA22189 for nasreq-outgoing; Thu, 17 Feb 2000 14:45:09 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA22148 for ; Thu, 17 Feb 2000 14:44:26 -0500 (EST) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Thu, 17 Feb 2000 14:42:15 -0500 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 12FVY1NW; Thu, 17 Feb 2000 14:42:14 -0500 Received: from mitton (mitton.corpeast.baynetworks.com [132.245.145.116]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1L2520SD; Thu, 17 Feb 2000 14:42:13 -0500 Message-Id: <4.2.2.20000217143607.0390ae90@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 17 Feb 2000 14:43:15 -0500 To: nasreq@tdmx.rutgers.edu From: "David Mitton" Subject: Draft-ietf-nasreq-ext-radiuspract-02.txt Cc: "Beadles, Mark A" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk Changes To ietf-draft-nasreq-ext-radpract-01.txt ------ At the last WG meeting (Nov 99, DC), there were comments from the floor requesting changes in this draft. The primary complaints were; - It should not name vendor's names, - It does not adequately represent the vendor's products as they update, - It contains significantly out-dated references, 1) The AD asked if the vendor's names added value, and my response was yes. Anytime I discuss this topic with anyone, they always wanted to know whom did what. This is always important to people, as they attempt to judge the impact of such functions on their environment. And it provides a way to find out more about the feature from the vendor's own documentation. Coincidentally, I just before the meeting I had received an email request from my co-chair asking about one of the features in the prior version where I had _not_ identified the implementing vendor. In any case, I have removed almost all mentions of vendors with respect to functions. 2) I am really baffled as to how it would be possible for any IETF document to continually stay current with implementations after it's been published. The whole point of naming versions is to lock the description to a given time in the past. Future readers will be able to refer to the publication date and the version number in order to figure out when the information was reviewed by the group. I would like an example of any BCP type RFC which has been updated past it's issuance date and if that is even relevant to this case. In any case, I have removed all mention of specific version numbers. The several existing disclaimers of being a reference document have been wordsmithed some more. 3) Looking through what I've actually written in the draft, I actually find very few of the references called out. I mostly just tacked a list of my favorite IETF documents on the end. Certainly none of them is "normative" to this document, as it's an informational work about non-standard practices. Looking over the list of documents in the reference section, I could only find two that were not available. So I have removed these, as there are other ways to communicate that information. [16] G. Zorn, "Yet Another Authentication Protocol (YAAP)", draft-zorn-yaap-01.txt, 30 June 1996 Is now acknowledged more properly in the draft-ietf- nasreq-criteria-03.txt document which is more appropriate to it's subject. And, [17] N. Greene, "Best Current Practice for Modem Outsourcing", draft-greene-nasreq-00.txt, March 1998, in which the concept was relevant, but the approach had nothing to do with RADIUS. I have also removed other various document listings, as I realized they were not particularly supporting to this document as well. If there are any other errors or updates to the references of this documents, or any other work item with this group, please send me email. I would like to move this document to Working Group Last Call. Thanks, Dave. --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com From owner-nasreq@kull.rutgers.edu Fri Feb 18 11:42:45 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26783; Fri, 18 Feb 2000 11:42:42 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id LAA05061 for nasreq-outgoing; Fri, 18 Feb 2000 11:06:36 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA05052 for ; Fri, 18 Feb 2000 11:06:30 -0500 (EST) Received: from chsharp-tecra (rtp-dial-2-152.cisco.com [10.83.96.152]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id IAA07260 for ; Fri, 18 Feb 2000 08:06:25 -0800 (PST) Message-Id: <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 18 Feb 2000 10:57:32 -0500 To: nasreq@tdmx.rutgers.edu From: Chip Sharp Subject: nasreq NAS Package for megaco/H.248 returned to IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk FYI, At the latest SG16 meeting discussing the megaco/H.248 protocol, it was decided that the IETF would be the best place to develop the NAS package defining how to control NASes using the megaco protocol. Chip Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-nasreq@kull.rutgers.edu Tue Feb 22 09:09:22 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10696; Tue, 22 Feb 2000 09:09:19 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id IAA11070 for nasreq-outgoing; Tue, 22 Feb 2000 08:43:11 -0500 (EST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA10927 for ; Tue, 22 Feb 2000 08:43:10 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA12132; Tue, 22 Feb 2000 06:43:03 -0700 (MST) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.105.34]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id FAA18282; Tue, 22 Feb 2000 05:43:03 -0800 (PST) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA04674; Tue, 22 Feb 2000 05:43:02 -0800 Date: Tue, 22 Feb 2000 05:43:00 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF To: Chip Sharp Cc: nasreq@tdmx.rutgers.edu In-Reply-To: "Your message with ID" <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk Well, there goes any hopes of wrapping up this WG anytime soon :) PatC > FYI, > At the latest SG16 meeting discussing the megaco/H.248 protocol, it was > decided that the IETF would be the best place to develop the NAS package > defining how to control NASes using the megaco protocol. > > Chip > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- > From owner-nasreq@kull.rutgers.edu Wed Feb 23 05:33:41 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17773; Wed, 23 Feb 2000 05:33:41 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id FAA15711 for nasreq-outgoing; Wed, 23 Feb 2000 05:16:42 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id FAA15547 for ; Wed, 23 Feb 2000 05:16:41 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id CAA04675; Wed, 23 Feb 2000 02:10:17 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 23 Feb 2000 10:16:36 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id CAA24066; Wed, 23 Feb 2000 02:16:35 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000222184405.00ae4650@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 22 Feb 2000 18:47:00 -0800 To: "pcalhoun@eng.sun.com" From: Matt Holdrege Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF Cc: nasreq@tdmx.rutgers.edu In-Reply-To: References: <"Your message with ID" <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk NASREQ (via ISOC) can always respond to SG16 and say that H.248 "as is" works fine for NAS's and no other response is required. In fact any other response would invalidate the way NAS's are supposed to work. Those who read the MEGACO list know my arguments. If not, I'd be happy to elucidate in Adelaide. At 05:43 AM 2/22/00 -0800, pcalhoun@eng.sun.com wrote: >Well, there goes any hopes of wrapping up this WG anytime soon :) > >PatC > > FYI, > > At the latest SG16 meeting discussing the megaco/H.248 protocol, it was > > decided that the IETF would be the best place to develop the NAS package > > defining how to control NASes using the megaco protocol. > > > > Chip > > Support NetAid! http://www.netaid.org > > -------------------------------------------------- > > Chip Sharp Consulting Engineering > > Cisco Systems Telco Bio-region > > Reality - Love it or Leave it. > > -------------------------------------------------- > > From owner-nasreq@kull.rutgers.edu Wed Feb 23 13:46:19 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29773; Wed, 23 Feb 2000 13:46:18 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id NAA21936 for nasreq-outgoing; Wed, 23 Feb 2000 13:24:38 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id NAA21859 for ; Wed, 23 Feb 2000 13:24:37 -0500 (EST) Received: from chsharp-tecra ([171.68.157.148]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id KAA26274; Wed, 23 Feb 2000 10:23:58 -0800 (PST) Message-Id: <4.2.2.20000223220730.00bbbba0@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Feb 2000 22:13:46 -0800 To: Matt Holdrege , "pcalhoun@eng.sun.com" From: Chip Sharp Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF Cc: nasreq@tdmx.rutgers.edu In-Reply-To: <4.2.2.20000222184405.00ae4650@porky> References: <"Your message with ID" <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk Yes, please read through the megaco archives if you wish to know our disagreement. I agree with Matt that NASes work fine with current operation. The main disagreement I believe is that i believe enhancements can be made to the NAS package to allow other capabilities. Basically, though there is no NAS package currently defined for megaco. SG16 doesn't want to do any more work to define the package. Currently it is just a draft. But perhaps this doesn't fall within the NASREQ charter and should be the subject of a separate BOF. chip At 06:47 PM 2/22/00 -0800, Matt Holdrege wrote: >NASREQ (via ISOC) can always respond to SG16 and say that H.248 "as is" >works fine for NAS's and no other response is required. In fact any other >response would invalidate the way NAS's are supposed to work. > >Those who read the MEGACO list know my arguments. If not, I'd be happy to >elucidate in Adelaide. > > >At 05:43 AM 2/22/00 -0800, pcalhoun@eng.sun.com wrote: >>Well, there goes any hopes of wrapping up this WG anytime soon :) >> >>PatC >> > FYI, >> > At the latest SG16 meeting discussing the megaco/H.248 protocol, it was >> > decided that the IETF would be the best place to develop the NAS package >> > defining how to control NASes using the megaco protocol. >> > >> > Chip >> > Support NetAid! http://www.netaid.org >> > -------------------------------------------------- >> > Chip Sharp Consulting Engineering >> > Cisco Systems Telco Bio-region >> > Reality - Love it or Leave it. >> > -------------------------------------------------- >> > > Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-nasreq@kull.rutgers.edu Wed Feb 23 15:45:49 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02545; Wed, 23 Feb 2000 15:45:48 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id PAA15592 for nasreq-outgoing; Wed, 23 Feb 2000 15:10:17 -0500 (EST) Received: from qhars001.nortel.com (qhars001.NortelNetworks.com [192.100.101.18]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id PAA15395 for ; Wed, 23 Feb 2000 15:10:16 -0500 (EST) Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com; Wed, 23 Feb 2000 20:09:45 +0000 Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Wed, 23 Feb 2000 14:09:34 -0600 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FKDDAG8P; Wed, 23 Feb 2000 15:09:26 -0500 Received: from mitton (mitton.corpeast.baynetworks.com [132.245.145.116]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FHA4DTAZ; Wed, 23 Feb 2000 15:09:23 -0500 Message-Id: <4.2.2.20000223150354.00d07e30@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Feb 2000 15:10:21 -0500 To: nasreq@tdmx.rutgers.edu From: "David Mitton" Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF In-Reply-To: <4.2.2.20000223220730.00bbbba0@dogwood.cisco.com> References: <4.2.2.20000222184405.00ae4650@porky> <"Your message with ID" <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk ummm... At 10:13 PM 2/23/00 -0800, you wrote: >Yes, please read through the megaco archives if you wish to know our >disagreement. that's only 35MB of text in my mail reader. But please do not attempt to explain here. Just direct us to the prime temporal location of the discussion. >I agree with Matt that NASes work fine with current operation. The main >disagreement I believe is that i believe enhancements can be made to the >NAS package to allow other capabilities. You know, "package" is a real general term in english. I usually use UPS or FedEx. Can you explain in about 64 words or less what this means to megaco? >Basically, though there is no NAS package currently defined for >megaco. SG16 doesn't want to do any more work to define the >package. Currently it is just a draft. > >But perhaps this doesn't fall within the NASREQ charter and should be the >subject of a separate BOF. That is hard to assess until we understand the issue. It might be more expedient to use the Nasreq group that is already formed, than to go through the overhead of starting another, if this is a fairly simple item. >chip > >At 06:47 PM 2/22/00 -0800, Matt Holdrege wrote: >>NASREQ (via ISOC) can always respond to SG16 and say that H.248 "as is" >>works fine for NAS's and no other response is required. In fact any other >>response would invalidate the way NAS's are supposed to work. >> >>Those who read the MEGACO list know my arguments. If not, I'd be happy to >>elucidate in Adelaide. >> >> >>At 05:43 AM 2/22/00 -0800, pcalhoun@eng.sun.com wrote: >>>Well, there goes any hopes of wrapping up this WG anytime soon :) >>> >>>PatC >>> > FYI, >>> > At the latest SG16 meeting discussing the megaco/H.248 protocol, it was >>> > decided that the IETF would be the best place to develop the NAS package >>> > defining how to control NASes using the megaco protocol. >>> > >>> > Chip >>> > Support NetAid! http://www.netaid.org >>> > -------------------------------------------------- >>> > Chip Sharp Consulting Engineering >>> > Cisco Systems Telco Bio-region >>> > Reality - Love it or Leave it. >>> > -------------------------------------------------- >>> > > >Support NetAid! http://www.netaid.org >-------------------------------------------------- >Chip Sharp Consulting Engineering >Cisco Systems Telco Bio-region >Reality - Love it or Leave it. >-------------------------------------------------- --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com From owner-nasreq@kull.rutgers.edu Wed Feb 23 16:33:05 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03162; Wed, 23 Feb 2000 16:33:05 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id PAA01162 for nasreq-outgoing; Wed, 23 Feb 2000 15:59:40 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id PAA00505 for ; Wed, 23 Feb 2000 15:59:34 -0500 (EST) Received: from chsharp-tecra ([171.68.157.148]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id MAA05039; Wed, 23 Feb 2000 12:59:21 -0800 (PST) Message-Id: <4.2.2.20000224003415.00c21b90@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 24 Feb 2000 00:54:20 -0800 To: "David Mitton" , nasreq@tdmx.rutgers.edu From: Chip Sharp Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF In-Reply-To: <4.2.2.20000223150354.00d07e30@ZBL6C008.corpeast.baynetwork s.com> References: <4.2.2.20000223220730.00bbbba0@dogwood.cisco.com> <4.2.2.20000222184405.00ae4650@porky> <"Your message with ID" <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk At 03:10 PM 2/23/00 -0500, David Mitton wrote: >ummm... > >At 10:13 PM 2/23/00 -0800, you wrote: >>Yes, please read through the megaco archives if you wish to know our >>disagreement. > >that's only 35MB of text in my mail reader. But please do not attempt to >explain here. Just direct us to the prime temporal location of the discussion. Don't you keep 35 Mbytes in your In box in Eudora? ;-) The latest round of discussion can be found in a thread titled "Basic Package and NAS" which occured between 10/6/99 and 10/18/99 The megaco archive search page at http://standards.nortelnetworks.com/scripts/wa.exe?S1=megaco can be used to search for this. >>I agree with Matt that NASes work fine with current operation. The main >>disagreement I believe is that i believe enhancements can be made to the >>NAS package to allow other capabilities. > >You know, "package" is a real general term in english. I usually use UPS >or FedEx. Can you explain in about 64 words or less what this means to megaco? Megaco defines a base protocol for allowing a Media Gateway Controller to control what are called "terminations" on Media Gateways. A "termination" could be physical (e.g., DS0) or "ephemeral" (e.g., RTP endpoint). The specific parameters, events and signals for a particular type of termination are defined in "packages." A package defines the events that can be detected on a termination (e.g., Dial tone), signals to be transmitted on a termination (e.g., dtmf, dial tone, etc.) and parameters that can be used to configure the termination (e.g., what codec to use on a RTP termination). A NAS package would define a NAS termination and would define the events, signals and configuration parameters that a MGC could use to control a NAS (acting as a media gateway). Basically, the MGC would handle the call control and then configure the NAS to accept the call. The NAS would then do its normal PPP (or whatever) and RADIUS thing. The sticking point seems to be whether or not the protocol would allow the MGC to send down various configuration parameters (e.g., modem type, AAA server to use, L2TP LNS to connect to , etc.) based on the Calling/Called number (or other call info). If something is done in this area, it should probably be done in close cooperation with the megaco group. >>Basically, though there is no NAS package currently defined for >>megaco. SG16 doesn't want to do any more work to define the >>package. Currently it is just a draft. >> >>But perhaps this doesn't fall within the NASREQ charter and should be the >>subject of a separate BOF. > >That is hard to assess until we understand the issue. It might be more >expedient to use the Nasreq group that is already formed, than to go >through the overhead of starting another, if this is a fairly simple item. > > >>chip >> >>At 06:47 PM 2/22/00 -0800, Matt Holdrege wrote: >>>NASREQ (via ISOC) can always respond to SG16 and say that H.248 "as is" >>>works fine for NAS's and no other response is required. In fact any >>>other response would invalidate the way NAS's are supposed to work. >>> >>>Those who read the MEGACO list know my arguments. If not, I'd be happy >>>to elucidate in Adelaide. >>> >>> >>>At 05:43 AM 2/22/00 -0800, pcalhoun@eng.sun.com wrote: >>>>Well, there goes any hopes of wrapping up this WG anytime soon :) >>>> >>>>PatC >>>> > FYI, >>>> > At the latest SG16 meeting discussing the megaco/H.248 protocol, it was >>>> > decided that the IETF would be the best place to develop the NAS package >>>> > defining how to control NASes using the megaco protocol. >>>> > >>>> > Chip >>>> > Support NetAid! http://www.netaid.org >>>> > -------------------------------------------------- >>>> > Chip Sharp Consulting Engineering >>>> > Cisco Systems Telco Bio-region >>>> > Reality - Love it or Leave it. >>>> > -------------------------------------------------- >>>> > >> >>Support NetAid! http://www.netaid.org >>-------------------------------------------------- >>Chip Sharp Consulting Engineering >>Cisco Systems Telco Bio-region >>Reality - Love it or Leave it. >>-------------------------------------------------- > >--------------------------------------------------------------- >David Mitton ESN: 248-4570 >Advisor, Nortel Networks 978-288-4570 Direct >Carrier Packet Solutions, Preside 978-288-3030 FAX >Billerica, MA 01821 dmitton@nortelnetworks.com > Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-nasreq@kull.rutgers.edu Wed Feb 23 17:13:05 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03682; Wed, 23 Feb 2000 17:13:03 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id QAA06836 for nasreq-outgoing; Wed, 23 Feb 2000 16:42:58 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA06717 for ; Wed, 23 Feb 2000 16:42:57 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01486; Wed, 23 Feb 2000 13:42:36 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA11699; Wed, 23 Feb 2000 13:42:35 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id NAA10213; Wed, 23 Feb 2000 13:42:22 -0800 (PST) From: Patrice Calhoun Message-Id: <200002232142.NAA10213@nasnfs.eng.sun.com> Date: Wed, 23 Feb 2000 13:43:54 -0800 To: "Chip Sharp" , , "David Mitton" Reply-To: Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk Content-Transfer-Encoding: 7bit >At 03:10 PM 2/23/00 -0500, David Mitton wrote: >>ummm... >> >>At 10:13 PM 2/23/00 -0800, you wrote: >>>Yes, please read through the megaco archives if you wish to know our >>>disagreement. >> >>that's only 35MB of text in my mail reader. But please do not attempt to >>explain here. Just direct us to the prime temporal location of the >discussion. > >Don't you keep 35 Mbytes in your In box in Eudora? ;-) > >The latest round of discussion can be found in a thread titled >"Basic Package and NAS" which occured between 10/6/99 and 10/18/99 > >The megaco archive search page at >http://standards.nortelnetworks.com/scripts/wa.exe?S1=megaco > >can be used to search for this. > > > >>>I agree with Matt that NASes work fine with current operation. The main >>>disagreement I believe is that i believe enhancements can be made to the >>>NAS package to allow other capabilities. >> >>You know, "package" is a real general term in english. I usually use UPS >>or FedEx. Can you explain in about 64 words or less what this means to >megaco? > >Megaco defines a base protocol for allowing a Media Gateway Controller to >control what are called "terminations" on Media Gateways. A "termination" >could be physical (e.g., DS0) or "ephemeral" (e.g., RTP endpoint). The >specific parameters, events and signals for a particular type of >termination are defined in "packages." A package defines the events that >can be detected on a termination (e.g., Dial tone), signals to be >transmitted on a termination (e.g., dtmf, dial tone, etc.) and parameters >that can be used to configure the termination (e.g., what codec to use on a >RTP termination). > >A NAS package would define a NAS termination and would define the events, >signals and configuration parameters that a MGC could use to control a NAS >(acting as a media gateway). Basically, the MGC would handle the call >control and then configure the NAS to accept the call. The NAS would then >do its normal PPP (or whatever) and RADIUS thing. > >The sticking point seems to be whether or not the protocol would allow the >MGC to send down various configuration parameters (e.g., modem type, AAA >server to use, L2TP LNS to connect to , etc.) based on the Calling/Called >number (or other call info). hmm... does the MGC "talk" to AAA? It sounds like it if it knows L2TP LNS information (or perhaps all of this is statically configured, ugh!). How would the MGC know the modem type, if the call wasn't answered? Or are we talking about something that gets sent in the ISDN control message (X.75, etc)? Lastly, as for AAA, it seems simpler to have the NAS talk to a AAA, and have that AAA proxy to the appropriate server. I understand that there may be MANY other configuration items involved, and I really should stop everything I am doing to learn MEGACO :). Seriously, the question I have is whether this is information that the MGC (and only the MGC has), or whether it is information that can (and does) get derived by the NAS. > >If something is done in this area, it should probably be done in close >cooperation with the megaco group. agreed. PatC From owner-nasreq@kull.rutgers.edu Wed Feb 23 20:04:51 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06127; Wed, 23 Feb 2000 20:04:50 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id TAA03851 for nasreq-outgoing; Wed, 23 Feb 2000 19:44:14 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id TAA03655 for ; Wed, 23 Feb 2000 19:44:12 -0500 (EST) Received: from chsharp-tecra ([171.68.157.148]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA11834; Wed, 23 Feb 2000 16:44:04 -0800 (PST) Message-Id: <4.2.2.20000223160717.00b52890@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Feb 2000 16:35:35 -0800 To: , , "David Mitton" From: Chip Sharp Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF In-Reply-To: <200002232142.NAA10213@nasnfs.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk At 01:43 PM 2/23/00 -0800, Patrice Calhoun wrote: > >At 03:10 PM 2/23/00 -0500, David Mitton wrote: > >>ummm... > >> > >>At 10:13 PM 2/23/00 -0800, you wrote: > >>>Yes, please read through the megaco archives if you wish to know our > >>>disagreement. > >> > >>that's only 35MB of text in my mail reader. But please do not attempt to > >>explain here. Just direct us to the prime temporal location of the > >discussion. > > > >Don't you keep 35 Mbytes in your In box in Eudora? ;-) > > > >The latest round of discussion can be found in a thread titled > >"Basic Package and NAS" which occured between 10/6/99 and 10/18/99 > > > >The megaco archive search page at > >http://standards.nortelnetworks.com/scripts/wa.exe?S1=megaco > > > >can be used to search for this. > > > > > > > >>>I agree with Matt that NASes work fine with current operation. The main > >>>disagreement I believe is that i believe enhancements can be made to the > >>>NAS package to allow other capabilities. > >> > >>You know, "package" is a real general term in english. I usually use UPS > >>or FedEx. Can you explain in about 64 words or less what this means to > >megaco? > > > >Megaco defines a base protocol for allowing a Media Gateway Controller to > >control what are called "terminations" on Media Gateways. A "termination" > >could be physical (e.g., DS0) or "ephemeral" (e.g., RTP endpoint). The > >specific parameters, events and signals for a particular type of > >termination are defined in "packages." A package defines the events that > >can be detected on a termination (e.g., Dial tone), signals to be > >transmitted on a termination (e.g., dtmf, dial tone, etc.) and parameters > >that can be used to configure the termination (e.g., what codec to use on a > >RTP termination). > > > >A NAS package would define a NAS termination and would define the events, > >signals and configuration parameters that a MGC could use to control a NAS > >(acting as a media gateway). Basically, the MGC would handle the call > >control and then configure the NAS to accept the call. The NAS would then > >do its normal PPP (or whatever) and RADIUS thing. > > > >The sticking point seems to be whether or not the protocol would allow the > >MGC to send down various configuration parameters (e.g., modem type, AAA > >server to use, L2TP LNS to connect to , etc.) based on the Calling/Called > >number (or other call info). > >hmm... does the MGC "talk" to AAA? It sounds like it if it knows L2TP LNS >information (or perhaps all of this is statically configured, ugh!). How >would the MGC know the modem type, if the call wasn't answered? Or are >we talking about something that gets sent in the ISDN control message (X.75, >etc)? Lastly, as for AAA, it seems simpler to have the NAS talk to a AAA, >and have that AAA proxy to the appropriate server. The only thing the MGC can key on is call information. Most of the time this would be Called and Calling Party Number. This operation happens before the call is answered, so there is no PPP (LCP or NCP). Sample applications would be a service provider that wants to support credit card verification and other applications on the same modem pool. Credit card verification tends to use V.22bis modem and it is too time-consuming to start at V.90 and negotiate down to V.22bis. Therefore, the provider would want to have a way to tell the NAS to start modulation at V.22bis instead of V.90. The provider could allocate a phone number to use for credit card verification. The NAS would key off the phone number to know what type of modulation to start with. A provider may also provide different phone numbers for customers to use for a virtual private dial network using L2TP. The provider may want to key on the phone number to determine which AAA server to use or which LNS to use for a call. If the NAS does this directly, it could receive the incoming call and then send a request to the RADIUS server containing the called/calling phone number. The RADIUS server would then key on the phone number and return parameters for the call. I won't call this AAA since it does not have anything to do with Authentication, Authorization or Accounting. It is basically a call-by-call configuration function. In either case (the NAS collecting pre-connect configuration info from a RADIUS server or from the MGC), during LCP/NCP the NAS would still do Authentication and Authorization as currently defined. >I understand that there may be MANY other configuration items involved, and >I really should stop everything I am doing to learn MEGACO :). Seriously, >the question I have is whether this is information that the MGC (and only the >MGC has), or whether it is information that can (and does) get derived by >the NAS. Any pre-connect configuration info that is used on a call-by-call basis could reside on the NAS, RADIUS server or delivered to the NAS by the MGC. I anticipate that initially the MGC will deliver the call to the NAS and the NAS will operate as it does today in terms of pre-connect configuration information. However, I would rather not make a general statement now that prohibits enhancements to be defined in the future that allows the MGC to deliver pre-connect configuration to the NAS. > > > >If something is done in this area, it should probably be done in close > >cooperation with the megaco group. > >agreed. > >PatC Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-nasreq@kull.rutgers.edu Thu Feb 24 04:41:33 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25062; Thu, 24 Feb 2000 04:41:33 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id EAA01601 for nasreq-outgoing; Thu, 24 Feb 2000 04:06:16 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id EAA01463 for ; Thu, 24 Feb 2000 04:06:15 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id AAA29582; Thu, 24 Feb 2000 00:59:53 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 24 Feb 2000 09:06:13 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id BAA09666; Thu, 24 Feb 2000 01:06:11 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000223175016.00b47da0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Feb 2000 17:52:10 -0800 To: "David Mitton" From: Matt Holdrege Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF Cc: nasreq@tdmx.rutgers.edu In-Reply-To: <4.2.2.20000223150354.00d07e30@ZBL6C008.corpeast.baynetwork s.com> References: <4.2.2.20000223220730.00bbbba0@dogwood.cisco.com> <4.2.2.20000222184405.00ae4650@porky> <"Your message with ID" <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk At 03:10 PM 2/23/00 -0500, David Mitton wrote: >ummm... > >At 10:13 PM 2/23/00 -0800, you wrote: >>Yes, please read through the megaco archives if you wish to know our >>disagreement. > >that's only 35MB of text in my mail reader. But please do not attempt to >explain here. Just direct us to the prime temporal location of the discussion. I wouldn't wish reading the MEGACO archive on my worst enemy. :) Please add some time in the NASREQ agenda for me to discuss this in Adelaide. I'm not going to try on email. No way. From owner-nasreq@kull.rutgers.edu Thu Feb 24 04:41:37 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25073; Thu, 24 Feb 2000 04:41:37 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id EAA03917 for nasreq-outgoing; Thu, 24 Feb 2000 04:10:39 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id EAA03812 for ; Thu, 24 Feb 2000 04:10:38 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id BAA29622; Thu, 24 Feb 2000 01:00:02 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 24 Feb 2000 09:06:22 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id BAA09739; Thu, 24 Feb 2000 01:06:20 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000223175851.00af17e0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Feb 2000 18:03:13 -0800 To: Chip Sharp From: Matt Holdrege Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF Cc: "David Mitton" , nasreq@tdmx.rutgers.edu In-Reply-To: <4.2.2.20000224003415.00c21b90@dogwood.cisco.com> References: <4.2.2.20000223150354.00d07e30@ZBL6C008.corpeast.baynetwork s.com> <4.2.2.20000223220730.00bbbba0@dogwood.cisco.com> <4.2.2.20000222184405.00ae4650@porky> <"Your message with ID" <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk At 12:54 AM 2/24/00 -0800, Chip Sharp wrote: >The sticking point seems to be whether or not the protocol would allow the >MGC to send down various configuration parameters (e.g., modem type, AAA >server to use, L2TP LNS to connect to , etc.) based on the Calling/Called >number (or other call info). Yes, one of my arguments is that a lot of work has gone into developing the NAS-Radius interface/protocol to make AAA items such as L2TP Radius attributes work well. By redirecting or encapsulating or translating those attributes into another protocol and having them pass through an intermediate device/function, we are stepping into dangerous territory for no good reason. >If something is done in this area, it should probably be done in close >cooperation with the megaco group. Ipso facto. What I've been pushing for in Megaco is that they work closely with NASREQ where the proper experts are. From owner-nasreq@kull.rutgers.edu Thu Feb 24 11:27:38 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04873; Thu, 24 Feb 2000 11:27:36 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id LAA27215 for nasreq-outgoing; Thu, 24 Feb 2000 11:09:14 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA27054 for ; Thu, 24 Feb 2000 11:09:12 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12O0pA-0009SR-00; Thu, 24 Feb 2000 08:09:08 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Holdrege Cc: nasreq@tdmx.rutgers.edu Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF References: <4.2.2.20000223220730.00bbbba0@dogwood.cisco.com> <4.2.2.20000222184405.00ae4650@porky> <"Your message with ID" <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> <4.2.2.20000223175016.00b47da0@porky> Message-Id: Date: Thu, 24 Feb 2000 08:09:08 -0800 Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Please add some time in the NASREQ agenda for me to discuss this in > Adelaide. i look forward. is there a differing view that should also be soliticted to speak? randy From owner-nasreq@kull.rutgers.edu Thu Feb 24 13:03:28 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07495; Thu, 24 Feb 2000 13:03:26 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id MAA11052 for nasreq-outgoing; Thu, 24 Feb 2000 12:44:24 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id MAA10935 for ; Thu, 24 Feb 2000 12:44:23 -0500 (EST) Received: from chsharp-tecra ([171.68.157.148]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id JAA05371; Thu, 24 Feb 2000 09:43:03 -0800 (PST) Message-Id: <4.2.2.20000224093556.00c42770@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 24 Feb 2000 09:36:39 -0800 To: Randy Bush , Matt Holdrege From: Chip Sharp Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF Cc: nasreq@tdmx.rutgers.edu In-Reply-To: References: <4.2.2.20000223220730.00bbbba0@dogwood.cisco.com> <4.2.2.20000222184405.00ae4650@porky> <"Your message with ID" <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> <4.2.2.20000223175016.00b47da0@porky> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk If I make it to Adelaide, I can help out with that. Chip At 08:09 AM 2/24/00 -0800, Randy Bush wrote: > > Please add some time in the NASREQ agenda for me to discuss this in > > Adelaide. > >i look forward. is there a differing view that should also be soliticted to >speak? > >randy Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-nasreq@kull.rutgers.edu Thu Feb 24 18:46:49 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12774; Thu, 24 Feb 2000 18:46:49 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id SAA05170 for nasreq-outgoing; Thu, 24 Feb 2000 18:31:54 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id SAA05015 for ; Thu, 24 Feb 2000 18:31:53 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id PAA23662; Thu, 24 Feb 2000 15:25:31 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 24 Feb 2000 23:31:51 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id PAA07461; Thu, 24 Feb 2000 15:31:50 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000224153221.00ba0de0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 24 Feb 2000 15:33:01 -0800 To: Chip Sharp From: Matt Holdrege Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF Cc: Randy Bush , nasreq@tdmx.rutgers.edu In-Reply-To: <4.2.2.20000224093556.00c42770@dogwood.cisco.com> References: <4.2.2.20000223220730.00bbbba0@dogwood.cisco.com> <4.2.2.20000222184405.00ae4650@porky> <"Your message with ID" <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> <4.2.2.20000223175016.00b47da0@porky> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk Chip and I know of a couple MEGACO folks who could fill in if Chip can't make it. At 09:36 AM 2/24/00 -0800, Chip Sharp wrote: >If I make it to Adelaide, I can help out with that. > >Chip > >At 08:09 AM 2/24/00 -0800, Randy Bush wrote: >> > Please add some time in the NASREQ agenda for me to discuss this in >> > Adelaide. >> >>i look forward. is there a differing view that should also be soliticted to >>speak? >> >>randy > >Support NetAid! http://www.netaid.org >-------------------------------------------------- >Chip Sharp Consulting Engineering >Cisco Systems Telco Bio-region >Reality - Love it or Leave it. >-------------------------------------------------- From owner-nasreq@kull.rutgers.edu Thu Feb 24 19:49:37 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13267; Thu, 24 Feb 2000 19:49:35 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id TAA07493 for nasreq-outgoing; Thu, 24 Feb 2000 19:35:54 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id TAA07347 for ; Thu, 24 Feb 2000 19:35:52 -0500 (EST) Received: from chsharp-tecra ([171.68.157.148]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA05456; Thu, 24 Feb 2000 16:34:28 -0800 (PST) Message-Id: <4.2.2.20000224162522.00b261e0@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 24 Feb 2000 16:31:07 -0800 To: Matt Holdrege From: Chip Sharp Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF Cc: Randy Bush , nasreq@tdmx.rutgers.edu In-Reply-To: <4.2.2.20000224153221.00ba0de0@porky> References: <4.2.2.20000224093556.00c42770@dogwood.cisco.com> <4.2.2.20000223220730.00bbbba0@dogwood.cisco.com> <4.2.2.20000222184405.00ae4650@porky> <"Your message with ID" <4.2.2.20000218105508.00b09cf0@dogwood.cisco.com> <4.2.2.20000223175016.00b47da0@porky> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk Yes, I'm sure. I'm planning to be there, but I'm kinda burned out on travel now. BTW, if the group is expecting a big oppositional debate on this issue might be disappointed to learn that I agree with just about everything Matt has said on the issue. :-) Chip At 03:33 PM 2/24/00 -0800, Matt Holdrege wrote: >Chip and I know of a couple MEGACO folks who could fill in if Chip can't >make it. > > >At 09:36 AM 2/24/00 -0800, Chip Sharp wrote: >>If I make it to Adelaide, I can help out with that. >> >>Chip >> >>At 08:09 AM 2/24/00 -0800, Randy Bush wrote: >>> > Please add some time in the NASREQ agenda for me to discuss this in >>> > Adelaide. >>> >>>i look forward. is there a differing view that should also be soliticted to >>>speak? >>> >>>randy >> >>Support NetAid! http://www.netaid.org >>-------------------------------------------------- >>Chip Sharp Consulting Engineering >>Cisco Systems Telco Bio-region >>Reality - Love it or Leave it. >>-------------------------------------------------- > Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-nasreq@kull.rutgers.edu Thu Feb 24 19:57:00 2000 Received: from kull.rutgers.edu (kull.rutgers.edu [128.6.21.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13317; Thu, 24 Feb 2000 19:56:59 -0500 (EST) Received: (from majordom@localhost) by kull.rutgers.edu (8.8.8+Sun/8.8.8) id TAA17674 for nasreq-outgoing; Thu, 24 Feb 2000 19:45:09 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by kull.rutgers.edu (8.8.8+Sun/8.8.8) with ESMTP id TAA17528 for ; Thu, 24 Feb 2000 19:45:08 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA18450; Thu, 24 Feb 2000 16:44:55 -0800 (PST) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.105.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id QAA25227; Thu, 24 Feb 2000 16:44:54 -0800 (PST) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA11919; Thu, 24 Feb 2000 16:44:51 -0800 Date: Thu, 24 Feb 2000 16:44:51 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: nasreq NAS Package for megaco/H.248 returned to IETF To: Matt Holdrege Cc: Chip Sharp , Randy Bush , nasreq@tdmx.rutgers.edu In-Reply-To: "Your message with ID" <4.2.2.20000224153221.00ba0de0@porky> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-nasreq@tdmx.rutgers.edu Precedence: bulk Oh, if you are looking for opinions, the IETF is normally a pretty easy place to find some :) PatC