From seamoby-admin@ietf.org Tue Oct 1 04:25:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02019 for ; Tue, 1 Oct 2002 04:25:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g918Qlv01424; Tue, 1 Oct 2002 04:26:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g918Miv01298 for ; Tue, 1 Oct 2002 04:22:44 -0400 Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01951 for ; Tue, 1 Oct 2002 04:20:35 -0400 (EDT) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g918MV932095 for ; Tue, 1 Oct 2002 11:22:31 +0300 Date: Tue, 1 Oct 2002 11:22:31 +0300 (EEST) From: Jukka MJ Manner To: seamoby@ietf.org Subject: Re: [Seamoby] I-D ACTION:draft-ietf-seamoby-mobility-terminology-00.txt In-Reply-To: <200209041155.HAA23228@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi all, since the list seems somewhat quiet at the moment, perhaps it would be a good time to discuss the terminology draft submitted a month ago. There has been no comments so far, but I doubt that people agree with all the definitions and the text in the draft...:) So, please, people, go through the draft and comment at least on the "TODOs" part before the TOC: would the items mentioned be a good/bad idea to add, what is still missing, what is badly phrased or shouldn't be in the draft in the first place, etc. ? Please bear in mind that the draft was (at least originally) meant for a broader scope that just Seamoby, all work related to "IP mobility". In addition to the items listed in the draft, the following definition has come up that should be included (in some form): Routing Proxy: A node that routes packets by overlays, eg. by tunneling, between communicating partners and without doing any non-routing related processing. The Home Agent and Foreign Agent are examples of routing proxies, in that they receive packets destined for the mobile node and tunnel them to the current address of the mobile node. We now have one month to discuss the draft and myself and Markku could try to get a new version to the Atlanta meeting where we could, hopefully, finalize the definitions. Waiting eagerly for your feedback, Jukka On Wed, 4 Sep 2002 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. > > Title : Mobility Related Terminology > Author(s) : J. Manner, M. Kojo > Filename : draft-ietf-seamoby-mobility-terminology-00.txt > Pages : 29 > Date : 2002-9-3 > > There is a need for common definitions of terminology in the work to > be done around IP mobility. This memo defines terms for mobility > related terminology. It is intended as a living document for use by > the Seamoby working group in Seamoby drafts and in WG discussions. > Other working groups dealing with mobility may also take advantage of > this terminology. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 1 04:26:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02065 for ; Tue, 1 Oct 2002 04:26:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g918SXh01515 for seamoby-archive@odin.ietf.org; Tue, 1 Oct 2002 04:28:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g918SXv01512 for ; Tue, 1 Oct 2002 04:28:33 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02058 for ; Tue, 1 Oct 2002 04:26:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g918Qlv01424; Tue, 1 Oct 2002 04:26:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g918Miv01298 for ; Tue, 1 Oct 2002 04:22:44 -0400 Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01951 for ; Tue, 1 Oct 2002 04:20:35 -0400 (EDT) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g918MV932095 for ; Tue, 1 Oct 2002 11:22:31 +0300 Date: Tue, 1 Oct 2002 11:22:31 +0300 (EEST) From: Jukka MJ Manner To: seamoby@ietf.org Subject: Re: [Seamoby] I-D ACTION:draft-ietf-seamoby-mobility-terminology-00.txt In-Reply-To: <200209041155.HAA23228@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi all, since the list seems somewhat quiet at the moment, perhaps it would be a good time to discuss the terminology draft submitted a month ago. There has been no comments so far, but I doubt that people agree with all the definitions and the text in the draft...:) So, please, people, go through the draft and comment at least on the "TODOs" part before the TOC: would the items mentioned be a good/bad idea to add, what is still missing, what is badly phrased or shouldn't be in the draft in the first place, etc. ? Please bear in mind that the draft was (at least originally) meant for a broader scope that just Seamoby, all work related to "IP mobility". In addition to the items listed in the draft, the following definition has come up that should be included (in some form): Routing Proxy: A node that routes packets by overlays, eg. by tunneling, between communicating partners and without doing any non-routing related processing. The Home Agent and Foreign Agent are examples of routing proxies, in that they receive packets destined for the mobile node and tunnel them to the current address of the mobile node. We now have one month to discuss the draft and myself and Markku could try to get a new version to the Atlanta meeting where we could, hopefully, finalize the definitions. Waiting eagerly for your feedback, Jukka On Wed, 4 Sep 2002 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. > > Title : Mobility Related Terminology > Author(s) : J. Manner, M. Kojo > Filename : draft-ietf-seamoby-mobility-terminology-00.txt > Pages : 29 > Date : 2002-9-3 > > There is a need for common definitions of terminology in the work to > be done around IP mobility. This memo defines terms for mobility > related terminology. It is intended as a living document for use by > the Seamoby working group in Seamoby drafts and in WG discussions. > Other working groups dealing with mobility may also take advantage of > this terminology. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From sip-admin@ietf.org Tue Oct 1 07:42:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09761 for ; Tue, 1 Oct 2002 07:42:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91BiLv23150 for ; Tue, 1 Oct 2002 07:44:21 -0400 Date: Tue, 01 Oct 2002 07:44:21 -0400 Message-ID: <20021001114421.2977.17294.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder To: seamoby-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, seamoby-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@. Thanks! Passwords for seamoby-archive@lists.ietf.org: List Password // URL ---- -------- seamoby@ietf.org Zzch https://www1.ietf.org/mailman/options/seamoby/seamoby-archive%40lists.ietf.org From seamoby-admin@ietf.org Tue Oct 1 07:44:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09830 for ; Tue, 1 Oct 2002 07:44:19 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Bg2v22562; Tue, 1 Oct 2002 07:42:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Bccv21529 for ; Tue, 1 Oct 2002 07:38:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09416; Tue, 1 Oct 2002 07:36:36 -0400 (EDT) Message-Id: <200210011136.HAA09416@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 01 Oct 2002 07:36:36 -0400 Subject: [Seamoby] I-D ACTION:draft-liebsch-dmha-framework-00.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Architecture and Protocol framework for Dormant Mode Host Alerting Author(s) : M. Liebsch, Y. Ohba, T. Zhang Filename : draft-liebsch-dmha-framework-00.txt Pages : 27 Date : 2002-9-30 This document discusses and describes an architecture and protocol framework for the design and specification of a generic IP based architecture and protocol for Dormant Mode Host Alerting, aka IP paging. It focuses on the location and operation related interworking of the different functional entities as required to allow for a flexible and scalable deployment of the protocol. Furthermore, protocol transport and security mechanisms are evaluated and proposed to meet respective requirements on a DMHA protocol. This document intends to be a comprehensive guideline for the design of a generic IP paging architecture and protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-liebsch-dmha-framework-00.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-liebsch-dmha-framework-00.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-liebsch-dmha-framework-00.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-30152033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-liebsch-dmha-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-liebsch-dmha-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-30152033.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 1 07:45:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09855 for ; Tue, 1 Oct 2002 07:45:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91Bknm23811 for seamoby-archive@odin.ietf.org; Tue, 1 Oct 2002 07:46:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Bknv23808 for ; Tue, 1 Oct 2002 07:46:49 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09849 for ; Tue, 1 Oct 2002 07:44:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Bg2v22562; Tue, 1 Oct 2002 07:42:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Bccv21529 for ; Tue, 1 Oct 2002 07:38:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09416; Tue, 1 Oct 2002 07:36:36 -0400 (EDT) Message-Id: <200210011136.HAA09416@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 01 Oct 2002 07:36:36 -0400 Subject: [Seamoby] I-D ACTION:draft-liebsch-dmha-framework-00.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Architecture and Protocol framework for Dormant Mode Host Alerting Author(s) : M. Liebsch, Y. Ohba, T. Zhang Filename : draft-liebsch-dmha-framework-00.txt Pages : 27 Date : 2002-9-30 This document discusses and describes an architecture and protocol framework for the design and specification of a generic IP based architecture and protocol for Dormant Mode Host Alerting, aka IP paging. It focuses on the location and operation related interworking of the different functional entities as required to allow for a flexible and scalable deployment of the protocol. Furthermore, protocol transport and security mechanisms are evaluated and proposed to meet respective requirements on a DMHA protocol. This document intends to be a comprehensive guideline for the design of a generic IP paging architecture and protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-liebsch-dmha-framework-00.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-liebsch-dmha-framework-00.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-liebsch-dmha-framework-00.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-30152033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-liebsch-dmha-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-liebsch-dmha-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-30152033.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Oct 1 10:12:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18755 for ; Tue, 1 Oct 2002 10:12:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91E3Qv29526; Tue, 1 Oct 2002 10:03:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91E2mv29486 for ; Tue, 1 Oct 2002 10:02:48 -0400 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17940 for ; Tue, 1 Oct 2002 10:00:48 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g91E26M22143; Tue, 1 Oct 2002 09:02:06 -0500 (CDT) Message-ID: <3D99AB14.7030902@alcatel.com> Date: Tue, 01 Oct 2002 09:03:00 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner CC: seamoby@ietf.org Subject: Re: [Seamoby] I-D ACTION:draft-ietf-seamoby-mobility-terminology-00.txt References: Content-Type: multipart/alternative; boundary="------------040309020401000303050801" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------040309020401000303050801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Jukka, If you check out the draft at: http://www.ietf.org/internet-drafts/draft-sarikaya-mobileip-lmmframework-01.txt there is a slightly different definition of routing proxy that I made. This definition has some advantages over the one you mention so I suggest adopting it with or without reference to the draft (I do not really care). Regards, Jukka MJ Manner wrote: > Hi all, > > since the list seems somewhat quiet at the moment, perhaps it >would be a good time to discuss the terminology draft submitted a month >ago. There has been no comments so far, but I doubt that people agree with >all the definitions and the text in the draft...:) > > So, please, people, go through the draft and comment at least on >the "TODOs" part before the TOC: would the items mentioned be a good/bad >idea to add, what is still missing, what is badly phrased or shouldn't be >in the draft in the first place, etc. ? Please bear in mind that the draft >was (at least originally) meant for a broader scope that just Seamoby, >all work related to "IP mobility". > > In addition to the items listed in the draft, the following >definition has come up that should be included (in some form): > >Routing Proxy: >A node that routes packets by overlays, eg. by tunneling, between >communicating partners and without doing any non-routing related >processing. The Home Agent and Foreign Agent are examples of routing >proxies, in that they receive packets destined for the mobile node and >tunnel them to the current address of the mobile node. > > We now have one month to discuss the draft and myself and Markku >could try to get a new version to the Atlanta meeting where we could, >hopefully, finalize the definitions. > > Waiting eagerly for your feedback, > > Jukka > >On Wed, 4 Sep 2002 Internet-Drafts@ietf.org wrote: > > > >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. >> >> Title : Mobility Related Terminology >> Author(s) : J. Manner, M. Kojo >> Filename : draft-ietf-seamoby-mobility-terminology-00.txt >> Pages : 29 >> Date : 2002-9-3 >> >>There is a need for common definitions of terminology in the work to >>be done around IP mobility. This memo defines terms for mobility >>related terminology. It is intended as a living document for use by >>the Seamoby working group in Seamoby drafts and in WG discussions. >>Other working groups dealing with mobility may also take advantage of >>this terminology. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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. >> >> >> > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > -- Behcet --------------040309020401000303050801 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jukka,
  If you check out the draft at:
http://www.ietf.org/internet-drafts/draft-sarikaya-mobileip-lmmframework-01.txt
there is a slightly different definition of routing proxy that I made.
This definition has some advantages over the one you mention so I suggest adopting it with or without reference to the draft (I do not really care).

Regards,

Jukka MJ Manner wrote:
	Hi all,

	since the list seems somewhat quiet at the moment, perhaps it
would be a good time to discuss the terminology draft submitted a month
ago. There has been no comments so far, but I doubt that people agree with
all the definitions and the text in the draft...:)

	So, please, people, go through the draft and comment at least on 
the "TODOs" part before the TOC: would the items mentioned be a good/bad 
idea to add, what is still missing, what is badly phrased or shouldn't be 
in the draft in the first place, etc. ? Please bear in mind that the draft 
was (at least originally) meant for a broader scope that just Seamoby, 
all work related to "IP mobility".

	In addition to the items listed in the draft, the following 
definition has come up that should be included (in some form):

Routing Proxy:
A node that routes packets by overlays, eg. by tunneling, between
communicating partners and without doing any non-routing related
processing. The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node and
tunnel them to the current address of the mobile node.

	We now have one month to discuss the draft and myself and Markku
could try to get a new version to the Atlanta meeting where we could,
hopefully, finalize the definitions.

	Waiting eagerly for your feedback,

	Jukka

On Wed, 4 Sep 2002 Internet-Drafts@ietf.org wrote:

  
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF.

	Title		: Mobility Related Terminology
	Author(s)	: J. Manner, M. Kojo
	Filename	: draft-ietf-seamoby-mobility-terminology-00.txt
	Pages		: 29
	Date		: 2002-9-3
	
There is a need for common definitions of terminology in the work to
be done around IP mobility. This memo defines terms for mobility
related terminology. It is intended as a living document for use by
the Seamoby working group in Seamoby drafts and in WG discussions.
Other working groups dealing with mobility may also take advantage of
this terminology.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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.

    

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby
  

-- 
Behcet

--------------040309020401000303050801-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 1 10:14:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18810 for ; Tue, 1 Oct 2002 10:14:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91EFVD01882 for seamoby-archive@odin.ietf.org; Tue, 1 Oct 2002 10:15:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EFVv01879 for ; Tue, 1 Oct 2002 10:15:31 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18781 for ; Tue, 1 Oct 2002 10:13:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91E3Qv29526; Tue, 1 Oct 2002 10:03:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91E2mv29486 for ; Tue, 1 Oct 2002 10:02:48 -0400 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17940 for ; Tue, 1 Oct 2002 10:00:48 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g91E26M22143; Tue, 1 Oct 2002 09:02:06 -0500 (CDT) Message-ID: <3D99AB14.7030902@alcatel.com> Date: Tue, 01 Oct 2002 09:03:00 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner CC: seamoby@ietf.org Subject: Re: [Seamoby] I-D ACTION:draft-ietf-seamoby-mobility-terminology-00.txt References: Content-Type: multipart/alternative; boundary="------------040309020401000303050801" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------040309020401000303050801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Jukka, If you check out the draft at: http://www.ietf.org/internet-drafts/draft-sarikaya-mobileip-lmmframework-01.txt there is a slightly different definition of routing proxy that I made. This definition has some advantages over the one you mention so I suggest adopting it with or without reference to the draft (I do not really care). Regards, Jukka MJ Manner wrote: > Hi all, > > since the list seems somewhat quiet at the moment, perhaps it >would be a good time to discuss the terminology draft submitted a month >ago. There has been no comments so far, but I doubt that people agree with >all the definitions and the text in the draft...:) > > So, please, people, go through the draft and comment at least on >the "TODOs" part before the TOC: would the items mentioned be a good/bad >idea to add, what is still missing, what is badly phrased or shouldn't be >in the draft in the first place, etc. ? Please bear in mind that the draft >was (at least originally) meant for a broader scope that just Seamoby, >all work related to "IP mobility". > > In addition to the items listed in the draft, the following >definition has come up that should be included (in some form): > >Routing Proxy: >A node that routes packets by overlays, eg. by tunneling, between >communicating partners and without doing any non-routing related >processing. The Home Agent and Foreign Agent are examples of routing >proxies, in that they receive packets destined for the mobile node and >tunnel them to the current address of the mobile node. > > We now have one month to discuss the draft and myself and Markku >could try to get a new version to the Atlanta meeting where we could, >hopefully, finalize the definitions. > > Waiting eagerly for your feedback, > > Jukka > >On Wed, 4 Sep 2002 Internet-Drafts@ietf.org wrote: > > > >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. >> >> Title : Mobility Related Terminology >> Author(s) : J. Manner, M. Kojo >> Filename : draft-ietf-seamoby-mobility-terminology-00.txt >> Pages : 29 >> Date : 2002-9-3 >> >>There is a need for common definitions of terminology in the work to >>be done around IP mobility. This memo defines terms for mobility >>related terminology. It is intended as a living document for use by >>the Seamoby working group in Seamoby drafts and in WG discussions. >>Other working groups dealing with mobility may also take advantage of >>this terminology. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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. >> >> >> > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > -- Behcet --------------040309020401000303050801 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jukka,
  If you check out the draft at:
http://www.ietf.org/internet-drafts/draft-sarikaya-mobileip-lmmframework-01.txt
there is a slightly different definition of routing proxy that I made.
This definition has some advantages over the one you mention so I suggest adopting it with or without reference to the draft (I do not really care).

Regards,

Jukka MJ Manner wrote:
	Hi all,

	since the list seems somewhat quiet at the moment, perhaps it
would be a good time to discuss the terminology draft submitted a month
ago. There has been no comments so far, but I doubt that people agree with
all the definitions and the text in the draft...:)

	So, please, people, go through the draft and comment at least on 
the "TODOs" part before the TOC: would the items mentioned be a good/bad 
idea to add, what is still missing, what is badly phrased or shouldn't be 
in the draft in the first place, etc. ? Please bear in mind that the draft 
was (at least originally) meant for a broader scope that just Seamoby, 
all work related to "IP mobility".

	In addition to the items listed in the draft, the following 
definition has come up that should be included (in some form):

Routing Proxy:
A node that routes packets by overlays, eg. by tunneling, between
communicating partners and without doing any non-routing related
processing. The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node and
tunnel them to the current address of the mobile node.

	We now have one month to discuss the draft and myself and Markku
could try to get a new version to the Atlanta meeting where we could,
hopefully, finalize the definitions.

	Waiting eagerly for your feedback,

	Jukka

On Wed, 4 Sep 2002 Internet-Drafts@ietf.org wrote:

  
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF.

	Title		: Mobility Related Terminology
	Author(s)	: J. Manner, M. Kojo
	Filename	: draft-ietf-seamoby-mobility-terminology-00.txt
	Pages		: 29
	Date		: 2002-9-3
	
There is a need for common definitions of terminology in the work to
be done around IP mobility. This memo defines terms for mobility
related terminology. It is intended as a living document for use by
the Seamoby working group in Seamoby drafts and in WG discussions.
Other working groups dealing with mobility may also take advantage of
this terminology.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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-seamoby-mobility-terminology-00.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.

    

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby
  

-- 
Behcet

--------------040309020401000303050801-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Oct 1 10:19:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19019 for ; Tue, 1 Oct 2002 10:19:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EKBv02095; Tue, 1 Oct 2002 10:20:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EH9v01931 for ; Tue, 1 Oct 2002 10:17:09 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18861 for ; Tue, 1 Oct 2002 10:15:08 -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 g91EGqOW024115; Tue, 1 Oct 2002 16:16:52 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 1 Oct 2002 16:16:52 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0AAB@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Phil Neumiller'" , dirk.trossen@nokia.com, govind.krishnamurthi@nokia.com, hemant.chaskar@nokia.com, kempf@docomolabs-usa.com, mankin@psg.com, seamoby@ietf.org Subject: RE: [Seamoby] IESG review of car discovery issues, AD review, and ... Date: Tue, 1 Oct 2002 16:16:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , > 2). Why is there no mention of RFC 1256 which seems to be > a perfectly > valid starting point for this work. => 1256 and 2461 are both very valid starting points. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 1 10:20:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19089 for ; Tue, 1 Oct 2002 10:20:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91EMED02233 for seamoby-archive@odin.ietf.org; Tue, 1 Oct 2002 10:22:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EMEv02230 for ; Tue, 1 Oct 2002 10:22:14 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19078 for ; Tue, 1 Oct 2002 10:20:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EKBv02095; Tue, 1 Oct 2002 10:20:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EH9v01931 for ; Tue, 1 Oct 2002 10:17:09 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18861 for ; Tue, 1 Oct 2002 10:15:08 -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 g91EGqOW024115; Tue, 1 Oct 2002 16:16:52 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 1 Oct 2002 16:16:52 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0AAB@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Phil Neumiller'" , dirk.trossen@nokia.com, govind.krishnamurthi@nokia.com, hemant.chaskar@nokia.com, kempf@docomolabs-usa.com, mankin@psg.com, seamoby@ietf.org Subject: RE: [Seamoby] IESG review of car discovery issues, AD review, and ... Date: Tue, 1 Oct 2002 16:16:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , > 2). Why is there no mention of RFC 1256 which seems to be > a perfectly > valid starting point for this work. => 1256 and 2461 are both very valid starting points. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Oct 1 10:29:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19364 for ; Tue, 1 Oct 2002 10:29:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91ER5v02478; Tue, 1 Oct 2002 10:27:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EQKv02432 for ; Tue, 1 Oct 2002 10:26:20 -0400 Received: from mailman.xlresponder.com (mailman.xlresponder.com [217.18.64.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19264 for ; Tue, 1 Oct 2002 10:24:19 -0400 (EDT) Received: (qmail 26201 invoked by uid 10001); 30 Sep 2002 20:26:31 -0000 Date: 30 Sep 2002 20:26:31 -0000 Message-ID: <20020930202631.26200.qmail@mailman.xlresponder.com> To: seamoby@ietf.org From: jem486749@yahoo.com Content-Type: text/plain; charset=us-ascii X-Header: Reply-To: jem486749@yahoo.com X-Loop-Prevention: 1 Size DOES Matter!! You're girlfriend tells you that she doesn't care about your size(penis)? Scientific studies show that there is a significant relationship between the intensiveness of women's orgasm and the penis size. Ged a bigger penis with this doctor-approved natural penis enlargement pill. If you don't see any effect, you'll get 100% money back. Why wait? The result is 100% guaranteed. Find out more at http://www.albionmedical.com/pt=truedreammaker2/ Subject: [Seamoby] Want a Big Penis? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Click on the link below to remove yourself http://www.xlresponder.com/cgi-bin/varpro/r.cgi?id=dreammaker5&a=seamoby@ietf.org AOL Users Remove Me _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 1 10:30:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19467 for ; Tue, 1 Oct 2002 10:30:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g91EVcI02747 for seamoby-archive@odin.ietf.org; Tue, 1 Oct 2002 10:31:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EVcv02744 for ; Tue, 1 Oct 2002 10:31:38 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19401 for ; Tue, 1 Oct 2002 10:29:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91ER5v02478; Tue, 1 Oct 2002 10:27:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91EQKv02432 for ; Tue, 1 Oct 2002 10:26:20 -0400 Received: from mailman.xlresponder.com (mailman.xlresponder.com [217.18.64.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19264 for ; Tue, 1 Oct 2002 10:24:19 -0400 (EDT) Received: (qmail 26201 invoked by uid 10001); 30 Sep 2002 20:26:31 -0000 Date: 30 Sep 2002 20:26:31 -0000 Message-ID: <20020930202631.26200.qmail@mailman.xlresponder.com> To: seamoby@ietf.org From: jem486749@yahoo.com Content-Type: text/plain; charset=us-ascii X-Header: Reply-To: jem486749@yahoo.com X-Loop-Prevention: 1 Size DOES Matter!! You're girlfriend tells you that she doesn't care about your size(penis)? Scientific studies show that there is a significant relationship between the intensiveness of women's orgasm and the penis size. Ged a bigger penis with this doctor-approved natural penis enlargement pill. If you don't see any effect, you'll get 100% money back. Why wait? The result is 100% guaranteed. Find out more at http://www.albionmedical.com/pt=truedreammaker2/ Subject: [Seamoby] Want a Big Penis? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Click on the link below to remove yourself http://www.xlresponder.com/cgi-bin/varpro/r.cgi?id=dreammaker5&a=seamoby@ietf.org AOL Users Remove Me _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 4 07:10:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28316 for ; Fri, 4 Oct 2002 07:10:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94BBLv32576; Fri, 4 Oct 2002 07:11:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94B9sv32479 for ; Fri, 4 Oct 2002 07:09:54 -0400 Received: from aibo.runbox.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28241 for ; Fri, 4 Oct 2002 07:07:51 -0400 (EDT) Received: from [10.9.9.9] (helo=fetch.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17xQLA-0002x5-00 for seamoby@ietf.org; Fri, 04 Oct 2002 13:09:52 +0200 Received: from [80.96.62.203] (helo=opula) (Authenticated Sender=opula) by fetch.runbox.com with asmtp (Exim 3.35 #1) id 17xQL5-0000v9-00 for seamoby@ietf.org; Fri, 04 Oct 2002 13:09:47 +0200 From: "ileana Popescu" To: seamoby@ietf.org X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Reply-To: ipopescu_i@yahoo.com Date: Fri, 4 Oct 2002 01:10:39 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: Subject: [Seamoby] Job Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Dear Sir, I am writing to explore employment opportunities within your organization. I am convinced that in addition to contributing directly as a member of your staff, my aspirations for continued professional development will contribute to your company’s cultural environment and make me a valuable part of the organization. I graduated with a diploma in Chemical Engineering (approximately equivalent to an MS) from Polytechnic Institute of Bucharest in 1991. My score of 9/10 on the final exam is considered outstanding. Since graduation my professional activities have allowed me to participate in numerous research symposia. With more than a decade of professional experience, I now steady ready to use my talents for your company. Currently, I’m employed by S.C. OLTCHIM S.A Râmnicu Vâlcea (see www.oltchim.ro) and during my four years with this company I have developed good communication and organization skills, and have increased and refined my technical knowledge. I am now interested in moving to a dynamic organization where I can continue to grow professionally. Please contact me if an interview is possible. With sincerely, Ms.Ileana POPESCU Curriculum Vitae Ileana POPESCU OBJECTIVES I`m looking for a long term employment in wich I can use my knowledge and training. PERSONAL DATA Date of birth and place: March 4 th, 1968, CARACAL- Romania EDUCATION 1986-1991: Polytechnic Institute of Bucharest- Industrial Chemistry Faculty Graduated with diploma as Chemistry Engineer 1982-1986: "IONITA ASSAN" National High-School CARACAL, Graduated with diploma in mathematics and physics. COURSES AND SPECIALIZATIONS 1997: Course of Computer operator graduated with diploma in computer operator PROFESIONAL EXPERIENCE 1997 - present day: employed of the company S.C. OLTCHIM S.A. Ramnicu Valcea 1999 - 2001: research chemistry engineer in pesticides formulation research chemistry engineer in analitic chemistry (GC/HPLC) at Formulation Research Laboratory from the company: S.C. OLTCHIM S.A. Ramnicu Valcea; 1997 -1999: technology chemistry engineer in the Propenoxide - Propyleneglycol Plant from the company S.C. OLTCHIM S.A. Ramnicu Valcea; 1993 - 1997: chemistry engineer to Environment Radioactivity Laboratory; 1991 - 1992: teacher to "IONITA ASSAN" National High-School LANGUAGES English- spoken, read, written French - spoken, read, written - satisfactory level PC KNOWLEDGES MS Office (Word, Excel) PERSONALITY Intelligent, calm and well organized,good memory, research work oriented, hard working, adaptable, team oriented, good communication skills, flexibility. Contact me to: Street Carpati, No75 Caracal - ROMANIA Mobile phone: +40 745791130,E-mail: ipopescu_i@yahoo.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 4 07:10:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28337 for ; Fri, 4 Oct 2002 07:10:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94BCL632689 for seamoby-archive@odin.ietf.org; Fri, 4 Oct 2002 07:12:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94BCLv32685 for ; Fri, 4 Oct 2002 07:12:21 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28333 for ; Fri, 4 Oct 2002 07:10:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94BBLv32576; Fri, 4 Oct 2002 07:11:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94B9sv32479 for ; Fri, 4 Oct 2002 07:09:54 -0400 Received: from aibo.runbox.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28241 for ; Fri, 4 Oct 2002 07:07:51 -0400 (EDT) Received: from [10.9.9.9] (helo=fetch.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17xQLA-0002x5-00 for seamoby@ietf.org; Fri, 04 Oct 2002 13:09:52 +0200 Received: from [80.96.62.203] (helo=opula) (Authenticated Sender=opula) by fetch.runbox.com with asmtp (Exim 3.35 #1) id 17xQL5-0000v9-00 for seamoby@ietf.org; Fri, 04 Oct 2002 13:09:47 +0200 From: "ileana Popescu" To: seamoby@ietf.org X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Reply-To: ipopescu_i@yahoo.com Date: Fri, 4 Oct 2002 01:10:39 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: Subject: [Seamoby] Job Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Dear Sir, I am writing to explore employment opportunities within your organization. I am convinced that in addition to contributing directly as a member of your staff, my aspirations for continued professional development will contribute to your company’s cultural environment and make me a valuable part of the organization. I graduated with a diploma in Chemical Engineering (approximately equivalent to an MS) from Polytechnic Institute of Bucharest in 1991. My score of 9/10 on the final exam is considered outstanding. Since graduation my professional activities have allowed me to participate in numerous research symposia. With more than a decade of professional experience, I now steady ready to use my talents for your company. Currently, I’m employed by S.C. OLTCHIM S.A Râmnicu Vâlcea (see www.oltchim.ro) and during my four years with this company I have developed good communication and organization skills, and have increased and refined my technical knowledge. I am now interested in moving to a dynamic organization where I can continue to grow professionally. Please contact me if an interview is possible. With sincerely, Ms.Ileana POPESCU Curriculum Vitae Ileana POPESCU OBJECTIVES I`m looking for a long term employment in wich I can use my knowledge and training. PERSONAL DATA Date of birth and place: March 4 th, 1968, CARACAL- Romania EDUCATION 1986-1991: Polytechnic Institute of Bucharest- Industrial Chemistry Faculty Graduated with diploma as Chemistry Engineer 1982-1986: "IONITA ASSAN" National High-School CARACAL, Graduated with diploma in mathematics and physics. COURSES AND SPECIALIZATIONS 1997: Course of Computer operator graduated with diploma in computer operator PROFESIONAL EXPERIENCE 1997 - present day: employed of the company S.C. OLTCHIM S.A. Ramnicu Valcea 1999 - 2001: research chemistry engineer in pesticides formulation research chemistry engineer in analitic chemistry (GC/HPLC) at Formulation Research Laboratory from the company: S.C. OLTCHIM S.A. Ramnicu Valcea; 1997 -1999: technology chemistry engineer in the Propenoxide - Propyleneglycol Plant from the company S.C. OLTCHIM S.A. Ramnicu Valcea; 1993 - 1997: chemistry engineer to Environment Radioactivity Laboratory; 1991 - 1992: teacher to "IONITA ASSAN" National High-School LANGUAGES English- spoken, read, written French - spoken, read, written - satisfactory level PC KNOWLEDGES MS Office (Word, Excel) PERSONALITY Intelligent, calm and well organized,good memory, research work oriented, hard working, adaptable, team oriented, good communication skills, flexibility. Contact me to: Street Carpati, No75 Caracal - ROMANIA Mobile phone: +40 745791130,E-mail: ipopescu_i@yahoo.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 4 10:47:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06312 for ; Fri, 4 Oct 2002 10:47:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94EmUv11847; Fri, 4 Oct 2002 10:48:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94Ei2v11632 for ; Fri, 4 Oct 2002 10:44:02 -0400 Received: from zcars04e.ca.nortel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06060 for ; Fri, 4 Oct 2002 10:41:58 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g94EhTQ24978; Fri, 4 Oct 2002 10:43:30 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Oct 2002 10:43:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05350BB3@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 10:43:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BB4.689F4970" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C26BB4.689F4970 Content-Type: text/plain; charset="iso-8859-1" My comment is past due, so it is immediately ignorable, but worth stating if only for future reference.... When I first read through Madjid's proposed change my reaction was simply, and honestly, I did not really care. Manufacturers and network engineers have been known to ignore IETF recommendations in the past, so changing SHOULD to MAY did not seem to have much impact. However, in considering the change a second time (in the process of updating the draft), I sensed a subtle problem in the argument; a problem that has been discussed in the past in this group. Madjid, if I have misinterpreted your reasoning, please correct me. The CT requirements draft is NOT, as far as I know, a requirements document for the deployment of a system that supports CT. Clearly, a deployment of CT capabilities would be at the discretion of all the entities involved in actually building the network - the network operator, the network engineer, and even as Madjid points out, the equipment vendor. It would be reasonable to try and anticipate those CT features that an operator might want to be optional, BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT. The CT requirements draft IS a requirements draft for the CT protocol. It is intended to provide a template for eventual protocol draft submissions. Ideally, out of these submissions, only one proposal will be selected. A MAY in the CT requirements draft essentially states that a protocol proposal need not consider supporting this feature. A MAY in the CT requirements draft does NOT mean that the feature should be one that can be optionally enabled or disabled by someone implementing or deploying the CT solution. A MAY clearly indicates that protocol proposals can completely ignore the requirement, and if one of these protocols is selected by the working group, the feature will likely never be available to the vendor, the network engineer or the operator. The proper way to specify requirements that must be supported by the CT protocol, but must also must be optional for implementation is to state that in a second requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented with a second requirement that states that 4.6 MUST be an optional feature. In identifying this subtlety, I wonder how many of the requirements in the CT draft are actually system requirements and not protocol requirements. I am, at this point, somewhat hesitant to look at this point. However, a CT protocol that does not support of feature means that the feature will never be available to anyone. Gary Kenward > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: September 24, 2002 12:19 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements > Ends Wed. > > > Reading from 2119 > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course > > MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item > because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the > same item. > ...... > > > It means you need to fully understand the implication of not > supporting > a SHOULD item, before you exclude it. On the other hand if it > is something > that may be useful in some cases, a may is more appropriate. > > Looking at 4.6, I would say one-to-many context transfer is not > an item that its "not use" needs to be investigated, but its "use" > needs careful considerations. > Example: > If you are dealing with dynamic context that is affected by > flow of data > at a specific AR (header compression, or measurement based > QoS context) > sending the context through a whole bunch of ARs that may not even see > the data causes serious synchronization issues for such context. > > Based on this counter-example: > I say this requirement should be changed to "may" unless it > is stated that > SHOULD only applies to the context whose value is not > affected by data flow. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, September 23, 2002 11:24 AM > To: seamoby@ietf.org > Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed. > > > A reminder: last call for the CT requirements document > (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept > 25. So far, we have > not received any comments. If you have any comments, please > send them to the > list by that date. > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C26BB4.689F4970 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

My comment is past due, so it is immediately ignorable, but worth stating
if only for future reference....

When I first read through Madjid's proposed change my reaction was simply,
and honestly, I did not really care. Manufacturers and network engineers
have been known to ignore IETF recommendations in the past, so changing
SHOULD to MAY did not seem to have much impact.

However, in considering the change a second time (in the process of updating
the draft), I sensed a subtle problem in the argument; a problem that has
been discussed in the past in this group. Madjid, if I have misinterpreted
your reasoning, please correct me.

The CT requirements draft is NOT, as far as I know, a requirements document
for the deployment of a system that supports CT. Clearly, a deployment of CT
capabilities would be at the discretion of all the entities involved in actually
building the network - the network operator, the network engineer, and even as
Madjid points out, the equipment vendor. It would be reasonable to try and
anticipate those CT features that an operator might want to be optional,
BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT.

The CT requirements draft IS a requirements draft for the CT protocol. It is
intended to provide a template for eventual protocol draft submissions. Ideally,
out of these submissions, only one proposal will be selected. A MAY in the CT
requirements draft essentially states that a protocol proposal need not consider
supporting this feature. A MAY in the CT requirements draft does NOT mean that
the feature should be one that can be optionally enabled or disabled by someone
implementing or deploying the CT solution. A MAY clearly indicates that protocol
proposals can completely ignore the requirement, and if one of these protocols
is selected by the working group, the feature will likely never be available to
the vendor, the network engineer or the operator.

The proper way to specify requirements that must be supported by the CT protocol,
but must also must be optional for implementation is to state that in a second
requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented
with a second requirement that states that 4.6 MUST be an optional feature.

In identifying this subtlety, I wonder how many of the requirements in the CT
draft are actually system requirements and not protocol requirements. I am,
at this point, somewhat hesitant to look at this point. However, a CT protocol
that does not support of feature means that the feature will never be available
to anyone.

Gary Kenward

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: September 24, 2002 12:19
> To: 'James Kempf'; seamoby@ietf.org
> Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements
> Ends Wed.
>
>
> Reading from 2119
>
>    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course
>
>    MAY   This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item
> because a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the
> same item.
>    ......
>   
>
> It means you need to fully understand the implication of not
> supporting
> a SHOULD item, before you exclude it. On the other hand if it
> is something
> that may be useful in some cases, a may is more appropriate.
>
> Looking at 4.6, I would say one-to-many context transfer is not
> an item that its "not use" needs to be investigated, but its "use"
> needs careful considerations.
> Example:
> If you are dealing with dynamic context that is affected by
> flow of data
> at a specific AR (header compression, or measurement based
> QoS context)
> sending the context through a whole bunch of ARs that may not even see
> the data causes serious synchronization issues for such context.
>
> Based on this counter-example:
> I say this requirement should be changed to "may" unless it
> is stated that
> SHOULD only applies to the context whose value is not
> affected by data flow.
>
> Madjid
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Monday, September 23, 2002 11:24 AM
> To: seamoby@ietf.org
> Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed.
>
>
> A reminder: last call for the CT requirements document
> (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept
> 25. So far, we have
> not received any comments. If you have any comments, please
> send them to the
> list by that date.
>
>             jak
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C26BB4.689F4970-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 4 10:48:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06345 for ; Fri, 4 Oct 2002 10:48:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94EnYV11914 for seamoby-archive@odin.ietf.org; Fri, 4 Oct 2002 10:49:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94EnYv11911 for ; Fri, 4 Oct 2002 10:49:34 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06326 for ; Fri, 4 Oct 2002 10:47:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94EmUv11847; Fri, 4 Oct 2002 10:48:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94Ei2v11632 for ; Fri, 4 Oct 2002 10:44:02 -0400 Received: from zcars04e.ca.nortel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06060 for ; Fri, 4 Oct 2002 10:41:58 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g94EhTQ24978; Fri, 4 Oct 2002 10:43:30 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Oct 2002 10:43:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05350BB3@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 10:43:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BB4.689F4970" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C26BB4.689F4970 Content-Type: text/plain; charset="iso-8859-1" My comment is past due, so it is immediately ignorable, but worth stating if only for future reference.... When I first read through Madjid's proposed change my reaction was simply, and honestly, I did not really care. Manufacturers and network engineers have been known to ignore IETF recommendations in the past, so changing SHOULD to MAY did not seem to have much impact. However, in considering the change a second time (in the process of updating the draft), I sensed a subtle problem in the argument; a problem that has been discussed in the past in this group. Madjid, if I have misinterpreted your reasoning, please correct me. The CT requirements draft is NOT, as far as I know, a requirements document for the deployment of a system that supports CT. Clearly, a deployment of CT capabilities would be at the discretion of all the entities involved in actually building the network - the network operator, the network engineer, and even as Madjid points out, the equipment vendor. It would be reasonable to try and anticipate those CT features that an operator might want to be optional, BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT. The CT requirements draft IS a requirements draft for the CT protocol. It is intended to provide a template for eventual protocol draft submissions. Ideally, out of these submissions, only one proposal will be selected. A MAY in the CT requirements draft essentially states that a protocol proposal need not consider supporting this feature. A MAY in the CT requirements draft does NOT mean that the feature should be one that can be optionally enabled or disabled by someone implementing or deploying the CT solution. A MAY clearly indicates that protocol proposals can completely ignore the requirement, and if one of these protocols is selected by the working group, the feature will likely never be available to the vendor, the network engineer or the operator. The proper way to specify requirements that must be supported by the CT protocol, but must also must be optional for implementation is to state that in a second requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented with a second requirement that states that 4.6 MUST be an optional feature. In identifying this subtlety, I wonder how many of the requirements in the CT draft are actually system requirements and not protocol requirements. I am, at this point, somewhat hesitant to look at this point. However, a CT protocol that does not support of feature means that the feature will never be available to anyone. Gary Kenward > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: September 24, 2002 12:19 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements > Ends Wed. > > > Reading from 2119 > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course > > MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item > because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the > same item. > ...... > > > It means you need to fully understand the implication of not > supporting > a SHOULD item, before you exclude it. On the other hand if it > is something > that may be useful in some cases, a may is more appropriate. > > Looking at 4.6, I would say one-to-many context transfer is not > an item that its "not use" needs to be investigated, but its "use" > needs careful considerations. > Example: > If you are dealing with dynamic context that is affected by > flow of data > at a specific AR (header compression, or measurement based > QoS context) > sending the context through a whole bunch of ARs that may not even see > the data causes serious synchronization issues for such context. > > Based on this counter-example: > I say this requirement should be changed to "may" unless it > is stated that > SHOULD only applies to the context whose value is not > affected by data flow. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, September 23, 2002 11:24 AM > To: seamoby@ietf.org > Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed. > > > A reminder: last call for the CT requirements document > (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept > 25. So far, we have > not received any comments. If you have any comments, please > send them to the > list by that date. > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C26BB4.689F4970 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

My comment is past due, so it is immediately ignorable, but worth stating
if only for future reference....

When I first read through Madjid's proposed change my reaction was simply,
and honestly, I did not really care. Manufacturers and network engineers
have been known to ignore IETF recommendations in the past, so changing
SHOULD to MAY did not seem to have much impact.

However, in considering the change a second time (in the process of updating
the draft), I sensed a subtle problem in the argument; a problem that has
been discussed in the past in this group. Madjid, if I have misinterpreted
your reasoning, please correct me.

The CT requirements draft is NOT, as far as I know, a requirements document
for the deployment of a system that supports CT. Clearly, a deployment of CT
capabilities would be at the discretion of all the entities involved in actually
building the network - the network operator, the network engineer, and even as
Madjid points out, the equipment vendor. It would be reasonable to try and
anticipate those CT features that an operator might want to be optional,
BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT.

The CT requirements draft IS a requirements draft for the CT protocol. It is
intended to provide a template for eventual protocol draft submissions. Ideally,
out of these submissions, only one proposal will be selected. A MAY in the CT
requirements draft essentially states that a protocol proposal need not consider
supporting this feature. A MAY in the CT requirements draft does NOT mean that
the feature should be one that can be optionally enabled or disabled by someone
implementing or deploying the CT solution. A MAY clearly indicates that protocol
proposals can completely ignore the requirement, and if one of these protocols
is selected by the working group, the feature will likely never be available to
the vendor, the network engineer or the operator.

The proper way to specify requirements that must be supported by the CT protocol,
but must also must be optional for implementation is to state that in a second
requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented
with a second requirement that states that 4.6 MUST be an optional feature.

In identifying this subtlety, I wonder how many of the requirements in the CT
draft are actually system requirements and not protocol requirements. I am,
at this point, somewhat hesitant to look at this point. However, a CT protocol
that does not support of feature means that the feature will never be available
to anyone.

Gary Kenward

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: September 24, 2002 12:19
> To: 'James Kempf'; seamoby@ietf.org
> Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements
> Ends Wed.
>
>
> Reading from 2119
>
>    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course
>
>    MAY   This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item
> because a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the
> same item.
>    ......
>   
>
> It means you need to fully understand the implication of not
> supporting
> a SHOULD item, before you exclude it. On the other hand if it
> is something
> that may be useful in some cases, a may is more appropriate.
>
> Looking at 4.6, I would say one-to-many context transfer is not
> an item that its "not use" needs to be investigated, but its "use"
> needs careful considerations.
> Example:
> If you are dealing with dynamic context that is affected by
> flow of data
> at a specific AR (header compression, or measurement based
> QoS context)
> sending the context through a whole bunch of ARs that may not even see
> the data causes serious synchronization issues for such context.
>
> Based on this counter-example:
> I say this requirement should be changed to "may" unless it
> is stated that
> SHOULD only applies to the context whose value is not
> affected by data flow.
>
> Madjid
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Monday, September 23, 2002 11:24 AM
> To: seamoby@ietf.org
> Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed.
>
>
> A reminder: last call for the CT requirements document
> (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept
> 25. So far, we have
> not received any comments. If you have any comments, please
> send them to the
> list by that date.
>
>             jak
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C26BB4.689F4970-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 4 13:14:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13653 for ; Fri, 4 Oct 2002 13:14:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94HGBv21264; Fri, 4 Oct 2002 13:16:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94HBwv21077 for ; Fri, 4 Oct 2002 13:11:58 -0400 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13453 for ; Fri, 4 Oct 2002 13:09:52 -0400 (EDT) Message-ID: <008b01c26bc8$e5426480$476015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Nakhjiri Madjid-MNAKHJI1'" , References: <9FBD322B7824D511B36900508BF93C9C05350BB3@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 10:10:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > The CT requirements draft IS a requirements draft for the CT protocol. It is > > intended to provide a template for eventual protocol draft submissions. Correction. The requirements are input to the design team, which is currently working on draft 00 of the protocol. In order to achieve some forward progress (after two years of debate), Pat and I decided to move to a design team approach. Frankly, I think the time for semantic hair splitting on this document is long past. IETF requirements are meant to be general guidelines to the protocol designers. The important part is the protocol design, and we are way overdue in getting that done. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 4 13:15:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13681 for ; Fri, 4 Oct 2002 13:15:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94HH2X21301 for seamoby-archive@odin.ietf.org; Fri, 4 Oct 2002 13:17:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94HH2v21298 for ; Fri, 4 Oct 2002 13:17:02 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13667 for ; Fri, 4 Oct 2002 13:14:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94HGBv21264; Fri, 4 Oct 2002 13:16:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94HBwv21077 for ; Fri, 4 Oct 2002 13:11:58 -0400 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13453 for ; Fri, 4 Oct 2002 13:09:52 -0400 (EDT) Message-ID: <008b01c26bc8$e5426480$476015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Nakhjiri Madjid-MNAKHJI1'" , References: <9FBD322B7824D511B36900508BF93C9C05350BB3@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 10:10:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The CT requirements draft IS a requirements draft for the CT protocol. It is > > intended to provide a template for eventual protocol draft submissions. Correction. The requirements are input to the design team, which is currently working on draft 00 of the protocol. In order to achieve some forward progress (after two years of debate), Pat and I decided to move to a design team approach. Frankly, I think the time for semantic hair splitting on this document is long past. IETF requirements are meant to be general guidelines to the protocol designers. The important part is the protocol design, and we are way overdue in getting that done. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 4 14:29:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16281 for ; Fri, 4 Oct 2002 14:29:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94IR3v25037; Fri, 4 Oct 2002 14:27:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94INev24937 for ; Fri, 4 Oct 2002 14:23:40 -0400 Received: from zcars04f.ca.nortel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15986 for ; Fri, 4 Oct 2002 14:21:33 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g94INCR13653; Fri, 4 Oct 2002 14:23:13 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Oct 2002 14:23:14 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05350BB5@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Nakhjiri Madjid-MNAKHJI1'" , seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 14:23:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BD2.A4A142F2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C26BD2.A4A142F2 Content-Type: text/plain; charset="iso-8859-1" Thanks James, but it is not semantic hair splitting. If a protocol is produced that does not support one-to-many CT because the requirement was specified as an option, then as far as I am concerned, it is useless for proactive CT in many wireless networking scenarios. (Note that one-to-many does not mean multicast, it means the ability to perform CT, and CT updates, to more then one target AR). But, as I said, "imminently ignorable". Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: October 4, 2002 13:10 > To: Kenward, Gary [CAR:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1'; > seamoby@ietf.org > Subject: Re: [Seamoby] Reminder: Last Call for CT > Requirements Ends Wed. > > > > The CT requirements draft IS a requirements draft for the > CT protocol. It is > > > > intended to provide a template for eventual protocol draft > submissions. > > Correction. The requirements are input to the design team, > which is currently > working on draft 00 of the protocol. In order to achieve some > forward progress > (after two years of debate), Pat and I decided to move to a > design team > approach. > > > > Frankly, I think the time for semantic hair splitting on this > document is long > past. IETF requirements are meant to be general guidelines to > the protocol > designers. The important part is the protocol design, and we > are way overdue in > getting that done. > > > jak > > ------_=_NextPart_001_01C26BD2.A4A142F2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

Thanks James, but it is not semantic hair splitting.
If a protocol is produced that does not support one-to-many
CT because the requirement was specified as an option, then
as far as I am concerned, it is useless for proactive CT in
many wireless networking scenarios. (Note that one-to-many
does not mean multicast, it means the ability to perform
CT, and CT updates, to more then one target AR).

But, as I said, "imminently ignorable".

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: October 4, 2002 13:10
> To: Kenward, Gary [CAR:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1';
> seamoby@ietf.org
> Subject: Re: [Seamoby] Reminder: Last Call for CT
> Requirements Ends Wed.
>
>
> > The CT requirements draft IS a requirements draft for the
> CT protocol. It is
> >
> > intended to provide a template for eventual protocol draft
> submissions.
>
> Correction. The requirements are input to the design team,
> which is currently
> working on draft 00 of the protocol. In order to achieve some
> forward progress
> (after two years of debate), Pat and I decided to move to a
> design team
> approach.
>
>
> <WG Chair hat off>
> Frankly, I think the time for semantic hair splitting on this
> document is long
> past. IETF requirements are meant to be general guidelines to
> the protocol
> designers. The important part is the protocol design, and we
> are way overdue in
> getting that done.
> <WG Chair hat on>
>
>             jak
>
>

------_=_NextPart_001_01C26BD2.A4A142F2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 4 14:29:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16316 for ; Fri, 4 Oct 2002 14:29:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94IVOm25231 for seamoby-archive@odin.ietf.org; Fri, 4 Oct 2002 14:31:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94IVOv25228 for ; Fri, 4 Oct 2002 14:31:24 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16295 for ; Fri, 4 Oct 2002 14:29:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94IR3v25037; Fri, 4 Oct 2002 14:27:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94INev24937 for ; Fri, 4 Oct 2002 14:23:40 -0400 Received: from zcars04f.ca.nortel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15986 for ; Fri, 4 Oct 2002 14:21:33 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g94INCR13653; Fri, 4 Oct 2002 14:23:13 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Oct 2002 14:23:14 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05350BB5@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Nakhjiri Madjid-MNAKHJI1'" , seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 14:23:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BD2.A4A142F2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C26BD2.A4A142F2 Content-Type: text/plain; charset="iso-8859-1" Thanks James, but it is not semantic hair splitting. If a protocol is produced that does not support one-to-many CT because the requirement was specified as an option, then as far as I am concerned, it is useless for proactive CT in many wireless networking scenarios. (Note that one-to-many does not mean multicast, it means the ability to perform CT, and CT updates, to more then one target AR). But, as I said, "imminently ignorable". Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: October 4, 2002 13:10 > To: Kenward, Gary [CAR:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1'; > seamoby@ietf.org > Subject: Re: [Seamoby] Reminder: Last Call for CT > Requirements Ends Wed. > > > > The CT requirements draft IS a requirements draft for the > CT protocol. It is > > > > intended to provide a template for eventual protocol draft > submissions. > > Correction. The requirements are input to the design team, > which is currently > working on draft 00 of the protocol. In order to achieve some > forward progress > (after two years of debate), Pat and I decided to move to a > design team > approach. > > > > Frankly, I think the time for semantic hair splitting on this > document is long > past. IETF requirements are meant to be general guidelines to > the protocol > designers. The important part is the protocol design, and we > are way overdue in > getting that done. > > > jak > > ------_=_NextPart_001_01C26BD2.A4A142F2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

Thanks James, but it is not semantic hair splitting.
If a protocol is produced that does not support one-to-many
CT because the requirement was specified as an option, then
as far as I am concerned, it is useless for proactive CT in
many wireless networking scenarios. (Note that one-to-many
does not mean multicast, it means the ability to perform
CT, and CT updates, to more then one target AR).

But, as I said, "imminently ignorable".

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: October 4, 2002 13:10
> To: Kenward, Gary [CAR:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1';
> seamoby@ietf.org
> Subject: Re: [Seamoby] Reminder: Last Call for CT
> Requirements Ends Wed.
>
>
> > The CT requirements draft IS a requirements draft for the
> CT protocol. It is
> >
> > intended to provide a template for eventual protocol draft
> submissions.
>
> Correction. The requirements are input to the design team,
> which is currently
> working on draft 00 of the protocol. In order to achieve some
> forward progress
> (after two years of debate), Pat and I decided to move to a
> design team
> approach.
>
>
> <WG Chair hat off>
> Frankly, I think the time for semantic hair splitting on this
> document is long
> past. IETF requirements are meant to be general guidelines to
> the protocol
> designers. The important part is the protocol design, and we
> are way overdue in
> getting that done.
> <WG Chair hat on>
>
>             jak
>
>

------_=_NextPart_001_01C26BD2.A4A142F2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 4 16:16:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20185 for ; Fri, 4 Oct 2002 16:16:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KHnv30678; Fri, 4 Oct 2002 16:17:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KCrv30497 for ; Fri, 4 Oct 2002 16:12:53 -0400 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19784 for ; Fri, 4 Oct 2002 16:10:46 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA06790 for ; Fri, 4 Oct 2002 13:12:45 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id NAA17271 for ; Fri, 4 Oct 2002 13:12:45 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 4 Oct 2002 15:12:44 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD58DD@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 15:12:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BE2.649BFAC0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C26BE2.649BFAC0 Content-Type: text/plain; charset="iso-8859-1" Gary, reading your email, I was thinking to myself that many of the requirements are in fact architectural requirements/features, until you mentioned it at the bottom of your email. I agree with you on the distinction, but I doubt if you can use CT as a protocol without paving the way for its use in the architecture. Otherwise there would be no difference between CT and any messaging protocol. Having said that, at this point, I felt that this support of this specific feature would cause conflict for some protocol design approaches that don't even need such a feature. While, the other features did not cause an alarm at the time of reading the draft. So call it may, call it Must optional, if that means I don't have to twist the design to support something that may not be needed in the first place. Regards, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, October 04, 2002 9:44 AM To: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. My comment is past due, so it is immediately ignorable, but worth stating if only for future reference.... When I first read through Madjid's proposed change my reaction was simply, and honestly, I did not really care. Manufacturers and network engineers have been known to ignore IETF recommendations in the past, so changing SHOULD to MAY did not seem to have much impact. However, in considering the change a second time (in the process of updating the draft), I sensed a subtle problem in the argument; a problem that has been discussed in the past in this group. Madjid, if I have misinterpreted your reasoning, please correct me. The CT requirements draft is NOT, as far as I know, a requirements document for the deployment of a system that supports CT. Clearly, a deployment of CT capabilities would be at the discretion of all the entities involved in actually building the network - the network operator, the network engineer, and even as Madjid points out, the equipment vendor. It would be reasonable to try and anticipate those CT features that an operator might want to be optional, BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT. The CT requirements draft IS a requirements draft for the CT protocol. It is intended to provide a template for eventual protocol draft submissions. Ideally, out of these submissions, only one proposal will be selected. A MAY in the CT requirements draft essentially states that a protocol proposal need not consider supporting this feature. A MAY in the CT requirements draft does NOT mean that the feature should be one that can be optionally enabled or disabled by someone implementing or deploying the CT solution. A MAY clearly indicates that protocol proposals can completely ignore the requirement, and if one of these protocols is selected by the working group, the feature will likely never be available to the vendor, the network engineer or the operator. The proper way to specify requirements that must be supported by the CT protocol, but must also must be optional for implementation is to state that in a second requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented with a second requirement that states that 4.6 MUST be an optional feature. In identifying this subtlety, I wonder how many of the requirements in the CT draft are actually system requirements and not protocol requirements. I am, at this point, somewhat hesitant to look at this point. However, a CT protocol that does not support of feature means that the feature will never be available to anyone. Gary Kenward > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] > Sent: September 24, 2002 12:19 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements > Ends Wed. > > > Reading from 2119 > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course > > MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item > because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the > same item. > ...... > > > It means you need to fully understand the implication of not > supporting > a SHOULD item, before you exclude it. On the other hand if it > is something > that may be useful in some cases, a may is more appropriate. > > Looking at 4.6, I would say one-to-many context transfer is not > an item that its "not use" needs to be investigated, but its "use" > needs careful considerations. > Example: > If you are dealing with dynamic context that is affected by > flow of data > at a specific AR (header compression, or measurement based > QoS context) > sending the context through a whole bunch of ARs that may not even see > the data causes serious synchronization issues for such context. > > Based on this counter-example: > I say this requirement should be changed to "may" unless it > is stated that > SHOULD only applies to the context whose value is not > affected by data flow. > > Madjid > > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: Monday, September 23, 2002 11:24 AM > To: seamoby@ietf.org > Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed. > > > A reminder: last call for the CT requirements document > (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept > 25. So far, we have > not received any comments. If you have any comments, please > send them to the > list by that date. > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C26BE2.649BFAC0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.
 Gary,
 
reading your email, I was thinking to myself that many of the requirements are in fact
architectural requirements/features, until you mentioned it at the bottom of your email.
 
I agree with you on the distinction, but I doubt if you can use CT as a protocol
without paving the way for its use in the architecture. Otherwise there would be no
difference between CT and any messaging protocol.
 
 
Having said that, at this point, I felt that this support of this specific feature would
cause conflict for some protocol design approaches that don't even need such a feature.
While, the other features did not cause an alarm at the time of reading the draft.
So call it may, call it Must optional, if that means I don't have to twist the design to support
something that may not be needed in the first place.
 
Regards,
 
Madjid
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, October 04, 2002 9:44 AM
To: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org
Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

My comment is past due, so it is immediately ignorable, but worth stating
if only for future reference....

When I first read through Madjid's proposed change my reaction was simply,
and honestly, I did not really care. Manufacturers and network engineers
have been known to ignore IETF recommendations in the past, so changing
SHOULD to MAY did not seem to have much impact.

However, in considering the change a second time (in the process of updating
the draft), I sensed a subtle problem in the argument; a problem that has
been discussed in the past in this group. Madjid, if I have misinterpreted
your reasoning, please correct me.

The CT requirements draft is NOT, as far as I know, a requirements document
for the deployment of a system that supports CT. Clearly, a deployment of CT
capabilities would be at the discretion of all the entities involved in actually
building the network - the network operator, the network engineer, and even as
Madjid points out, the equipment vendor. It would be reasonable to try and
anticipate those CT features that an operator might want to be optional,
BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT.

The CT requirements draft IS a requirements draft for the CT protocol. It is
intended to provide a template for eventual protocol draft submissions. Ideally,
out of these submissions, only one proposal will be selected. A MAY in the CT
requirements draft essentially states that a protocol proposal need not consider
supporting this feature. A MAY in the CT requirements draft does NOT mean that
the feature should be one that can be optionally enabled or disabled by someone
implementing or deploying the CT solution. A MAY clearly indicates that protocol
proposals can completely ignore the requirement, and if one of these protocols
is selected by the working group, the feature will likely never be available to
the vendor, the network engineer or the operator.

The proper way to specify requirements that must be supported by the CT protocol,
but must also must be optional for implementation is to state that in a second
requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented
with a second requirement that states that 4.6 MUST be an optional feature.

In identifying this subtlety, I wonder how many of the requirements in the CT
draft are actually system requirements and not protocol requirements. I am,
at this point, somewhat hesitant to look at this point. However, a CT protocol
that does not support of feature means that the feature will never be available
to anyone.

Gary Kenward

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: September 24, 2002 12:19
> To: 'James Kempf'; seamoby@ietf.org
> Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements
> Ends Wed.
>
>
> Reading from 2119
>
>    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course
>
>    MAY   This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item
> because a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the
> same item.
>    ......
>   
>
> It means you need to fully understand the implication of not
> supporting
> a SHOULD item, before you exclude it. On the other hand if it
> is something
> that may be useful in some cases, a may is more appropriate.
>
> Looking at 4.6, I would say one-to-many context transfer is not
> an item that its "not use" needs to be investigated, but its "use"
> needs careful considerations.
> Example:
> If you are dealing with dynamic context that is affected by
> flow of data
> at a specific AR (header compression, or measurement based
> QoS context)
> sending the context through a whole bunch of ARs that may not even see
> the data causes serious synchronization issues for such context.
>
> Based on this counter-example:
> I say this requirement should be changed to "may" unless it
> is stated that
> SHOULD only applies to the context whose value is not
> affected by data flow.
>
> Madjid
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Monday, September 23, 2002 11:24 AM
> To: seamoby@ietf.org
> Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed.
>
>
> A reminder: last call for the CT requirements document
> (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept
> 25. So far, we have
> not received any comments. If you have any comments, please
> send them to the
> list by that date.
>
>             jak
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C26BE2.649BFAC0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 4 16:17:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20256 for ; Fri, 4 Oct 2002 16:17:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94KItD30804 for seamoby-archive@odin.ietf.org; Fri, 4 Oct 2002 16:18:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KItv30801 for ; Fri, 4 Oct 2002 16:18:55 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20199 for ; Fri, 4 Oct 2002 16:16:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KHnv30678; Fri, 4 Oct 2002 16:17:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KCrv30497 for ; Fri, 4 Oct 2002 16:12:53 -0400 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19784 for ; Fri, 4 Oct 2002 16:10:46 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA06790 for ; Fri, 4 Oct 2002 13:12:45 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id NAA17271 for ; Fri, 4 Oct 2002 13:12:45 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 4 Oct 2002 15:12:44 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD58DD@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 15:12:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BE2.649BFAC0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C26BE2.649BFAC0 Content-Type: text/plain; charset="iso-8859-1" Gary, reading your email, I was thinking to myself that many of the requirements are in fact architectural requirements/features, until you mentioned it at the bottom of your email. I agree with you on the distinction, but I doubt if you can use CT as a protocol without paving the way for its use in the architecture. Otherwise there would be no difference between CT and any messaging protocol. Having said that, at this point, I felt that this support of this specific feature would cause conflict for some protocol design approaches that don't even need such a feature. While, the other features did not cause an alarm at the time of reading the draft. So call it may, call it Must optional, if that means I don't have to twist the design to support something that may not be needed in the first place. Regards, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, October 04, 2002 9:44 AM To: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. My comment is past due, so it is immediately ignorable, but worth stating if only for future reference.... When I first read through Madjid's proposed change my reaction was simply, and honestly, I did not really care. Manufacturers and network engineers have been known to ignore IETF recommendations in the past, so changing SHOULD to MAY did not seem to have much impact. However, in considering the change a second time (in the process of updating the draft), I sensed a subtle problem in the argument; a problem that has been discussed in the past in this group. Madjid, if I have misinterpreted your reasoning, please correct me. The CT requirements draft is NOT, as far as I know, a requirements document for the deployment of a system that supports CT. Clearly, a deployment of CT capabilities would be at the discretion of all the entities involved in actually building the network - the network operator, the network engineer, and even as Madjid points out, the equipment vendor. It would be reasonable to try and anticipate those CT features that an operator might want to be optional, BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT. The CT requirements draft IS a requirements draft for the CT protocol. It is intended to provide a template for eventual protocol draft submissions. Ideally, out of these submissions, only one proposal will be selected. A MAY in the CT requirements draft essentially states that a protocol proposal need not consider supporting this feature. A MAY in the CT requirements draft does NOT mean that the feature should be one that can be optionally enabled or disabled by someone implementing or deploying the CT solution. A MAY clearly indicates that protocol proposals can completely ignore the requirement, and if one of these protocols is selected by the working group, the feature will likely never be available to the vendor, the network engineer or the operator. The proper way to specify requirements that must be supported by the CT protocol, but must also must be optional for implementation is to state that in a second requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented with a second requirement that states that 4.6 MUST be an optional feature. In identifying this subtlety, I wonder how many of the requirements in the CT draft are actually system requirements and not protocol requirements. I am, at this point, somewhat hesitant to look at this point. However, a CT protocol that does not support of feature means that the feature will never be available to anyone. Gary Kenward > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] > Sent: September 24, 2002 12:19 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements > Ends Wed. > > > Reading from 2119 > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course > > MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item > because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the > same item. > ...... > > > It means you need to fully understand the implication of not > supporting > a SHOULD item, before you exclude it. On the other hand if it > is something > that may be useful in some cases, a may is more appropriate. > > Looking at 4.6, I would say one-to-many context transfer is not > an item that its "not use" needs to be investigated, but its "use" > needs careful considerations. > Example: > If you are dealing with dynamic context that is affected by > flow of data > at a specific AR (header compression, or measurement based > QoS context) > sending the context through a whole bunch of ARs that may not even see > the data causes serious synchronization issues for such context. > > Based on this counter-example: > I say this requirement should be changed to "may" unless it > is stated that > SHOULD only applies to the context whose value is not > affected by data flow. > > Madjid > > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: Monday, September 23, 2002 11:24 AM > To: seamoby@ietf.org > Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed. > > > A reminder: last call for the CT requirements document > (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept > 25. So far, we have > not received any comments. If you have any comments, please > send them to the > list by that date. > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C26BE2.649BFAC0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.
 Gary,
 
reading your email, I was thinking to myself that many of the requirements are in fact
architectural requirements/features, until you mentioned it at the bottom of your email.
 
I agree with you on the distinction, but I doubt if you can use CT as a protocol
without paving the way for its use in the architecture. Otherwise there would be no
difference between CT and any messaging protocol.
 
 
Having said that, at this point, I felt that this support of this specific feature would
cause conflict for some protocol design approaches that don't even need such a feature.
While, the other features did not cause an alarm at the time of reading the draft.
So call it may, call it Must optional, if that means I don't have to twist the design to support
something that may not be needed in the first place.
 
Regards,
 
Madjid
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, October 04, 2002 9:44 AM
To: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org
Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

My comment is past due, so it is immediately ignorable, but worth stating
if only for future reference....

When I first read through Madjid's proposed change my reaction was simply,
and honestly, I did not really care. Manufacturers and network engineers
have been known to ignore IETF recommendations in the past, so changing
SHOULD to MAY did not seem to have much impact.

However, in considering the change a second time (in the process of updating
the draft), I sensed a subtle problem in the argument; a problem that has
been discussed in the past in this group. Madjid, if I have misinterpreted
your reasoning, please correct me.

The CT requirements draft is NOT, as far as I know, a requirements document
for the deployment of a system that supports CT. Clearly, a deployment of CT
capabilities would be at the discretion of all the entities involved in actually
building the network - the network operator, the network engineer, and even as
Madjid points out, the equipment vendor. It would be reasonable to try and
anticipate those CT features that an operator might want to be optional,
BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT.

The CT requirements draft IS a requirements draft for the CT protocol. It is
intended to provide a template for eventual protocol draft submissions. Ideally,
out of these submissions, only one proposal will be selected. A MAY in the CT
requirements draft essentially states that a protocol proposal need not consider
supporting this feature. A MAY in the CT requirements draft does NOT mean that
the feature should be one that can be optionally enabled or disabled by someone
implementing or deploying the CT solution. A MAY clearly indicates that protocol
proposals can completely ignore the requirement, and if one of these protocols
is selected by the working group, the feature will likely never be available to
the vendor, the network engineer or the operator.

The proper way to specify requirements that must be supported by the CT protocol,
but must also must be optional for implementation is to state that in a second
requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented
with a second requirement that states that 4.6 MUST be an optional feature.

In identifying this subtlety, I wonder how many of the requirements in the CT
draft are actually system requirements and not protocol requirements. I am,
at this point, somewhat hesitant to look at this point. However, a CT protocol
that does not support of feature means that the feature will never be available
to anyone.

Gary Kenward

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: September 24, 2002 12:19
> To: 'James Kempf'; seamoby@ietf.org
> Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements
> Ends Wed.
>
>
> Reading from 2119
>
>    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course
>
>    MAY   This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item
> because a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the
> same item.
>    ......
>   
>
> It means you need to fully understand the implication of not
> supporting
> a SHOULD item, before you exclude it. On the other hand if it
> is something
> that may be useful in some cases, a may is more appropriate.
>
> Looking at 4.6, I would say one-to-many context transfer is not
> an item that its "not use" needs to be investigated, but its "use"
> needs careful considerations.
> Example:
> If you are dealing with dynamic context that is affected by
> flow of data
> at a specific AR (header compression, or measurement based
> QoS context)
> sending the context through a whole bunch of ARs that may not even see
> the data causes serious synchronization issues for such context.
>
> Based on this counter-example:
> I say this requirement should be changed to "may" unless it
> is stated that
> SHOULD only applies to the context whose value is not
> affected by data flow.
>
> Madjid
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Monday, September 23, 2002 11:24 AM
> To: seamoby@ietf.org
> Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed.
>
>
> A reminder: last call for the CT requirements document
> (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept
> 25. So far, we have
> not received any comments. If you have any comments, please
> send them to the
> list by that date.
>
>             jak
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C26BE2.649BFAC0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 4 16:57:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21682 for ; Fri, 4 Oct 2002 16:57:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94Kkmv32379; Fri, 4 Oct 2002 16:46:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KfPv32158 for ; Fri, 4 Oct 2002 16:41:25 -0400 Received: from zcars04e.ca.nortel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20829 for ; Fri, 4 Oct 2002 16:39:16 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g94Kf7Q22343; Fri, 4 Oct 2002 16:41:08 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Oct 2002 16:41:11 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05350BBA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 16:41:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BE6.5C802FB0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C26BE6.5C802FB0 Content-Type: text/plain; charset="iso-8859-1" Madjid: First, I agree with your observation about architecture. In my view, you cannot talk about mobility solutions, without having a fairly specific functional architecture and topology in mind. Next, I guess I would say that the is exactly as I feared. At the moment, I believe CT is still "a" protocol, not a number of similar but different protocols. And, as I said in response to James, without this one to many capability, the protocol will not at all meet the objectives I had in mind when considering what would be needed to enable proactive preparation for handovers and thus improve handover performance significantly. Consider that 2G and 3G soft handovers require the equivalent of a one-to-many transfer of context to establish the active set. This requirement is now effectively eliminated from the list - that is, what you are stating is that it has been reduced to a MAY so that the design team can ignore it . Since the design team is a closed group, by the time this decision is apparent, it will be too exhausting to argue that the "MAY" requirement should have been included. There are many others requirements related to proactive CT which very likely have no real meaning. I wonder if the IESG will spot them? Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: October 4, 2002 16:13 To: Kenward, Gary [CAR:AN10:EXCH]; 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Gary, reading your email, I was thinking to myself that many of the requirements are in fact architectural requirements/features, until you mentioned it at the bottom of your email. I agree with you on the distinction, but I doubt if you can use CT as a protocol without paving the way for its use in the architecture. Otherwise there would be no difference between CT and any messaging protocol. Having said that, at this point, I felt that this support of this specific feature would cause conflict for some protocol design approaches that don't even need such a feature. While, the other features did not cause an alarm at the time of reading the draft. So call it may, call it Must optional, if that means I don't have to twist the design to support something that may not be needed in the first place. Regards, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, October 04, 2002 9:44 AM To: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. My comment is past due, so it is immediately ignorable, but worth stating if only for future reference.... When I first read through Madjid's proposed change my reaction was simply, and honestly, I did not really care. Manufacturers and network engineers have been known to ignore IETF recommendations in the past, so changing SHOULD to MAY did not seem to have much impact. However, in considering the change a second time (in the process of updating the draft), I sensed a subtle problem in the argument; a problem that has been discussed in the past in this group. Madjid, if I have misinterpreted your reasoning, please correct me. The CT requirements draft is NOT, as far as I know, a requirements document for the deployment of a system that supports CT. Clearly, a deployment of CT capabilities would be at the discretion of all the entities involved in actually building the network - the network operator, the network engineer, and even as Madjid points out, the equipment vendor. It would be reasonable to try and anticipate those CT features that an operator might want to be optional, BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT. The CT requirements draft IS a requirements draft for the CT protocol. It is intended to provide a template for eventual protocol draft submissions. Ideally, out of these submissions, only one proposal will be selected. A MAY in the CT requirements draft essentially states that a protocol proposal need not consider supporting this feature. A MAY in the CT requirements draft does NOT mean that the feature should be one that can be optionally enabled or disabled by someone implementing or deploying the CT solution. A MAY clearly indicates that protocol proposals can completely ignore the requirement, and if one of these protocols is selected by the working group, the feature will likely never be available to the vendor, the network engineer or the operator. The proper way to specify requirements that must be supported by the CT protocol, but must also must be optional for implementation is to state that in a second requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented with a second requirement that states that 4.6 MUST be an optional feature. In identifying this subtlety, I wonder how many of the requirements in the CT draft are actually system requirements and not protocol requirements. I am, at this point, somewhat hesitant to look at this point. However, a CT protocol that does not support of feature means that the feature will never be available to anyone. Gary Kenward > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] > Sent: September 24, 2002 12:19 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements > Ends Wed. > > > Reading from 2119 > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course > > MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item > because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the > same item. > ...... > > > It means you need to fully understand the implication of not > supporting > a SHOULD item, before you exclude it. On the other hand if it > is something > that may be useful in some cases, a may is more appropriate. > > Looking at 4.6, I would say one-to-many context transfer is not > an item that its "not use" needs to be investigated, but its "use" > needs careful considerations. > Example: > If you are dealing with dynamic context that is affected by > flow of data > at a specific AR (header compression, or measurement based > QoS context) > sending the context through a whole bunch of ARs that may not even see > the data causes serious synchronization issues for such context. > > Based on this counter-example: > I say this requirement should be changed to "may" unless it > is stated that > SHOULD only applies to the context whose value is not > affected by data flow. > > Madjid > > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: Monday, September 23, 2002 11:24 AM > To: seamoby@ietf.org > Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed. > > > A reminder: last call for the CT requirements document > (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept > 25. So far, we have > not received any comments. If you have any comments, please > send them to the > list by that date. > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C26BE6.5C802FB0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.
Madjid:
 
   First, I agree with your observation about architecture. In my
view, you cannot talk about mobility solutions, without having a
fairly specific functional architecture and topology in mind.
 
   Next, I guess I would say that the is exactly as I feared. At
the moment, I believe CT is still "a" protocol, not a number of
similar but different protocols. And, as I said in response to
James, without this one to many capability, the protocol will
not at all meet the objectives I had in mind when considering what
would be needed to enable proactive preparation for handovers
and thus improve handover performance significantly. Consider
that 2G and 3G soft handovers require the equivalent of a
one-to-many transfer of context to establish the active set.
 
  This requirement is now effectively eliminated from
the list - that is, what you are stating is that it has been reduced
to a MAY so that the design team can ignore it . Since the design team
is a closed group, by the time this decision is apparent, it will
be too exhausting to argue that the "MAY" requirement should have
been included.
 
  There are many others requirements related to proactive CT
which very likely have no real meaning. I wonder if the IESG
will spot them?
 
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: October 4, 2002 16:13
To: Kenward, Gary [CAR:AN10:EXCH]; 'James Kempf'; seamoby@ietf.org
Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

 Gary,
 
reading your email, I was thinking to myself that many of the requirements are in fact
architectural requirements/features, until you mentioned it at the bottom of your email.
 
I agree with you on the distinction, but I doubt if you can use CT as a protocol
without paving the way for its use in the architecture. Otherwise there would be no
difference between CT and any messaging protocol.
 
 
Having said that, at this point, I felt that this support of this specific feature would
cause conflict for some protocol design approaches that don't even need such a feature.
While, the other features did not cause an alarm at the time of reading the draft.
So call it may, call it Must optional, if that means I don't have to twist the design to support
something that may not be needed in the first place.
 
Regards,
 
Madjid
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, October 04, 2002 9:44 AM
To: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org
Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

My comment is past due, so it is immediately ignorable, but worth stating
if only for future reference....

When I first read through Madjid's proposed change my reaction was simply,
and honestly, I did not really care. Manufacturers and network engineers
have been known to ignore IETF recommendations in the past, so changing
SHOULD to MAY did not seem to have much impact.

However, in considering the change a second time (in the process of updating
the draft), I sensed a subtle problem in the argument; a problem that has
been discussed in the past in this group. Madjid, if I have misinterpreted
your reasoning, please correct me.

The CT requirements draft is NOT, as far as I know, a requirements document
for the deployment of a system that supports CT. Clearly, a deployment of CT
capabilities would be at the discretion of all the entities involved in actually
building the network - the network operator, the network engineer, and even as
Madjid points out, the equipment vendor. It would be reasonable to try and
anticipate those CT features that an operator might want to be optional,
BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT.

The CT requirements draft IS a requirements draft for the CT protocol. It is
intended to provide a template for eventual protocol draft submissions. Ideally,
out of these submissions, only one proposal will be selected. A MAY in the CT
requirements draft essentially states that a protocol proposal need not consider
supporting this feature. A MAY in the CT requirements draft does NOT mean that
the feature should be one that can be optionally enabled or disabled by someone
implementing or deploying the CT solution. A MAY clearly indicates that protocol
proposals can completely ignore the requirement, and if one of these protocols
is selected by the working group, the feature will likely never be available to
the vendor, the network engineer or the operator.

The proper way to specify requirements that must be supported by the CT protocol,
but must also must be optional for implementation is to state that in a second
requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented
with a second requirement that states that 4.6 MUST be an optional feature.

In identifying this subtlety, I wonder how many of the requirements in the CT
draft are actually system requirements and not protocol requirements. I am,
at this point, somewhat hesitant to look at this point. However, a CT protocol
that does not support of feature means that the feature will never be available
to anyone.

Gary Kenward

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: September 24, 2002 12:19
> To: 'James Kempf'; seamoby@ietf.org
> Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements
> Ends Wed.
>
>
> Reading from 2119
>
>    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course
>
>    MAY   This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item
> because a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the
> same item.
>    ......
>   
>
> It means you need to fully understand the implication of not
> supporting
> a SHOULD item, before you exclude it. On the other hand if it
> is something
> that may be useful in some cases, a may is more appropriate.
>
> Looking at 4.6, I would say one-to-many context transfer is not
> an item that its "not use" needs to be investigated, but its "use"
> needs careful considerations.
> Example:
> If you are dealing with dynamic context that is affected by
> flow of data
> at a specific AR (header compression, or measurement based
> QoS context)
> sending the context through a whole bunch of ARs that may not even see
> the data causes serious synchronization issues for such context.
>
> Based on this counter-example:
> I say this requirement should be changed to "may" unless it
> is stated that
> SHOULD only applies to the context whose value is not
> affected by data flow.
>
> Madjid
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Monday, September 23, 2002 11:24 AM
> To: seamoby@ietf.org
> Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed.
>
>
> A reminder: last call for the CT requirements document
> (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept
> 25. So far, we have
> not received any comments. If you have any comments, please
> send them to the
> list by that date.
>
>             jak
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C26BE6.5C802FB0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 4 16:58:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21832 for ; Fri, 4 Oct 2002 16:58:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94Kxo300417 for seamoby-archive@odin.ietf.org; Fri, 4 Oct 2002 16:59:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94Kxov00413 for ; Fri, 4 Oct 2002 16:59:50 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21700 for ; Fri, 4 Oct 2002 16:57:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94Kkmv32379; Fri, 4 Oct 2002 16:46:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KfPv32158 for ; Fri, 4 Oct 2002 16:41:25 -0400 Received: from zcars04e.ca.nortel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20829 for ; Fri, 4 Oct 2002 16:39:16 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g94Kf7Q22343; Fri, 4 Oct 2002 16:41:08 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Oct 2002 16:41:11 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05350BBA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 16:41:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BE6.5C802FB0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C26BE6.5C802FB0 Content-Type: text/plain; charset="iso-8859-1" Madjid: First, I agree with your observation about architecture. In my view, you cannot talk about mobility solutions, without having a fairly specific functional architecture and topology in mind. Next, I guess I would say that the is exactly as I feared. At the moment, I believe CT is still "a" protocol, not a number of similar but different protocols. And, as I said in response to James, without this one to many capability, the protocol will not at all meet the objectives I had in mind when considering what would be needed to enable proactive preparation for handovers and thus improve handover performance significantly. Consider that 2G and 3G soft handovers require the equivalent of a one-to-many transfer of context to establish the active set. This requirement is now effectively eliminated from the list - that is, what you are stating is that it has been reduced to a MAY so that the design team can ignore it . Since the design team is a closed group, by the time this decision is apparent, it will be too exhausting to argue that the "MAY" requirement should have been included. There are many others requirements related to proactive CT which very likely have no real meaning. I wonder if the IESG will spot them? Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: October 4, 2002 16:13 To: Kenward, Gary [CAR:AN10:EXCH]; 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Gary, reading your email, I was thinking to myself that many of the requirements are in fact architectural requirements/features, until you mentioned it at the bottom of your email. I agree with you on the distinction, but I doubt if you can use CT as a protocol without paving the way for its use in the architecture. Otherwise there would be no difference between CT and any messaging protocol. Having said that, at this point, I felt that this support of this specific feature would cause conflict for some protocol design approaches that don't even need such a feature. While, the other features did not cause an alarm at the time of reading the draft. So call it may, call it Must optional, if that means I don't have to twist the design to support something that may not be needed in the first place. Regards, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, October 04, 2002 9:44 AM To: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. My comment is past due, so it is immediately ignorable, but worth stating if only for future reference.... When I first read through Madjid's proposed change my reaction was simply, and honestly, I did not really care. Manufacturers and network engineers have been known to ignore IETF recommendations in the past, so changing SHOULD to MAY did not seem to have much impact. However, in considering the change a second time (in the process of updating the draft), I sensed a subtle problem in the argument; a problem that has been discussed in the past in this group. Madjid, if I have misinterpreted your reasoning, please correct me. The CT requirements draft is NOT, as far as I know, a requirements document for the deployment of a system that supports CT. Clearly, a deployment of CT capabilities would be at the discretion of all the entities involved in actually building the network - the network operator, the network engineer, and even as Madjid points out, the equipment vendor. It would be reasonable to try and anticipate those CT features that an operator might want to be optional, BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT. The CT requirements draft IS a requirements draft for the CT protocol. It is intended to provide a template for eventual protocol draft submissions. Ideally, out of these submissions, only one proposal will be selected. A MAY in the CT requirements draft essentially states that a protocol proposal need not consider supporting this feature. A MAY in the CT requirements draft does NOT mean that the feature should be one that can be optionally enabled or disabled by someone implementing or deploying the CT solution. A MAY clearly indicates that protocol proposals can completely ignore the requirement, and if one of these protocols is selected by the working group, the feature will likely never be available to the vendor, the network engineer or the operator. The proper way to specify requirements that must be supported by the CT protocol, but must also must be optional for implementation is to state that in a second requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented with a second requirement that states that 4.6 MUST be an optional feature. In identifying this subtlety, I wonder how many of the requirements in the CT draft are actually system requirements and not protocol requirements. I am, at this point, somewhat hesitant to look at this point. However, a CT protocol that does not support of feature means that the feature will never be available to anyone. Gary Kenward > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] > Sent: September 24, 2002 12:19 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements > Ends Wed. > > > Reading from 2119 > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course > > MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item > because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the > same item. > ...... > > > It means you need to fully understand the implication of not > supporting > a SHOULD item, before you exclude it. On the other hand if it > is something > that may be useful in some cases, a may is more appropriate. > > Looking at 4.6, I would say one-to-many context transfer is not > an item that its "not use" needs to be investigated, but its "use" > needs careful considerations. > Example: > If you are dealing with dynamic context that is affected by > flow of data > at a specific AR (header compression, or measurement based > QoS context) > sending the context through a whole bunch of ARs that may not even see > the data causes serious synchronization issues for such context. > > Based on this counter-example: > I say this requirement should be changed to "may" unless it > is stated that > SHOULD only applies to the context whose value is not > affected by data flow. > > Madjid > > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: Monday, September 23, 2002 11:24 AM > To: seamoby@ietf.org > Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed. > > > A reminder: last call for the CT requirements document > (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept > 25. So far, we have > not received any comments. If you have any comments, please > send them to the > list by that date. > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C26BE6.5C802FB0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.
Madjid:
 
   First, I agree with your observation about architecture. In my
view, you cannot talk about mobility solutions, without having a
fairly specific functional architecture and topology in mind.
 
   Next, I guess I would say that the is exactly as I feared. At
the moment, I believe CT is still "a" protocol, not a number of
similar but different protocols. And, as I said in response to
James, without this one to many capability, the protocol will
not at all meet the objectives I had in mind when considering what
would be needed to enable proactive preparation for handovers
and thus improve handover performance significantly. Consider
that 2G and 3G soft handovers require the equivalent of a
one-to-many transfer of context to establish the active set.
 
  This requirement is now effectively eliminated from
the list - that is, what you are stating is that it has been reduced
to a MAY so that the design team can ignore it . Since the design team
is a closed group, by the time this decision is apparent, it will
be too exhausting to argue that the "MAY" requirement should have
been included.
 
  There are many others requirements related to proactive CT
which very likely have no real meaning. I wonder if the IESG
will spot them?
 
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: October 4, 2002 16:13
To: Kenward, Gary [CAR:AN10:EXCH]; 'James Kempf'; seamoby@ietf.org
Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

 Gary,
 
reading your email, I was thinking to myself that many of the requirements are in fact
architectural requirements/features, until you mentioned it at the bottom of your email.
 
I agree with you on the distinction, but I doubt if you can use CT as a protocol
without paving the way for its use in the architecture. Otherwise there would be no
difference between CT and any messaging protocol.
 
 
Having said that, at this point, I felt that this support of this specific feature would
cause conflict for some protocol design approaches that don't even need such a feature.
While, the other features did not cause an alarm at the time of reading the draft.
So call it may, call it Must optional, if that means I don't have to twist the design to support
something that may not be needed in the first place.
 
Regards,
 
Madjid
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, October 04, 2002 9:44 AM
To: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org
Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

My comment is past due, so it is immediately ignorable, but worth stating
if only for future reference....

When I first read through Madjid's proposed change my reaction was simply,
and honestly, I did not really care. Manufacturers and network engineers
have been known to ignore IETF recommendations in the past, so changing
SHOULD to MAY did not seem to have much impact.

However, in considering the change a second time (in the process of updating
the draft), I sensed a subtle problem in the argument; a problem that has
been discussed in the past in this group. Madjid, if I have misinterpreted
your reasoning, please correct me.

The CT requirements draft is NOT, as far as I know, a requirements document
for the deployment of a system that supports CT. Clearly, a deployment of CT
capabilities would be at the discretion of all the entities involved in actually
building the network - the network operator, the network engineer, and even as
Madjid points out, the equipment vendor. It would be reasonable to try and
anticipate those CT features that an operator might want to be optional,
BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT.

The CT requirements draft IS a requirements draft for the CT protocol. It is
intended to provide a template for eventual protocol draft submissions. Ideally,
out of these submissions, only one proposal will be selected. A MAY in the CT
requirements draft essentially states that a protocol proposal need not consider
supporting this feature. A MAY in the CT requirements draft does NOT mean that
the feature should be one that can be optionally enabled or disabled by someone
implementing or deploying the CT solution. A MAY clearly indicates that protocol
proposals can completely ignore the requirement, and if one of these protocols
is selected by the working group, the feature will likely never be available to
the vendor, the network engineer or the operator.

The proper way to specify requirements that must be supported by the CT protocol,
but must also must be optional for implementation is to state that in a second
requirement. Thus, 4.6 should not be changed to a "MAY", but should be augmented
with a second requirement that states that 4.6 MUST be an optional feature.

In identifying this subtlety, I wonder how many of the requirements in the CT
draft are actually system requirements and not protocol requirements. I am,
at this point, somewhat hesitant to look at this point. However, a CT protocol
that does not support of feature means that the feature will never be available
to anyone.

Gary Kenward

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: September 24, 2002 12:19
> To: 'James Kempf'; seamoby@ietf.org
> Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements
> Ends Wed.
>
>
> Reading from 2119
>
>    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course
>
>    MAY   This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item
> because a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the
> same item.
>    ......
>   
>
> It means you need to fully understand the implication of not
> supporting
> a SHOULD item, before you exclude it. On the other hand if it
> is something
> that may be useful in some cases, a may is more appropriate.
>
> Looking at 4.6, I would say one-to-many context transfer is not
> an item that its "not use" needs to be investigated, but its "use"
> needs careful considerations.
> Example:
> If you are dealing with dynamic context that is affected by
> flow of data
> at a specific AR (header compression, or measurement based
> QoS context)
> sending the context through a whole bunch of ARs that may not even see
> the data causes serious synchronization issues for such context.
>
> Based on this counter-example:
> I say this requirement should be changed to "may" unless it
> is stated that
> SHOULD only applies to the context whose value is not
> affected by data flow.
>
> Madjid
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Monday, September 23, 2002 11:24 AM
> To: seamoby@ietf.org
> Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed.
>
>
> A reminder: last call for the CT requirements document
> (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept
> 25. So far, we have
> not received any comments. If you have any comments, please
> send them to the
> list by that date.
>
>             jak
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C26BE6.5C802FB0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 4 17:27:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22886 for ; Fri, 4 Oct 2002 17:27:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94Kthv32729; Fri, 4 Oct 2002 16:55:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KpLv32594 for ; Fri, 4 Oct 2002 16:51:21 -0400 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21308 for ; Fri, 4 Oct 2002 16:49:13 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA29210; Fri, 4 Oct 2002 13:51:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g94KpCM32093; Fri, 4 Oct 2002 13:51:12 -0700 X-mProtect: <200210042051> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBYIwYA; Fri, 04 Oct 2002 13:51:10 PDT Message-ID: <3D9DFF3E.A6735B18@iprg.nokia.com> Date: Fri, 04 Oct 2002 13:51:10 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. References: <9FBD322B7824D511B36900508BF93C9C05350BBA@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Gary, I reckon we will have something that works with proactive context transfer. Why not? It's not so closely bound with one-to-many dissemination as your note would indicate. Besides that, if we make the protocol complicated so that simple things are no longer simple, I think it would be a mistake. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 4 17:28:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22940 for ; Fri, 4 Oct 2002 17:28:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94LU9F02462 for seamoby-archive@odin.ietf.org; Fri, 4 Oct 2002 17:30:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94LU9v02459 for ; Fri, 4 Oct 2002 17:30:09 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22907 for ; Fri, 4 Oct 2002 17:28:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94Kthv32729; Fri, 4 Oct 2002 16:55:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KpLv32594 for ; Fri, 4 Oct 2002 16:51:21 -0400 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21308 for ; Fri, 4 Oct 2002 16:49:13 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA29210; Fri, 4 Oct 2002 13:51:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g94KpCM32093; Fri, 4 Oct 2002 13:51:12 -0700 X-mProtect: <200210042051> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBYIwYA; Fri, 04 Oct 2002 13:51:10 PDT Message-ID: <3D9DFF3E.A6735B18@iprg.nokia.com> Date: Fri, 04 Oct 2002 13:51:10 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. References: <9FBD322B7824D511B36900508BF93C9C05350BBA@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Gary, I reckon we will have something that works with proactive context transfer. Why not? It's not so closely bound with one-to-many dissemination as your note would indicate. Besides that, if we make the protocol complicated so that simple things are no longer simple, I think it would be a mistake. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 4 17:35:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23085 for ; Fri, 4 Oct 2002 17:35:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94L1jv00757; Fri, 4 Oct 2002 17:01:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KwFv00369 for ; Fri, 4 Oct 2002 16:58:15 -0400 Received: from zcars04f.ca.nortel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21596 for ; Fri, 4 Oct 2002 16:56:07 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g94KvrR25213; Fri, 4 Oct 2002 16:57:53 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Oct 2002 16:57:55 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05350BBB@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 16:57:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BE8.B2A22270" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C26BE8.B2A22270 Content-Type: text/plain; charset="iso-8859-1" Describe to me how you would support an active set in a distributed environment withou a one-to-many context transfer? Btw: given that we have designed such a protocol, and it's not "complex", I don't see the mistake that you fear so much. I can see that if the issue is how to modify HI/HACK or ICMP messages to perform one to many, there would be complexities, mostly due to the limitations of modifying existing protocols. Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: October 4, 2002 16:51 > To: Kenward, Gary [CAR:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] Reminder: Last Call for CT > Requirements Ends Wed. > > > > Hello Gary, > > I reckon we will have something that works with proactive > context transfer. Why not? It's not so closely bound with > one-to-many dissemination as your note would indicate. > Besides that, if we make the protocol complicated so that > simple things are no longer simple, I think it would be > a mistake. > > Regards, > Charlie P. > ------_=_NextPart_001_01C26BE8.B2A22270 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

Describe to me how you would support an active set in a distributed
environment withou a one-to-many context transfer?

Btw: given that we have designed such a protocol, and it's not "complex",
I don't see the mistake that you fear so much.

I can see that if the issue is how to modify HI/HACK or ICMP messages to
perform one to many, there would be complexities, mostly due to the
limitations of modifying existing protocols.

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: October 4, 2002 16:51
> To: Kenward, Gary [CAR:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] Reminder: Last Call for CT
> Requirements Ends Wed.
>
>
>
> Hello Gary,
>
> I reckon we will have something that works with proactive
> context transfer.  Why not?  It's not so closely bound with
> one-to-many dissemination as your note would indicate.
> Besides that, if we make the protocol complicated so that
> simple things are no longer simple, I think it would be
> a mistake.
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C26BE8.B2A22270-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 4 17:35:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23108 for ; Fri, 4 Oct 2002 17:35:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94LbOB03232 for seamoby-archive@odin.ietf.org; Fri, 4 Oct 2002 17:37:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94LbOv03228 for ; Fri, 4 Oct 2002 17:37:24 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23099 for ; Fri, 4 Oct 2002 17:35:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94L1jv00757; Fri, 4 Oct 2002 17:01:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94KwFv00369 for ; Fri, 4 Oct 2002 16:58:15 -0400 Received: from zcars04f.ca.nortel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21596 for ; Fri, 4 Oct 2002 16:56:07 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g94KvrR25213; Fri, 4 Oct 2002 16:57:53 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Oct 2002 16:57:55 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C05350BBB@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 16:57:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BE8.B2A22270" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C26BE8.B2A22270 Content-Type: text/plain; charset="iso-8859-1" Describe to me how you would support an active set in a distributed environment withou a one-to-many context transfer? Btw: given that we have designed such a protocol, and it's not "complex", I don't see the mistake that you fear so much. I can see that if the issue is how to modify HI/HACK or ICMP messages to perform one to many, there would be complexities, mostly due to the limitations of modifying existing protocols. Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: October 4, 2002 16:51 > To: Kenward, Gary [CAR:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] Reminder: Last Call for CT > Requirements Ends Wed. > > > > Hello Gary, > > I reckon we will have something that works with proactive > context transfer. Why not? It's not so closely bound with > one-to-many dissemination as your note would indicate. > Besides that, if we make the protocol complicated so that > simple things are no longer simple, I think it would be > a mistake. > > Regards, > Charlie P. > ------_=_NextPart_001_01C26BE8.B2A22270 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

Describe to me how you would support an active set in a distributed
environment withou a one-to-many context transfer?

Btw: given that we have designed such a protocol, and it's not "complex",
I don't see the mistake that you fear so much.

I can see that if the issue is how to modify HI/HACK or ICMP messages to
perform one to many, there would be complexities, mostly due to the
limitations of modifying existing protocols.

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: October 4, 2002 16:51
> To: Kenward, Gary [CAR:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] Reminder: Last Call for CT
> Requirements Ends Wed.
>
>
>
> Hello Gary,
>
> I reckon we will have something that works with proactive
> context transfer.  Why not?  It's not so closely bound with
> one-to-many dissemination as your note would indicate.
> Besides that, if we make the protocol complicated so that
> simple things are no longer simple, I think it would be
> a mistake.
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C26BE8.B2A22270-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 4 18:12:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23785 for ; Fri, 4 Oct 2002 18:12:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94M58v03989; Fri, 4 Oct 2002 18:05:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94M1Ov03887 for ; Fri, 4 Oct 2002 18:01:24 -0400 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23394 for ; Fri, 4 Oct 2002 17:59:16 -0400 (EDT) Message-ID: <017901c26bf1$51f3d5a0$476015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Nakhjiri Madjid-MNAKHJI1'" , References: <9FBD322B7824D511B36900508BF93C9C05350BBA@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 14:59:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Gary, Design teams are only closed while they are designing. The last word on the design comes from the working group. If the design team neglects something that you think is important, then you're perfectly free to bring it up after the initial design is complete. If the working group agrees, then it will become part of the design. jak ----- Original Message ----- From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" ; "'James Kempf'" ; Sent: Friday, October 04, 2002 1:41 PM Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. > Madjid: > > First, I agree with your observation about architecture. In my > view, you cannot talk about mobility solutions, without having a > fairly specific functional architecture and topology in mind. > > Next, I guess I would say that the is exactly as I feared. At > the moment, I believe CT is still "a" protocol, not a number of > similar but different protocols. And, as I said in response to > James, without this one to many capability, the protocol will > not at all meet the objectives I had in mind when considering what > would be needed to enable proactive preparation for handovers > and thus improve handover performance significantly. Consider > that 2G and 3G soft handovers require the equivalent of a > one-to-many transfer of context to establish the active set. > > This requirement is now effectively eliminated from > the list - that is, what you are stating is that it has been reduced > to a MAY so that the design team can ignore it . Since the design team > is a closed group, by the time this decision is apparent, it will > be too exhausting to argue that the "MAY" requirement should have > been included. > > There are many others requirements related to proactive CT > which very likely have no real meaning. I wonder if the IESG > will spot them? > > Gary > > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: October 4, 2002 16:13 > To: Kenward, Gary [CAR:AN10:EXCH]; 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. > > > Gary, > > > reading your email, I was thinking to myself that many of the requirements > are in fact > architectural requirements/features, until you mentioned it at the bottom of > your email. > > I agree with you on the distinction, but I doubt if you can use CT as a > protocol > without paving the way for its use in the architecture. Otherwise there > would be no > difference between CT and any messaging protocol. > > > Having said that, at this point, I felt that this support of this specific > feature would > cause conflict for some protocol design approaches that don't even need such > a feature. > While, the other features did not cause an alarm at the time of reading the > draft. > So call it may, call it Must optional, if that means I don't have to twist > the design to support > something that may not be needed in the first place. > > Regards, > > Madjid > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Friday, October 04, 2002 9:44 AM > To: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. > > > > My comment is past due, so it is immediately ignorable, but worth stating > if only for future reference.... > > When I first read through Madjid's proposed change my reaction was simply, > and honestly, I did not really care. Manufacturers and network engineers > have been known to ignore IETF recommendations in the past, so changing > SHOULD to MAY did not seem to have much impact. > > However, in considering the change a second time (in the process of updating > > the draft), I sensed a subtle problem in the argument; a problem that has > been discussed in the past in this group. Madjid, if I have misinterpreted > your reasoning, please correct me. > > The CT requirements draft is NOT, as far as I know, a requirements document > for the deployment of a system that supports CT. Clearly, a deployment of CT > > capabilities would be at the discretion of all the entities involved in > actually > building the network - the network operator, the network engineer, and even > as > Madjid points out, the equipment vendor. It would be reasonable to try and > anticipate those CT features that an operator might want to be optional, > BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT. > > The CT requirements draft IS a requirements draft for the CT protocol. It is > > intended to provide a template for eventual protocol draft submissions. > Ideally, > out of these submissions, only one proposal will be selected. A MAY in the > CT > requirements draft essentially states that a protocol proposal need not > consider > supporting this feature. A MAY in the CT requirements draft does NOT mean > that > the feature should be one that can be optionally enabled or disabled by > someone > implementing or deploying the CT solution. A MAY clearly indicates that > protocol > proposals can completely ignore the requirement, and if one of these > protocols > is selected by the working group, the feature will likely never be available > to > the vendor, the network engineer or the operator. > > The proper way to specify requirements that must be supported by the CT > protocol, > but must also must be optional for implementation is to state that in a > second > requirement. Thus, 4.6 should not be changed to a "MAY", but should be > augmented > with a second requirement that states that 4.6 MUST be an optional feature. > > In identifying this subtlety, I wonder how many of the requirements in the > CT > draft are actually system requirements and not protocol requirements. I am, > at this point, somewhat hesitant to look at this point. However, a CT > protocol > that does not support of feature means that the feature will never be > available > to anyone. > > Gary Kenward > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com > ] > > Sent: September 24, 2002 12:19 > > To: 'James Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements > > Ends Wed. > > > > > > Reading from 2119 > > > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course > > > > MAY This word, or the adjective "OPTIONAL", mean that an item is > > truly optional. One vendor may choose to include the item > > because a > > particular marketplace requires it or because the vendor feels that > > it enhances the product while another vendor may omit the > > same item. > > ...... > > > > > > It means you need to fully understand the implication of not > > supporting > > a SHOULD item, before you exclude it. On the other hand if it > > is something > > that may be useful in some cases, a may is more appropriate. > > > > Looking at 4.6, I would say one-to-many context transfer is not > > an item that its "not use" needs to be investigated, but its "use" > > needs careful considerations. > > Example: > > If you are dealing with dynamic context that is affected by > > flow of data > > at a specific AR (header compression, or measurement based > > QoS context) > > sending the context through a whole bunch of ARs that may not even see > > the data causes serious synchronization issues for such context. > > > > Based on this counter-example: > > I say this requirement should be changed to "may" unless it > > is stated that > > SHOULD only applies to the context whose value is not > > affected by data flow. > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > ] > > Sent: Monday, September 23, 2002 11:24 AM > > To: seamoby@ietf.org > > Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed. > > > > > > A reminder: last call for the CT requirements document > > (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept > > 25. So far, we have > > not received any comments. If you have any comments, please > > send them to the > > list by that date. > > > > jak > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 4 18:12:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23803 for ; Fri, 4 Oct 2002 18:12:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g94MECI04795 for seamoby-archive@odin.ietf.org; Fri, 4 Oct 2002 18:14:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94MECv04792 for ; Fri, 4 Oct 2002 18:14:12 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23799 for ; Fri, 4 Oct 2002 18:12:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94M58v03989; Fri, 4 Oct 2002 18:05:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g94M1Ov03887 for ; Fri, 4 Oct 2002 18:01:24 -0400 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23394 for ; Fri, 4 Oct 2002 17:59:16 -0400 (EDT) Message-ID: <017901c26bf1$51f3d5a0$476015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Nakhjiri Madjid-MNAKHJI1'" , References: <9FBD322B7824D511B36900508BF93C9C05350BBA@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. Date: Fri, 4 Oct 2002 14:59:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gary, Design teams are only closed while they are designing. The last word on the design comes from the working group. If the design team neglects something that you think is important, then you're perfectly free to bring it up after the initial design is complete. If the working group agrees, then it will become part of the design. jak ----- Original Message ----- From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" ; "'James Kempf'" ; Sent: Friday, October 04, 2002 1:41 PM Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. > Madjid: > > First, I agree with your observation about architecture. In my > view, you cannot talk about mobility solutions, without having a > fairly specific functional architecture and topology in mind. > > Next, I guess I would say that the is exactly as I feared. At > the moment, I believe CT is still "a" protocol, not a number of > similar but different protocols. And, as I said in response to > James, without this one to many capability, the protocol will > not at all meet the objectives I had in mind when considering what > would be needed to enable proactive preparation for handovers > and thus improve handover performance significantly. Consider > that 2G and 3G soft handovers require the equivalent of a > one-to-many transfer of context to establish the active set. > > This requirement is now effectively eliminated from > the list - that is, what you are stating is that it has been reduced > to a MAY so that the design team can ignore it . Since the design team > is a closed group, by the time this decision is apparent, it will > be too exhausting to argue that the "MAY" requirement should have > been included. > > There are many others requirements related to proactive CT > which very likely have no real meaning. I wonder if the IESG > will spot them? > > Gary > > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: October 4, 2002 16:13 > To: Kenward, Gary [CAR:AN10:EXCH]; 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. > > > Gary, > > > reading your email, I was thinking to myself that many of the requirements > are in fact > architectural requirements/features, until you mentioned it at the bottom of > your email. > > I agree with you on the distinction, but I doubt if you can use CT as a > protocol > without paving the way for its use in the architecture. Otherwise there > would be no > difference between CT and any messaging protocol. > > > Having said that, at this point, I felt that this support of this specific > feature would > cause conflict for some protocol design approaches that don't even need such > a feature. > While, the other features did not cause an alarm at the time of reading the > draft. > So call it may, call it Must optional, if that means I don't have to twist > the design to support > something that may not be needed in the first place. > > Regards, > > Madjid > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Friday, October 04, 2002 9:44 AM > To: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed. > > > > My comment is past due, so it is immediately ignorable, but worth stating > if only for future reference.... > > When I first read through Madjid's proposed change my reaction was simply, > and honestly, I did not really care. Manufacturers and network engineers > have been known to ignore IETF recommendations in the past, so changing > SHOULD to MAY did not seem to have much impact. > > However, in considering the change a second time (in the process of updating > > the draft), I sensed a subtle problem in the argument; a problem that has > been discussed in the past in this group. Madjid, if I have misinterpreted > your reasoning, please correct me. > > The CT requirements draft is NOT, as far as I know, a requirements document > for the deployment of a system that supports CT. Clearly, a deployment of CT > > capabilities would be at the discretion of all the entities involved in > actually > building the network - the network operator, the network engineer, and even > as > Madjid points out, the equipment vendor. It would be reasonable to try and > anticipate those CT features that an operator might want to be optional, > BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT. > > The CT requirements draft IS a requirements draft for the CT protocol. It is > > intended to provide a template for eventual protocol draft submissions. > Ideally, > out of these submissions, only one proposal will be selected. A MAY in the > CT > requirements draft essentially states that a protocol proposal need not > consider > supporting this feature. A MAY in the CT requirements draft does NOT mean > that > the feature should be one that can be optionally enabled or disabled by > someone > implementing or deploying the CT solution. A MAY clearly indicates that > protocol > proposals can completely ignore the requirement, and if one of these > protocols > is selected by the working group, the feature will likely never be available > to > the vendor, the network engineer or the operator. > > The proper way to specify requirements that must be supported by the CT > protocol, > but must also must be optional for implementation is to state that in a > second > requirement. Thus, 4.6 should not be changed to a "MAY", but should be > augmented > with a second requirement that states that 4.6 MUST be an optional feature. > > In identifying this subtlety, I wonder how many of the requirements in the > CT > draft are actually system requirements and not protocol requirements. I am, > at this point, somewhat hesitant to look at this point. However, a CT > protocol > that does not support of feature means that the feature will never be > available > to anyone. > > Gary Kenward > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com > ] > > Sent: September 24, 2002 12:19 > > To: 'James Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements > > Ends Wed. > > > > > > Reading from 2119 > > > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course > > > > MAY This word, or the adjective "OPTIONAL", mean that an item is > > truly optional. One vendor may choose to include the item > > because a > > particular marketplace requires it or because the vendor feels that > > it enhances the product while another vendor may omit the > > same item. > > ...... > > > > > > It means you need to fully understand the implication of not > > supporting > > a SHOULD item, before you exclude it. On the other hand if it > > is something > > that may be useful in some cases, a may is more appropriate. > > > > Looking at 4.6, I would say one-to-many context transfer is not > > an item that its "not use" needs to be investigated, but its "use" > > needs careful considerations. > > Example: > > If you are dealing with dynamic context that is affected by > > flow of data > > at a specific AR (header compression, or measurement based > > QoS context) > > sending the context through a whole bunch of ARs that may not even see > > the data causes serious synchronization issues for such context. > > > > Based on this counter-example: > > I say this requirement should be changed to "may" unless it > > is stated that > > SHOULD only applies to the context whose value is not > > affected by data flow. > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > ] > > Sent: Monday, September 23, 2002 11:24 AM > > To: seamoby@ietf.org > > Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed. > > > > > > A reminder: last call for the CT requirements document > > (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept > > 25. So far, we have > > not received any comments. If you have any comments, please > > send them to the > > list by that date. > > > > jak > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 7 12:58:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26934 for ; Mon, 7 Oct 2002 12:58:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97Gtcv28997; Mon, 7 Oct 2002 12:55:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97Gmqv28699 for ; Mon, 7 Oct 2002 12:48:52 -0400 Received: from 46.49.33.07 (216-91-88-22.biltmorecomm.com [216.91.88.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26477 for ; Mon, 7 Oct 2002 12:46:42 -0400 (EDT) Message-Id: <200210071646.MAA26477@ietf.org> From: WebXperts.Design@ietf.org, "Inc." To: Seamoby@ietf.org Reply-To: WebBuilders@YourService.com Date: Mon, 07 Oct 2002 12:50:02 -0400 MIME-Version: 1.0 Content-Type: multipart/related; boundary="3817d9ac-b246-4085-acb6-c9da635125cf" Subject: [Seamoby] We Build The Internet. WebXperts Design, Inc. (Design / Programming / Consultation) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format --3817d9ac-b246-4085-acb6-c9da635125cf Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We Build The Internet. WebXperts Design, Inc.
If This Flyer does not appear correctly and/or images do not appear, please = click the following link: www.webxwireless.com


Your email address was obtained from a purchased list. You are receiving this = from Eluxmedia LLC, and are a part of their mailing list. If you wish to = unsubscribe from this list, please click here and enter = your name into the remove box.

If you have previously unsubscribed and are still receiving this message, = you may email our Abuse Control = Center.
--3817d9ac-b246-4085-acb6-c9da635125cf-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 7 12:58:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26969 for ; Mon, 7 Oct 2002 12:58:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g97H0T429392 for seamoby-archive@odin.ietf.org; Mon, 7 Oct 2002 13:00:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97H0Tv29389 for ; Mon, 7 Oct 2002 13:00:29 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26948 for ; Mon, 7 Oct 2002 12:58:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97Gtcv28997; Mon, 7 Oct 2002 12:55:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97Gmqv28699 for ; Mon, 7 Oct 2002 12:48:52 -0400 Received: from 46.49.33.07 (216-91-88-22.biltmorecomm.com [216.91.88.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26477 for ; Mon, 7 Oct 2002 12:46:42 -0400 (EDT) Message-Id: <200210071646.MAA26477@ietf.org> From: WebXperts.Design@ietf.org, "Inc." To: Seamoby@ietf.org Reply-To: WebBuilders@YourService.com Date: Mon, 07 Oct 2002 12:50:02 -0400 MIME-Version: 1.0 Content-Type: multipart/related; boundary="3817d9ac-b246-4085-acb6-c9da635125cf" Subject: [Seamoby] We Build The Internet. WebXperts Design, Inc. (Design / Programming / Consultation) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format --3817d9ac-b246-4085-acb6-c9da635125cf Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We Build The Internet. WebXperts Design, Inc.
If This Flyer does not appear correctly and/or images do not appear, please = click the following link: www.webxwireless.com


Your email address was obtained from a purchased list. You are receiving this = from Eluxmedia LLC, and are a part of their mailing list. If you wish to = unsubscribe from this list, please click here and enter = your name into the remove box.

If you have previously unsubscribed and are still receiving this message, = you may email our Abuse Control = Center.
--3817d9ac-b246-4085-acb6-c9da635125cf-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 7 13:19:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27543 for ; Mon, 7 Oct 2002 13:19:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97GqYv28915; Mon, 7 Oct 2002 12:52:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97Gmov28695 for ; Mon, 7 Oct 2002 12:48:50 -0400 Received: from 46.49.33.07 (216-91-88-22.biltmorecomm.com [216.91.88.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26471 for ; Mon, 7 Oct 2002 12:46:38 -0400 (EDT) Message-Id: <200210071646.MAA26471@ietf.org> From: WebXperts.Design@ietf.org, "Inc." To: seamoby@ietf.org Reply-To: WebBuilders@YourService.com Date: Mon, 07 Oct 2002 12:49:59 -0400 MIME-Version: 1.0 Content-Type: multipart/related; boundary="3817d9ac-b246-4085-acb6-c9da635125cf" Subject: [Seamoby] We Build The Internet. WebXperts Design, Inc. (Design / Programming / Consultation) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format --3817d9ac-b246-4085-acb6-c9da635125cf Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We Build The Internet. WebXperts Design, Inc.
If This Flyer does not appear correctly and/or images do not appear, please = click the following link: www.webxwireless.com


Your email address was obtained from a purchased list. You are receiving this = from Eluxmedia LLC, and are a part of their mailing list. If you wish to = unsubscribe from this list, please click here and enter = your name into the remove box.

If you have previously unsubscribed and are still receiving this message, = you may email our Abuse Control = Center.
--3817d9ac-b246-4085-acb6-c9da635125cf-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 7 13:20:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27576 for ; Mon, 7 Oct 2002 13:20:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g97HLp830579 for seamoby-archive@odin.ietf.org; Mon, 7 Oct 2002 13:21:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97HLov30576 for ; Mon, 7 Oct 2002 13:21:50 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27557 for ; Mon, 7 Oct 2002 13:19:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97GqYv28915; Mon, 7 Oct 2002 12:52:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g97Gmov28695 for ; Mon, 7 Oct 2002 12:48:50 -0400 Received: from 46.49.33.07 (216-91-88-22.biltmorecomm.com [216.91.88.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26471 for ; Mon, 7 Oct 2002 12:46:38 -0400 (EDT) Message-Id: <200210071646.MAA26471@ietf.org> From: WebXperts.Design@ietf.org, "Inc." To: seamoby@ietf.org Reply-To: WebBuilders@YourService.com Date: Mon, 07 Oct 2002 12:49:59 -0400 MIME-Version: 1.0 Content-Type: multipart/related; boundary="3817d9ac-b246-4085-acb6-c9da635125cf" Subject: [Seamoby] We Build The Internet. WebXperts Design, Inc. (Design / Programming / Consultation) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format --3817d9ac-b246-4085-acb6-c9da635125cf Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We Build The Internet. WebXperts Design, Inc.
If This Flyer does not appear correctly and/or images do not appear, please = click the following link: www.webxwireless.com


Your email address was obtained from a purchased list. You are receiving this = from Eluxmedia LLC, and are a part of their mailing list. If you wish to = unsubscribe from this list, please click here and enter = your name into the remove box.

If you have previously unsubscribed and are still receiving this message, = you may email our Abuse Control = Center.
--3817d9ac-b246-4085-acb6-c9da635125cf-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Oct 8 07:20:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06630 for ; Tue, 8 Oct 2002 07:20:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98BHWv28867; Tue, 8 Oct 2002 07:17:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98BFUv28790 for ; Tue, 8 Oct 2002 07:15:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05995; Tue, 8 Oct 2002 07:13:19 -0400 (EDT) Message-Id: <200210081113.HAA05995@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Oct 2002 07:13:18 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-ct-reqs-05.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : General Requirements for a Context Transfer Author(s) : G. Kenward Filename : draft-ietf-seamoby-ct-reqs-05.txt Pages : 10 Date : 2002-10-7 The success of time sensitive services like VoIP telephony, video, etc., in a mobile environment depends heavily on the ability to minimize the impact of the traffic redirection during a change of packet forwarding path. In the process of establishing the new forwarding path, the nodes along the new path must be prepared to provide similar forwarding treatment to the IP packets. The transfer of context information may be advantageous in minimizing the impact of host mobility on IP services. This document captures the set of requirements for a context transfer framework and the requirements for a generic context transfer protocol to carry the context between the context transfer peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-ct-reqs-05.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-seamoby-ct-reqs-05.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-seamoby-ct-reqs-05.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-10-7141019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-ct-reqs-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-ct-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-7141019.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 8 07:21:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06670 for ; Tue, 8 Oct 2002 07:21:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g98BN2u29206 for seamoby-archive@odin.ietf.org; Tue, 8 Oct 2002 07:23:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98BN2v29203 for ; Tue, 8 Oct 2002 07:23:02 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06651 for ; Tue, 8 Oct 2002 07:20:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98BHWv28867; Tue, 8 Oct 2002 07:17:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98BFUv28790 for ; Tue, 8 Oct 2002 07:15:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05995; Tue, 8 Oct 2002 07:13:19 -0400 (EDT) Message-Id: <200210081113.HAA05995@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Oct 2002 07:13:18 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-ct-reqs-05.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : General Requirements for a Context Transfer Author(s) : G. Kenward Filename : draft-ietf-seamoby-ct-reqs-05.txt Pages : 10 Date : 2002-10-7 The success of time sensitive services like VoIP telephony, video, etc., in a mobile environment depends heavily on the ability to minimize the impact of the traffic redirection during a change of packet forwarding path. In the process of establishing the new forwarding path, the nodes along the new path must be prepared to provide similar forwarding treatment to the IP packets. The transfer of context information may be advantageous in minimizing the impact of host mobility on IP services. This document captures the set of requirements for a context transfer framework and the requirements for a generic context transfer protocol to carry the context between the context transfer peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-ct-reqs-05.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-seamoby-ct-reqs-05.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-seamoby-ct-reqs-05.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-10-7141019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-ct-reqs-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-ct-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-7141019.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Oct 8 09:13:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10951 for ; Tue, 8 Oct 2002 09:13:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98DBSv02896; Tue, 8 Oct 2002 09:11:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98DArv02874 for ; Tue, 8 Oct 2002 09:10:53 -0400 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10701 for ; Tue, 8 Oct 2002 09:08:45 -0400 (EDT) Message-Id: <200210081308.JAA10701@ietf.org> From: "Angélica Díaz" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="= Multipart Boundary 1008021511" Date: Tue, 8 Oct 2002 15:11:05 +0200 Subject: [Seamoby] (no subject) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multipart MIME message. --= Multipart Boundary 1008021511 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit --= Multipart Boundary 1008021511 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit
 
--= Multipart Boundary 1008021511-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 8 09:13:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10990 for ; Tue, 8 Oct 2002 09:13:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g98DFUC03078 for seamoby-archive@odin.ietf.org; Tue, 8 Oct 2002 09:15:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98DFUv03075 for ; Tue, 8 Oct 2002 09:15:30 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10967 for ; Tue, 8 Oct 2002 09:13:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98DBSv02896; Tue, 8 Oct 2002 09:11:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98DArv02874 for ; Tue, 8 Oct 2002 09:10:53 -0400 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10701 for ; Tue, 8 Oct 2002 09:08:45 -0400 (EDT) Message-Id: <200210081308.JAA10701@ietf.org> From: "Angélica Díaz" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="= Multipart Boundary 1008021511" Date: Tue, 8 Oct 2002 15:11:05 +0200 Subject: [Seamoby] (no subject) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multipart MIME message. --= Multipart Boundary 1008021511 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit --= Multipart Boundary 1008021511 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit
 
--= Multipart Boundary 1008021511-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Oct 13 12:06:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21450 for ; Sun, 13 Oct 2002 12:06:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9DG80v03720; Sun, 13 Oct 2002 12:08:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9DG61v03133 for ; Sun, 13 Oct 2002 12:06:01 -0400 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21374 for ; Sun, 13 Oct 2002 12:03:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 3.36 #2) id 180lFc-000F3k-00; Sun, 13 Oct 2002 09:05:56 -0700 To: seamoby@ietf.org Cc: kempf@docomolabs-usa.com, pcalhoun@bstormnetworks.com, sob@harvard.edu Reply-To: mankin@psg.com Date: Sun, 13 Oct 2002 09:05:56 -0700 From: Allison Mankin Message-Id: Subject: [Seamoby] AD: more about draft-ietf-seamoby-cardiscovery-issues-03.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Folks, There was a bit more IESG discussion of draft-ietf-seamoby-cardiscovery-issues since I wrote to the list with Steve Bellovin's and my comments. This note is to convey the few more IESG comments, which must be addressed by by the rev of cardiscovery-issues. The new comments are from Randy Bush. I interleaved some guidance as your AD. The editors of -issues and -requirements* should get their revs in asap now. I plan to approve -issues. IESG won't review it again. Here are Randy Bush's IESG comments: > > in sec 3 scenario 2, if > > it is possible that the new AR does not have the capability to > support the MN's application. The MN can then be informed about > this fact when it is still connected to the current AR. > > what the heck might the MN do? maybe give a clue, e.g., push it up > the stack and tell the user not to move, advise on which sub-choice > in direction to move might give the best, though insufficient, > service, etc. [My guidance here: the issues document should note there are issues around what to do with a failure of the capability match - this is related to the complexity point I raised - the requirements editor needs to mention that there is some requirement on this - it's not mentioned.] > sec 5, might you want to certify MNs, ARs, and APs? i.e. don't > allocate resources to an illegitimate MN, detect an intruder AP or > AR, etc. [AD: The issues draft should consider how much ARs and APs in CAR discovery also certify/authorize the MNs...Steve's request has already asked for you to put in issues about certify/authorize/sign info on the AR/AP] Allison _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Oct 13 12:07:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21499 for ; Sun, 13 Oct 2002 12:07:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9DG8tb03733 for seamoby-archive@odin.ietf.org; Sun, 13 Oct 2002 12:08:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9DG8tv03730 for ; Sun, 13 Oct 2002 12:08:55 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21492 for ; Sun, 13 Oct 2002 12:06:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9DG80v03720; Sun, 13 Oct 2002 12:08:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9DG61v03133 for ; Sun, 13 Oct 2002 12:06:01 -0400 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21374 for ; Sun, 13 Oct 2002 12:03:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 3.36 #2) id 180lFc-000F3k-00; Sun, 13 Oct 2002 09:05:56 -0700 To: seamoby@ietf.org Cc: kempf@docomolabs-usa.com, pcalhoun@bstormnetworks.com, sob@harvard.edu Reply-To: mankin@psg.com Date: Sun, 13 Oct 2002 09:05:56 -0700 From: Allison Mankin Message-Id: Subject: [Seamoby] AD: more about draft-ietf-seamoby-cardiscovery-issues-03.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Folks, There was a bit more IESG discussion of draft-ietf-seamoby-cardiscovery-issues since I wrote to the list with Steve Bellovin's and my comments. This note is to convey the few more IESG comments, which must be addressed by by the rev of cardiscovery-issues. The new comments are from Randy Bush. I interleaved some guidance as your AD. The editors of -issues and -requirements* should get their revs in asap now. I plan to approve -issues. IESG won't review it again. Here are Randy Bush's IESG comments: > > in sec 3 scenario 2, if > > it is possible that the new AR does not have the capability to > support the MN's application. The MN can then be informed about > this fact when it is still connected to the current AR. > > what the heck might the MN do? maybe give a clue, e.g., push it up > the stack and tell the user not to move, advise on which sub-choice > in direction to move might give the best, though insufficient, > service, etc. [My guidance here: the issues document should note there are issues around what to do with a failure of the capability match - this is related to the complexity point I raised - the requirements editor needs to mention that there is some requirement on this - it's not mentioned.] > sec 5, might you want to certify MNs, ARs, and APs? i.e. don't > allocate resources to an illegitimate MN, detect an intruder AP or > AR, etc. [AD: The issues draft should consider how much ARs and APs in CAR discovery also certify/authorize the MNs...Steve's request has already asked for you to put in issues about certify/authorize/sign info on the AR/AP] Allison _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 14 11:24:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23656 for ; Mon, 14 Oct 2002 11:24:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EFPTv05633; Mon, 14 Oct 2002 11:25:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EFOJv05591 for ; Mon, 14 Oct 2002 11:24:19 -0400 Received: from 168.160.251.52 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23598 for ; Mon, 14 Oct 2002 11:22:01 -0400 (EDT) Message-Id: <200210141522.LAA23598@ietf.org> Content-Transfer-Encoding: binary Content-Type: multipart/alternative; boundary="_----------=_1034609198272153" MIME-Version: 1.0 Date: Mon, 14 Oct 2002 15:26:38 UT From: "Rick Ruben" To: seamoby@ietf.org Return-Errors-To: Reply-To: X-Sender: "Rick Ruben" X-Mime-Flavour: eJxjYmFiYuR3DYoM0VOwYtFRdgmXiXELAgAiJwPl Subject: [Seamoby] hi Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --_----------=_1034609198272153 Content-Disposition: inline Content-Length: 3 Content-Type: text/plain Content-Transfer-Encoding: binary hey --_----------=_1034609198272153 Content-Disposition: inline Content-Length: 225 Content-Type: text/html Content-Transfer-Encoding: binary I remembered this time friend! --_----------=_1034609198272153-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 14 11:24:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23676 for ; Mon, 14 Oct 2002 11:24:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EFQN905686 for seamoby-archive@odin.ietf.org; Mon, 14 Oct 2002 11:26:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EFQNv05683 for ; Mon, 14 Oct 2002 11:26:23 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23670 for ; Mon, 14 Oct 2002 11:24:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EFPTv05633; Mon, 14 Oct 2002 11:25:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EFOJv05591 for ; Mon, 14 Oct 2002 11:24:19 -0400 Received: from 168.160.251.52 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23598 for ; Mon, 14 Oct 2002 11:22:01 -0400 (EDT) Message-Id: <200210141522.LAA23598@ietf.org> Content-Transfer-Encoding: binary Content-Type: multipart/alternative; boundary="_----------=_1034609198272153" MIME-Version: 1.0 Date: Mon, 14 Oct 2002 15:26:38 UT From: "Rick Ruben" To: seamoby@ietf.org Return-Errors-To: Reply-To: X-Sender: "Rick Ruben" X-Mime-Flavour: eJxjYmFiYuR3DYoM0VOwYtFRdgmXiXELAgAiJwPl Subject: [Seamoby] hi Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --_----------=_1034609198272153 Content-Disposition: inline Content-Length: 3 Content-Type: text/plain Content-Transfer-Encoding: binary hey --_----------=_1034609198272153 Content-Disposition: inline Content-Length: 225 Content-Type: text/html Content-Transfer-Encoding: binary I remembered this time friend! --_----------=_1034609198272153-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 14 12:49:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25856 for ; Mon, 14 Oct 2002 12:49:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EGjZv10216; Mon, 14 Oct 2002 12:45:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EGikv10189 for ; Mon, 14 Oct 2002 12:44:46 -0400 Received: from 61.178.23.90 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25502 for ; Mon, 14 Oct 2002 12:42:31 -0400 (EDT) Message-Id: <200210141642.MAA25502@ietf.org> Content-Transfer-Encoding: binary Content-Type: multipart/alternative; boundary="_----------=_103461403243079" MIME-Version: 1.0 Date: Mon, 14 Oct 2002 16:47:12 UT From: "Rick Ruben" To: seamoby@ietf.org Return-Errors-To: Reply-To: X-Sender: "Rick Ruben" X-Mime-Flavour: eJxjYmFiYOV3DYoM0VOwYtFRdgmXiXELAgAiSQPn Subject: [Seamoby] hi Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --_----------=_103461403243079 Content-Disposition: inline Content-Length: 3 Content-Type: text/plain Content-Transfer-Encoding: binary hey --_----------=_103461403243079 Content-Disposition: inline Content-Length: 233 Content-Type: text/html Content-Transfer-Encoding: binary I remembered this time friend! --_----------=_103461403243079-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 14 12:49:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25884 for ; Mon, 14 Oct 2002 12:49:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9EGpbT10602 for seamoby-archive@odin.ietf.org; Mon, 14 Oct 2002 12:51:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EGpbv10599 for ; Mon, 14 Oct 2002 12:51:37 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25871 for ; Mon, 14 Oct 2002 12:49:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EGjZv10216; Mon, 14 Oct 2002 12:45:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EGikv10189 for ; Mon, 14 Oct 2002 12:44:46 -0400 Received: from 61.178.23.90 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25502 for ; Mon, 14 Oct 2002 12:42:31 -0400 (EDT) Message-Id: <200210141642.MAA25502@ietf.org> Content-Transfer-Encoding: binary Content-Type: multipart/alternative; boundary="_----------=_103461403243079" MIME-Version: 1.0 Date: Mon, 14 Oct 2002 16:47:12 UT From: "Rick Ruben" To: seamoby@ietf.org Return-Errors-To: Reply-To: X-Sender: "Rick Ruben" X-Mime-Flavour: eJxjYmFiYOV3DYoM0VOwYtFRdgmXiXELAgAiSQPn Subject: [Seamoby] hi Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --_----------=_103461403243079 Content-Disposition: inline Content-Length: 3 Content-Type: text/plain Content-Transfer-Encoding: binary hey --_----------=_103461403243079 Content-Disposition: inline Content-Length: 233 Content-Type: text/html Content-Transfer-Encoding: binary I remembered this time friend! --_----------=_103461403243079-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Oct 15 14:51:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11729 for ; Tue, 15 Oct 2002 14:51:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIlmv00675; Tue, 15 Oct 2002 14:47:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIkNv00623 for ; Tue, 15 Oct 2002 14:46:23 -0400 Received: from web14906.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11455 for ; Tue, 15 Oct 2002 14:44:08 -0400 (EDT) Message-ID: <20021015184618.66747.qmail@web14906.mail.yahoo.com> Received: from [208.28.84.65] by web14906.mail.yahoo.com via HTTP; Tue, 15 Oct 2002 11:46:18 PDT Date: Tue, 15 Oct 2002 11:46:18 -0700 (PDT) From: Sharif Shahrier To: mobile-ip@sunroof.eng.sun.com, seamoby@ietf.org, nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Seamoby] Carl Williams e-mail Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi, Could Carl Williams please send me e-mail directly, so I have his e-mail address. I was working on a draft with him, but don't have access to my old computer right now. I am not subscribed to any IETFl ists. Thus, I'll be glad if Carl can send me e-mail so we can establish communication. Thanks. Sharif. __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 15 14:52:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11755 for ; Tue, 15 Oct 2002 14:52:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FIrl600887 for seamoby-archive@odin.ietf.org; Tue, 15 Oct 2002 14:53:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIrkv00884 for ; Tue, 15 Oct 2002 14:53:46 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11743 for ; Tue, 15 Oct 2002 14:51:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIlmv00675; Tue, 15 Oct 2002 14:47:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FIkNv00623 for ; Tue, 15 Oct 2002 14:46:23 -0400 Received: from web14906.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11455 for ; Tue, 15 Oct 2002 14:44:08 -0400 (EDT) Message-ID: <20021015184618.66747.qmail@web14906.mail.yahoo.com> Received: from [208.28.84.65] by web14906.mail.yahoo.com via HTTP; Tue, 15 Oct 2002 11:46:18 PDT Date: Tue, 15 Oct 2002 11:46:18 -0700 (PDT) From: Sharif Shahrier To: mobile-ip@sunroof.eng.sun.com, seamoby@ietf.org, nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Seamoby] Carl Williams e-mail Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi, Could Carl Williams please send me e-mail directly, so I have his e-mail address. I was working on a draft with him, but don't have access to my old computer right now. I am not subscribed to any IETFl ists. Thus, I'll be glad if Carl can send me e-mail so we can establish communication. Thanks. Sharif. __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Oct 16 11:41:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03758 for ; Wed, 16 Oct 2002 11:41:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GFVUv09909; Wed, 16 Oct 2002 11:31:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GFU8v09831 for ; Wed, 16 Oct 2002 11:30:08 -0400 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03355 for ; Wed, 16 Oct 2002 11:27:54 -0400 (EDT) From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Oct 2002 08:30:09 +0000 Message-Id: <1034757010.24526.41.camel@dhcp-229-243> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Atlanta Meeting Administrivia Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All, It is time to start setting the agenda for the Atlanta meeting. If you want to discuss issues with drafts at the Atlanta meeting, please request a slot to do so, by sending mail to the WG chairs. As always the slots will be allocated for discussions according to what is outlined below. It is not the purpose of a WG session to have presentation of the content of a document. It is assumed that all attendees will have read the drafts in advance of the meeting. For documents that are work-in-progress, the presentation should cover issues resolved since the last draft followed by open issues, and controversial topics with the intent to reach a resolution of said issues and topics. For new work items, the presentation should focus on what the problem is and why it is necessary for the work group to address it. Further it must be shown how the work falls within the existing charter; no time will be allocated for proposals that do not fit the current WG charter. The solution should only be sketched. The appropriate way of bringing new work to the working group is to post an Internet Draft, send a pointer to the draft to the mailing list and promote discussion on the list. Slots on the agenda should be used to discuss outstanding topics that haven't been settled on the mailing list. In all cases only a limited number of slides should be used. Speakers should budget their at least 25% of their time to allow for discussion/questions. Below is a proposed agenda for the Atlanta meeting: 1. Agenda Bashing (2 mins) - Chairs 2. Draft Status (10 mins) - Chairs 2.1 CT Requirements Draft update 2.2 CAR PS & Req Draft update 3. Brief discussion on terminology draft (10 mins) - Jukka 4. Issues with CAR (20 mins) - Ajoy or Marco 5. Issues with CT (20 mins) - John L Thanks, Pat & James _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Oct 16 11:41:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03814 for ; Wed, 16 Oct 2002 11:41:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GFhMA10947 for seamoby-archive@odin.ietf.org; Wed, 16 Oct 2002 11:43:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GFhMv10944 for ; Wed, 16 Oct 2002 11:43:22 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03772 for ; Wed, 16 Oct 2002 11:41:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GFVUv09909; Wed, 16 Oct 2002 11:31:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GFU8v09831 for ; Wed, 16 Oct 2002 11:30:08 -0400 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03355 for ; Wed, 16 Oct 2002 11:27:54 -0400 (EDT) From: Pat Calhoun To: seamoby@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Oct 2002 08:30:09 +0000 Message-Id: <1034757010.24526.41.camel@dhcp-229-243> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Atlanta Meeting Administrivia Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, It is time to start setting the agenda for the Atlanta meeting. If you want to discuss issues with drafts at the Atlanta meeting, please request a slot to do so, by sending mail to the WG chairs. As always the slots will be allocated for discussions according to what is outlined below. It is not the purpose of a WG session to have presentation of the content of a document. It is assumed that all attendees will have read the drafts in advance of the meeting. For documents that are work-in-progress, the presentation should cover issues resolved since the last draft followed by open issues, and controversial topics with the intent to reach a resolution of said issues and topics. For new work items, the presentation should focus on what the problem is and why it is necessary for the work group to address it. Further it must be shown how the work falls within the existing charter; no time will be allocated for proposals that do not fit the current WG charter. The solution should only be sketched. The appropriate way of bringing new work to the working group is to post an Internet Draft, send a pointer to the draft to the mailing list and promote discussion on the list. Slots on the agenda should be used to discuss outstanding topics that haven't been settled on the mailing list. In all cases only a limited number of slides should be used. Speakers should budget their at least 25% of their time to allow for discussion/questions. Below is a proposed agenda for the Atlanta meeting: 1. Agenda Bashing (2 mins) - Chairs 2. Draft Status (10 mins) - Chairs 2.1 CT Requirements Draft update 2.2 CAR PS & Req Draft update 3. Brief discussion on terminology draft (10 mins) - Jukka 4. Issues with CAR (20 mins) - Ajoy or Marco 5. Issues with CT (20 mins) - John L Thanks, Pat & James _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 18 03:30:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17556 for ; Fri, 18 Oct 2002 03:30:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7Uxv27544; Fri, 18 Oct 2002 03:30:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7TWv27496 for ; Fri, 18 Oct 2002 03:29:32 -0400 Received: from webdb.cs.ndsu.nodak.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17533 for ; Fri, 18 Oct 2002 03:27:09 -0400 (EDT) Received: from localhost (mylvarab@localhost) by webdb.cs.ndsu.nodak.edu (8.11.1/8.11.1) with SMTP id g9I7TKv98182 for ; Fri, 18 Oct 2002 02:29:21 -0500 (CDT) (envelope-from mylvarab@webdb.cs.ndsu.nodak.edu) Date: Fri, 18 Oct 2002 02:29:20 -0500 (CDT) From: Prashanth Mylvarabatla Reply-To: Prashanth Mylvarabatla To: seamoby@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] rfc3374 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , An alternative is to transfer enough information on the context transfer-candidate service state, or context, to the new subnet so that the services can be re-established quickly, rather than require the mobile host to establish them from scratch. The transfer of service context may be advantageous in minimizing the impact of host mobility on, for example, AAA, header compression, QoS, policy, and possibly sub-IP protocols and services such as PPP. Can somebody educate me as to where this information is stored and how it is being set on the access router.I really dont know what you mean by this,say user is roaming a between subnets how are you sure that you can allocate the same QOS(The other AP could have been flooded with users and is peaking out ) _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 18 03:33:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17653 for ; Fri, 18 Oct 2002 03:33:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9I7Zlj27709 for seamoby-archive@odin.ietf.org; Fri, 18 Oct 2002 03:35:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7Zlv27706 for ; Fri, 18 Oct 2002 03:35:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17644 for ; Fri, 18 Oct 2002 03:33:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7Uxv27544; Fri, 18 Oct 2002 03:30:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9I7TWv27496 for ; Fri, 18 Oct 2002 03:29:32 -0400 Received: from webdb.cs.ndsu.nodak.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17533 for ; Fri, 18 Oct 2002 03:27:09 -0400 (EDT) Received: from localhost (mylvarab@localhost) by webdb.cs.ndsu.nodak.edu (8.11.1/8.11.1) with SMTP id g9I7TKv98182 for ; Fri, 18 Oct 2002 02:29:21 -0500 (CDT) (envelope-from mylvarab@webdb.cs.ndsu.nodak.edu) Date: Fri, 18 Oct 2002 02:29:20 -0500 (CDT) From: Prashanth Mylvarabatla Reply-To: Prashanth Mylvarabatla To: seamoby@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] rfc3374 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , An alternative is to transfer enough information on the context transfer-candidate service state, or context, to the new subnet so that the services can be re-established quickly, rather than require the mobile host to establish them from scratch. The transfer of service context may be advantageous in minimizing the impact of host mobility on, for example, AAA, header compression, QoS, policy, and possibly sub-IP protocols and services such as PPP. Can somebody educate me as to where this information is stored and how it is being set on the access router.I really dont know what you mean by this,say user is roaming a between subnets how are you sure that you can allocate the same QOS(The other AP could have been flooded with users and is peaking out ) _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 18 07:31:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21598 for ; Fri, 18 Oct 2002 07:31:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBWYv08094; Fri, 18 Oct 2002 07:32:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBVZv08051 for ; Fri, 18 Oct 2002 07:31:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21188; Fri, 18 Oct 2002 07:29:20 -0400 (EDT) Message-Id: <200210181129.HAA21188@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 18 Oct 2002 07:29:20 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-cardiscovery-issues-04.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Issues in candidate access router discovery for seamless IP-level handoffs Author(s) : D. Trossen, G. Krishnamurthi, H. Chaskar, J. Kempf Filename : draft-ietf-seamoby-cardiscovery-issues-04.txt Pages : 9 Date : 2002-10-17 Handoff in IP mobility protocols involves moving a mobile node's Layer 3 routing reachability point from one access router to another, before or after the mobile node has established a Layer 2 connection with the radio access point that is covered by the new access router. In addition, other context information about the mobile node's IP service may be transferred from the old access router to the new one, in order to minimize the service disruption during the handoff process. While the exact details of how this is accomplished vary depending on the IP mobility and seamless handoff protocols, one common thread required for IP-level handoffs is discovering the candidate access routers for the mobile node's handoff. Discovering the candidate access router involves identifying its IP address as well as its capabilities that the mobile node might be interested in. At the time of IP-level handoff, if a collection of candidates is identified, an algorithm is run to determine the target access router for the mobile node's handoff. This document describes the problem of candidate access router discovery. The document does not discuss the algorithm by which the actual target access router is selected, nor how the handoff to the target is achieved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-cardiscovery-issues-04.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-seamoby-cardiscovery-issues-04.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-seamoby-cardiscovery-issues-04.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-10-17145805.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-cardiscovery-issues-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-cardiscovery-issues-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-17145805.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 18 07:31:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21616 for ; Fri, 18 Oct 2002 07:31:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBX5v08124; Fri, 18 Oct 2002 07:33:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBVev08059 for ; Fri, 18 Oct 2002 07:31:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21207; Fri, 18 Oct 2002 07:29:25 -0400 (EDT) Message-Id: <200210181129.HAA21207@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 18 Oct 2002 07:29:25 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-card-requirements-02.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Requirements for CAR Discovery Protocols Author(s) : G. Krishnamurthi Filename : draft-ietf-seamoby-card-requirements-02.txt Pages : 6 Date : 2002-10-17 The pre-requisite for IP based seamless mobility protocols is the knowledge of the access router (AR) to which a mobile node can be handed over to. Further, a handoff can be optimized if the capabilities of the AR being considered for handoff are known. The protocol which discovers ARs for potential handoff along with their capabilities is called the CAR discovery protocol. In this draft we list the requirements which are to be met by any solution for CAR Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-requirements-02.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-seamoby-card-requirements-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-seamoby-card-requirements-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: <2002-10-17145820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-card-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-card-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-17145820.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 18 07:32:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21640 for ; Fri, 18 Oct 2002 07:32:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IBXp808157 for seamoby-archive@odin.ietf.org; Fri, 18 Oct 2002 07:33:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBXpv08154 for ; Fri, 18 Oct 2002 07:33:51 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21612 for ; Fri, 18 Oct 2002 07:31:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBWYv08094; Fri, 18 Oct 2002 07:32:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBVZv08051 for ; Fri, 18 Oct 2002 07:31:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21188; Fri, 18 Oct 2002 07:29:20 -0400 (EDT) Message-Id: <200210181129.HAA21188@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 18 Oct 2002 07:29:20 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-cardiscovery-issues-04.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Issues in candidate access router discovery for seamless IP-level handoffs Author(s) : D. Trossen, G. Krishnamurthi, H. Chaskar, J. Kempf Filename : draft-ietf-seamoby-cardiscovery-issues-04.txt Pages : 9 Date : 2002-10-17 Handoff in IP mobility protocols involves moving a mobile node's Layer 3 routing reachability point from one access router to another, before or after the mobile node has established a Layer 2 connection with the radio access point that is covered by the new access router. In addition, other context information about the mobile node's IP service may be transferred from the old access router to the new one, in order to minimize the service disruption during the handoff process. While the exact details of how this is accomplished vary depending on the IP mobility and seamless handoff protocols, one common thread required for IP-level handoffs is discovering the candidate access routers for the mobile node's handoff. Discovering the candidate access router involves identifying its IP address as well as its capabilities that the mobile node might be interested in. At the time of IP-level handoff, if a collection of candidates is identified, an algorithm is run to determine the target access router for the mobile node's handoff. This document describes the problem of candidate access router discovery. The document does not discuss the algorithm by which the actual target access router is selected, nor how the handoff to the target is achieved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-cardiscovery-issues-04.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-seamoby-cardiscovery-issues-04.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-seamoby-cardiscovery-issues-04.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-10-17145805.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-cardiscovery-issues-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-cardiscovery-issues-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-17145805.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 18 07:32:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21661 for ; Fri, 18 Oct 2002 07:32:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IBY0q08182 for seamoby-archive@odin.ietf.org; Fri, 18 Oct 2002 07:34:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBY0v08179 for ; Fri, 18 Oct 2002 07:34:00 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21631 for ; Fri, 18 Oct 2002 07:31:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBX5v08124; Fri, 18 Oct 2002 07:33:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBVev08059 for ; Fri, 18 Oct 2002 07:31:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21207; Fri, 18 Oct 2002 07:29:25 -0400 (EDT) Message-Id: <200210181129.HAA21207@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 18 Oct 2002 07:29:25 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-card-requirements-02.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Requirements for CAR Discovery Protocols Author(s) : G. Krishnamurthi Filename : draft-ietf-seamoby-card-requirements-02.txt Pages : 6 Date : 2002-10-17 The pre-requisite for IP based seamless mobility protocols is the knowledge of the access router (AR) to which a mobile node can be handed over to. Further, a handoff can be optimized if the capabilities of the AR being considered for handoff are known. The protocol which discovers ARs for potential handoff along with their capabilities is called the CAR discovery protocol. In this draft we list the requirements which are to be met by any solution for CAR Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-requirements-02.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-seamoby-card-requirements-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-seamoby-card-requirements-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: <2002-10-17145820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-card-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-card-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-17145820.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 18 18:09:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11181 for ; Fri, 18 Oct 2002 18:09:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IMAsv14027; Fri, 18 Oct 2002 18:10:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IM9Rv13971 for ; Fri, 18 Oct 2002 18:09:27 -0400 Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11155 for ; Fri, 18 Oct 2002 18:07:07 -0400 (EDT) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id g9IM5Qu25168 for ; Fri, 18 Oct 2002 22:05:26 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id g9IMCDs01393 for ; Fri, 18 Oct 2002 22:12:13 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002101815095309800 for ; Fri, 18 Oct 2002 15:09:53 -0700 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Oct 2002 15:09:19 -0700 Message-ID: <29AD895CE780D511A8870002A50A666D02A45BD1@hdsmsx106.hd.intel.com> From: "Pareek, Sameer" To: "'seamoby@ietf.org'" Date: Fri, 18 Oct 2002 15:16:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Seamoby] agenda for Atlanta meeting? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Group, Could someone please point me to what's on the agenda for Seamoby group during the upcoming Atlanta meeting in November? Email/Contirbutions/URL? Thanks, -Sameer Sameer Pareek Mobile Standards & Architecture, Emerging Platforms Group, Intel Labs Work Phone: 503 712 9657 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 18 18:10:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11200 for ; Fri, 18 Oct 2002 18:10:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IMC1N14052 for seamoby-archive@odin.ietf.org; Fri, 18 Oct 2002 18:12:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IMC1v14049 for ; Fri, 18 Oct 2002 18:12:01 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11195 for ; Fri, 18 Oct 2002 18:09:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IMAsv14027; Fri, 18 Oct 2002 18:10:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IM9Rv13971 for ; Fri, 18 Oct 2002 18:09:27 -0400 Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11155 for ; Fri, 18 Oct 2002 18:07:07 -0400 (EDT) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id g9IM5Qu25168 for ; Fri, 18 Oct 2002 22:05:26 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id g9IMCDs01393 for ; Fri, 18 Oct 2002 22:12:13 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002101815095309800 for ; Fri, 18 Oct 2002 15:09:53 -0700 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Oct 2002 15:09:19 -0700 Message-ID: <29AD895CE780D511A8870002A50A666D02A45BD1@hdsmsx106.hd.intel.com> From: "Pareek, Sameer" To: "'seamoby@ietf.org'" Date: Fri, 18 Oct 2002 15:16:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Seamoby] agenda for Atlanta meeting? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Group, Could someone please point me to what's on the agenda for Seamoby group during the upcoming Atlanta meeting in November? Email/Contirbutions/URL? Thanks, -Sameer Sameer Pareek Mobile Standards & Architecture, Emerging Platforms Group, Intel Labs Work Phone: 503 712 9657 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 18 19:32:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12384 for ; Fri, 18 Oct 2002 19:32:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9INXLv17191; Fri, 18 Oct 2002 19:33:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9INUDv17065 for ; Fri, 18 Oct 2002 19:30:13 -0400 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12296 for ; Fri, 18 Oct 2002 19:27:52 -0400 (EDT) Subject: Re: [Seamoby] agenda for Atlanta meeting? From: Pat Calhoun To: "Pareek, Sameer" Cc: "'seamoby@ietf.org'" In-Reply-To: <29AD895CE780D511A8870002A50A666D02A45BD1@hdsmsx106.hd.intel.com> References: <29AD895CE780D511A8870002A50A666D02A45BD1@hdsmsx106.hd.intel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Oct 2002 16:30:08 +0000 Message-Id: <1034958608.27634.88.camel@dhcp-229-243> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> Could someone please point me to what's on the agenda for Seamoby group >> during the upcoming Atlanta meeting in November? Email/Contirbutions/URL? > Below is a proposed agenda for the Atlanta meeting: > > 1. Agenda Bashing (2 mins) - Chairs > 2. Draft Status (10 mins) - Chairs > 2.1 CT Requirements Draft update > 2.2 CAR PS & Req Draft update > 3. Brief discussion on terminology draft (10 mins) - Jukka > 4. Issues with CAR (20 mins) - Ajoy or Marco > 5. Issues with CT (20 mins) - John L drafts are available on the seamoby web page. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 18 19:32:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12401 for ; Fri, 18 Oct 2002 19:32:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9INYPD17286 for seamoby-archive@odin.ietf.org; Fri, 18 Oct 2002 19:34:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9INYPv17283 for ; Fri, 18 Oct 2002 19:34:25 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12398 for ; Fri, 18 Oct 2002 19:32:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9INXLv17191; Fri, 18 Oct 2002 19:33:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9INUDv17065 for ; Fri, 18 Oct 2002 19:30:13 -0400 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12296 for ; Fri, 18 Oct 2002 19:27:52 -0400 (EDT) Subject: Re: [Seamoby] agenda for Atlanta meeting? From: Pat Calhoun To: "Pareek, Sameer" Cc: "'seamoby@ietf.org'" In-Reply-To: <29AD895CE780D511A8870002A50A666D02A45BD1@hdsmsx106.hd.intel.com> References: <29AD895CE780D511A8870002A50A666D02A45BD1@hdsmsx106.hd.intel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Oct 2002 16:30:08 +0000 Message-Id: <1034958608.27634.88.camel@dhcp-229-243> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> Could someone please point me to what's on the agenda for Seamoby group >> during the upcoming Atlanta meeting in November? Email/Contirbutions/URL? > Below is a proposed agenda for the Atlanta meeting: > > 1. Agenda Bashing (2 mins) - Chairs > 2. Draft Status (10 mins) - Chairs > 2.1 CT Requirements Draft update > 2.2 CAR PS & Req Draft update > 3. Brief discussion on terminology draft (10 mins) - Jukka > 4. Issues with CAR (20 mins) - Ajoy or Marco > 5. Issues with CT (20 mins) - John L drafts are available on the seamoby web page. PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 21 08:34:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25648 for ; Mon, 21 Oct 2002 08:34:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LCUmv25580; Mon, 21 Oct 2002 08:30:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LCTIv25518 for ; Mon, 21 Oct 2002 08:29:18 -0400 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25430 for ; Mon, 21 Oct 2002 08:27:00 -0400 (EDT) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g9LCTDw26204; Mon, 21 Oct 2002 15:29:14 +0300 Date: Mon, 21 Oct 2002 15:29:12 +0300 (EEST) From: Jukka MJ Manner To: Seamoby Working Group cc: Markku Kojo , "Hancock, Robert" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] Next Steps for the terminology draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi all, So far I have seen only one comment to the terminology draft, to replace our proposed definition of "Routing Proxy" "A node that routes packets by overlays, eg. by tunneling, between communicating partners and without doing any non-routing related processing. The Home Agent and Foreign Agent are examples of routing proxies, in that they receive packets destined for the mobile node and tunnel them to the current address of the mobile node." with the following: "Routing proxies are the network nodes that receive datagrams, decide based on a lookup to which server to forward the datagram. The forwarding is stateless." I would keep the existing definition... it says a little more. In addition, we had the following TODO items mentioned in the draft: 1) Add basic terminology about mobile networks. Question: what terms should be considered? 2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, FBU. Question: would these be needed? What else? 3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add missing parts. Question: This draft does not have any mention of various care of addresses, should it? What else? 4) Compare against definitions in the LMM documents of the IRTF MM- subgroup (taxonomy draft expired). See if there is some harmonization to be done. Can be found at: http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt Question: is there something someone would like to have in the Seamoby terminology draft, to better cover the world on IP mobility? 5) Re-write the Network Components section Question: How should the present version be changed? We would like to get the comments from the Working Group this week, so that we may prepare a new version for Atlanta. Regards, Jukka _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 21 08:35:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25702 for ; Mon, 21 Oct 2002 08:35:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LCb4n25934 for seamoby-archive@odin.ietf.org; Mon, 21 Oct 2002 08:37:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LCb3v25931 for ; Mon, 21 Oct 2002 08:37:03 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25662 for ; Mon, 21 Oct 2002 08:34:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LCUmv25580; Mon, 21 Oct 2002 08:30:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LCTIv25518 for ; Mon, 21 Oct 2002 08:29:18 -0400 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25430 for ; Mon, 21 Oct 2002 08:27:00 -0400 (EDT) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g9LCTDw26204; Mon, 21 Oct 2002 15:29:14 +0300 Date: Mon, 21 Oct 2002 15:29:12 +0300 (EEST) From: Jukka MJ Manner To: Seamoby Working Group cc: Markku Kojo , "Hancock, Robert" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] Next Steps for the terminology draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi all, So far I have seen only one comment to the terminology draft, to replace our proposed definition of "Routing Proxy" "A node that routes packets by overlays, eg. by tunneling, between communicating partners and without doing any non-routing related processing. The Home Agent and Foreign Agent are examples of routing proxies, in that they receive packets destined for the mobile node and tunnel them to the current address of the mobile node." with the following: "Routing proxies are the network nodes that receive datagrams, decide based on a lookup to which server to forward the datagram. The forwarding is stateless." I would keep the existing definition... it says a little more. In addition, we had the following TODO items mentioned in the draft: 1) Add basic terminology about mobile networks. Question: what terms should be considered? 2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, FBU. Question: would these be needed? What else? 3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add missing parts. Question: This draft does not have any mention of various care of addresses, should it? What else? 4) Compare against definitions in the LMM documents of the IRTF MM- subgroup (taxonomy draft expired). See if there is some harmonization to be done. Can be found at: http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt Question: is there something someone would like to have in the Seamoby terminology draft, to better cover the world on IP mobility? 5) Re-write the Network Components section Question: How should the present version be changed? We would like to get the comments from the Working Group this week, so that we may prepare a new version for Atlanta. Regards, Jukka _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 21 11:23:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02693 for ; Mon, 21 Oct 2002 11:23:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFOQv03647; Mon, 21 Oct 2002 11:24:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFNMv03616 for ; Mon, 21 Oct 2002 11:23:22 -0400 Received: from auds953.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02612 for ; Mon, 21 Oct 2002 11:21:03 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g9LFNBi24668; Mon, 21 Oct 2002 10:23:11 -0500 (CDT) Message-ID: <3DB41C19.6000608@alcatel.com> Date: Mon, 21 Oct 2002 10:24:09 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner CC: Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft References: Content-Type: multipart/alternative; boundary="------------010200010508030805060904" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------010200010508030805060904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jukka, what about: Routing proxies are the network nodes that receive datagrams, decide based on a lookup to which server to forward the datagram. The forwarding is stateless. The Home Agent and Foreign Agent are examples of routing proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and tunnel them to the current address of the the correct mobile node. This would clarify forwarding by tunneling and other concepts. Regards, Jukka MJ Manner wrote: > Hi all, > > So far I have seen only one comment to the terminology draft, to >replace our proposed definition of "Routing Proxy" > >"A node that routes packets by overlays, eg. by tunneling, between >communicating partners and without doing any non-routing related >processing. The Home Agent and Foreign Agent are examples of routing >proxies, in that they receive packets destined for the mobile node and >tunnel them to the current address of the mobile node." > > with the following: > >"Routing proxies are the network nodes that receive datagrams, decide >based on a lookup to which server to forward the datagram. The forwarding >is stateless." > > > I would keep the existing definition... it says a little more. > > > In addition, we had the following TODO items mentioned in the >draft: > > >1) Add basic terminology about mobile networks. > >Question: what terms should be considered? > > >2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, >FBU. > >Question: would these be needed? What else? > > >3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add >missing parts. > >Question: This draft does not have any mention of various care of >addresses, should it? What else? > > >4) Compare against definitions in the LMM documents of the IRTF MM- >subgroup (taxonomy draft expired). See if there is some harmonization to >be done. Can be found at: >http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt > >Question: is there something someone would like to have in the Seamoby >terminology draft, to better cover the world on IP mobility? > > >5) Re-write the Network Components section > >Question: How should the present version be changed? > > > We would like to get the comments from the Working Group this >week, so that we may prepare a new version for Atlanta. > > > Regards, > > Jukka > > > > -- Behcet --------------010200010508030805060904 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jukka, what about:
Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless.
The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and
tunnel them to the current address of the the correct mobile node.

This would clarify forwarding by tunneling and other concepts.

Regards,

Jukka MJ Manner wrote:
	Hi all,

	So far I have seen only one comment to the terminology draft, to 
replace our proposed definition of "Routing Proxy"

"A node that routes packets by overlays, eg. by tunneling, between
communicating partners and without doing any non-routing related
processing. The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node and
tunnel them to the current address of the mobile node."

	with the following:

"Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless."


	I would keep the existing definition... it says a little more.


	In addition, we had the following TODO items mentioned in the 
draft:


1) Add basic terminology about mobile networks. 

Question: what terms should be considered?


2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, 
FBU.

Question: would these be needed? What else?


3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add 
missing parts.

Question: This draft does not have any mention of various care of
addresses, should it? What else?


4) Compare against definitions in the LMM documents of the IRTF MM-
subgroup (taxonomy draft expired).  See if there is some harmonization to
be done. Can be found at: 
http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt

Question: is there something someone would like to have in the Seamoby 
terminology draft, to better cover the world on IP mobility?


5) Re-write the Network Components section

Question: How should the present version be changed?


	We would like to get the comments from the Working Group this
week, so that we may prepare a new version for Atlanta.


	Regards,

	Jukka


  

-- 
Behcet

--------------010200010508030805060904-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 21 11:24:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02798 for ; Mon, 21 Oct 2002 11:24:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LFQLt03704 for seamoby-archive@odin.ietf.org; Mon, 21 Oct 2002 11:26:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFQLv03701 for ; Mon, 21 Oct 2002 11:26:21 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02708 for ; Mon, 21 Oct 2002 11:24:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFOQv03647; Mon, 21 Oct 2002 11:24:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFNMv03616 for ; Mon, 21 Oct 2002 11:23:22 -0400 Received: from auds953.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02612 for ; Mon, 21 Oct 2002 11:21:03 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g9LFNBi24668; Mon, 21 Oct 2002 10:23:11 -0500 (CDT) Message-ID: <3DB41C19.6000608@alcatel.com> Date: Mon, 21 Oct 2002 10:24:09 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner CC: Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft References: Content-Type: multipart/alternative; boundary="------------010200010508030805060904" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------010200010508030805060904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jukka, what about: Routing proxies are the network nodes that receive datagrams, decide based on a lookup to which server to forward the datagram. The forwarding is stateless. The Home Agent and Foreign Agent are examples of routing proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and tunnel them to the current address of the the correct mobile node. This would clarify forwarding by tunneling and other concepts. Regards, Jukka MJ Manner wrote: > Hi all, > > So far I have seen only one comment to the terminology draft, to >replace our proposed definition of "Routing Proxy" > >"A node that routes packets by overlays, eg. by tunneling, between >communicating partners and without doing any non-routing related >processing. The Home Agent and Foreign Agent are examples of routing >proxies, in that they receive packets destined for the mobile node and >tunnel them to the current address of the mobile node." > > with the following: > >"Routing proxies are the network nodes that receive datagrams, decide >based on a lookup to which server to forward the datagram. The forwarding >is stateless." > > > I would keep the existing definition... it says a little more. > > > In addition, we had the following TODO items mentioned in the >draft: > > >1) Add basic terminology about mobile networks. > >Question: what terms should be considered? > > >2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, >FBU. > >Question: would these be needed? What else? > > >3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add >missing parts. > >Question: This draft does not have any mention of various care of >addresses, should it? What else? > > >4) Compare against definitions in the LMM documents of the IRTF MM- >subgroup (taxonomy draft expired). See if there is some harmonization to >be done. Can be found at: >http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt > >Question: is there something someone would like to have in the Seamoby >terminology draft, to better cover the world on IP mobility? > > >5) Re-write the Network Components section > >Question: How should the present version be changed? > > > We would like to get the comments from the Working Group this >week, so that we may prepare a new version for Atlanta. > > > Regards, > > Jukka > > > > -- Behcet --------------010200010508030805060904 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jukka, what about:
Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless.
The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and
tunnel them to the current address of the the correct mobile node.

This would clarify forwarding by tunneling and other concepts.

Regards,

Jukka MJ Manner wrote:
	Hi all,

	So far I have seen only one comment to the terminology draft, to 
replace our proposed definition of "Routing Proxy"

"A node that routes packets by overlays, eg. by tunneling, between
communicating partners and without doing any non-routing related
processing. The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node and
tunnel them to the current address of the mobile node."

	with the following:

"Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless."


	I would keep the existing definition... it says a little more.


	In addition, we had the following TODO items mentioned in the 
draft:


1) Add basic terminology about mobile networks. 

Question: what terms should be considered?


2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, 
FBU.

Question: would these be needed? What else?


3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add 
missing parts.

Question: This draft does not have any mention of various care of
addresses, should it? What else?


4) Compare against definitions in the LMM documents of the IRTF MM-
subgroup (taxonomy draft expired).  See if there is some harmonization to
be done. Can be found at: 
http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt

Question: is there something someone would like to have in the Seamoby 
terminology draft, to better cover the world on IP mobility?


5) Re-write the Network Components section

Question: How should the present version be changed?


	We would like to get the comments from the Working Group this
week, so that we may prepare a new version for Atlanta.


	Regards,

	Jukka


  

-- 
Behcet

--------------010200010508030805060904-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 21 11:44:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03475 for ; Mon, 21 Oct 2002 11:44:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFjAv04847; Mon, 21 Oct 2002 11:45:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFi7v04808 for ; Mon, 21 Oct 2002 11:44:07 -0400 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03408 for ; Mon, 21 Oct 2002 11:41: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 g9LFi2Q1000165; Mon, 21 Oct 2002 17:44:02 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 21 Oct 2002 17:44:02 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0BAC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Behcet Sarikaya'" , Jukka MJ Manner Cc: Seamoby Working Group Subject: RE: [Seamoby] Next Steps for the terminology draft Date: Mon, 21 Oct 2002 17:44:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27918.803C7BFE" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C27918.803C7BFE Content-Type: text/plain; charset="iso-8859-1" If the intention is to use HAs as examples of routing proxies then I don't think we can say that they are stateless. Hesham -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Monday, October 21, 2002 5:24 PM To: Jukka MJ Manner Cc: Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft Jukka, what about: Routing proxies are the network nodes that receive datagrams, decide based on a lookup to which server to forward the datagram. The forwarding is stateless. The Home Agent and Foreign Agent are examples of routing proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and tunnel them to the current address of the the correct mobile node. This would clarify forwarding by tunneling and other concepts. Regards, Jukka MJ Manner wrote: Hi all, So far I have seen only one comment to the terminology draft, to replace our proposed definition of "Routing Proxy" "A node that routes packets by overlays, eg. by tunneling, between communicating partners and without doing any non-routing related processing. The Home Agent and Foreign Agent are examples of routing proxies, in that they receive packets destined for the mobile node and tunnel them to the current address of the mobile node." with the following: "Routing proxies are the network nodes that receive datagrams, decide based on a lookup to which server to forward the datagram. The forwarding is stateless." I would keep the existing definition... it says a little more. In addition, we had the following TODO items mentioned in the draft: 1) Add basic terminology about mobile networks. Question: what terms should be considered? 2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, FBU. Question: would these be needed? What else? 3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add missing parts. Question: This draft does not have any mention of various care of addresses, should it? What else? 4) Compare against definitions in the LMM documents of the IRTF MM- subgroup (taxonomy draft expired). See if there is some harmonization to be done. Can be found at: http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt Question: is there something someone would like to have in the Seamoby terminology draft, to better cover the world on IP mobility? 5) Re-write the Network Components section Question: How should the present version be changed? We would like to get the comments from the Working Group this week, so that we may prepare a new version for Atlanta. Regards, Jukka -- Behcet ------_=_NextPart_001_01C27918.803C7BFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If the=20 intention is to use HAs as examples of routing proxies then I=20
don't=20 think we can say that they are stateless.
 
Hesham
-----Original Message-----
From: Behcet Sarikaya=20 [mailto:behcet.sarikaya@alcatel.com]
Sent: Monday, October = 21, 2002=20 5:24 PM
To: Jukka MJ Manner
Cc: Seamoby Working=20 Group
Subject: Re: [Seamoby] Next Steps for the terminology = draft

Jukka, what about:
Routing proxies are the network nodes that receive datagrams, =
decide
based on a lookup to which server to forward the datagram. The =
forwarding
is stateless.
The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node, =
do a lookup in the binding cache and
tunnel them to the current address of the the correct mobile node.

This would clarify forwarding by tunneling and other=20 concepts.

Regards,

Jukka MJ Manner wrote:
	Hi all,

	So far I have seen only one comment to the terminology draft, to=20
replace our proposed definition of "Routing Proxy"

"A node that routes packets by overlays, eg. by tunneling, between
communicating partners and without doing any non-routing related
processing. The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node and
tunnel them to the current address of the mobile node."

	with the following:

"Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The =
forwarding
is stateless."


	I would keep the existing definition... it says a little more.


	In addition, we had the following TODO items mentioned in the=20
draft:


1) Add basic terminology about mobile networks.=20

Question: what terms should be considered?


2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", =
BU,=20
FBU.

Question: would these be needed? What else?


3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add=20
missing parts.

Question: This draft does not have any mention of various care of
addresses, should it? What else?


4) Compare against definitions in the LMM documents of the IRTF MM-
subgroup (taxonomy draft expired).  See if there is some harmonization =
to
be done. Can be found at:=20
http:/=
/www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt

Question: is there something someone would like to have in the Seamoby=20
terminology draft, to better cover the world on IP mobility?


5) Re-write the Network Components section

Question: How should the present version be changed?


	We would like to get the comments from the Working Group this
week, so that we may prepare a new version for Atlanta.


	Regards,

	Jukka


  

--=20
Behcet

------_=_NextPart_001_01C27918.803C7BFE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 21 11:44:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03498 for ; Mon, 21 Oct 2002 11:44:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LFkX804905 for seamoby-archive@odin.ietf.org; Mon, 21 Oct 2002 11:46:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFkXv04902 for ; Mon, 21 Oct 2002 11:46:33 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03489 for ; Mon, 21 Oct 2002 11:44:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFjAv04847; Mon, 21 Oct 2002 11:45:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFi7v04808 for ; Mon, 21 Oct 2002 11:44:07 -0400 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03408 for ; Mon, 21 Oct 2002 11:41: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 g9LFi2Q1000165; Mon, 21 Oct 2002 17:44:02 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 21 Oct 2002 17:44:02 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0BAC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Behcet Sarikaya'" , Jukka MJ Manner Cc: Seamoby Working Group Subject: RE: [Seamoby] Next Steps for the terminology draft Date: Mon, 21 Oct 2002 17:44:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27918.803C7BFE" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C27918.803C7BFE Content-Type: text/plain; charset="iso-8859-1" If the intention is to use HAs as examples of routing proxies then I don't think we can say that they are stateless. Hesham -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Monday, October 21, 2002 5:24 PM To: Jukka MJ Manner Cc: Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft Jukka, what about: Routing proxies are the network nodes that receive datagrams, decide based on a lookup to which server to forward the datagram. The forwarding is stateless. The Home Agent and Foreign Agent are examples of routing proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and tunnel them to the current address of the the correct mobile node. This would clarify forwarding by tunneling and other concepts. Regards, Jukka MJ Manner wrote: Hi all, So far I have seen only one comment to the terminology draft, to replace our proposed definition of "Routing Proxy" "A node that routes packets by overlays, eg. by tunneling, between communicating partners and without doing any non-routing related processing. The Home Agent and Foreign Agent are examples of routing proxies, in that they receive packets destined for the mobile node and tunnel them to the current address of the mobile node." with the following: "Routing proxies are the network nodes that receive datagrams, decide based on a lookup to which server to forward the datagram. The forwarding is stateless." I would keep the existing definition... it says a little more. In addition, we had the following TODO items mentioned in the draft: 1) Add basic terminology about mobile networks. Question: what terms should be considered? 2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, FBU. Question: would these be needed? What else? 3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add missing parts. Question: This draft does not have any mention of various care of addresses, should it? What else? 4) Compare against definitions in the LMM documents of the IRTF MM- subgroup (taxonomy draft expired). See if there is some harmonization to be done. Can be found at: http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt Question: is there something someone would like to have in the Seamoby terminology draft, to better cover the world on IP mobility? 5) Re-write the Network Components section Question: How should the present version be changed? We would like to get the comments from the Working Group this week, so that we may prepare a new version for Atlanta. Regards, Jukka -- Behcet ------_=_NextPart_001_01C27918.803C7BFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If the=20 intention is to use HAs as examples of routing proxies then I=20
don't=20 think we can say that they are stateless.
 
Hesham
-----Original Message-----
From: Behcet Sarikaya=20 [mailto:behcet.sarikaya@alcatel.com]
Sent: Monday, October = 21, 2002=20 5:24 PM
To: Jukka MJ Manner
Cc: Seamoby Working=20 Group
Subject: Re: [Seamoby] Next Steps for the terminology = draft

Jukka, what about:
Routing proxies are the network nodes that receive datagrams, =
decide
based on a lookup to which server to forward the datagram. The =
forwarding
is stateless.
The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node, =
do a lookup in the binding cache and
tunnel them to the current address of the the correct mobile node.

This would clarify forwarding by tunneling and other=20 concepts.

Regards,

Jukka MJ Manner wrote:
	Hi all,

	So far I have seen only one comment to the terminology draft, to=20
replace our proposed definition of "Routing Proxy"

"A node that routes packets by overlays, eg. by tunneling, between
communicating partners and without doing any non-routing related
processing. The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node and
tunnel them to the current address of the mobile node."

	with the following:

"Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The =
forwarding
is stateless."


	I would keep the existing definition... it says a little more.


	In addition, we had the following TODO items mentioned in the=20
draft:


1) Add basic terminology about mobile networks.=20

Question: what terms should be considered?


2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", =
BU,=20
FBU.

Question: would these be needed? What else?


3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add=20
missing parts.

Question: This draft does not have any mention of various care of
addresses, should it? What else?


4) Compare against definitions in the LMM documents of the IRTF MM-
subgroup (taxonomy draft expired).  See if there is some harmonization =
to
be done. Can be found at:=20
http:/=
/www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt

Question: is there something someone would like to have in the Seamoby=20
terminology draft, to better cover the world on IP mobility?


5) Re-write the Network Components section

Question: How should the present version be changed?


	We would like to get the comments from the Working Group this
week, so that we may prepare a new version for Atlanta.


	Regards,

	Jukka


  

--=20
Behcet

------_=_NextPart_001_01C27918.803C7BFE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 21 11:58:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03880 for ; Mon, 21 Oct 2002 11:58:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFt8v05225; Mon, 21 Oct 2002 11:55:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFs5v05189 for ; Mon, 21 Oct 2002 11:54:05 -0400 Received: from auds953.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03692 for ; Mon, 21 Oct 2002 11:51:46 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g9LFrqi02678; Mon, 21 Oct 2002 10:53:52 -0500 (CDT) Message-ID: <3DB42340.4060107@alcatel.com> Date: Mon, 21 Oct 2002 10:54:40 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: Jukka MJ Manner , Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft References: <4DA6EA82906FD511BE2F00508BCF0538044F0BAC@Esealnt861.al.sw.ericsson.se> Content-Type: multipart/alternative; boundary="------------010501090704030305010903" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------010501090704030305010903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Hesham, Forwarding is stateless here means that RP forwards the packet and then forgets about it, i.e. no sequence numbering/retransmissions, etc. Hesham Soliman (EAB) wrote: > If the intention is to use HAs as examples of routing proxies then I > don't think we can say that they are stateless. > > Hesham > > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] > Sent: Monday, October 21, 2002 5:24 PM > To: Jukka MJ Manner > Cc: Seamoby Working Group > Subject: Re: [Seamoby] Next Steps for the terminology draft > > Jukka, what about: > >Routing proxies are the network nodes that receive datagrams, decide >based on a lookup to which server to forward the datagram. The forwarding >is stateless. >The Home Agent and Foreign Agent are examples of routing >proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and >tunnel them to the current address of the the correct mobile node. > > > > This would clarify forwarding by tunneling and other concepts. > > Regards, > > Jukka MJ Manner wrote: > >> Hi all, >> >> So far I have seen only one comment to the terminology draft, to >>replace our proposed definition of "Routing Proxy" >> >>"A node that routes packets by overlays, eg. by tunneling, between >>communicating partners and without doing any non-routing related >>processing. The Home Agent and Foreign Agent are examples of routing >>proxies, in that they receive packets destined for the mobile node and >>tunnel them to the current address of the mobile node." >> >> with the following: >> >>"Routing proxies are the network nodes that receive datagrams, decide >>based on a lookup to which server to forward the datagram. The forwarding >>is stateless." >> >> >> I would keep the existing definition... it says a little more. >> >> >> In addition, we had the following TODO items mentioned in the >>draft: >> >> >>1) Add basic terminology about mobile networks. >> >>Question: what terms should be considered? >> >> >>2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, >>FBU. >> >>Question: would these be needed? What else? >> >> >>3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add >>missing parts. >> >>Question: This draft does not have any mention of various care of >>addresses, should it? What else? >> >> >>4) Compare against definitions in the LMM documents of the IRTF MM- >>subgroup (taxonomy draft expired). See if there is some harmonization to >>be done. Can be found at: >>http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt >> >>Question: is there something someone would like to have in the Seamoby >>terminology draft, to better cover the world on IP mobility? >> >> >>5) Re-write the Network Components section >> >>Question: How should the present version be changed? >> >> >> We would like to get the comments from the Working Group this >>week, so that we may prepare a new version for Atlanta. >> >> >> Regards, >> >> Jukka >> >> >> >> > >-- >Behcet > --------------010501090704030305010903 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Hesham,
  Forwarding is stateless

here means that RP forwards the packet and then forgets about it, i.e. no sequence numbering/retransmissions, etc.



Hesham Soliman (EAB) wrote:
If the intention is to use HAs as examples of routing proxies then I
don't think we can say that they are stateless.
 
Hesham
-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Monday, October 21, 2002 5:24 PM
To: Jukka MJ Manner
Cc: Seamoby Working Group
Subject: Re: [Seamoby] Next Steps for the terminology draft

Jukka, what about:
Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless.
The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and
tunnel them to the current address of the the correct mobile node.

This would clarify forwarding by tunneling and other concepts.

Regards,

Jukka MJ Manner wrote:
	Hi all,

	So far I have seen only one comment to the terminology draft, to 
replace our proposed definition of "Routing Proxy"

"A node that routes packets by overlays, eg. by tunneling, between
communicating partners and without doing any non-routing related
processing. The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node and
tunnel them to the current address of the mobile node."

	with the following:

"Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless."


	I would keep the existing definition... it says a little more.


	In addition, we had the following TODO items mentioned in the 
draft:


1) Add basic terminology about mobile networks. 

Question: what terms should be considered?


2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, 
FBU.

Question: would these be needed? What else?


3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add 
missing parts.

Question: This draft does not have any mention of various care of
addresses, should it? What else?


4) Compare against definitions in the LMM documents of the IRTF MM-
subgroup (taxonomy draft expired).  See if there is some harmonization to
be done. Can be found at: 
http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt

Question: is there something someone would like to have in the Seamoby 
terminology draft, to better cover the world on IP mobility?


5) Re-write the Network Components section

Question: How should the present version be changed?


	We would like to get the comments from the Working Group this
week, so that we may prepare a new version for Atlanta.


	Regards,

	Jukka


  

-- 
Behcet

--------------010501090704030305010903-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 21 11:59:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03925 for ; Mon, 21 Oct 2002 11:59:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LG17k05412 for seamoby-archive@odin.ietf.org; Mon, 21 Oct 2002 12:01:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LG17v05409 for ; Mon, 21 Oct 2002 12:01:07 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03894 for ; Mon, 21 Oct 2002 11:58:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFt8v05225; Mon, 21 Oct 2002 11:55:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LFs5v05189 for ; Mon, 21 Oct 2002 11:54:05 -0400 Received: from auds953.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03692 for ; Mon, 21 Oct 2002 11:51:46 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g9LFrqi02678; Mon, 21 Oct 2002 10:53:52 -0500 (CDT) Message-ID: <3DB42340.4060107@alcatel.com> Date: Mon, 21 Oct 2002 10:54:40 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: Jukka MJ Manner , Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft References: <4DA6EA82906FD511BE2F00508BCF0538044F0BAC@Esealnt861.al.sw.ericsson.se> Content-Type: multipart/alternative; boundary="------------010501090704030305010903" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------010501090704030305010903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Hesham, Forwarding is stateless here means that RP forwards the packet and then forgets about it, i.e. no sequence numbering/retransmissions, etc. Hesham Soliman (EAB) wrote: > If the intention is to use HAs as examples of routing proxies then I > don't think we can say that they are stateless. > > Hesham > > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] > Sent: Monday, October 21, 2002 5:24 PM > To: Jukka MJ Manner > Cc: Seamoby Working Group > Subject: Re: [Seamoby] Next Steps for the terminology draft > > Jukka, what about: > >Routing proxies are the network nodes that receive datagrams, decide >based on a lookup to which server to forward the datagram. The forwarding >is stateless. >The Home Agent and Foreign Agent are examples of routing >proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and >tunnel them to the current address of the the correct mobile node. > > > > This would clarify forwarding by tunneling and other concepts. > > Regards, > > Jukka MJ Manner wrote: > >> Hi all, >> >> So far I have seen only one comment to the terminology draft, to >>replace our proposed definition of "Routing Proxy" >> >>"A node that routes packets by overlays, eg. by tunneling, between >>communicating partners and without doing any non-routing related >>processing. The Home Agent and Foreign Agent are examples of routing >>proxies, in that they receive packets destined for the mobile node and >>tunnel them to the current address of the mobile node." >> >> with the following: >> >>"Routing proxies are the network nodes that receive datagrams, decide >>based on a lookup to which server to forward the datagram. The forwarding >>is stateless." >> >> >> I would keep the existing definition... it says a little more. >> >> >> In addition, we had the following TODO items mentioned in the >>draft: >> >> >>1) Add basic terminology about mobile networks. >> >>Question: what terms should be considered? >> >> >>2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, >>FBU. >> >>Question: would these be needed? What else? >> >> >>3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add >>missing parts. >> >>Question: This draft does not have any mention of various care of >>addresses, should it? What else? >> >> >>4) Compare against definitions in the LMM documents of the IRTF MM- >>subgroup (taxonomy draft expired). See if there is some harmonization to >>be done. Can be found at: >>http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt >> >>Question: is there something someone would like to have in the Seamoby >>terminology draft, to better cover the world on IP mobility? >> >> >>5) Re-write the Network Components section >> >>Question: How should the present version be changed? >> >> >> We would like to get the comments from the Working Group this >>week, so that we may prepare a new version for Atlanta. >> >> >> Regards, >> >> Jukka >> >> >> >> > >-- >Behcet > --------------010501090704030305010903 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Hesham,
  Forwarding is stateless

here means that RP forwards the packet and then forgets about it, i.e. no sequence numbering/retransmissions, etc.



Hesham Soliman (EAB) wrote:
If the intention is to use HAs as examples of routing proxies then I
don't think we can say that they are stateless.
 
Hesham
-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Monday, October 21, 2002 5:24 PM
To: Jukka MJ Manner
Cc: Seamoby Working Group
Subject: Re: [Seamoby] Next Steps for the terminology draft

Jukka, what about:
Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless.
The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and
tunnel them to the current address of the the correct mobile node.

This would clarify forwarding by tunneling and other concepts.

Regards,

Jukka MJ Manner wrote:
	Hi all,

	So far I have seen only one comment to the terminology draft, to 
replace our proposed definition of "Routing Proxy"

"A node that routes packets by overlays, eg. by tunneling, between
communicating partners and without doing any non-routing related
processing. The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node and
tunnel them to the current address of the mobile node."

	with the following:

"Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless."


	I would keep the existing definition... it says a little more.


	In addition, we had the following TODO items mentioned in the 
draft:


1) Add basic terminology about mobile networks. 

Question: what terms should be considered?


2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, 
FBU.

Question: would these be needed? What else?


3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add 
missing parts.

Question: This draft does not have any mention of various care of
addresses, should it? What else?


4) Compare against definitions in the LMM documents of the IRTF MM-
subgroup (taxonomy draft expired).  See if there is some harmonization to
be done. Can be found at: 
http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt

Question: is there something someone would like to have in the Seamoby 
terminology draft, to better cover the world on IP mobility?


5) Re-write the Network Components section

Question: How should the present version be changed?


	We would like to get the comments from the Working Group this
week, so that we may prepare a new version for Atlanta.


	Regards,

	Jukka


  

-- 
Behcet

--------------010501090704030305010903-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 21 13:16:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06558 for ; Mon, 21 Oct 2002 13:16:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LHHMv09837; Mon, 21 Oct 2002 13:17:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LHGjv09779 for ; Mon, 21 Oct 2002 13:16:45 -0400 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06475 for ; Mon, 21 Oct 2002 13:14:26 -0400 (EDT) Message-ID: <00db01c27925$620d12d0$146015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , "Jukka MJ Manner" Cc: "Seamoby Working Group" References: <3DB41C19.6000608@alcatel.com> Subject: Re: [Seamoby] Next Steps for the terminology draft Date: Mon, 21 Oct 2002 10:13:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Jukka, what about: > > Routing proxies are the network nodes that receive datagrams, decide > based on a lookup to which server to forward the datagram. The forwarding > is stateless. > The Home Agent and Foreign Agent are examples of routing > proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and > tunnel them to the current address of the the correct mobile node. > A binding cache contains state. Thus, the forwarding done by the HA is not stateless. > > This would clarify forwarding by tunneling and other concepts. > I like the original definition. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 21 13:16:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06577 for ; Mon, 21 Oct 2002 13:16:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LHILD09892 for seamoby-archive@odin.ietf.org; Mon, 21 Oct 2002 13:18:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LHILv09889 for ; Mon, 21 Oct 2002 13:18:21 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06572 for ; Mon, 21 Oct 2002 13:16:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LHHMv09837; Mon, 21 Oct 2002 13:17:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LHGjv09779 for ; Mon, 21 Oct 2002 13:16:45 -0400 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06475 for ; Mon, 21 Oct 2002 13:14:26 -0400 (EDT) Message-ID: <00db01c27925$620d12d0$146015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , "Jukka MJ Manner" Cc: "Seamoby Working Group" References: <3DB41C19.6000608@alcatel.com> Subject: Re: [Seamoby] Next Steps for the terminology draft Date: Mon, 21 Oct 2002 10:13:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Jukka, what about: > > Routing proxies are the network nodes that receive datagrams, decide > based on a lookup to which server to forward the datagram. The forwarding > is stateless. > The Home Agent and Foreign Agent are examples of routing > proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and > tunnel them to the current address of the the correct mobile node. > A binding cache contains state. Thus, the forwarding done by the HA is not stateless. > > This would clarify forwarding by tunneling and other concepts. > I like the original definition. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 21 13:17:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06613 for ; Mon, 21 Oct 2002 13:17:19 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LHI2v09859; Mon, 21 Oct 2002 13:18:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LHHTv09845 for ; Mon, 21 Oct 2002 13:17:29 -0400 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06529 for ; Mon, 21 Oct 2002 13:15:10 -0400 (EDT) Message-ID: <00dc01c27925$7ac050d0$146015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , "Hesham Soliman \(EAB\)" Cc: "Jukka MJ Manner" , "Seamoby Working Group" References: <4DA6EA82906FD511BE2F00508BCF0538044F0BAC@Esealnt861.al.sw.ericsson.se> <3DB42340.4060107@alcatel.com> Subject: Re: [Seamoby] Next Steps for the terminology draft Date: Mon, 21 Oct 2002 10:15:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Hello Hesham, > Forwarding is stateless > > here means that RP forwards the packet and then forgets about it, i.e. > no sequence numbering/retransmissions, etc. > > Why is this important? The point should be that these network elements operate like routers, but they do not exchange information with the routing fabric via an IGP. Routers typically do no sequence numbering or retransmissions. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 21 13:17:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06633 for ; Mon, 21 Oct 2002 13:17:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LHJdw09932 for seamoby-archive@odin.ietf.org; Mon, 21 Oct 2002 13:19:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LHJdv09929 for ; Mon, 21 Oct 2002 13:19:39 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06627 for ; Mon, 21 Oct 2002 13:17:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LHI2v09859; Mon, 21 Oct 2002 13:18:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LHHTv09845 for ; Mon, 21 Oct 2002 13:17:29 -0400 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06529 for ; Mon, 21 Oct 2002 13:15:10 -0400 (EDT) Message-ID: <00dc01c27925$7ac050d0$146015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , "Hesham Soliman \(EAB\)" Cc: "Jukka MJ Manner" , "Seamoby Working Group" References: <4DA6EA82906FD511BE2F00508BCF0538044F0BAC@Esealnt861.al.sw.ericsson.se> <3DB42340.4060107@alcatel.com> Subject: Re: [Seamoby] Next Steps for the terminology draft Date: Mon, 21 Oct 2002 10:15:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Hello Hesham, > Forwarding is stateless > > here means that RP forwards the packet and then forgets about it, i.e. > no sequence numbering/retransmissions, etc. > > Why is this important? The point should be that these network elements operate like routers, but they do not exchange information with the routing fabric via an IGP. Routers typically do no sequence numbering or retransmissions. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 21 14:05:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08670 for ; Mon, 21 Oct 2002 14:05:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LI5Jv12812; Mon, 21 Oct 2002 14:05:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LI4Fv12775 for ; Mon, 21 Oct 2002 14:04:15 -0400 Received: from auds953.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08534 for ; Mon, 21 Oct 2002 14:01:55 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g9LI43i02651; Mon, 21 Oct 2002 13:04:03 -0500 (CDT) Message-ID: <3DB441C3.5090002@alcatel.com> Date: Mon, 21 Oct 2002 13:04:51 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: "Hesham Soliman (EAB)" , Jukka MJ Manner , Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft References: <4DA6EA82906FD511BE2F00508BCF0538044F0BAC@Esealnt861.al.sw.ericsson.se> <3DB42340.4060107@alcatel.com> <00dc01c27925$7ac050d0$146015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------010003040806090907050305" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------010003040806090907050305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit So binding cache state you mentioned in your previous message was not the state mentioned here, hope you agree with this. --more below. James Kempf wrote: >>Hello Hesham, >> Forwarding is stateless >> >>here means that RP forwards the packet and then forgets about it, i.e. >>no sequence numbering/retransmissions, etc. >> >> >> >> > >Why is this important? The point should be that these network elements operate >like routers, but they do not exchange information with the routing fabric via >an IGP. Routers typically do no sequence numbering or retransmissions. > > jak > >_________ > because 1. Jukka was asking the members' opinion, 2. It does matter to have a good definition rather than an average one. -- Behcet --------------010003040806090907050305 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit So binding cache state you mentioned in your previous message
was not the state mentioned here, hope you agree with this.

--more below.

James Kempf wrote:
Hello Hesham,
  Forwarding is stateless

here means that RP forwards the packet and then forgets about it, i.e.
no sequence numbering/retransmissions, etc.


    

Why is this important? The point should be that these network elements operate
like routers, but they do not exchange information with the routing fabric via
an IGP. Routers typically do no sequence numbering or retransmissions.

            jak

_________

because
1. Jukka was asking the members' opinion,
2. It does matter to have a good definition rather than an average one.

-- 
Behcet

--------------010003040806090907050305-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 21 14:05:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08726 for ; Mon, 21 Oct 2002 14:05:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LI7k613449 for seamoby-archive@odin.ietf.org; Mon, 21 Oct 2002 14:07:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LI7kv13446 for ; Mon, 21 Oct 2002 14:07:46 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08680 for ; Mon, 21 Oct 2002 14:05:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LI5Jv12812; Mon, 21 Oct 2002 14:05:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LI4Fv12775 for ; Mon, 21 Oct 2002 14:04:15 -0400 Received: from auds953.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08534 for ; Mon, 21 Oct 2002 14:01:55 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g9LI43i02651; Mon, 21 Oct 2002 13:04:03 -0500 (CDT) Message-ID: <3DB441C3.5090002@alcatel.com> Date: Mon, 21 Oct 2002 13:04:51 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: "Hesham Soliman (EAB)" , Jukka MJ Manner , Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft References: <4DA6EA82906FD511BE2F00508BCF0538044F0BAC@Esealnt861.al.sw.ericsson.se> <3DB42340.4060107@alcatel.com> <00dc01c27925$7ac050d0$146015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------010003040806090907050305" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------010003040806090907050305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit So binding cache state you mentioned in your previous message was not the state mentioned here, hope you agree with this. --more below. James Kempf wrote: >>Hello Hesham, >> Forwarding is stateless >> >>here means that RP forwards the packet and then forgets about it, i.e. >>no sequence numbering/retransmissions, etc. >> >> >> >> > >Why is this important? The point should be that these network elements operate >like routers, but they do not exchange information with the routing fabric via >an IGP. Routers typically do no sequence numbering or retransmissions. > > jak > >_________ > because 1. Jukka was asking the members' opinion, 2. It does matter to have a good definition rather than an average one. -- Behcet --------------010003040806090907050305 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit So binding cache state you mentioned in your previous message
was not the state mentioned here, hope you agree with this.

--more below.

James Kempf wrote:
Hello Hesham,
  Forwarding is stateless

here means that RP forwards the packet and then forgets about it, i.e.
no sequence numbering/retransmissions, etc.


    

Why is this important? The point should be that these network elements operate
like routers, but they do not exchange information with the routing fabric via
an IGP. Routers typically do no sequence numbering or retransmissions.

            jak

_________

because
1. Jukka was asking the members' opinion,
2. It does matter to have a good definition rather than an average one.

-- 
Behcet

--------------010003040806090907050305-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Oct 22 01:02:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26381 for ; Tue, 22 Oct 2002 01:02:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M4wNv11197; Tue, 22 Oct 2002 00:58:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M4tbv11140 for ; Tue, 22 Oct 2002 00:55:37 -0400 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26171 for ; Tue, 22 Oct 2002 00:53:12 -0400 (EDT) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g9M4tKw26522; Tue, 22 Oct 2002 07:55:21 +0300 Date: Tue, 22 Oct 2002 07:55:20 +0300 (EEST) From: Jukka MJ Manner To: Behcet Sarikaya cc: Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft In-Reply-To: <3DB41C19.6000608@alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi, It is the first sentence of your definition that doesn't seem right. It looks to me that it defines any IP router: receives packets, does a lookup, forwards the packets. Regards, Jukka On Mon, 21 Oct 2002, Behcet Sarikaya wrote: > Jukka, what about: > > Routing proxies are the network nodes that receive datagrams, decide > based on a lookup to which server to forward the datagram. The forwarding > is stateless. > The Home Agent and Foreign Agent are examples of routing > proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and > tunnel them to the current address of the the correct mobile node. > > > This would clarify forwarding by tunneling and other concepts. > > Regards, > > Jukka MJ Manner wrote: > > > Hi all, > > > > So far I have seen only one comment to the terminology draft, to > >replace our proposed definition of "Routing Proxy" > > > >"A node that routes packets by overlays, eg. by tunneling, between > >communicating partners and without doing any non-routing related > >processing. The Home Agent and Foreign Agent are examples of routing > >proxies, in that they receive packets destined for the mobile node and > >tunnel them to the current address of the mobile node." > > > > with the following: > > > >"Routing proxies are the network nodes that receive datagrams, decide > >based on a lookup to which server to forward the datagram. The forwarding > >is stateless." > > > > > > I would keep the existing definition... it says a little more. > > > > > > In addition, we had the following TODO items mentioned in the > >draft: > > > > > >1) Add basic terminology about mobile networks. > > > >Question: what terms should be considered? > > > > > >2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, > >FBU. > > > >Question: would these be needed? What else? > > > > > >3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add > >missing parts. > > > >Question: This draft does not have any mention of various care of > >addresses, should it? What else? > > > > > >4) Compare against definitions in the LMM documents of the IRTF MM- > >subgroup (taxonomy draft expired). See if there is some harmonization to > >be done. Can be found at: > >http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt > > > >Question: is there something someone would like to have in the Seamoby > >terminology draft, to better cover the world on IP mobility? > > > > > >5) Re-write the Network Components section > > > >Question: How should the present version be changed? > > > > > > We would like to get the comments from the Working Group this > >week, so that we may prepare a new version for Atlanta. > > > > > > Regards, > > > > Jukka > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 22 01:02:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26439 for ; Tue, 22 Oct 2002 01:02:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9M54jX11411 for seamoby-archive@odin.ietf.org; Tue, 22 Oct 2002 01:04:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M54jv11408 for ; Tue, 22 Oct 2002 01:04:45 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26395 for ; Tue, 22 Oct 2002 01:02:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M4wNv11197; Tue, 22 Oct 2002 00:58:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9M4tbv11140 for ; Tue, 22 Oct 2002 00:55:37 -0400 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26171 for ; Tue, 22 Oct 2002 00:53:12 -0400 (EDT) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g9M4tKw26522; Tue, 22 Oct 2002 07:55:21 +0300 Date: Tue, 22 Oct 2002 07:55:20 +0300 (EEST) From: Jukka MJ Manner To: Behcet Sarikaya cc: Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft In-Reply-To: <3DB41C19.6000608@alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi, It is the first sentence of your definition that doesn't seem right. It looks to me that it defines any IP router: receives packets, does a lookup, forwards the packets. Regards, Jukka On Mon, 21 Oct 2002, Behcet Sarikaya wrote: > Jukka, what about: > > Routing proxies are the network nodes that receive datagrams, decide > based on a lookup to which server to forward the datagram. The forwarding > is stateless. > The Home Agent and Foreign Agent are examples of routing > proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and > tunnel them to the current address of the the correct mobile node. > > > This would clarify forwarding by tunneling and other concepts. > > Regards, > > Jukka MJ Manner wrote: > > > Hi all, > > > > So far I have seen only one comment to the terminology draft, to > >replace our proposed definition of "Routing Proxy" > > > >"A node that routes packets by overlays, eg. by tunneling, between > >communicating partners and without doing any non-routing related > >processing. The Home Agent and Foreign Agent are examples of routing > >proxies, in that they receive packets destined for the mobile node and > >tunnel them to the current address of the mobile node." > > > > with the following: > > > >"Routing proxies are the network nodes that receive datagrams, decide > >based on a lookup to which server to forward the datagram. The forwarding > >is stateless." > > > > > > I would keep the existing definition... it says a little more. > > > > > > In addition, we had the following TODO items mentioned in the > >draft: > > > > > >1) Add basic terminology about mobile networks. > > > >Question: what terms should be considered? > > > > > >2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, > >FBU. > > > >Question: would these be needed? What else? > > > > > >3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add > >missing parts. > > > >Question: This draft does not have any mention of various care of > >addresses, should it? What else? > > > > > >4) Compare against definitions in the LMM documents of the IRTF MM- > >subgroup (taxonomy draft expired). See if there is some harmonization to > >be done. Can be found at: > >http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt > > > >Question: is there something someone would like to have in the Seamoby > >terminology draft, to better cover the world on IP mobility? > > > > > >5) Re-write the Network Components section > > > >Question: How should the present version be changed? > > > > > > We would like to get the comments from the Working Group this > >week, so that we may prepare a new version for Atlanta. > > > > > > Regards, > > > > Jukka > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Oct 22 10:59:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20654 for ; Tue, 22 Oct 2002 10:59:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MEtZv18517; Tue, 22 Oct 2002 10:55:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MEoav18357 for ; Tue, 22 Oct 2002 10:50:36 -0400 Received: from auds951.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19935 for ; Tue, 22 Oct 2002 10:48:15 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g9MEoQp00929; Tue, 22 Oct 2002 09:50:26 -0500 (CDT) Message-ID: <3DB565EB.8070004@alcatel.com> Date: Tue, 22 Oct 2002 09:51:23 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner CC: Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft References: Content-Type: multipart/alternative; boundary="------------050200070703070004090002" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------050200070703070004090002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit You are right, maybe this one could help: Routing proxies are the network nodes that build a lookup table based on registrations, arrange for receiving datagrams on the behalf of the registered nodes, receive the datagrams, decide based on a lookup to which destination to forward the datagram. The forwarding is stateless. The Home Agent, Foreign Agent and Localized Mobility Agents such as MAP are examples of routing proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and tunnel them to the current address of the correct mobile node. Jukka MJ Manner wrote: > Hi, > > It is the first sentence of your definition that doesn't seem >right. It looks to me that it defines any IP router: receives packets, >does a lookup, forwards the packets. > > Regards, > > Jukka > >On Mon, 21 Oct 2002, Behcet Sarikaya wrote: > > > >>Jukka, what about: >> >>Routing proxies are the network nodes that receive datagrams, decide >>based on a lookup to which server to forward the datagram. The forwarding >>is stateless. >>The Home Agent and Foreign Agent are examples of routing >>proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and >>tunnel them to the current address of the the correct mobile node. >> >> >>This would clarify forwarding by tunneling and other concepts. >> >>Regards, >> >>Jukka MJ Manner wrote: >> >> >> >>> Hi all, >>> >>> So far I have seen only one comment to the terminology draft, to >>>replace our proposed definition of "Routing Proxy" >>> >>>"A node that routes packets by overlays, eg. by tunneling, between >>>communicating partners and without doing any non-routing related >>>processing. The Home Agent and Foreign Agent are examples of routing >>>proxies, in that they receive packets destined for the mobile node and >>>tunnel them to the current address of the mobile node." >>> >>> with the following: >>> >>>"Routing proxies are the network nodes that receive datagrams, decide >>>based on a lookup to which server to forward the datagram. The forwarding >>>is stateless." >>> >>> >>> I would keep the existing definition... it says a little more. >>> >>> >>> In addition, we had the following TODO items mentioned in the >>>draft: >>> >>> >>>1) Add basic terminology about mobile networks. >>> >>>Question: what terms should be considered? >>> >>> >>>2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, >>>FBU. >>> >>>Question: would these be needed? What else? >>> >>> >>>3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add >>>missing parts. >>> >>>Question: This draft does not have any mention of various care of >>>addresses, should it? What else? >>> >>> >>>4) Compare against definitions in the LMM documents of the IRTF MM- >>>subgroup (taxonomy draft expired). See if there is some harmonization to >>>be done. Can be found at: >>>http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt >>> >>>Question: is there something someone would like to have in the Seamoby >>>terminology draft, to better cover the world on IP mobility? >>> >>> >>>5) Re-write the Network Components section >>> >>>Question: How should the present version be changed? >>> >>> >>> We would like to get the comments from the Working Group this >>>week, so that we may prepare a new version for Atlanta. >>> >>> >>> Regards, >>> >>> Jukka >>> >>> >>> >>> >>> >>> >> >> > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > -- Behcet --------------050200070703070004090002 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit You are right, maybe this one could help:

Routing proxies are the network nodes that build a lookup table based on registrations, arrange for receiving datagrams on the behalf of the registered nodes, receive the datagrams, decide based on a lookup to which destination to forward the datagram. The forwarding is stateless.

The Home Agent, Foreign Agent and Localized Mobility Agents such as MAP are examples of routing proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and tunnel them to the current address of the correct mobile node.


Jukka MJ Manner wrote:
	Hi,

	It is the first sentence of your definition that doesn't seem
right. It looks to me that it defines any IP router: receives packets,
does a lookup, forwards the packets.

	Regards,

	Jukka

On Mon, 21 Oct 2002, Behcet Sarikaya wrote:

  
Jukka, what about:

Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless.
The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and
tunnel them to the current address of the the correct mobile node.


This would clarify forwarding by tunneling and other concepts.

Regards,

Jukka MJ Manner wrote:

    
	Hi all,

	So far I have seen only one comment to the terminology draft, to 
replace our proposed definition of "Routing Proxy"

"A node that routes packets by overlays, eg. by tunneling, between
communicating partners and without doing any non-routing related
processing. The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node and
tunnel them to the current address of the mobile node."

	with the following:

"Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless."


	I would keep the existing definition... it says a little more.


	In addition, we had the following TODO items mentioned in the 
draft:


1) Add basic terminology about mobile networks. 

Question: what terms should be considered?


2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, 
FBU.

Question: would these be needed? What else?


3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add 
missing parts.

Question: This draft does not have any mention of various care of
addresses, should it? What else?


4) Compare against definitions in the LMM documents of the IRTF MM-
subgroup (taxonomy draft expired).  See if there is some harmonization to
be done. Can be found at: 
http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt

Question: is there something someone would like to have in the Seamoby 
terminology draft, to better cover the world on IP mobility?


5) Re-write the Network Components section

Question: How should the present version be changed?


	We would like to get the comments from the Working Group this
week, so that we may prepare a new version for Atlanta.


	Regards,

	Jukka


 

      
    

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby
  

-- 
Behcet

--------------050200070703070004090002-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 22 10:59:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20689 for ; Tue, 22 Oct 2002 10:59:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MF1fl18758 for seamoby-archive@odin.ietf.org; Tue, 22 Oct 2002 11:01:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MF1fv18755 for ; Tue, 22 Oct 2002 11:01:41 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20668 for ; Tue, 22 Oct 2002 10:59:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MEtZv18517; Tue, 22 Oct 2002 10:55:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MEoav18357 for ; Tue, 22 Oct 2002 10:50:36 -0400 Received: from auds951.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19935 for ; Tue, 22 Oct 2002 10:48:15 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g9MEoQp00929; Tue, 22 Oct 2002 09:50:26 -0500 (CDT) Message-ID: <3DB565EB.8070004@alcatel.com> Date: Tue, 22 Oct 2002 09:51:23 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner CC: Seamoby Working Group Subject: Re: [Seamoby] Next Steps for the terminology draft References: Content-Type: multipart/alternative; boundary="------------050200070703070004090002" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --------------050200070703070004090002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit You are right, maybe this one could help: Routing proxies are the network nodes that build a lookup table based on registrations, arrange for receiving datagrams on the behalf of the registered nodes, receive the datagrams, decide based on a lookup to which destination to forward the datagram. The forwarding is stateless. The Home Agent, Foreign Agent and Localized Mobility Agents such as MAP are examples of routing proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and tunnel them to the current address of the correct mobile node. Jukka MJ Manner wrote: > Hi, > > It is the first sentence of your definition that doesn't seem >right. It looks to me that it defines any IP router: receives packets, >does a lookup, forwards the packets. > > Regards, > > Jukka > >On Mon, 21 Oct 2002, Behcet Sarikaya wrote: > > > >>Jukka, what about: >> >>Routing proxies are the network nodes that receive datagrams, decide >>based on a lookup to which server to forward the datagram. The forwarding >>is stateless. >>The Home Agent and Foreign Agent are examples of routing >>proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and >>tunnel them to the current address of the the correct mobile node. >> >> >>This would clarify forwarding by tunneling and other concepts. >> >>Regards, >> >>Jukka MJ Manner wrote: >> >> >> >>> Hi all, >>> >>> So far I have seen only one comment to the terminology draft, to >>>replace our proposed definition of "Routing Proxy" >>> >>>"A node that routes packets by overlays, eg. by tunneling, between >>>communicating partners and without doing any non-routing related >>>processing. The Home Agent and Foreign Agent are examples of routing >>>proxies, in that they receive packets destined for the mobile node and >>>tunnel them to the current address of the mobile node." >>> >>> with the following: >>> >>>"Routing proxies are the network nodes that receive datagrams, decide >>>based on a lookup to which server to forward the datagram. The forwarding >>>is stateless." >>> >>> >>> I would keep the existing definition... it says a little more. >>> >>> >>> In addition, we had the following TODO items mentioned in the >>>draft: >>> >>> >>>1) Add basic terminology about mobile networks. >>> >>>Question: what terms should be considered? >>> >>> >>>2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, >>>FBU. >>> >>>Question: would these be needed? What else? >>> >>> >>>3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add >>>missing parts. >>> >>>Question: This draft does not have any mention of various care of >>>addresses, should it? What else? >>> >>> >>>4) Compare against definitions in the LMM documents of the IRTF MM- >>>subgroup (taxonomy draft expired). See if there is some harmonization to >>>be done. Can be found at: >>>http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt >>> >>>Question: is there something someone would like to have in the Seamoby >>>terminology draft, to better cover the world on IP mobility? >>> >>> >>>5) Re-write the Network Components section >>> >>>Question: How should the present version be changed? >>> >>> >>> We would like to get the comments from the Working Group this >>>week, so that we may prepare a new version for Atlanta. >>> >>> >>> Regards, >>> >>> Jukka >>> >>> >>> >>> >>> >>> >> >> > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > -- Behcet --------------050200070703070004090002 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit You are right, maybe this one could help:

Routing proxies are the network nodes that build a lookup table based on registrations, arrange for receiving datagrams on the behalf of the registered nodes, receive the datagrams, decide based on a lookup to which destination to forward the datagram. The forwarding is stateless.

The Home Agent, Foreign Agent and Localized Mobility Agents such as MAP are examples of routing proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and tunnel them to the current address of the correct mobile node.


Jukka MJ Manner wrote:
	Hi,

	It is the first sentence of your definition that doesn't seem
right. It looks to me that it defines any IP router: receives packets,
does a lookup, forwards the packets.

	Regards,

	Jukka

On Mon, 21 Oct 2002, Behcet Sarikaya wrote:

  
Jukka, what about:

Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless.
The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node, do a lookup in the binding cache and
tunnel them to the current address of the the correct mobile node.


This would clarify forwarding by tunneling and other concepts.

Regards,

Jukka MJ Manner wrote:

    
	Hi all,

	So far I have seen only one comment to the terminology draft, to 
replace our proposed definition of "Routing Proxy"

"A node that routes packets by overlays, eg. by tunneling, between
communicating partners and without doing any non-routing related
processing. The Home Agent and Foreign Agent are examples of routing
proxies, in that they receive packets destined for the mobile node and
tunnel them to the current address of the mobile node."

	with the following:

"Routing proxies are the network nodes that receive datagrams, decide
based on a lookup to which server to forward the datagram. The forwarding
is stateless."


	I would keep the existing definition... it says a little more.


	In addition, we had the following TODO items mentioned in the 
draft:


1) Add basic terminology about mobile networks. 

Question: what terms should be considered?


2) Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", BU, 
FBU.

Question: would these be needed? What else?


3) Compare to the definitions in FMIPv6 (and other MIP drafts) and add 
missing parts.

Question: This draft does not have any mention of various care of
addresses, should it? What else?


4) Compare against definitions in the LMM documents of the IRTF MM-
subgroup (taxonomy draft expired).  See if there is some harmonization to
be done. Can be found at: 
http://www.yegin.org/alper/draft-irtf-mm-taxonomy-00.txt

Question: is there something someone would like to have in the Seamoby 
terminology draft, to better cover the world on IP mobility?


5) Re-write the Network Components section

Question: How should the present version be changed?


	We would like to get the comments from the Working Group this
week, so that we may prepare a new version for Atlanta.


	Regards,

	Jukka


 

      
    

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby
  

-- 
Behcet

--------------050200070703070004090002-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Oct 22 17:33:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05428 for ; Tue, 22 Oct 2002 17:33:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MLZ2v07877; Tue, 22 Oct 2002 17:35:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MLYLv07831 for ; Tue, 22 Oct 2002 17:34:21 -0400 Received: from uber7.geektech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05325 for ; Tue, 22 Oct 2002 17:31:58 -0400 (EDT) Received: from localhost.localdomain (mail2.free-4you.com [64.214.129.45]) by uber7.geektech.com (Postfix) with ESMTP id E1C6452C1A for ; Wed, 23 Oct 2002 05:46:33 -0500 (CDT) Content-Transfer-Encoding: binary Content-Type: multipart/alternative; boundary="_----------=_103531511895751556" MIME-Version: 1.0 Date: Tue, 22 Oct 2002 19:31:58 UT From: "Carol S" To: seamoby@ietf.org Return-Errors-To: Reply-To: X-Sender: "Carol S" X-Mime-Flavour: eJxjYuLidA8IjwqPtmDSUjRUkItzCAEAJMUD+A== Message-Id: <20021023104633.E1C6452C1A@uber7.geektech.com> Subject: [Seamoby] hi Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --_----------=_103531511895751556 Content-Disposition: inline Content-Length: 2 Content-Type: text/plain Content-Transfer-Encoding: binary hi --_----------=_103531511895751556 Content-Disposition: inline Content-Length: 1697 Content-Type: text/html Content-Transfer-Encoding: binary Oct
Hey there!!!
I missed you the other day when you stopped by....
I cleaned my room....

They are inviting you back for a free peek for 30 minutes! Not sure how long they are gonna do that but I thought you would like to know...

looking forward to seeing you soon..

Love kristi




















You received this email because you have either had membership or trial now or at one time to one of our affiliate sites.. here to no longer get it in the future.

--_----------=_103531511895751556-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Oct 22 17:33:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05441 for ; Tue, 22 Oct 2002 17:33:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MLYav07844; Tue, 22 Oct 2002 17:34:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MLXcv07815 for ; Tue, 22 Oct 2002 17:33:38 -0400 Received: from uber6.geektech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05314 for ; Tue, 22 Oct 2002 17:31:14 -0400 (EDT) Received: from localhost.localdomain (mail2.free-4you.com [64.214.129.45]) by uber6.geektech.com (Postfix) with ESMTP id C8D5058089 for ; Tue, 22 Oct 2002 16:31:54 -0500 (CDT) Content-Transfer-Encoding: binary Content-Type: multipart/alternative; boundary="_----------=_103531507395859575" MIME-Version: 1.0 Date: Tue, 22 Oct 2002 19:31:13 UT From: "Carol S" To: seamoby@ietf.org Return-Errors-To: Reply-To: X-Sender: "Carol S" X-Mime-Flavour: eJxjYuLidA8IjwqPtmDSUjRUkItzCAEAJMUD+A== Message-Id: <20021022213154.C8D5058089@uber6.geektech.com> Subject: [Seamoby] hi Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --_----------=_103531507395859575 Content-Disposition: inline Content-Length: 2 Content-Type: text/plain Content-Transfer-Encoding: binary hi --_----------=_103531507395859575 Content-Disposition: inline Content-Length: 1697 Content-Type: text/html Content-Transfer-Encoding: binary Oct
Hey there!!!
I missed you the other day when you stopped by....
I cleaned my room....

They are inviting you back for a free peek for 30 minutes! Not sure how long they are gonna do that but I thought you would like to know...

looking forward to seeing you soon..

Love kristi




















You received this email because you have either had membership or trial now or at one time to one of our affiliate sites.. here to no longer get it in the future.

--_----------=_103531507395859575-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 22 17:34:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05479 for ; Tue, 22 Oct 2002 17:34:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MLZwv07899 for seamoby-archive@odin.ietf.org; Tue, 22 Oct 2002 17:35:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MLZwv07896 for ; Tue, 22 Oct 2002 17:35:58 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05444 for ; Tue, 22 Oct 2002 17:33:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MLZ2v07877; Tue, 22 Oct 2002 17:35:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MLYLv07831 for ; Tue, 22 Oct 2002 17:34:21 -0400 Received: from uber7.geektech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05325 for ; Tue, 22 Oct 2002 17:31:58 -0400 (EDT) Received: from localhost.localdomain (mail2.free-4you.com [64.214.129.45]) by uber7.geektech.com (Postfix) with ESMTP id E1C6452C1A for ; Wed, 23 Oct 2002 05:46:33 -0500 (CDT) Content-Transfer-Encoding: binary Content-Type: multipart/alternative; boundary="_----------=_103531511895751556" MIME-Version: 1.0 Date: Tue, 22 Oct 2002 19:31:58 UT From: "Carol S" To: seamoby@ietf.org Return-Errors-To: Reply-To: X-Sender: "Carol S" X-Mime-Flavour: eJxjYuLidA8IjwqPtmDSUjRUkItzCAEAJMUD+A== Message-Id: <20021023104633.E1C6452C1A@uber7.geektech.com> Subject: [Seamoby] hi Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --_----------=_103531511895751556 Content-Disposition: inline Content-Length: 2 Content-Type: text/plain Content-Transfer-Encoding: binary hi --_----------=_103531511895751556 Content-Disposition: inline Content-Length: 1697 Content-Type: text/html Content-Transfer-Encoding: binary Oct
Hey there!!!
I missed you the other day when you stopped by....
I cleaned my room....

They are inviting you back for a free peek for 30 minutes! Not sure how long they are gonna do that but I thought you would like to know...

looking forward to seeing you soon..

Love kristi




















You received this email because you have either had membership or trial now or at one time to one of our affiliate sites.. here to no longer get it in the future.

--_----------=_103531511895751556-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Oct 22 17:34:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05490 for ; Tue, 22 Oct 2002 17:34:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9MLZx807916 for seamoby-archive@odin.ietf.org; Tue, 22 Oct 2002 17:35:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MLZxv07911 for ; Tue, 22 Oct 2002 17:35:59 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05459 for ; Tue, 22 Oct 2002 17:33:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MLYav07844; Tue, 22 Oct 2002 17:34:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MLXcv07815 for ; Tue, 22 Oct 2002 17:33:38 -0400 Received: from uber6.geektech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05314 for ; Tue, 22 Oct 2002 17:31:14 -0400 (EDT) Received: from localhost.localdomain (mail2.free-4you.com [64.214.129.45]) by uber6.geektech.com (Postfix) with ESMTP id C8D5058089 for ; Tue, 22 Oct 2002 16:31:54 -0500 (CDT) Content-Transfer-Encoding: binary Content-Type: multipart/alternative; boundary="_----------=_103531507395859575" MIME-Version: 1.0 Date: Tue, 22 Oct 2002 19:31:13 UT From: "Carol S" To: seamoby@ietf.org Return-Errors-To: Reply-To: X-Sender: "Carol S" X-Mime-Flavour: eJxjYuLidA8IjwqPtmDSUjRUkItzCAEAJMUD+A== Message-Id: <20021022213154.C8D5058089@uber6.geektech.com> Subject: [Seamoby] hi Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --_----------=_103531507395859575 Content-Disposition: inline Content-Length: 2 Content-Type: text/plain Content-Transfer-Encoding: binary hi --_----------=_103531507395859575 Content-Disposition: inline Content-Length: 1697 Content-Type: text/html Content-Transfer-Encoding: binary Oct
Hey there!!!
I missed you the other day when you stopped by....
I cleaned my room....

They are inviting you back for a free peek for 30 minutes! Not sure how long they are gonna do that but I thought you would like to know...

looking forward to seeing you soon..

Love kristi




















You received this email because you have either had membership or trial now or at one time to one of our affiliate sites.. here to no longer get it in the future.

--_----------=_103531507395859575-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Oct 25 23:28:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20169 for ; Fri, 25 Oct 2002 23:28:19 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9Q3QIv16996; Fri, 25 Oct 2002 23:26:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9Q3Mvv16815 for ; Fri, 25 Oct 2002 23:22:57 -0400 Received: from mail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19853 for ; Fri, 25 Oct 2002 23:19:23 -0400 (EDT) Message-Id: <200210260319.XAA19853@ietf.org> From: "NOEL MBEKA" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 26 Oct 2002 04:21:43 +0100 Reply-To: "NOEL MBEKA" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Seamoby] SOLICITING FOR YOU ASSISTANCE. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit email: noel_mbeka@rediffmail.com noelmbeka@rediffmail.com E-fax : +1-775-514-9315 Greetings, I send this mail in good faith, if considered, contact me, if not disregard it.I needed a partner to protect my interest abroad, hence this mail to you. I am mr Noel Mbeka, i work with the bank of Liberia in the international draft payment section. I want to confirm from you, if you will permit me to raise a draft in your name or your company name which you will cash in any advanced country in the world. iF ACCEPTED, SEND THE NAME TO BE USED TO WRITE THE DRAFT, YOUR ADDRESS,TELEPHONE NUMBER. The draft will be raised in the amount of ten million America dollars. Please note that there must be an agreement binding us before sending out the draft. This is because of the war tenson in my country. You are free to suggest what will be your commission in your return mail. Your reply is anticipated. Yours faithfully, Noel mbeka. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Oct 25 23:28:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20209 for ; Fri, 25 Oct 2002 23:28:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9Q3Um017276 for seamoby-archive@odin.ietf.org; Fri, 25 Oct 2002 23:30:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9Q3Umv17273 for ; Fri, 25 Oct 2002 23:30:48 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20183 for ; Fri, 25 Oct 2002 23:28:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9Q3QIv16996; Fri, 25 Oct 2002 23:26:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9Q3Mvv16815 for ; Fri, 25 Oct 2002 23:22:57 -0400 Received: from mail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19853 for ; Fri, 25 Oct 2002 23:19:23 -0400 (EDT) Message-Id: <200210260319.XAA19853@ietf.org> From: "NOEL MBEKA" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 26 Oct 2002 04:21:43 +0100 Reply-To: "NOEL MBEKA" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Seamoby] SOLICITING FOR YOU ASSISTANCE. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit email: noel_mbeka@rediffmail.com noelmbeka@rediffmail.com E-fax : +1-775-514-9315 Greetings, I send this mail in good faith, if considered, contact me, if not disregard it.I needed a partner to protect my interest abroad, hence this mail to you. I am mr Noel Mbeka, i work with the bank of Liberia in the international draft payment section. I want to confirm from you, if you will permit me to raise a draft in your name or your company name which you will cash in any advanced country in the world. iF ACCEPTED, SEND THE NAME TO BE USED TO WRITE THE DRAFT, YOUR ADDRESS,TELEPHONE NUMBER. The draft will be raised in the amount of ten million America dollars. Please note that there must be an agreement binding us before sending out the draft. This is because of the war tenson in my country. You are free to suggest what will be your commission in your return mail. Your reply is anticipated. Yours faithfully, Noel mbeka. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Oct 26 09:07:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06087 for ; Sat, 26 Oct 2002 09:07:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QD5lv15258; Sat, 26 Oct 2002 09:05:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QD4gv15171 for ; Sat, 26 Oct 2002 09:04:42 -0400 Received: from smtp11.singnet.com.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06020 for ; Sat, 26 Oct 2002 09:02:19 -0400 (EDT) Received: from yahoo.com (bb-203-125-30-131.singnet.com.sg [203.125.30.131]) by smtp11.singnet.com.sg (8.12.6/8.12.6) with ESMTP id g9QD2kPe026447 for ; Sat, 26 Oct 2002 21:04:36 +0800 (SGT) Message-ID: <4180-220021062613422748@yahoo.com> From: "" To: seamoby@ietf.org Date: Sat, 26 Oct 2002 21:04:22 +0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9QD4hv15172 Subject: [Seamoby] Generate Your Funds With Not Repaid - is Yours Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear Friends & Potential Entrepreneur, FOLLOW & CREAT YOUR DREAM IT IS POSSIBLE This is your invitation to join the internet multi-lever marketing technique one of the chain most rewarding scheme to generate funds from the circular and live the life we have always dreamed. You may have been discreetly recommended by someone who considers you a valuable friend or alternatively an "ambition person" perhaps considers you a potential entrepreneur, with the growth of international commerce on internet has extended its operation around the world and is making people like yourself millionaires everyday. The scheme it having run with immense success in previous years by "Snail Mail" before its transfer to the Internet, the scheme going to offer you a complete mind dream, you receive the countless envelopes daily in your mailbox, the secret principles behind creating capital for themselves and living a long, prosperous and happy life, the flagging economy indicates that additional income is needed by many people like yourself if you follow & did it. ================================================================================ AS SEEN ON NATIONAL TV IN AMERICA Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time! Before you read the rest, this is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, US national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. Due to the recent increase of popularity & respect this program has attained, it is currently working better than ever; this is what one had to say: Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined to see what one could expect in return for the minimal effort and money required, To my I received total USD610,470.00 in 21 weeks. With money still coming in. This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and later I keep receiving envelope with $$$ till now. ================================================================================ THE SECRET RECOVERED HISTORY OF THE FOUNDATION STONE The unique ideal rapidly multiplying any size investment has always been successful, although the principle concept is unknown to the vast majority of people; the core secrets have been carefully preserved and passed on to each succeeding business through the ideal. The following is an example: Let's see how the ideals of rapidly multiplying goes, assume you and those involved send out 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report #1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's 100 people responded and ordered Report #2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report #3. Those 1000 people send out 5,000 e-mails each for a total of 5million e-mails sent out. The 0.2% response to that are 10,000 orders for Report #4. Those 10,000 people send out 5,000 e-mails each for a t! otal of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report #5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). Your total in come in this example is: 1....$50+ 2....$500+ 3....$5,000+ 4....$50,000+ 5....$500,000 Grand Total = $555,550.00 ================================================================================ MULTI - LEVEL MARKETING IS A LEADING WAY "MILLIONAIRES" There are 2 Primary methods to get this venture going: Method #1: By Sending Bulk E-mail Legally. To assist you with marketing your business on the Internet, the 5 reports herein below you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified Ads and much more. Method # 2 By Placing Free Ads on The Internet REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even one 4th of those people mailed 100,000e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! Advertising on the net is very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method #1 and add METHOD #2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it will be prompt because they can not advertise until they receive the report. ================================================================================ HOW TO START TO TAKE UP AN ORDER TO CREAT YOUR DREAM FROM THE REPORT # 1, 2, 3, 4, & 5 For each report order, send $5.00 Cash to the Name & Number of the Reports your are ordering and YOUR E-MAIL ADDRESS to the person whose name appears ON BELOW LIST, MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER. When you place your order, make sure you order each of the #1- 5 reports, your total cost $5 X 5=$25.00. Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals, so they will be accessible for you and advise you how to send to people who will order them from you. After you have ordered (posted out) all 5 reports specified below, please follow up the instruction as bellows: 1. REMOVE the name & address of the person in REPORT #5. This person has made it through the cycle and is no doubt counting their fortune. 2. Move the name & address in REPORT #4 down TO REPORT #5. 3. Move the name & address in REPORT #3 down TO REPORT #4. 4. Move the name & address in REPORT #2 down TO REPORT #3. 5. Move the name & address in REPORT #1 down TO REPORT #2. 6. Insert YOUR name & address in the REPORT #1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ** (After you have followed the instruction of 1 - 6, save them in your computer with an original massage you received and ready to e-mail out the massage to Potential Entrepreneur. You will be advised by the 5 reports you purchased and make sure you are ready to go). ** NOTE: ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step ''1 through 6'' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not tries to change anything other than what is instructed. If you do, it will not work for you. Remember, honesty reaps the reward! ================================================================================ PLACE YOUR ORDER FOR THESE REPORTS NOW REPORT #1 "The Insider's Guide to Advertising for Free on the Net" Order Report #1 From: Chunglin Blk 105 #17-07 Henderson Crescent Singapore 150105 REPORT #2 "The Insider's Guide to Advertising for Free on the Net" Order Report #2 From: Martt Bergen 40 West Boothby Crescent Cochrane, AB. T4C-1L9 Canada REPORT #3 "The Insider's Guide to Sending Bulk e-mail on the Net" Order Report # 3 From: William Burton 9-G Colonial Crest Circle Hanover, PA 17331 USA REPORT #4 "Secret to Multilevel Marketing on the Net" Order Report # 4 From: R Mosse P. O. Box 210161 Milwaukee, WI 53221 USA REPORT #5 "How to Become a Millionaire Utilizing MLM & the Net" Order Report # 5 From: RL and Associates 872 S. Milwaukee Ave. (#103) Libertyville, IL 60048-3277 USA ================================================================================ YOUR SUCCESS GUIDE LINES Follow these guidelines to guarantee your success; your success will be based primarily on your level of activity. The more activity you have, the more prospects you have, the more prospects you have, the larger your downline becomes, the larger your downline becomes, the more envelope you received. If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for Report #2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in Front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERA! TE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! ================================================================================ NOTE FROM THE ORIGINATOR OF THIS PROGRAM You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 thru # 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! ================================================================================ MORE TESTIMONIALS "My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois ********** ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ********** ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else........11 months passed then it luckily came again I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks." Susan De Suza, New York, N.Y. ********** ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20,560.00 and by the end of third month my total cash count was $362,840.00. Life is beautiful, Thank to Internet." Fred Dellaca, Westport, New Zealand ================================================================================ ORDER YOUR REPORTS TODAY AND GET STARTED ON 'YOUR' ROAD TO FINANCIAL FREEDOM! If you have any questions of the legality of this program, contact The Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C --------------------------------------------------------------------------------- The FREE booklet "Make $500,000 in the ext 100 days" will unlock the doors to success and money. Freesources1@yahoo.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Oct 26 09:08:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06107 for ; Sat, 26 Oct 2002 09:08:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9QDAEe15918 for seamoby-archive@odin.ietf.org; Sat, 26 Oct 2002 09:10:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QDAEv15915 for ; Sat, 26 Oct 2002 09:10:14 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06101 for ; Sat, 26 Oct 2002 09:07:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QD5lv15258; Sat, 26 Oct 2002 09:05:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QD4gv15171 for ; Sat, 26 Oct 2002 09:04:42 -0400 Received: from smtp11.singnet.com.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06020 for ; Sat, 26 Oct 2002 09:02:19 -0400 (EDT) Received: from yahoo.com (bb-203-125-30-131.singnet.com.sg [203.125.30.131]) by smtp11.singnet.com.sg (8.12.6/8.12.6) with ESMTP id g9QD2kPe026447 for ; Sat, 26 Oct 2002 21:04:36 +0800 (SGT) Message-ID: <4180-220021062613422748@yahoo.com> From: "" To: seamoby@ietf.org Date: Sat, 26 Oct 2002 21:04:22 +0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9QD4hv15172 Subject: [Seamoby] Generate Your Funds With Not Repaid - is Yours Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Dear Friends & Potential Entrepreneur, FOLLOW & CREAT YOUR DREAM IT IS POSSIBLE This is your invitation to join the internet multi-lever marketing technique one of the chain most rewarding scheme to generate funds from the circular and live the life we have always dreamed. You may have been discreetly recommended by someone who considers you a valuable friend or alternatively an "ambition person" perhaps considers you a potential entrepreneur, with the growth of international commerce on internet has extended its operation around the world and is making people like yourself millionaires everyday. The scheme it having run with immense success in previous years by "Snail Mail" before its transfer to the Internet, the scheme going to offer you a complete mind dream, you receive the countless envelopes daily in your mailbox, the secret principles behind creating capital for themselves and living a long, prosperous and happy life, the flagging economy indicates that additional income is needed by many people like yourself if you follow & did it. ================================================================================ AS SEEN ON NATIONAL TV IN AMERICA Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time! Before you read the rest, this is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, US national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. Due to the recent increase of popularity & respect this program has attained, it is currently working better than ever; this is what one had to say: Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined to see what one could expect in return for the minimal effort and money required, To my I received total USD610,470.00 in 21 weeks. With money still coming in. This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and later I keep receiving envelope with $$$ till now. ================================================================================ THE SECRET RECOVERED HISTORY OF THE FOUNDATION STONE The unique ideal rapidly multiplying any size investment has always been successful, although the principle concept is unknown to the vast majority of people; the core secrets have been carefully preserved and passed on to each succeeding business through the ideal. The following is an example: Let's see how the ideals of rapidly multiplying goes, assume you and those involved send out 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report #1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's 100 people responded and ordered Report #2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report #3. Those 1000 people send out 5,000 e-mails each for a total of 5million e-mails sent out. The 0.2% response to that are 10,000 orders for Report #4. Those 10,000 people send out 5,000 e-mails each for a t! otal of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report #5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). Your total in come in this example is: 1....$50+ 2....$500+ 3....$5,000+ 4....$50,000+ 5....$500,000 Grand Total = $555,550.00 ================================================================================ MULTI - LEVEL MARKETING IS A LEADING WAY "MILLIONAIRES" There are 2 Primary methods to get this venture going: Method #1: By Sending Bulk E-mail Legally. To assist you with marketing your business on the Internet, the 5 reports herein below you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified Ads and much more. Method # 2 By Placing Free Ads on The Internet REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even one 4th of those people mailed 100,000e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! Advertising on the net is very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method #1 and add METHOD #2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it will be prompt because they can not advertise until they receive the report. ================================================================================ HOW TO START TO TAKE UP AN ORDER TO CREAT YOUR DREAM FROM THE REPORT # 1, 2, 3, 4, & 5 For each report order, send $5.00 Cash to the Name & Number of the Reports your are ordering and YOUR E-MAIL ADDRESS to the person whose name appears ON BELOW LIST, MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER. When you place your order, make sure you order each of the #1- 5 reports, your total cost $5 X 5=$25.00. Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals, so they will be accessible for you and advise you how to send to people who will order them from you. After you have ordered (posted out) all 5 reports specified below, please follow up the instruction as bellows: 1. REMOVE the name & address of the person in REPORT #5. This person has made it through the cycle and is no doubt counting their fortune. 2. Move the name & address in REPORT #4 down TO REPORT #5. 3. Move the name & address in REPORT #3 down TO REPORT #4. 4. Move the name & address in REPORT #2 down TO REPORT #3. 5. Move the name & address in REPORT #1 down TO REPORT #2. 6. Insert YOUR name & address in the REPORT #1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ** (After you have followed the instruction of 1 - 6, save them in your computer with an original massage you received and ready to e-mail out the massage to Potential Entrepreneur. You will be advised by the 5 reports you purchased and make sure you are ready to go). ** NOTE: ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step ''1 through 6'' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not tries to change anything other than what is instructed. If you do, it will not work for you. Remember, honesty reaps the reward! ================================================================================ PLACE YOUR ORDER FOR THESE REPORTS NOW REPORT #1 "The Insider's Guide to Advertising for Free on the Net" Order Report #1 From: Chunglin Blk 105 #17-07 Henderson Crescent Singapore 150105 REPORT #2 "The Insider's Guide to Advertising for Free on the Net" Order Report #2 From: Martt Bergen 40 West Boothby Crescent Cochrane, AB. T4C-1L9 Canada REPORT #3 "The Insider's Guide to Sending Bulk e-mail on the Net" Order Report # 3 From: William Burton 9-G Colonial Crest Circle Hanover, PA 17331 USA REPORT #4 "Secret to Multilevel Marketing on the Net" Order Report # 4 From: R Mosse P. O. Box 210161 Milwaukee, WI 53221 USA REPORT #5 "How to Become a Millionaire Utilizing MLM & the Net" Order Report # 5 From: RL and Associates 872 S. Milwaukee Ave. (#103) Libertyville, IL 60048-3277 USA ================================================================================ YOUR SUCCESS GUIDE LINES Follow these guidelines to guarantee your success; your success will be based primarily on your level of activity. The more activity you have, the more prospects you have, the more prospects you have, the larger your downline becomes, the larger your downline becomes, the more envelope you received. If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for Report #2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in Front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERA! TE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! ================================================================================ NOTE FROM THE ORIGINATOR OF THIS PROGRAM You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 thru # 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! ================================================================================ MORE TESTIMONIALS "My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois ********** ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ********** ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else........11 months passed then it luckily came again I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks." Susan De Suza, New York, N.Y. ********** ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20,560.00 and by the end of third month my total cash count was $362,840.00. Life is beautiful, Thank to Internet." Fred Dellaca, Westport, New Zealand ================================================================================ ORDER YOUR REPORTS TODAY AND GET STARTED ON 'YOUR' ROAD TO FINANCIAL FREEDOM! If you have any questions of the legality of this program, contact The Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C --------------------------------------------------------------------------------- The FREE booklet "Make $500,000 in the ext 100 days" will unlock the doors to success and money. Freesources1@yahoo.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Oct 26 19:35:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14827 for ; Sat, 26 Oct 2002 19:35:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QNUdv08067; Sat, 26 Oct 2002 19:30:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QNT5v07636 for ; Sat, 26 Oct 2002 19:29:05 -0400 Received: from mail.com (host-66-133-60-178.verestar.net [66.133.60.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14425 for ; Sat, 26 Oct 2002 19:26:26 -0400 (EDT) Message-Id: <200210262326.TAA14425@ietf.org> From: "LOUISA E. ESTRADA" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Sun, 27 Oct 2002 00:28:51 +0100 Reply-To: "LOUISA E. ESTRADA" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Seamoby] SOLICITING FOR YOUR ASSISTANCE. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit FROM: MRS. LOUISA EJERCITOR ESTRADA Email: estradal@rediffmail.com estradalo@rediffmail.com E-fax: +1 775-458-2140 Dear Sir, I got your contact address through a reliable friend in my search for a reliable and trustworthy person who will assist me in a business investment venture in your country. I am Mrs. LOUISA EJERCITOR ESTRADA, the wife of Mr. Joseph Estrada the former president of Philippine located in the south East Asia. My husband was presently impeached from office by a backed uprising of mass demonstrators and the senate. During my husband's regime as president of Philippine, I realized US$21.540 millions of dollars from various contract projects I executed successfully. I had planned to invest this money for my children's future on real estate and industrial production. My husband is not aware of this because I wish to do it secretly for now. Before my husband was impeached from office, I concretely and secretly deposited this money and declared it computer ledger cards with diplomatic Security Company that transports valuable goods/consignment through diplomatic courier service to their offshore offices. The consignments that are contained in the two trunks are declared owned by my foreign business partners. I wish to discuss how much I will offer you if you will be willing to assist me claim the money and invest it in your country. I want to assure you that all modalities are put in place and it is a risk free transaction. I trust you as a God fearing person who will not sit on my life saving fund. This business demands absolute secrecy and confidentiality, thus all communications for now should be through e-mail because all my phone lines are connected to the Philippine's Telecommunication network services. I will furnish you with more details when I receive your positive response. Expecting your urgent reply. Thanking you for your anticipated co-operation. Best regards, MRS. LOUISA EJERCITOR ESTRADA _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sat Oct 26 19:36:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14859 for ; Sat, 26 Oct 2002 19:36:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9QNc7D09000 for seamoby-archive@odin.ietf.org; Sat, 26 Oct 2002 19:38:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QNc7v08997 for ; Sat, 26 Oct 2002 19:38:07 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14841 for ; Sat, 26 Oct 2002 19:35:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QNUdv08067; Sat, 26 Oct 2002 19:30:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QNT5v07636 for ; Sat, 26 Oct 2002 19:29:05 -0400 Received: from mail.com (host-66-133-60-178.verestar.net [66.133.60.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14425 for ; Sat, 26 Oct 2002 19:26:26 -0400 (EDT) Message-Id: <200210262326.TAA14425@ietf.org> From: "LOUISA E. ESTRADA" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Sun, 27 Oct 2002 00:28:51 +0100 Reply-To: "LOUISA E. ESTRADA" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Seamoby] SOLICITING FOR YOUR ASSISTANCE. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit FROM: MRS. LOUISA EJERCITOR ESTRADA Email: estradal@rediffmail.com estradalo@rediffmail.com E-fax: +1 775-458-2140 Dear Sir, I got your contact address through a reliable friend in my search for a reliable and trustworthy person who will assist me in a business investment venture in your country. I am Mrs. LOUISA EJERCITOR ESTRADA, the wife of Mr. Joseph Estrada the former president of Philippine located in the south East Asia. My husband was presently impeached from office by a backed uprising of mass demonstrators and the senate. During my husband's regime as president of Philippine, I realized US$21.540 millions of dollars from various contract projects I executed successfully. I had planned to invest this money for my children's future on real estate and industrial production. My husband is not aware of this because I wish to do it secretly for now. Before my husband was impeached from office, I concretely and secretly deposited this money and declared it computer ledger cards with diplomatic Security Company that transports valuable goods/consignment through diplomatic courier service to their offshore offices. The consignments that are contained in the two trunks are declared owned by my foreign business partners. I wish to discuss how much I will offer you if you will be willing to assist me claim the money and invest it in your country. I want to assure you that all modalities are put in place and it is a risk free transaction. I trust you as a God fearing person who will not sit on my life saving fund. This business demands absolute secrecy and confidentiality, thus all communications for now should be through e-mail because all my phone lines are connected to the Philippine's Telecommunication network services. I will furnish you with more details when I receive your positive response. Expecting your urgent reply. Thanking you for your anticipated co-operation. Best regards, MRS. LOUISA EJERCITOR ESTRADA _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 28 09:42:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11519 for ; Mon, 28 Oct 2002 09:42:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SEhsv27284; Mon, 28 Oct 2002 09:43:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SEg3v27233 for ; Mon, 28 Oct 2002 09:42:03 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11365 for ; Mon, 28 Oct 2002 09:39:39 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9SEgHB11858 for ; Mon, 28 Oct 2002 16:42:17 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 28 Oct 2002 16:41:59 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 16:41:59 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 16:41:59 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 16:41:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Oct 2002 16:41:58 +0200 Message-ID: Thread-Topic: [Seamoby] AD: more about draft-ietf-seamoby-cardiscovery-issues-03.txt Thread-Index: AcJy0sqQ2/7C/uJ3QmqchcMXYRdK6gLvHhYg To: X-OriginalArrivalTime: 28 Oct 2002 14:41:59.0219 (UTC) FILETIME=[2BA18030:01C27E90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9SEg4v27234 Subject: [Seamoby] Output of the CTP design team Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello all, I have recently submitted the first version of the Context Transfer Protocol to the drafts editor. Unfortunately, because of some time constaints, the current draft raises more questions than it answers. I hope to have time later to send a summary of the points that need resolving. Until it is announce, a version of the protocol can be found here: http://www-nrc.nokia.com/sua/draft-ietf-seamoby-ctp-00.txt I apologize in advance for the half-baked-ness of the proposal. My intention is to continue to refine the draft and submit a more fully-baked proposal as soon as the submissions queue is re-opened. thanks, John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 28 09:43:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11573 for ; Mon, 28 Oct 2002 09:43:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SEj5X27381 for seamoby-archive@odin.ietf.org; Mon, 28 Oct 2002 09:45:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SEj5v27378 for ; Mon, 28 Oct 2002 09:45:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11546 for ; Mon, 28 Oct 2002 09:42:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SEhsv27284; Mon, 28 Oct 2002 09:43:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SEg3v27233 for ; Mon, 28 Oct 2002 09:42:03 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11365 for ; Mon, 28 Oct 2002 09:39:39 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9SEgHB11858 for ; Mon, 28 Oct 2002 16:42:17 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 28 Oct 2002 16:41:59 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 16:41:59 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 16:41:59 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 16:41:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Oct 2002 16:41:58 +0200 Message-ID: Thread-Topic: [Seamoby] AD: more about draft-ietf-seamoby-cardiscovery-issues-03.txt Thread-Index: AcJy0sqQ2/7C/uJ3QmqchcMXYRdK6gLvHhYg To: X-OriginalArrivalTime: 28 Oct 2002 14:41:59.0219 (UTC) FILETIME=[2BA18030:01C27E90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9SEg4v27234 Subject: [Seamoby] Output of the CTP design team Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hello all, I have recently submitted the first version of the Context Transfer Protocol to the drafts editor. Unfortunately, because of some time constaints, the current draft raises more questions than it answers. I hope to have time later to send a summary of the points that need resolving. Until it is announce, a version of the protocol can be found here: http://www-nrc.nokia.com/sua/draft-ietf-seamoby-ctp-00.txt I apologize in advance for the half-baked-ness of the proposal. My intention is to continue to refine the draft and submit a more fully-baked proposal as soon as the submissions queue is re-opened. thanks, John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 28 14:52:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26787 for ; Mon, 28 Oct 2002 14:52:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SJrMv13187; Mon, 28 Oct 2002 14:53:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SJqwv13123 for ; Mon, 28 Oct 2002 14:52:58 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26676 for ; Mon, 28 Oct 2002 14:50:32 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9SJqrY04186 for ; Mon, 28 Oct 2002 20:52:53 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (kauai.mobility.ccrle.nec.de [192.168.101.96]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 69E1B2DAEB for ; Mon, 28 Oct 2002 20:52:45 +0100 (CET) Message-ID: <3DBD958E.3060902@ccrle.nec.de> Date: Mon, 28 Oct 2002 20:52:46 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] 1st version of CARD design team draft submitted Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, the first version of the CARD design team's draft on Candidate Access Router Discovery has been submitted to the Internet drafts editor today. This first version of the document is intended to expose some factors and alternatives to be considered for the further design of the CARD protocol. Intention is to get WG consensus on these issues to allow updating the initial version as soon as possible, having the WG's feedback incorporated. After the draft's availability has been announced, feedback and comments on this first version are highly appreciated. marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 28 14:52:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26813 for ; Mon, 28 Oct 2002 14:52:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SJsaF13316 for seamoby-archive@odin.ietf.org; Mon, 28 Oct 2002 14:54:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SJsZv13313 for ; Mon, 28 Oct 2002 14:54:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26801 for ; Mon, 28 Oct 2002 14:52:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SJrMv13187; Mon, 28 Oct 2002 14:53:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SJqwv13123 for ; Mon, 28 Oct 2002 14:52:58 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26676 for ; Mon, 28 Oct 2002 14:50:32 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g9SJqrY04186 for ; Mon, 28 Oct 2002 20:52:53 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (kauai.mobility.ccrle.nec.de [192.168.101.96]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 69E1B2DAEB for ; Mon, 28 Oct 2002 20:52:45 +0100 (CET) Message-ID: <3DBD958E.3060902@ccrle.nec.de> Date: Mon, 28 Oct 2002 20:52:46 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] 1st version of CARD design team draft submitted Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, the first version of the CARD design team's draft on Candidate Access Router Discovery has been submitted to the Internet drafts editor today. This first version of the document is intended to expose some factors and alternatives to be considered for the further design of the CARD protocol. Intention is to get WG consensus on these issues to allow updating the initial version as soon as possible, having the WG's feedback incorporated. After the draft's availability has been announced, feedback and comments on this first version are highly appreciated. marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Oct 28 15:05:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27492 for ; Mon, 28 Oct 2002 15:05:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SK7Av14303; Mon, 28 Oct 2002 15:07:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SK6kv13970 for ; Mon, 28 Oct 2002 15:06:46 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27380 for ; Mon, 28 Oct 2002 15:04:19 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27EBD.868E01EC" Date: Mon, 28 Oct 2002 12:06:39 -0800 Message-ID: <40301581B2962B448690A023EF16DFE1189086@bsn-mail-01.bstormnetworks.com> Thread-Topic: A big thank you to CARD and CT design team Thread-Index: AcJ+vYZH8VPoSDiOQkajVDKCrs4L3A== From: "Pat R. Calhoun" To: Subject: [Seamoby] A big thank you to CARD and CT design team Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C27EBD.868E01EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to thank both the CARD and the CT design teams for putting in the extra effort and getting version 1 of the protocol document out before the I-D deadline. Crafting a protocol spec that meets the requirements under such strict deadlines is always a difficult thing to achieve, but they pulled it off. =20 Of course, none of the two documents are finished yet and I expect additional versions of the document in the future. However, I would encourage the WG to review both documents and send your comments to the mailing list. =20 Thanks again! =20 PatC ------_=_NextPart_001_01C27EBD.868E01EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I = would like to=20 thank both the CARD and the CT design teams for putting in the extra = effort and=20 getting version 1 of the protocol document out before the I-D=20 deadline. Crafting a protocol spec that meets the requirements under = such strict=20 deadlines is always a difficult thing to achieve, but they pulled it=20 off.
 
Of = course, none of=20 the two documents are finished yet and I expect additional versions of = the=20 document in the future. However, I would encourage the WG to review = both=20 documents and send your comments to the mailing = list.
 
Thanks = again!
 
PatC
=00 ------_=_NextPart_001_01C27EBD.868E01EC-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Oct 28 15:06:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27532 for ; Mon, 28 Oct 2002 15:06:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SK8N914622 for seamoby-archive@odin.ietf.org; Mon, 28 Oct 2002 15:08:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SK8Nv14619 for ; Mon, 28 Oct 2002 15:08:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27506 for ; Mon, 28 Oct 2002 15:05:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SK7Av14303; Mon, 28 Oct 2002 15:07:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9SK6kv13970 for ; Mon, 28 Oct 2002 15:06:46 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27380 for ; Mon, 28 Oct 2002 15:04:19 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27EBD.868E01EC" Date: Mon, 28 Oct 2002 12:06:39 -0800 Message-ID: <40301581B2962B448690A023EF16DFE1189086@bsn-mail-01.bstormnetworks.com> Thread-Topic: A big thank you to CARD and CT design team Thread-Index: AcJ+vYZH8VPoSDiOQkajVDKCrs4L3A== From: "Pat R. Calhoun" To: Subject: [Seamoby] A big thank you to CARD and CT design team Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C27EBD.868E01EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to thank both the CARD and the CT design teams for putting in the extra effort and getting version 1 of the protocol document out before the I-D deadline. Crafting a protocol spec that meets the requirements under such strict deadlines is always a difficult thing to achieve, but they pulled it off. =20 Of course, none of the two documents are finished yet and I expect additional versions of the document in the future. However, I would encourage the WG to review both documents and send your comments to the mailing list. =20 Thanks again! =20 PatC ------_=_NextPart_001_01C27EBD.868E01EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I = would like to=20 thank both the CARD and the CT design teams for putting in the extra = effort and=20 getting version 1 of the protocol document out before the I-D=20 deadline. Crafting a protocol spec that meets the requirements under = such strict=20 deadlines is always a difficult thing to achieve, but they pulled it=20 off.
 
Of = course, none of=20 the two documents are finished yet and I expect additional versions of = the=20 document in the future. However, I would encourage the WG to review = both=20 documents and send your comments to the mailing = list.
 
Thanks = again!
 
PatC
=00 ------_=_NextPart_001_01C27EBD.868E01EC-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby