From mailman-owner@ietf.org Fri Feb 1 05:51:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14751 for ; Fri, 1 Feb 2002 05:51:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03392 for ; Fri, 1 Feb 2002 05:51:50 -0500 (EST) Date: Fri, 1 Feb 2002 05:51:50 -0500 (EST) Message-Id: <200202011051.FAA03392@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: seamoby-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol 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@ietf.org. Thanks! Passwords for seamoby-archive@lists.ietf.org: List Password // URL ---- -------- seamoby@ietf.org Zzch https://www1.ietf.org/mailman/options/seamoby/seamoby-archive@lists.ietf.org From mailman-owner@ietf.org Fri Feb 1 05:55:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14892 for ; Fri, 1 Feb 2002 05:55:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04607 for ; Fri, 1 Feb 2002 05:55:49 -0500 (EST) Date: Fri, 1 Feb 2002 05:55:49 -0500 (EST) Message-Id: <200202011055.FAA04607@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: seamoby-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol 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@ietf.org. Thanks! Passwords for seamoby-web-archive@ietf.org: List Password // URL ---- -------- seamoby@ietf.org zabP https://www1.ietf.org/mailman/options/seamoby/seamoby-web-archive@ietf.org From seamoby-admin@ietf.org Fri Feb 1 07:13:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19788 for ; Fri, 1 Feb 2002 07:13:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09355; Fri, 1 Feb 2002 07:00:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09324 for ; Fri, 1 Feb 2002 07:00:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19225; Fri, 1 Feb 2002 07:00:37 -0500 (EST) Message-Id: <200202011200.HAA19225@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, 01 Feb 2002 07:00:37 -0500 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-paging-protocol-assessment-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --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 : Dormant Mode Host Alerting (DMHA) Protocol Assessment Author(s) : J. Kempf et al. Filename : draft-ietf-seamoby-paging-protocol-assessment-01.txt Pages : 15 Date : 31-Jan-02 The Seamoby Working Group has been working toward specification of an IP-level protocol for Dormant Mode Host Alerting (DMHA), sometimes known as IP-paging or simply paging (the terms IP-DMHA, DMHA, IP Paging, and Paging will be used interchangeably in this document). A problem statement and requirements have been developed, and in response to a request for protocol submissions, five protocols were submitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-paging-protocol-assessment-01.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-paging-protocol-assessment-01.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-paging-protocol-assessment-01.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: <20020131125128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-paging-protocol-assessment-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-paging-protocol-assessment-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020131125128.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 Feb 1 11:15:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27823 for ; Fri, 1 Feb 2002 11:15:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22412; Fri, 1 Feb 2002 10:56:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22383 for ; Fri, 1 Feb 2002 10:56:28 -0500 (EST) Received: from hotmail.com (f224.law9.hotmail.com [64.4.9.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27322 for ; Fri, 1 Feb 2002 10:56:25 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 1 Feb 2002 07:55:54 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Fri, 01 Feb 2002 15:55:54 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Date: Fri, 01 Feb 2002 10:55:54 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Feb 2002 15:55:54.0478 (UTC) FILETIME=[EE2190E0:01C1AB38] Subject: [Seamoby] CAR Requirements Draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello all, I hope you have had the time to review the CAR Requirements Draft. Please let me know if the requirements are satisfactory. The link to the draft is http://www.ietf.org/internet-drafts/draft-krishnamurthi-seamoby-car-requirements-00.txt Regards, Govind. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 1 13:33:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06944 for ; Fri, 1 Feb 2002 13:32:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01635; Fri, 1 Feb 2002 13:13:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01607 for ; Fri, 1 Feb 2002 13:13:53 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06407 for ; Fri, 1 Feb 2002 13:13:49 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1B7WAVVF>; Fri, 1 Feb 2002 10:13:22 -0800 Message-ID: From: "Pat R. Calhoun" To: seamoby@ietf.org Date: Fri, 1 Feb 2002 10:13:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB4C.21697C70" Subject: [Seamoby] Moving forward with paging Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1AB4C.21697C70 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, As many of you know, last week we asked the WG for their comments on how to proceed with the paging work. A summary of the comments that came in is: Start from a known protocol - 5 Reopen selection phase - 3 Design team to start from scratch - 2 Drop the work altogether - 1 Many did not give opinions obviously, and these numbers are not to be viewed as a "vote" (our AD reminds us that rough consensus is not voting). But considering the 5 and 3, there is at least a preference for starting with a candidate, rather than from scratch. So the issue that needs to be resolved is which protocol should be used, since the protocol assessment wasn't conclusive, the chairs had picked one based on the findings of the assessment team. However, since an (admitedly useless) numbering rating scheme was used in the assessment, it was hard to really determine which protocol should be used. After discussing the matter ourselves, and with our AD, Allison, we decided to revise the paging assessment draft and remove the useless numerical ratings. This means that each draft must now be assessed using just technical merit. Further, a new section has been added to the document stating the chairs' basis (including charter reasons) for viewing the Renker draft as the starting point most likely to get us to the requirements and to a IETF-quality protocol... So we are calling a WG last call on the assessment document (draft-ietf-seamoby-paging-protocol-assessment-01.txt). We encourage folks to provide their *technical* comments on the draft should they believe that the findings of the assessment team are incorrect. We do ask the WG members to kindly refrain from posting any process related comments, since it detracts us from achieving our milestones. Once the WG last call is complete, we will collect the comments that have WG concensus and make any necessary changes to the draft. The WG last call ends February 25th. The end result is that the WG will get to decide which document is to be used as the *starting point*. Thanks for your patience, PatC & jak -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPFrawTN1fXKoxmisEQIaWQCfYIis0Nsd52Q0Xv7wA77/RWn4J9IAn0t2 FoREK4Kavht9sSs7VjZIhLlV =EmAk -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1AB4C.21697C70 Content-Type: text/html Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

As many of you know, last week we asked the WG for their comments on
how to proceed with the paging work.  A summary of the comments that
came in is:

       Start from a known protocol - 5
       Reopen selection phase - 3 
       Design team to start from scratch - 2 
       Drop the work altogether - 1 

Many did not give opinions obviously, and these numbers are not to be
viewed as a "vote" (our AD reminds us that rough consensus is not
voting).  But considering the 5 and 3, there is at least a preference
for starting with a candidate, rather
than from scratch.

So the issue that needs to be resolved is which protocol should be
used, since the protocol assessment wasn't conclusive, the chairs had
picked one based on the findings of the assessment team. However,
since an (admitedly useless) numbering rating scheme was used in the
assessment, it was hard to really determine which protocol should be
used.

After discussing the matter ourselves, and with our AD, Allison, we
decided to revise the paging assessment draft and remove the useless
numerical ratings. This means that each draft must now be assessed
using just technical merit. Further, a new section has been added to
the document stating the chairs' basis (including charter
reasons) for viewing the Renker draft as the starting point most
likely to get us to the requirements and to a IETF-quality
protocol...

So we are calling a WG last call on the assessment document
(draft-ietf-seamoby-paging-protocol-assessment-01.txt). We encourage
folks to provide their *technical* comments on the draft should they
believe that the findings of the assessment team are incorrect. We do
ask the WG members to kindly refrain from posting any process related
comments, since it detracts us from achieving our milestones. Once
the WG last call is complete, we will collect the comments that have
WG concensus and make any necessary changes to the draft. The WG last
call ends February 25th.

The end result is that the WG will get to decide which document is to
be used as the *starting point*.

Thanks for your patience,

PatC & jak

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPFrawTN1fXKoxmisEQIaWQCfYIis0Nsd52Q0Xv7wA77/RWn4J9IAn0t2
FoREK4Kavht9sSs7VjZIhLlV
=EmAk
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1AB4C.21697C70-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Feb 4 00:32:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06135 for ; Mon, 4 Feb 2002 00:32:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27085; Mon, 4 Feb 2002 00:10:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27060 for ; Mon, 4 Feb 2002 00:10:27 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05906 for ; Mon, 4 Feb 2002 00:10:23 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g145Ahi27554 for ; Mon, 4 Feb 2002 07:10:43 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Feb 2002 07:10:22 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Feb 2002 07:09:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AD3A.2A711358" Subject: RE: [Seamoby] Moving forward with paging Date: Mon, 4 Feb 2002 07:09:47 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9549@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Moving forward with paging Thread-Index: AcGrTER6ZZ16ch1TSTeTw9ZlR7u0GQB7WT8Q To: , X-OriginalArrivalTime: 04 Feb 2002 05:09:47.0977 (UTC) FILETIME=[2ABC3390:01C1AD3A] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1AD3A.2A711358 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pat, =20 Sorry for my late comments, I completely forgot to reply to the mail. =20 My suggest was to be quite similar to what you proposed: Use the Renker draft as a starting point, nearly a sort of 'framework' to get the work going. =20 Next, areas where the Renker document were deficient should be noted, and areas where the other candidates were strong be noted as well. =20 From this, a conference call could be held to discuss the next steps in paging could be held. Most likely, the authors of the other = documents could help move the new work group document forward. =20 best regards, John -----Original Message----- From: ext Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: 01 February, 2002 20:13 To: seamoby@ietf.org Subject: [Seamoby] Moving forward with paging -----BEGIN PGP SIGNED MESSAGE-----=20 Hash: SHA1=20 All,=20 As many of you know, last week we asked the WG for their comments on=20 how to proceed with the paging work. A summary of the comments that=20 came in is:=20 Start from a known protocol - 5=20 Reopen selection phase - 3 =20 Design team to start from scratch - 2 =20 Drop the work altogether - 1 =20 Many did not give opinions obviously, and these numbers are not to be=20 viewed as a "vote" (our AD reminds us that rough consensus is not=20 voting). But considering the 5 and 3, there is at least a preference=20 for starting with a candidate, rather=20 than from scratch.=20 So the issue that needs to be resolved is which protocol should be=20 used, since the protocol assessment wasn't conclusive, the chairs had=20 picked one based on the findings of the assessment team. However,=20 since an (admitedly useless) numbering rating scheme was used in the=20 assessment, it was hard to really determine which protocol should be=20 used.=20 After discussing the matter ourselves, and with our AD, Allison, we=20 decided to revise the paging assessment draft and remove the useless=20 numerical ratings. This means that each draft must now be assessed=20 using just technical merit. Further, a new section has been added to=20 the document stating the chairs' basis (including charter=20 reasons) for viewing the Renker draft as the starting point most=20 likely to get us to the requirements and to a IETF-quality=20 protocol...=20 So we are calling a WG last call on the assessment document=20 (draft-ietf-seamoby-paging-protocol-assessment-01.txt). We encourage=20 folks to provide their *technical* comments on the draft should they=20 believe that the findings of the assessment team are incorrect. We do=20 ask the WG members to kindly refrain from posting any process related=20 comments, since it detracts us from achieving our milestones. Once=20 the WG last call is complete, we will collect the comments that have=20 WG concensus and make any necessary changes to the draft. The WG last=20 call ends February 25th.=20 The end result is that the WG will get to decide which document is to=20 be used as the *starting point*.=20 Thanks for your patience,=20 PatC & jak=20 -----BEGIN PGP SIGNATURE-----=20 Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com>=20 iQA/AwUBPFrawTN1fXKoxmisEQIaWQCfYIis0Nsd52Q0Xv7wA77/RWn4J9IAn0t2=20 FoREK4Kavht9sSs7VjZIhLlV=20 =3DEmAk=20 -----END PGP SIGNATURE-----=20 ------_=_NextPart_001_01C1AD3A.2A711358 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Moving forward with paging
Hi=20 Pat,
 
Sorry=20 for my late comments, I completely forgot to reply to the=20 mail.
 
My=20 suggest was to be quite similar to what you proposed:  Use the=20 Renker
draft=20 as a starting point, nearly a sort of 'framework' to get the=20 work
going.
 
Next,=20 areas where the Renker document were deficient should be=20 noted,
and=20 areas where the other candidates were strong be noted as=20 well.
 
From=20 this, a conference call could be held to discuss the next=20 steps
in=20 paging could be held.  Most likely, the authors of the other=20 documents
could=20 help move the new work group document forward.
 
best=20 regards,
John
-----Original Message-----
From: ext Pat R. Calhoun = [mailto:pcalhoun@bstormnetworks.com]
Sent: 01 February, 2002 = 20:13
To: seamoby@ietf.org
Subject: [Seamoby] = Moving=20 forward with paging


-----BEGIN PGP SIGNED=20 MESSAGE-----
Hash: SHA1

All,

As many of you know, last week we asked the WG for = their=20 comments on
how to proceed with the paging = work. =20 A summary of the comments that
came in = is:

       Start from a = known=20 protocol - 5
      =20 Reopen selection phase - 3 
       Design team to start = from scratch=20 - 2 
       Drop=20 the work altogether - 1 

Many did not give opinions obviously, and these = numbers are=20 not to be
viewed as a "vote" (our AD reminds = us that=20 rough consensus is not
voting).  But = considering=20 the 5 and 3, there is at least a preference
for=20 starting with a candidate, rather
than from=20 scratch.

So the issue that needs to be resolved is which = protocol=20 should be
used, since the protocol = assessment wasn't=20 conclusive, the chairs had
picked one based = on the=20 findings of the assessment team. However,
since an=20 (admitedly useless) numbering rating scheme was used in the =
assessment, it was hard to really determine which protocol = should=20 be
used.

After discussing the matter ourselves, and with our = AD,=20 Allison, we
decided to revise the paging = assessment=20 draft and remove the useless
numerical = ratings. This=20 means that each draft must now be assessed
using just=20 technical merit. Further, a new section has been added to =
the document stating the chairs' basis (including = charter=20
reasons) for viewing the Renker draft as the = starting point=20 most
likely to get us to the requirements = and to a=20 IETF-quality
protocol...

So we are calling a WG last call on the assessment=20 document
(draft-ietf-seamoby-paging-protocol-assessment-01.txt). We=20 encourage
folks to provide their *technical* = comments=20 on the draft should they
believe that the = findings of=20 the assessment team are incorrect. We do
ask = the WG=20 members to kindly refrain from posting any process related =
comments, since it detracts us from achieving our milestones. = Once
the WG last call is complete, we will = collect the=20 comments that have
WG concensus and make any = necessary=20 changes to the draft. The WG last
call ends = February=20 25th.

The end result is that the WG will get to decide = which=20 document is to
be used as the *starting = point*.=20

Thanks for your patience,

PatC & jak

-----BEGIN PGP SIGNATURE-----
Version:=20 PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPFrawTN1fXKoxmisEQIaWQCfYIis0Nsd52Q0Xv7wA77/RWn4J9IAn0t2= =20
FoREK4Kavht9sSs7VjZIhLlV
=3DEmAk=20
-----END PGP SIGNATURE-----=20

------_=_NextPart_001_01C1AD3A.2A711358-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 6 06:54:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17763 for ; Wed, 6 Feb 2002 06:54:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25738; Wed, 6 Feb 2002 06:42:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25710 for ; Wed, 6 Feb 2002 06:41:58 -0500 (EST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17457 for ; Wed, 6 Feb 2002 06:41:55 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id EAA10515 for ; Wed, 6 Feb 2002 04:41:55 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id EAA05079 for ; Wed, 6 Feb 2002 04:41:55 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Wed, 6 Feb 2002 04:41:53 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id B9A572EC83; Wed, 6 Feb 2002 12:37:11 +0100 (CET) To: monet@nal.motlabs.com Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, seamoby@ietf.org From: Alexandru Petrescu Date: 06 Feb 2002 12:41:51 +0100 Message-Id: Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Seamoby] Announce: monet list moved, archives available over http Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org [Please excuse cross-posting and multiple copies] Hi, This is to announce that the monet list has been moved to monet@nal.motlabs.com. Archives of discussions starting now as well as archives of discussions Dec 2001-Jan 2002 are available at: http://www.nal.motlabs.com/mailman/listinfo/monet All subscribers to the old monet list have been de-subscribed from it and re-subscribed to the new location. The subject line changed from Monet to monet, so your local filters might need update. Thanks, Alex PS: the change in hosting name was needed in order to deliver archives directly over the web. PPS: I still have delivery problems to three addresses, I will try to contact them personally. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 6 16:52:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03599 for ; Wed, 6 Feb 2002 16:52:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28434; Wed, 6 Feb 2002 16:39:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28406 for ; Wed, 6 Feb 2002 16:39:27 -0500 (EST) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03174 for ; Wed, 6 Feb 2002 16:39:22 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA29606; Wed, 6 Feb 2002 15:38:55 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g16LcsG28774; Wed, 6 Feb 2002 15:38:55 -0600 (CST) Message-ID: <3C61A260.8060404@alcatel.com> Date: Wed, 06 Feb 2002 15:38:40 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Pat R. Calhoun" CC: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: Content-Type: multipart/alternative; boundary="------------080303090600010908040200" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------080303090600010908040200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So we are calling a WG last call on the assessment document > (draft-ietf-seamoby-paging-protocol-assessment-01.txt). We encourage > folks to provide their *technical* comments on the draft should they > believe that the findings of the assessment team are incorrect. We do > ask the WG members to kindly refrain from posting any process related > comments, since it detracts us from achieving our milestones. Once > the WG last call is complete, we will collect the comments that have > WG concensus and make any necessary changes to the draft. The WG last > call ends February 25th. > > The end result is that the WG will get to decide which document is to > be used as the *starting point*. > > Thanks for your patience, > > PatC & jak > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > > > iQA/AwUBPFrawTN1fXKoxmisEQIaWQCfYIis0Nsd52Q0Xv7wA77/RWn4J9IAn0t2 > FoREK4Kavht9sSs7VjZIhLlV > =EmAk > -----END PGP SIGNATURE----- > Dear all, Based on the technical evaluation of all the drafts I posted in a previous mail on this thread, I propose draft-guri as the starting point. This draft uses all the entities of the requirements architecture and it does not make any assumptions on the mobility protocol mapping. This means the text from other drafts (security from draft-ohba, time-slot based paging from draft-sarikaya, mipv6 mappings from draft-renker and draft-koodli) can be easily incorporated. Along with its own goodies of the triggers, draft-guri would make a perfect starting point. My 2 euro cents. -- Behcet --------------080303090600010908040200 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Pat R. Calhoun wrote:
Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So we are calling a WG last call on the assessment document
(draft-ietf-seamoby-paging-protocol-assessment-01.txt). We encourage
folks to provide their *technical* comments on the draft should they
believe that the findings of the assessment team are incorrect. We do
ask the WG members to kindly refrain from posting any process related
comments, since it detracts us from achieving our milestones. Once
the WG last call is complete, we will collect the comments that have
WG concensus and make any necessary changes to the draft. The WG last
call ends February 25th.

The end result is that the WG will get to decide which document is to
be used as the *starting point*.

Thanks for your patience,

PatC & jak

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com >

iQA/AwUBPFrawTN1fXKoxmisEQIaWQCfYIis0Nsd52Q0Xv7wA77/RWn4J9IAn0t2
FoREK4Kavht9sSs7VjZIhLlV
=EmAk
-----END PGP SIGNATURE-----

Dear all,
  Based on the technical evaluation of all the drafts I posted in a previous mail on this thread, I propose draft-guri as the starting point. This draft uses all the entities of the requirements architecture and it does not make any assumptions on the mobility protocol mapping. This means the text from other drafts (security from draft-ohba, time-slot based paging from draft-sarikaya, mipv6 mappings from draft-renker and draft-koodli) can be easily incorporated. Along with its own goodies of the triggers, draft-guri would make a perfect starting point.
  My 2 euro cents.

-- 
Behcet

--------------080303090600010908040200-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 6 20:49:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06768 for ; Wed, 6 Feb 2002 20:49:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08815; Wed, 6 Feb 2002 20:34:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08783 for ; Wed, 6 Feb 2002 20:34:24 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06437 for ; Wed, 6 Feb 2002 20:34:21 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1B7WAY0J>; Wed, 6 Feb 2002 17:33:53 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Behcet Sarikaya'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Moving forward with paging Date: Wed, 6 Feb 2002 17:33:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AF77.7FCC29A0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1AF77.7FCC29A0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the feedback. However, what would be much more useful is to provide comments on the assessment draft. If you believe that the technical assessment of a particular draft is incorrect, please make that statement. Perhaps the new text could justify the selection of another draft as the starting point. PatC - -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Wednesday, February 06, 2002 1:39 PM To: Pat R. Calhoun Cc: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging Pat R. Calhoun wrote: - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So we are calling a WG last call on the assessment document (draft-ietf-seamoby-paging-protocol-assessment-01.txt). We encourage folks to provide their *technical* comments on the draft should they believe that the findings of the assessment team are incorrect. We do ask the WG members to kindly refrain from posting any process related comments, since it detracts us from achieving our milestones. Once the WG last call is complete, we will collect the comments that have WG concensus and make any necessary changes to the draft. The WG last call ends February 25th. The end result is that the WG will get to decide which document is to be used as the *starting point*. Thanks for your patience, PatC & jak - -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > iQA/AwUBPFrawTN1fXKoxmisEQIaWQCfYIis0Nsd52Q0Xv7wA77/RWn4J9IAn0t2 FoREK4Kavht9sSs7VjZIhLlV =EmAk - -----END PGP SIGNATURE----- Dear all, Based on the technical evaluation of all the drafts I posted in a previous mail on this thread, I propose draft-guri as the starting point. This draft uses all the entities of the requirements architecture and it does not make any assumptions on the mobility protocol mapping. This means the text from other drafts (security from draft-ohba, time-slot based paging from draft-sarikaya, mipv6 mappings from draft-renker and draft-koodli) can be easily incorporated. Along with its own goodies of the triggers, draft-guri would make a perfect starting point. My 2 euro cents. - -- Behcet -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGHZgDN1fXKoxmisEQLkKgCfZB8kYt74/HUqk42ExHmd7M60bewAn2EU o0zDuVm62RQH1kSVFekwbJAI =d6em -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1AF77.7FCC29A0 Content-Type: text/html RE: [Seamoby] Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the feedback. However, what would be much more useful is
to provide comments on the assessment draft. If you believe that the
technical assessment of a particular draft is incorrect, please make
that statement. Perhaps the new text could justify the selection of
another draft as the starting point.
 
PatC

- -----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Wednesday, February 06, 2002 1:39 PM
To: Pat R. Calhoun
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Moving forward with paging




Pat R. Calhoun wrote:



- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



So we are calling a WG last call on the assessment document
(draft-ietf-seamoby-paging-protocol-assessment-01.txt). We encourage
folks to provide their *technical* comments on the draft should they
believe that the findings of the assessment team are incorrect. We do
ask the WG members to kindly refrain from posting any process related
comments, since it detracts us from achieving our milestones. Once
the WG last call is complete, we will collect the comments that have
WG concensus and make any necessary changes to the draft. The WG last
call ends February 25th.

The end result is that the WG will get to decide which document is to
be used as the *starting point*.

Thanks for your patience,

PatC & jak

- -----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <
http://www.pgp.com >

iQA/AwUBPFrawTN1fXKoxmisEQIaWQCfYIis0Nsd52Q0Xv7wA77/RWn4J9IAn0t2
FoREK4Kavht9sSs7VjZIhLlV
=EmAk
- -----END PGP SIGNATURE-----

Dear all,
  Based on the technical evaluation of all the drafts I posted in a
previous mail on this thread, I propose draft-guri as the starting
point. This draft uses all the entities of the requirements
architecture and it does not make any assumptions on the mobility
protocol mapping. This means the text from other drafts (security
from draft-ohba, time-slot based paging from draft-sarikaya, mipv6
mappings from draft-renker and draft-koodli) can be easily
incorporated. Along with its own goodies of the triggers, draft-guri
would make a perfect starting point.
  My 2 euro cents.


- --
Behcet



-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPGHZgDN1fXKoxmisEQLkKgCfZB8kYt74/HUqk42ExHmd7M60bewAn2EU
o0zDuVm62RQH1kSVFekwbJAI
=d6em
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1AF77.7FCC29A0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 7 06:14:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24742 for ; Thu, 7 Feb 2002 06:14:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14564; Thu, 7 Feb 2002 06:01:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14534 for ; Thu, 7 Feb 2002 06:01:35 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24609 for ; Thu, 7 Feb 2002 06:01:32 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g17B1rj08025; Thu, 7 Feb 2002 12:01:53 +0100 (CET) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA15192; Thu, 7 Feb 2002 12:01:04 +0100 Message-ID: <3C625E70.56925EC5@ccrle.nec.de> Date: Thu, 07 Feb 2002 12:01:04 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Pat R. Calhoun" CC: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Pat and all, proposing a protocol as starting point, I think the decision process described in the assessment-01.txt addresses the right things and the independence and flexibility of the draft-renker concept has been understood. Therefore, I support the opinion of many others to keep draft-renker as a starting point. With respect to technical feedback on the assessment draft, I would like to refer to my mail from Dec., 4th, 2001, where I covered feedback on most of the issues addressed for draft-renker-paging-ipv6-01.txt. If desired, I can send the mail again to the list. In addition I would like to add some comments now: wrt requirement 4.6: As the assessment-01.txt indicates, multiple dormant modes should address MTs, that have no explicit L2 paging support. The architecture and protocol in draft-renker allows to keep access technologies specifics transparent to the IP paging protocol up to Access Routers, but allows mapping to any specifics at the Access Routers. This can be a mapping to L2 wake-up/paging mechanisms, but might be a mapping to link-local L3 paging (for example a solicited node multicast). This concept allows easy integration of time-slotted paging from ARs in order to improve efficiency of dormancy. wrt requirement 4.19: I don't think that this issue has been addressed correctly, since we decribe how to authenticate paging related signaling by IPSec AH, like other proposals do. Some security issues are addressed in the Security Consideration section, but not describing threads addressed in RFC 3154 already. We described how our concept integrates into an IPSec framework, but does not discuss establishment of SAs (as none of the other drafts does). The deployment of the AAA framework as key distribution center is described roughly. In general, as addressed on the list already, the security issue is obviously one of the issues requiring a lot more study and discussion. wrt 4.20: Same as 4.19, the assessment criticizes that the protocol relies on BUs, which is not correct. It's only the case for MIPv6 optimization, as described. For the generic (explicit signaling) case, which is the one to be considered within the Seamoby WG protocol specification, IPSec AH is deployed for signaling message authentication. The advantage of an IPSec approach is also to support authentication of signaling messages independent of UDP or IPv6 Destination Option transport. wrt 4.21: true, but advertising PA info from the attendant function located on each Acces Router allows to authenticate and to keep this info broadcast away from RtAdv specifics. Regards, Marco "Pat R. Calhoun" wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks for the feedback. However, what would be much more useful is > to provide comments on the assessment draft. If you believe that the > technical assessment of a particular draft is incorrect, please make > that statement. Perhaps the new text could justify the selection of > another draft as the starting point. > > PatC > > - -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] > Sent: Wednesday, February 06, 2002 1:39 PM > To: Pat R. Calhoun > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] Moving forward with paging > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 7 16:20:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10177 for ; Thu, 7 Feb 2002 16:20:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16699; Thu, 7 Feb 2002 15:56:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16672 for ; Thu, 7 Feb 2002 15:56:41 -0500 (EST) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09622 for ; Thu, 7 Feb 2002 15:56:39 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA24043 for ; Thu, 7 Feb 2002 14:56:12 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g17KuBg02051 for ; Thu, 7 Feb 2002 14:56:11 -0600 (CST) Message-ID: <3C62E9D9.4080109@alcatel.com> Date: Thu, 07 Feb 2002 14:55:53 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: Content-Type: multipart/alternative; boundary="------------030909010704040606040000" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------030909010704040606040000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear All, My comments follow. If these changes are incorporated, I am OK with this draft going for the last call. Comments on the assessment draft: On page 2: Of these, [6] and [7] were from the same team and were treated as one contribution for purposes of assessment. Action: Drop this sentence, since 6 and 7 define different protocols and they were evaluated separately in 3.3 and 3.4. Page 4 draft-renker-paging-ipv6-01.txt Unacceptable Requirements Match: 4.4, 4.6, 4.19, 4.20, 4.21 Action: add 4.7 to the list. Page 5 Requirement 4.7: Independence of Mobility Protocol The independence of mobility protocol is valid for "explicit" case only. The design specifies two separate protocols, one for Mobile IP and one without Mobile IP. Even implicit mode requires HA, i.e. Mobile IP, see the figure on page 22 of draft-renker-paging-ipv6-01.txt. Action: replace the text above with this: The design basically specifies one protocol for Mobile IP home agent based paging. Page 13 Draft-sarikaya was ruled out because it is based on a protocol that is currently under evaluation in another working group, setting up an unacceptable dependency between the Seamoby paging protocol design and the other working group's process. Action: add the following to this. Moreover draft-sarikaya is not the only draft that has some dependency on HMIPv6. Draft-koodli also has included the mapping of their protocol to HMIPv6. Page 13 While the assessment of draft-guri was positive, draft-guri is explicitly concerned with utilizing Layer 2 support for paging, and was therefore not sufficiently broad enough as a base for IP paging. Action: Replace by: The assessment of draft-guri was positive. Page 13 and 14. Last 4 paragraphs starting with: Of these, both draft-renker and draft-ohba provided adequate support for the first two, independence of mobility protocol and support for existing mobility protocols. Until 5.0 Acknowledgements Action: Drop completely. The reasons are the following: 1. Some comments on the "advantages:" of draft-renker may be taken to mean that: IETF is soliciting the draft authors to have a long reference list of the published literature including conference/journal papers, otherwise you will be judged out not knowing the field The fact is that the text and the related references of draft-renker fail to identify clearly which is Layer 2 related (there is a very rich literature on the paging in cellular networks which is called Layer 2 paging) and which is Layer 3 related and some key references on Layer 3 paging are missing. Action. Add the following text. As the response to the survey sent out to the mailing list indicated, nobody is doing product in this area in the near future, so we have some time to get this right. The Working Group wants a design that will last, like Internet routing has, and fit properly into the Internet architecture, since paging will be a key component of the future all-IP wireless networks. This is naturally going to require some time. Page 15 The acknowledgements. This is the first time I see the authors acknowledging themselves. It is unheard of. Action. Drop section 5.0. Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks for the feedback. However, what would be much more useful is > to provide comments on the assessment draft. If you believe that the > technical assessment of a particular draft is incorrect, please make > that statement. Perhaps the new text could justify the selection of > another draft as the starting point. > > PatC > Regards, -- Behcet --------------030909010704040606040000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear All,
  My comments follow. If these changes are incorporated, I am OK with this draft going for the last call.
Comments on the assessment draft:
On page 2:
Of these, [6]
   and [7] were from the same team and were treated as one contribution
   for purposes of assessment.
Action: Drop this sentence, since 6 and 7 define different protocols and they were evaluated separately in 3.3 and 3.4.
Page 4
draft-renker-paging-ipv6-01.txt
       Unacceptable Requirements Match:
        4.4, 4.6, 4.19, 4.20, 4.21
Action: add 4.7 to the list.
Page 5
Requirement 4.7: Independence of Mobility Protocol
   
   The independence of mobility protocol is valid for "explicit" case
   only. The design specifies two separate protocols, one for Mobile IP
   and one without Mobile IP. 
Even implicit mode requires HA, i.e. Mobile IP, see the figure on page 22 of draft-renker-paging-ipv6-01.txt.
Action: replace the text above with this: The design basically specifies one protocol for Mobile IP home agent based paging. 

Page 13
Draft-sarikaya was ruled out
   because it is based on a protocol that is currently under evaluation
   in another working group, setting up an unacceptable dependency
   between the Seamoby paging protocol design and the other working
   group's process.
Action: add the following to this. Moreover draft-sarikaya is not the only draft that has some dependency on HMIPv6. Draft-koodli also has included the mapping of their protocol to HMIPv6.

Page 13
While the assessment
   of draft-guri was positive, draft-guri is explicitly concerned with
   utilizing Layer 2 support for paging, and was therefore not
   sufficiently broad enough as a base for IP paging.
Action: Replace by: The assessment of draft-guri was positive.

Page 13 and 14.
Last 4 paragraphs starting with:
Of these, both draft-renker and draft-ohba provided adequate support
   for the first two, independence of mobility protocol and support for
   existing mobility protocols.
Until 5.0 Acknowledgements
Action: Drop completely.
The reasons are the following:
1.    Some comments on the “advantages:” of draft-renker may be taken to mean that: IETF is soliciting the draft authors to have a long reference list of the published literature including conference/journal  papers, otherwise you will be judged out not knowing the field
The fact is that the text and the related references of draft-renker fail to identify clearly which is Layer 2 related (there is a very rich literature on the paging in cellular networks which is called Layer 2 paging) and which is Layer 3 related and some key references on Layer 3 paging are missing.

Action. Add the following text.
As the response to the survey  sent out to the mailing list indicated, nobody is doing product in this area in the near future, so we have some time to get this right.

The Working Group wants a design that will last, like Internet routing
has, and fit properly into the Internet architecture,
since paging will be a key component of the future
all-IP wireless networks.  This is naturally going to require
some time.

Page 15
The acknowledgements.

This is the first time I see the authors acknowledging themselves. It is unheard of.
Action. Drop section 5.0.

Pat R. Calhoun wrote:
RE: [Seamoby] Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the feedback. However, what would be much more useful is
to provide comments on the assessment draft. If you believe that the
technical assessment of a particular draft is incorrect, please make
that statement. Perhaps the new text could justify the selection of
another draft as the starting point.
 
PatC

Regards,
-- 
Behcet

--------------030909010704040606040000-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 8 04:26:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01937 for ; Fri, 8 Feb 2002 04:26:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25407; Fri, 8 Feb 2002 04:14:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25378 for ; Fri, 8 Feb 2002 04:14:48 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01790 for ; Fri, 8 Feb 2002 04:14:45 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g189EHa53875; Fri, 8 Feb 2002 10:14:17 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA26808; Fri, 8 Feb 2002 10:14:16 +0100 Message-ID: <3C6396E8.7D674A11@ccrle.nec.de> Date: Fri, 08 Feb 2002 10:14:17 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Behcet Sarikaya CC: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C62E9D9.4080109@alcatel.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Behcet and all, finally, are there some mails with technical content appearing on the list? Great, this is what we need ;) Please, be referred to my comments to your comments below. Behcet Sarikaya wrote: > Dear All, > My comments follow. If these changes are incorporated, I am OK with > this draft going for the last call. > Comments on the assessment draft: > On page 2: > Of these, [6] > and [7] were from the same team and were treated as one > contribution > for purposes of assessment. > Action: Drop this sentence, since 6 and 7 define different protocols > and they were evaluated separately in 3.3 and 3.4. > Page 4 > draft-renker-paging-ipv6-01.txt > Unacceptable Requirements Match: > 4.4, 4.6, 4.19, 4.20, 4.21 Please, be referred to my previous mail, addressing these requirements (and please comment, if somebody does not agree) > > Action: add 4.7 to the list. > Page 5 > Requirement 4.7: Independence of Mobility Protocol > > The independence of mobility protocol is valid for "explicit" case > only. The design specifies two separate protocols, one for Mobile > IP > and one without Mobile IP. > Even implicit mode requires HA, i.e. Mobile IP, see the figure on page > 22 of draft-renker-paging-ipv6-01.txt. > Why 'even'?. 'Only' implicit mode assumes a HA, since 'implicit' mode addresses MIPv6 related optimization. 'Explicit' mode is what we consider in Seamoby, and ths mode is independent of a HA. You only have to ensure, that initial paging trigger packets are captured by a DMA FE in order to initiate a paging process. So what? 4.7 addresses overspecification, which is in this case provision of more than the generic 'explicit' case. Not considering the 'implicit' case, as proposed several times for a framework draft, this requirement is definitely a requirement match. > Action: replace the text above with this: The design basically > specifies one protocol for Mobile IP home agent based paging. > This is not true, please see my explanation above (and remember SLC discussion). Although my feedback in the previous mail addressed some issues probably not correctly interpreted by the assessment team, assessment of requirement 4.7 is correct. > > Page 13 > Draft-sarikaya was ruled out > because it is based on a protocol that is currently under > evaluation > in another working group, setting up an unacceptable dependency > between the Seamoby paging protocol design and the other working > group's process. > Action: add the following to this. Moreover draft-sarikaya is not the > only draft that has some dependency on HMIPv6. Draft-koodli also has > included the mapping of their protocol to HMIPv6. > I don' think that one can assume a protocol is 'dependent' on a specific mobility platform only if the proposal decribes how the paging architecture integrates into some available mobility management solution 'as an example'. Correct? > > Page 13 > While the assessment > of draft-guri was positive, draft-guri is explicitly concerned with > > utilizing Layer 2 support for paging, and was therefore not > sufficiently broad enough as a base for IP paging. > Action: Replace by: The assessment of draft-guri was positive. > > Page 13 and 14. > Last 4 paragraphs starting with: > Of these, both draft-renker and draft-ohba provided adequate support > for the first two, independence of mobility protocol and support > for > existing mobility protocols. > Until 5.0 Acknowledgements > Action: Drop completely. > I do not agree to drop this section, since for description of the selection process, it is reasonable to have it in. > The reasons are the following: > 1. Some comments on the “advantages:” of draft-renker may be taken > to mean that: IETF is soliciting the draft authors to have a long > reference list of the published literature including > conference/journal papers, otherwise you will be judged out not > knowing the field > The fact is that the text and the related references of draft-renker > fail to identify clearly which is Layer 2 related (there is a very > rich literature on the paging in cellular networks which is called > Layer 2 paging) and which is Layer 3 related and some key references > on Layer 3 paging are missing. > Since some sections in draft-renker refer to advanced paging strategies, related work has been referenced. You concern is not acceptable for me. > > Action. Add the following text. > As the response to the survey sent out to the mailing list indicated, > nobody is doing product in this area in the near future, so we have > some time to get this right. > Since some good work has been done already, why shifting further steps to later? The importance of having a solution has been recognized, otherwise there wouldn't be quite a lot of draft-submissions on this. Better to work relaxed in order to come up with a clever solution in the near future than working (possibly from scratch?) in the near future under pressure. Furthermore, if standardization process will start early, companies have the possibility to orientate their product development planning early. Regards, Marco > > The Working Group wants a design that will last, like Internet routing > > has, and fit properly into the Internet architecture, > since paging will be a key component of the future > all-IP wireless networks. This is naturally going to require > some time. > > Page 15 > The acknowledgements. > > This is the first time I see the authors acknowledging themselves. It > is unheard of. > Action. Drop section 5.0. > > Pat R. Calhoun wrote: > >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Thanks for the feedback. However, what would be much more useful is >> to provide comments on the assessment draft. If you believe that the >> >> technical assessment of a particular draft is incorrect, please make >> >> that statement. Perhaps the new text could justify the selection of >> another draft as the starting point. >> >> PatC >> >> > > Regards, > > -- > Behcet > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 8 11:27:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13690 for ; Fri, 8 Feb 2002 11:27:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16745; Fri, 8 Feb 2002 11:10:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16722 for ; Fri, 8 Feb 2002 11:10:50 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13015 for ; Fri, 8 Feb 2002 11:10:47 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7RWVZ>; Fri, 8 Feb 2002 08:10:13 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Behcet Sarikaya'" , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward with paging Date: Fri, 8 Feb 2002 08:10:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B0BB.164FB560" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B0BB.164FB560 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > My comments follow. If these changes are incorporated, I am OK > with this draft going > for the last call. Just for clarification - the IETF does not simply accept changes proposed by a single person. If we have rough concensus for each point, then they will be added to the document > Page 13 > Draft-sarikaya was ruled out > because it is based on a protocol that is currently under > evaluation > in another working group, setting up an unacceptable dependency > between the Seamoby paging protocol design and the other working > group's process. > Action: add the following to this. Moreover draft-sarikaya is not > the only draft that has some dependency on HMIPv6. Draft-koodli > also has included the mapping of their protocol to HMIPv6. Is text along these lines in the actual review of the sarikaya draft? It is needed in the review, as well as the summary > Page 13 > While the assessment > of draft-guri was positive, draft-guri is explicitly concerned > with > utilizing Layer 2 support for paging, and was therefore not > sufficiently broad enough as a base for IP paging. > Action: Replace by: The assessment of draft-guri was positive. So as a point of clarification - you are stating that the assessment of the protocol is incorrect? > Page 13 and 14. > Last 4 paragraphs starting with: > Of these, both draft-renker and draft-ohba provided adequate > support > for the first two, independence of mobility protocol and support > for > existing mobility protocols. > Until 5.0 Acknowledgements > Action: Drop completely. > The reasons are the following: > 1. Some comments on the "advantages:" of draft-renker may be > taken to mean that: IETF > is soliciting the draft authors to have > a long reference list of the published literature including > conference/journal papers, otherwise you will be judged out not > knowing the field Hmmm... This would clearly not be in the best interest of the IETF... But I can't quite see where this implication is made. Could you be more specific in terms of examples that led you to this conclusion? > The fact is that the text and the related references of > draft-renker fail to identify clearly which is Layer 2 related > (there is a very rich literature on the paging in cellular > networks which is called Layer 2 paging) and which is Layer 3 > related and some key references on Layer 3 paging are missing. Again, could you be more specific (examples) on how you came to this conclusion? > Action. Add the following text. > As the response to the survey sent out to the mailing list > indicated, nobody is doing product in this area in the near > future, so we have some time to get this right. An RFC should never contain time-sensitive information, so this cannot be added. The IETF is also not too keep on WGs that last forever... We need an end goal. > The Working Group wants a design that will last, like Internet > routing has, and fit properly into the Internet architecture, > since paging will be a key component of the future > all-IP wireless networks. This is naturally going to require > some time. As does any protocol design... No argument there... But define "some time". -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGP4YzN1fXKoxmisEQJlyACguXmACymrllGR6qZ7ZI67ASEyXAIAoP2L 3c2IWq0ne8sLDdGJe6G+FCvv =6oui -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B0BB.164FB560 Content-Type: text/html RE: [Seamoby] Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>  My comments follow. If these changes are incorporated, I am OK
> with this draft going 
>  for the last call.

Just for clarification - the IETF does not simply accept changes
proposed by a single person. If we have rough concensus for each
point, then they will be added to the document


> Page 13
> Draft-sarikaya was ruled out
>   because it is based on a protocol that is currently under
> evaluation 
>   in another working group, setting up an unacceptable dependency
>   between the Seamoby paging protocol design and the other working
>   group's process.
> Action: add the following to this. Moreover draft-sarikaya is not
> the only draft that  has some dependency on HMIPv6. Draft-koodli
> also has included the mapping of their  protocol to HMIPv6.

Is text along these lines in the actual review of the sarikaya draft?
It is needed in the review, as well as the summary

> Page 13
> While the assessment
>   of draft-guri was positive, draft-guri is explicitly concerned
> with 
>   utilizing Layer 2 support for paging, and was therefore not
>   sufficiently broad enough as a base for IP paging.
> Action: Replace by: The assessment of draft-guri was positive.

So as a point of clarification - you are stating that the assessment
of the protocol is incorrect?

> Page 13 and 14.
> Last 4 paragraphs starting with:
> Of these, both draft-renker and draft-ohba provided adequate
> support 
>   for the first two, independence of mobility protocol and support
> for 
>   existing mobility protocols.
> Until 5.0 Acknowledgements
> Action: Drop completely.
> The reasons are the following:
> 1.    Some comments on the "advantages:" of draft-renker may be
> taken to mean that: IETF > is soliciting the draft authors to have
> a long reference list of the published  literature including
> conference/journal  papers, otherwise you will be judged out not
> knowing the field

Hmmm... This would clearly not be in the best interest of the IETF...
But I can't quite see where this implication is made. Could you be
more specific in terms of examples that led you to this conclusion?

> The fact is that the text and the related references of
> draft-renker fail to identify  clearly which is Layer 2 related
> (there is a very rich literature on the paging in  cellular
> networks which is called Layer 2 paging) and which is Layer 3
> related and some  key references on Layer 3 paging are missing.

Again, could you be more specific (examples) on how you came to this
conclusion?

> Action. Add the following text.
> As the response to the survey  sent out to the mailing list
> indicated, nobody is doing  product in this area in the near
> future, so we have some time to get this right.  

An RFC should never contain time-sensitive information, so this
cannot be added. The IETF is also not too keep on WGs that last
forever... We need an end goal.

> The Working Group wants a design that will last, like Internet
> routing has, and fit properly into the Internet architecture,
> since paging will be a key component of the future
> all-IP wireless networks.  This is naturally going to require
> some time.

As does any protocol design... No argument there... But define "some
time".


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPGP4YzN1fXKoxmisEQJlyACguXmACymrllGR6qZ7ZI67ASEyXAIAoP2L
3c2IWq0ne8sLDdGJe6G+FCvv
=6oui
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B0BB.164FB560-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 8 11:38:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14096 for ; Fri, 8 Feb 2002 11:38:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17552; Fri, 8 Feb 2002 11:24:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17491 for ; Fri, 8 Feb 2002 11:24:53 -0500 (EST) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13564 for ; Fri, 8 Feb 2002 11:24:50 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA24382 for ; Fri, 8 Feb 2002 10:24:22 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g18GOMg07168 for ; Fri, 8 Feb 2002 10:24:22 -0600 (CST) Message-ID: <3C63FB9F.6040507@alcatel.com> Date: Fri, 08 Feb 2002 10:23:59 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C62E9D9.4080109@alcatel.com> <3C6396E8.7D674A11@ccrle.nec.de> Content-Type: multipart/alternative; boundary="------------050503040900040109050902" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------050503040900040109050902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Marco and all, Some remarks on Marco's email: 1. Issue of Requirement 4.7. You said draft-renker satisfied it and mentioned DMA FE. Sorry but I could not find DMA in draft-renker (using a simple search). Also none of the figures of draft-renker has this entity. Maybe you meant to add this, but then probably there is no need, because draft-guri already has it and does the packet capturing using DMA. So we seem to agree on this important architectural issue that it should be done at DMA. Also let's agree that draft-renker does not satisfy 4.7 :) 2. Regarding HMIPv6, I agree with you. The text I suggested added regarding draft-koodli may or may not be added, but I stand by all other suggested changes. What is important here is that the statements in the assessment draft on this are too strong, I think that Seamoby can not close its eyes to what is going on in Mobile IP WG. We all know that James is an active contributor to MIP WG, 3. Regarding the next steps, the text I suggested was taken from James' recent email. Yes we do have some drafts and it does represent some progress. Remember that the "front runner" draft-renker is based on home agent paging whose disadvantages are well known. Of course the knowledge developed so far and is being developed can be utilized in the next steps whatever they they will be. One possible avenue is to reconsider the requirements such as security items and even 4.7. The assessment draft can be advanced with the modifications if there is desire to have yet another RFC on IP paging or DHMA protocol. Remember that in IETF WGs there are many stale WG documents. So I suggest that we continue to discuss on the mailing list and have a session at Minneapolis on IP Paging solutions. Regards, Marco Liebsch wrote: >Behcet and all, > >finally, are there some mails with technical content appearing on the >list? Great, this is what we need ;) >Please, be referred to my comments to your comments below. > >Behcet Sarikaya wrote: > >>Dear All, >> My comments follow. If these changes are incorporated, I am OK with >>this draft going for the last call. >>Comments on the assessment draft: >>On page 2: >>Of these, [6] >> and [7] were from the same team and were treated as one >>contribution >> for purposes of assessment. >>Action: Drop this sentence, since 6 and 7 define different protocols >>and they were evaluated separately in 3.3 and 3.4. >>Page 4 >>draft-renker-paging-ipv6-01.txt >> Unacceptable Requirements Match: >> 4.4, 4.6, 4.19, 4.20, 4.21 >> > >Please, be referred to my previous mail, addressing these requirements >(and please comment, if somebody does not agree) > >>Action: add 4.7 to the list. >>Page 5 >>Requirement 4.7: Independence of Mobility Protocol >> >> The independence of mobility protocol is valid for "explicit" case >> only. The design specifies two separate protocols, one for Mobile >>IP >> and one without Mobile IP. >>Even implicit mode requires HA, i.e. Mobile IP, see the figure on page >>22 of draft-renker-paging-ipv6-01.txt. >> > >Why 'even'?. 'Only' implicit mode assumes a HA, since 'implicit' mode >addresses MIPv6 related optimization. 'Explicit' mode is what we >consider in Seamoby, and ths mode is independent of a HA. You only have >to ensure, that initial paging trigger packets are captured by a DMA FE >in order to initiate a paging process. So what? 4.7 addresses >overspecification, which is in this case provision of more than the >generic 'explicit' case. Not considering the 'implicit' case, as >proposed several times for a framework draft, this requirement is >definitely a requirement match. > >>Action: replace the text above with this: The design basically >>specifies one protocol for Mobile IP home agent based paging. >> > >This is not true, please see my explanation above (and remember SLC >discussion). Although my feedback in the previous mail addressed some >issues probably not correctly interpreted by the assessment team, >assessment of requirement 4.7 is correct. > >>Page 13 >>Draft-sarikaya was ruled out >> because it is based on a protocol that is currently under >>evaluation >> in another working group, setting up an unacceptable dependency >> between the Seamoby paging protocol design and the other working >> group's process. >>Action: add the following to this. Moreover draft-sarikaya is not the >>only draft that has some dependency on HMIPv6. Draft-koodli also has >>included the mapping of their protocol to HMIPv6. >> > >I don' think that one can assume a protocol is 'dependent' on a specific >mobility platform only if the proposal decribes how the paging >architecture integrates into some available mobility management solution >'as an example'. Correct? > >>Page 13 >>While the assessment >> of draft-guri was positive, draft-guri is explicitly concerned with >> >> utilizing Layer 2 support for paging, and was therefore not >> sufficiently broad enough as a base for IP paging. >>Action: Replace by: The assessment of draft-guri was positive. >> >>Page 13 and 14. >>Last 4 paragraphs starting with: >>Of these, both draft-renker and draft-ohba provided adequate support >> for the first two, independence of mobility protocol and support >>for >> existing mobility protocols. >>Until 5.0 Acknowledgements >>Action: Drop completely. >> > >I do not agree to drop this section, since for description of the >selection process, it is reasonable to have it in. > >>The reasons are the following: >>1. Some comments on the "advantages:" of draft-renker may be taken >>to mean that: IETF is soliciting the draft authors to have a long >>reference list of the published literature including >>conference/journal papers, otherwise you will be judged out not >>knowing the field >>The fact is that the text and the related references of draft-renker >>fail to identify clearly which is Layer 2 related (there is a very >>rich literature on the paging in cellular networks which is called >>Layer 2 paging) and which is Layer 3 related and some key references >>on Layer 3 paging are missing. >> > >Since some sections in draft-renker refer to advanced paging strategies, >related work has been referenced. You concern is not acceptable for me. > >>Action. Add the following text. >>As the response to the survey sent out to the mailing list indicated, >>nobody is doing product in this area in the near future, so we have >>some time to get this right. >> > >Since some good work has been done already, why shifting further steps >to later? The importance of having a solution has been recognized, >otherwise there wouldn't be quite a lot of draft-submissions on this. >Better to work relaxed in order to come up with a clever solution in the >near future than working (possibly from scratch?) in the near future >under pressure. Furthermore, if standardization process will start >early, companies have the possibility to orientate their product >development planning early. > > >Regards, > >Marco > > >>The Working Group wants a design that will last, like Internet routing >> >>has, and fit properly into the Internet architecture, >>since paging will be a key component of the future >>all-IP wireless networks. This is naturally going to require >>some time. >> >>Page 15 >>The acknowledgements. >> >>This is the first time I see the authors acknowledging themselves. It >>is unheard of. >>Action. Drop section 5.0. >> >>Pat R. Calhoun wrote: >> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>>Thanks for the feedback. However, what would be much more useful is >>>to provide comments on the assessment draft. If you believe that the >>> >>>technical assessment of a particular draft is incorrect, please make >>> >>>that statement. Perhaps the new text could justify the selection of >>>another draft as the starting point. >>> >>>PatC >>> >>> >>Regards, >> >>-- >>Behcet >> >> > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > -- Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S 026 1000 Coit Road PB7 Plano, TX 75075 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 477 2794 Fax: (972) 519 2460 --------------050503040900040109050902 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Marco and all,
  Some remarks on Marco's email:
1. Issue of Requirement 4.7. You said draft-renker satisfied it and mentioned DMA FE. Sorry but I could not find DMA in draft-renker (using a simple search). Also none of the figures of draft-renker has this entity. Maybe you meant to add this, but then probably there is no need, because draft-guri already has it and does the packet capturing using DMA. So we seem to agree on this important architectural issue that it should be done at DMA. Also let's agree that draft-renker does not satisfy 4.7 :)
2. Regarding HMIPv6, I agree with you. The text I suggested added regarding draft-koodli may or may not be added, but I stand by all other suggested changes. What is important here is that the statements in the assessment draft on this are too strong, I think that Seamoby can not close its eyes to what is going on in Mobile IP WG. We all know that James is an active contributor to MIP WG,
3. Regarding the next steps, the text I suggested was taken from James' recent email. Yes we do have some drafts and it does represent some progress. Remember that the "front runner" draft-renker is based on home agent paging whose disadvantages are well known. Of course the knowledge developed so far and is being developed can be utilized in the next steps whatever they they will be.

One possible avenue is to reconsider the requirements such as security items and even 4.7. The assessment draft can be advanced with the modifications if there is desire to have yet another RFC on IP paging or DHMA protocol. Remember that in IETF WGs there are many stale WG documents.
So I suggest that we continue to discuss on the mailing list and have a session at Minneapolis on
IP Paging solutions.

Regards,

Marco Liebsch wrote:
Behcet and all,

finally, are there some mails with technical content appearing on the
list? Great, this is what we need ;)
Please, be referred to my comments to your comments below.

Behcet Sarikaya wrote:

Dear All,
  My comments follow. If these changes are incorporated, I am OK with
this draft going for the last call.
Comments on the assessment draft:
On page 2:
Of these, [6]
   and [7] were from the same team and were treated as one
contribution
   for purposes of assessment.
Action: Drop this sentence, since 6 and 7 define different protocols
and they were evaluated separately in 3.3 and 3.4.
Page 4
draft-renker-paging-ipv6-01.txt
       Unacceptable Requirements Match:
        4.4, 4.6, 4.19, 4.20, 4.21

Please, be referred to my previous mail, addressing these requirements
(and please comment, if somebody does not agree)

Action: add 4.7 to the list.
Page 5
Requirement 4.7: Independence of Mobility Protocol

   The independence of mobility protocol is valid for "explicit" case
   only. The design specifies two separate protocols, one for Mobile
IP
   and one without Mobile IP.
Even implicit mode requires HA, i.e. Mobile IP, see the figure on page
22 of draft-renker-paging-ipv6-01.txt.


Why 'even'?. 'Only' implicit mode assumes a HA, since 'implicit' mode
addresses MIPv6 related optimization. 'Explicit' mode is what we
consider in Seamoby, and ths mode is independent of a HA. You only have
to ensure, that initial paging trigger packets are captured by a DMA FE
in order to initiate a paging process. So what? 4.7 addresses
overspecification, which is in this case provision of more than the
generic 'explicit' case. Not considering the 'implicit' case, as
proposed several times for a framework draft, this requirement is
definitely a requirement match.

Action: replace the text above with this: The design basically
specifies one protocol for Mobile IP home agent based paging.


This is not true, please see my explanation above (and remember SLC
discussion). Although my feedback in the previous mail addressed some
issues probably not correctly interpreted by the assessment team,
assessment of requirement 4.7 is correct.

Page 13
Draft-sarikaya was ruled out
   because it is based on a protocol that is currently under
evaluation
   in another working group, setting up an unacceptable dependency
   between the Seamoby paging protocol design and the other working
   group's process.
Action: add the following to this. Moreover draft-sarikaya is not the
only draft that has some dependency on HMIPv6. Draft-koodli also has
included the mapping of their protocol to HMIPv6.


I don' think that one can assume a protocol is 'dependent' on a specific
mobility platform only if the proposal decribes how the paging
architecture integrates into some available mobility management solution
'as an example'. Correct?

Page 13
While the assessment
   of draft-guri was positive, draft-guri is explicitly concerned with

   utilizing Layer 2 support for paging, and was therefore not
   sufficiently broad enough as a base for IP paging.
Action: Replace by: The assessment of draft-guri was positive.

Page 13 and 14.
Last 4 paragraphs starting with:
Of these, both draft-renker and draft-ohba provided adequate support
   for the first two, independence of mobility protocol and support
for
   existing mobility protocols.
Until 5.0 Acknowledgements
Action: Drop completely.


I do not agree to drop this section, since for description of the
selection process, it is reasonable to have it in.

The reasons are the following:
1.    Some comments on the “advantages:” of draft-renker may be taken
to mean that: IETF is soliciting the draft authors to have a long
reference list of the published literature including
conference/journal  papers, otherwise you will be judged out not
knowing the field
The fact is that the text and the related references of draft-renker
fail to identify clearly which is Layer 2 related (there is a very
rich literature on the paging in cellular networks which is called
Layer 2 paging) and which is Layer 3 related and some key references
on Layer 3 paging are missing.


Since some sections in draft-renker refer to advanced paging strategies,
related work has been referenced. You concern is not acceptable for me.

Action. Add the following text.
As the response to the survey  sent out to the mailing list indicated,
nobody is doing product in this area in the near future, so we have
some time to get this right.


Since some good work has been done already, why shifting further steps
to later? The importance of having a solution has been recognized,
otherwise there wouldn't be quite a lot of draft-submissions on this.
Better to work relaxed in order to come up with a clever solution in the
near future than working (possibly from scratch?) in the near future
under pressure. Furthermore, if standardization process will start
early, companies have the possibility to orientate their product
development planning early.


Regards,

Marco


The Working Group wants a design that will last, like Internet routing

has, and fit properly into the Internet architecture,
since paging will be a key component of the future
all-IP wireless networks.  This is naturally going to require
some time.

Page 15
The acknowledgements.

This is the first time I see the authors acknowledging themselves. It
is unheard of.
Action. Drop section 5.0.

Pat R. Calhoun wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the feedback. However, what would be much more useful is
to provide comments on the assessment draft. If you believe that the

technical assessment of a particular draft is incorrect, please make

that statement. Perhaps the new text could justify the selection of
another draft as the starting point.

PatC


Regards,

--
Behcet






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

-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460

--------------050503040900040109050902-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 8 11:58:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14672 for ; Fri, 8 Feb 2002 11:58:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20228; Fri, 8 Feb 2002 11:46:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20197 for ; Fri, 8 Feb 2002 11:46:32 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14411 for ; Fri, 8 Feb 2002 11:46:29 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7RWWQ>; Fri, 8 Feb 2002 08:46:02 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Behcet Sarikaya'" , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward with paging Date: Fri, 8 Feb 2002 08:46:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B0C0.177138B0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B0C0.177138B0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 3. Regarding the next steps, the text I suggested was taken from > James' recent email. Yes we do have some drafts and it does > represent some progress. Remember that the "front runner" > draft-renker is based on home agent paging whose disadvantages are > well known. For those of us that are not aware of these "disadvantages" that you are refering to, perhaps you could provide additional information? Remember, rough concensus is easier to achieve if enough justification is provided. PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGQAyTN1fXKoxmisEQI1wQCgyrru7DfH/AHZs43GrFZM9hqmrusAnA+6 Fri8z8M0JodiaKgjcaF7t+kR =3KaT -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B0C0.177138B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 3. Regarding the next steps, the text I = suggested was taken from
> James' recent email.  Yes we do have some = drafts and it does
> represent some progress. Remember that the = "front  runner"
> draft-renker is based on home agent paging = whose disadvantages are
> well known.  

For those of us that are not aware of these = "disadvantages" that you
are refering to, perhaps you could provide = additional information?

Remember, rough concensus is easier to achieve if = enough
justification is provided.

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPGQAyTN1fXKoxmisEQI1wQCgyrru7DfH/AHZs43GrFZM9hqmrusAnA+= 6
Fri8z8M0JodiaKgjcaF7t+kR
=3D3KaT
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B0C0.177138B0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 8 12:24:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15932 for ; Fri, 8 Feb 2002 12:24:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22998; Fri, 8 Feb 2002 12:12:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22970 for ; Fri, 8 Feb 2002 12:12:35 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15276 for ; Fri, 8 Feb 2002 12:12:31 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g18HC4a74946; Fri, 8 Feb 2002 18:12:05 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA32763; Fri, 8 Feb 2002 18:12:04 +0100 Message-ID: <3C6406E3.DD236E32@ccrle.nec.de> Date: Fri, 08 Feb 2002 18:12:03 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Behcet Sarikaya CC: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C62E9D9.4080109@alcatel.com> <3C6396E8.7D674A11@ccrle.nec.de> <3C63FB9F.6040507@alcatel.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Behcet, Behcet Sarikaya wrote: > Marco and all, > Some remarks on Marco's email: > 1. Issue of Requirement 4.7. You said draft-renker satisfied it and > mentioned DMA FE. Sorry but I could not find DMA in draft-renker > (using a simple search). Also none of the figures of draft-renker has > this entity. Please be referred to section C.1 of the draft. > Maybe you meant to add this, but then probably there is no need, > because draft-guri already has it and does the packet capturing using > DMA. So we seem to agree on this important architectural issue that it > should be done at DMA. Also let's agree that draft-renker does not > satisfy 4.7 :) Not agreed. Think of having a further section in draft-gury, describing how your architecture might be integrated in a Mobile IPv6 platform. Reading the 'entire' draft and understanding the architecture and protocol ;), nobody would assume that your architecture is MIP / HA dependent, or? > > 2. Regarding HMIPv6, I agree with you. The text I suggested added > regarding draft-koodli may or may not be added, but I stand by all > other suggested changes. What is important here is that the statements > in the assessment draft on this are too strong, I think that Seamoby > can not close its eyes to what is going on in Mobile IP WG. We all > know that James is an active contributor to MIP WG, > It cannot close its eyes, but the specific requirement intends to de-couple the IP paging solution from the mobility platform. > 3. Regarding the next steps, the text I suggested was taken from > James' recent email. Yes we do have some drafts and it does represent > some progress. Remember that the "front runner" draft-renker is based > on home agent paging whose disadvantages are well known. Of course the > knowledge developed so far and is being developed can be utilized in > the next steps whatever they they will be. > Same issue as above, its not dependent on a HA. Regards, marco > > One possible avenue is to reconsider the requirements such as security > items and even 4.7. The assessment draft can be advanced with the > modifications if there is desire to have yet another RFC on IP paging > or DHMA protocol. Remember that in IETF WGs there are many stale WG > documents. > So I suggest that we continue to discuss on the mailing list and have > a session at Minneapolis on > IP Paging solutions. > > Regards, > > Marco Liebsch wrote: > >> Behcet and all, >> >> finally, are there some mails with technical content appearing on >> the >> list? Great, this is what we need ;) >> Please, be referred to my comments to your comments below. >> >> Behcet Sarikaya wrote: >> >> >> > Dear All, >> > My comments follow. If these changes are incorporated, I am OK >> > with >> > this draft going for the last call. >> > Comments on the assessment draft: >> > On page 2: >> > Of these, [6] >> > and [7] were from the same team and were treated as one >> > contribution >> > for purposes of assessment. >> > Action: Drop this sentence, since 6 and 7 define different >> > protocols >> > and they were evaluated separately in 3.3 and 3.4. >> > Page 4 >> > draft-renker-paging-ipv6-01.txt >> > Unacceptable Requirements Match: >> > 4.4, 4.6, 4.19, 4.20, 4.21 >> > >> Please, be referred to my previous mail, addressing these >> requirements >> (and please comment, if somebody does not agree) >> >> >> > Action: add 4.7 to the list. >> > Page 5 >> > Requirement 4.7: Independence of Mobility Protocol >> > >> > The independence of mobility protocol is valid for "explicit" >> > case >> > only. The design specifies two separate protocols, one for >> > Mobile >> > IP >> > and one without Mobile IP. >> > Even implicit mode requires HA, i.e. Mobile IP, see the figure on >> > page >> > 22 of draft-renker-paging-ipv6-01.txt. >> > >> > >> Why 'even'?. 'Only' implicit mode assumes a HA, since 'implicit' >> mode >> addresses MIPv6 related optimization. 'Explicit' mode is what we >> consider in Seamoby, and ths mode is independent of a HA. You only >> have >> to ensure, that initial paging trigger packets are captured by a DMA >> FE >> in order to initiate a paging process. So what? 4.7 addresses >> overspecification, which is in this case provision of more than the >> generic 'explicit' case. Not considering the 'implicit' case, as >> proposed several times for a framework draft, this requirement is >> definitely a requirement match. >> >> >> > Action: replace the text above with this: The design basically >> > specifies one protocol for Mobile IP home agent based paging. >> > >> > >> This is not true, please see my explanation above (and remember SLC >> discussion). Although my feedback in the previous mail addressed >> some >> issues probably not correctly interpreted by the assessment team, >> assessment of requirement 4.7 is correct. >> >> >> > Page 13 >> > Draft-sarikaya was ruled out >> > because it is based on a protocol that is currently under >> > evaluation >> > in another working group, setting up an unacceptable dependency >> > between the Seamoby paging protocol design and the other working >> > group's process. >> > Action: add the following to this. Moreover draft-sarikaya is not >> > the >> > only draft that has some dependency on HMIPv6. Draft-koodli also >> > has >> > included the mapping of their protocol to HMIPv6. >> > >> > >> I don' think that one can assume a protocol is 'dependent' on a >> specific >> mobility platform only if the proposal decribes how the paging >> architecture integrates into some available mobility management >> solution >> 'as an example'. Correct? >> >> >> > Page 13 >> > While the assessment >> > of draft-guri was positive, draft-guri is explicitly concerned >> > with >> > >> > utilizing Layer 2 support for paging, and was therefore not >> > sufficiently broad enough as a base for IP paging. >> > Action: Replace by: The assessment of draft-guri was positive. >> > >> > Page 13 and 14. >> > Last 4 paragraphs starting with: >> > Of these, both draft-renker and draft-ohba provided adequate >> > support >> > for the first two, independence of mobility protocol and support >> > for >> > existing mobility protocols. >> > Until 5.0 Acknowledgements >> > Action: Drop completely. >> > >> > >> I do not agree to drop this section, since for description of the >> selection process, it is reasonable to have it in. >> >> >> > The reasons are the following: >> > 1. Some comments on the “advantages:” of draft-renker may be >> > taken >> > to mean that: IETF is soliciting the draft authors to have a long >> > reference list of the published literature including >> > conference/journal papers, otherwise you will be judged out not >> > knowing the field >> > The fact is that the text and the related references of >> > draft-renker >> > fail to identify clearly which is Layer 2 related (there is a very >> > rich literature on the paging in cellular networks which is called >> > Layer 2 paging) and which is Layer 3 related and some key >> > references >> > on Layer 3 paging are missing. >> > >> > >> Since some sections in draft-renker refer to advanced paging >> strategies, >> related work has been referenced. You concern is not acceptable for >> me. >> >> >> > Action. Add the following text. >> > As the response to the survey sent out to the mailing list >> > indicated, >> > nobody is doing product in this area in the near future, so we have >> > some time to get this right. >> > >> > >> Since some good work has been done already, why shifting further >> steps >> to later? The importance of having a solution has been recognized, >> otherwise there wouldn't be quite a lot of draft-submissions on >> this. >> Better to work relaxed in order to come up with a clever solution in >> the >> near future than working (possibly from scratch?) in the near future >> under pressure. Furthermore, if standardization process will start >> early, companies have the possibility to orientate their product >> development planning early. >> >> >> Regards, >> >> Marco >> >> >> >> > The Working Group wants a design that will last, like Internet >> > routing >> > >> > has, and fit properly into the Internet architecture, >> > since paging will be a key component of the future >> > all-IP wireless networks. This is naturally going to require >> > some time. >> > >> > Page 15 >> > The acknowledgements. >> > >> > This is the first time I see the authors acknowledging themselves. >> > It >> > is unheard of. >> > Action. Drop section 5.0. >> > >> > Pat R. Calhoun wrote: >> > >> > >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA1 >> >> >> >> Thanks for the feedback. However, what would be much more useful >> >> is >> >> to provide comments on the assessment draft. If you believe that >> >> the >> >> >> >> technical assessment of a particular draft is incorrect, please >> >> make >> >> >> >> that statement. Perhaps the new text could justify the selection >> >> of >> >> another draft as the starting point. >> >> >> >> PatC >> >> >> >> >> >> >> > Regards, >> > >> > -- >> > Behcet >> > >> > >> > >> >> >> >> _______________________________________________ >> Seamoby mailing list >> Seamoby@ietf.org >> https://www1.ietf.org/mailman/listinfo/seamoby >> > -- > Behcet Sarikaya > Network Strategy Group, Mobile Networking Team > Alcatel USA M/S 026 > 1000 Coit Road PB7 > Plano, TX 75075 USA > Email: behcet.sarikaya@alcatel.com > Phone: (972) 477 2794 Fax: (972) 519 2460 > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 8 13:20:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18381 for ; Fri, 8 Feb 2002 13:20:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26790; Fri, 8 Feb 2002 13:08:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26764 for ; Fri, 8 Feb 2002 13:08:58 -0500 (EST) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17873 for ; Fri, 8 Feb 2002 13:08:56 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id MAA14602 for ; Fri, 8 Feb 2002 12:08:27 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g18I8QG02526 for ; Fri, 8 Feb 2002 12:08:26 -0600 (CST) Message-ID: <3C641405.7010807@alcatel.com> Date: Fri, 08 Feb 2002 12:08:05 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: Content-Type: multipart/alternative; boundary="------------070009080800040503090905" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------070009080800040503090905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Pat, The problems with HA based paging are 1. it is inefficient because HA can be far away from the visited network, this would induce large latencies on registration messages as well as in the paging process with high paging load. 2. In cases like Simple IP service in CDMA2000 it can not be used due to the dependence on MIP. However if MIP is assumed and in small networks, HA based paging can still be useful with small paging loads. Hope this helps, Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > 3. Regarding the next steps, the text I suggested was taken from > > James' recent email. Yes we do have some drafts and it does > > represent some progress. Remember that the "front runner" > > draft-renker is based on home agent paging whose disadvantages are > > well known. > > For those of us that are not aware of these "disadvantages" that you > are refering to, perhaps you could provide additional information? > > Remember, rough concensus is easier to achieve if enough > justification is provided. > > PatC > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > > > iQA/AwUBPGQAyTN1fXKoxmisEQI1wQCgyrru7DfH/AHZs43GrFZM9hqmrusAnA+6 > Fri8z8M0JodiaKgjcaF7t+kR > =3KaT > -----END PGP SIGNATURE----- > Regards, -- Behcet --------------070009080800040503090905 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Pat,  
  The problems with HA based paging are
1. it is inefficient because HA can be far away from the visited network, this would induce large latencies on registration messages as well as in the paging process with high paging load.
2. In cases like Simple IP service in CDMA2000 it can not be used due to the dependence on MIP.

However if MIP is assumed and in small networks, HA based paging can still be useful with small paging loads.

Hope this helps,

Pat R. Calhoun wrote:
RE: [Seamoby] Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 3. Regarding the next steps, the text I suggested was taken from
> James' recent email.  Yes we do have some drafts and it does
> represent some progress. Remember that the "front  runner"
> draft-renker is based on home agent paging whose disadvantages are
> well known.  

For those of us that are not aware of these "disadvantages" that you
are refering to, perhaps you could provide additional information?

Remember, rough concensus is easier to achieve if enough
justification is provided.

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com >

iQA/AwUBPGQAyTN1fXKoxmisEQI1wQCgyrru7DfH/AHZs43GrFZM9hqmrusAnA+6
Fri8z8M0JodiaKgjcaF7t+kR
=3KaT
-----END PGP SIGNATURE-----

Regards,
-- 
Behcet 

--------------070009080800040503090905-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 8 15:35:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23960 for ; Fri, 8 Feb 2002 15:35:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03531; Fri, 8 Feb 2002 15:23:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03490 for ; Fri, 8 Feb 2002 15:23:13 -0500 (EST) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23625 for ; Fri, 8 Feb 2002 15:23:09 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA19050 for ; Fri, 8 Feb 2002 14:22:41 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g18KMfg14105 for ; Fri, 8 Feb 2002 14:22:41 -0600 (CST) Message-ID: <3C64337B.20201@alcatel.com> Date: Fri, 08 Feb 2002 14:22:19 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dear all, I would like to expand upon the requirements reconsideration. Presently RFC 3154 has 4.7 and 4.8 and trying to satisfy all leads to a draft that defines a mobility independent protocol and at least two (mipv4 and mipv6) mobility dependent protocols, i.e. 3 protocols in one draft. How will the implementors cope with such specifications? How could interoperability be tested on such implementations? Instead would it not make sense to define separate drafts for each? Then interoperability can easily be tested. Also the drafts would be much easier to evaluate by WG members. So a better selection can be made. I think that Mobile IP can be extended by other WGs, I know at least one by AAA WG. So let us make some slight changes in RFC 3154 to make this possible. Profiting the occasion, we also could make the typographical corrections pointed out earlier. For the security requirements some comments were made before, one point here is the mip based protocol can make use of mip security which is being worked out at MIP WG so we should make this possible. I am not sure if this requires a charter change? I hope not. My 2 euro cents. -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Feb 11 15:09:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15825 for ; Mon, 11 Feb 2002 15:09:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29155; Mon, 11 Feb 2002 14:50:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29127 for ; Mon, 11 Feb 2002 14:49:58 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15284 for ; Mon, 11 Feb 2002 14:49:55 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1BJnBe23946; Mon, 11 Feb 2002 11:49:15 -0800 (PST) Message-ID: <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , References: <3C64337B.20201@alcatel.com> Subject: Re: [Seamoby] Moving forward with paging Date: Mon, 11 Feb 2002 11:47:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Behcet, > I would like to expand upon the requirements reconsideration. > Presently RFC 3154 has 4.7 and 4.8 and trying to satisfy all leads to a > draft that defines a mobility independent protocol and at least two > (mipv4 and mipv6) mobility dependent protocols, i.e. 3 protocols in one > draft. > How will the implementors cope with such specifications? How could > interoperability be tested on such implementations? Not necessarily. IMHO, if the implementation of the Tracking Agent function in Section 5.1 of RFC 3154 is moved from the paging protocol to the mobility protocol, the need for maintaining mobility information in the paging protocol about the host while it is in dormant mode is avoided. The advantages of this are: - simplifies paging protocol to just dormant mode alerting and advertising of paging areas, plus possible hooks to assist the mobility protocol in tracking. - avoids duplication of location state information across multiple protocols/agents. - simplifies recovery if a paging agent fails, since there is no need to duplicate location state information at replicated agents (of course, the mobility protocol still has to maintain this information, but it is only at one place). The disadvantages are; - Need to specify how dormant mode location updating is performed for each individual protocol. - Possible security implications of having an agent which is not the host do location updating, because requiring the host to do it would impact dormant mode too heavily, and thus be a power sink. With further study, accepatable solutions could be found to these problems. > Instead would it not make sense to define separate drafts for each? > Then interoperability can easily be tested. Also the drafts would be > much easier to evaluate by WG members. So a better selection can be made. > I think that Mobile IP can be extended by other WGs, I know at least > one by AAA WG. > So let us make some slight changes in RFC 3154 to make this possible. > Profiting the occasion, we also could make the typographical corrections > pointed out earlier. I don't think we need to make any changes to RFC 3154, since the functional architecture doesn't specify a particular protocol implementation. I think we need to agree that there is an IP paging protocol that covers DMA and Paging functionality, and that dormant mode location updating is the function of the mobility protocol. Of course, there may need to be some hooks for the paging agent to assist in dormant mode location updating. In addition, we would need to specify how the exisiting mobility protocols, MIPv4 and MIPv6, handle dormant mode location updating. Whether these should be in the same draft or separate drafts is another discussion. > For the security requirements some comments were made before, one > point here is the mip based protocol can make use of mip security which > is being worked out at MIP WG so we should make this possible. I don't think we want to depend on MIP security, but the discussion in the MIP WG is relevent. In particular, there has been some discussion there and I've had some discussion offline with some members of the MIP BU security design team about using CGAs for general IP signaling security. There is some interest in this, and there may be some attempt to pull together some activity in this area. Fortunately, the paging work is not under as much of a time pressure as MIPv6, so we do not have to decide this issue right now. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Feb 11 16:46:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18449 for ; Mon, 11 Feb 2002 16:46:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03941; Mon, 11 Feb 2002 16:32:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03911 for ; Mon, 11 Feb 2002 16:31:58 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17816 for ; Mon, 11 Feb 2002 16:31:56 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1BLVSe28758 for ; Mon, 11 Feb 2002 13:31:28 -0800 (PST) Message-ID: <06ec01c1b343$3e1fb290$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 11 Feb 2002 13:29:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Moving forward on CAR Discovery Requirements Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Folks, We would like to move the CAR requirements draft to WG status, with Govind as the editor. The draft is not accessable through the IETF drafts search engine for some reason, but can be found through the following URL: http://www.ietf.org/internet-drafts/draft-krishnamurthi-seamoby-car-requ irements-00.txt so it is in the drafts directory. If there is no objection to this, then we would like to start WG Last Call for the CAR discovery requirements draft today and run until Feb. 25. This gives Govind a couple days to get in a 01 draft with comments before the March 1 deadline. So, please send any comments you may have on the CAR discovery requirements draft to the list. Thanx. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Feb 11 19:13:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20740 for ; Mon, 11 Feb 2002 19:13:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08145; Mon, 11 Feb 2002 18:01:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08116 for ; Mon, 11 Feb 2002 18:01:55 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20050 for ; Mon, 11 Feb 2002 18:01:53 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1BN1Pv04081 for ; Mon, 11 Feb 2002 17:01:25 -0600 (CST) Message-ID: <3C684D25.90803@alcatel.com> Date: Mon, 11 Feb 2002 17:00:53 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------090502000402080709060805" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------090502000402080709060805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jim, Only if we combine paging with MIP then your analysis applies. Unfortunately we won't have a MIP independent paging protocol. Originally this was what I had argued for if you remember the discussions we had last March. Then the requirement 4.7 will be violated. If we are talking about mobility protocol independent IP Paging protocol as there are two IPs it makes two right there. I believe that MIP independent IP Paging protocols for v4 and v6 have to be defined because there will be demand and interest for cases like Simple IP service of CDMA2000, etc. IPv4 and IPv6 being fairly diferent means we'd better define them in separate IDs, although one approach could be to concentrate on one first (maybe v6 version). Then the requirement 4.8 will be violated. This is the problem with RFC 3154. If RFC3154bis could state 4.7 or 4.8 as the requirements, then this would pave the way to the development of possibly 4 different IDs. What do you think? James Kempf wrote: >Behcet, > >> I would like to expand upon the requirements reconsideration. >>Presently RFC 3154 has 4.7 and 4.8 and trying to satisfy all leads to >> >a > >>draft that defines a mobility independent protocol and at least two >>(mipv4 and mipv6) mobility dependent protocols, i.e. 3 protocols in >> >one > >>draft. >> How will the implementors cope with such specifications? How could >>interoperability be tested on such implementations? >> > >Not necessarily. > >IMHO, if the implementation of the Tracking Agent function in Section >5.1 of RFC 3154 >is moved from the paging protocol to the mobility protocol, the need for >maintaining mobility information in the paging protocol about the host >while it is >in dormant mode is avoided. > >The advantages of this are: > > - simplifies paging protocol to just dormant mode alerting and > advertising of paging areas, plus possible hooks to assist > the mobility protocol in tracking. > > - avoids duplication of location state information across multiple > protocols/agents. > > - simplifies recovery if a paging agent fails, since there is no >need > to duplicate location state information at replicated agents (of >course, > the mobility protocol still has to maintain this information, but it > is only at one place). > >The disadvantages are; > > - Need to specify how dormant mode location updating is performed > for each individual protocol. > > - Possible security implications of having an agent which is not > the host do location updating, because requiring the host > to do it would impact dormant mode too heavily, and > thus be a power sink. > >With further study, accepatable solutions could >be found to these problems. > >> Instead would it not make sense to define separate drafts for each? >>Then interoperability can easily be tested. Also the drafts would be >>much easier to evaluate by WG members. So a better selection can be >> >made. > >> I think that Mobile IP can be extended by other WGs, I know at least >>one by AAA WG. >> So let us make some slight changes in RFC 3154 to make this >> >possible. > >>Profiting the occasion, we also could make the typographical >> >corrections > >>pointed out earlier. >> > >I don't think we need to make any changes to RFC 3154, since the >functional >architecture doesn't specify a particular protocol implementation. > >I think we need to agree that there is an IP paging protocol that covers >DMA and Paging functionality, and that dormant mode location >updating is the function of the mobility protocol. Of course, there >may need to be some hooks for the paging agent to assist >in dormant mode location updating. > >In addition, we would need to specify how the exisiting mobility >protocols, MIPv4 and MIPv6, handle dormant mode location >updating. > >Whether these should be in the same draft or separate drafts >is another discussion. > >> For the security requirements some comments were made before, one >>point here is the mip based protocol can make use of mip security >> >which > >>is being worked out at MIP WG so we should make this possible. >> > >I don't think we want to depend on MIP security, but the discussion >in the MIP WG is relevent. In particular, there has been some discussion >there and I've had some discussion offline with some members >of the MIP BU security design team about using CGAs for >general IP signaling security. There is some interest in this, and there >may be some attempt to pull together some activity in this area. >Fortunately, the paging work is not under as much of a time >pressure as MIPv6, so we do not have to decide this issue >right now. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > -- Behcet --------------090502000402080709060805 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jim,

 Only if we combine paging with MIP then your analysis applies. Unfortunately we won't have a MIP independent paging protocol. Originally this was what I had argued for if you remember the discussions we had last March.
Then the requirement 4.7 will be violated.
  If we are talking about mobility protocol independent IP Paging protocol as there are two IPs it makes two right there. I believe that MIP independent IP Paging protocols for v4 and v6 have to be defined because there will be demand and interest for cases like Simple IP service of CDMA2000, etc. IPv4 and IPv6 being fairly diferent means we'd better define them in separate IDs, although one approach could be to concentrate on one first (maybe v6 version).
Then the requirement 4.8 will be violated.

This is the problem with RFC 3154.
  If RFC3154bis could state 4.7 or 4.8 as the requirements, then this would pave the way to the development of possibly 4 different IDs.
  What do you think?

James Kempf wrote:
Behcet,

  I would like to expand upon the requirements reconsideration.
Presently RFC 3154 has 4.7 and 4.8 and trying to satisfy all leads to
a
draft that defines a mobility independent protocol and at least two
(mipv4 and mipv6) mobility dependent protocols, i.e. 3 protocols in
one
draft.
  How will the implementors cope with such specifications? How could
interoperability be tested on such implementations?

Not necessarily.

IMHO, if the implementation of the Tracking Agent function in Section
5.1  of RFC 3154
is moved from the paging protocol to the mobility protocol, the need for
maintaining mobility information in the paging protocol about the host
while it is
in dormant mode is avoided.

The advantages of this are:

    - simplifies paging protocol to just dormant mode alerting and
    advertising of paging areas, plus possible hooks to assist
    the mobility protocol in tracking.

    - avoids duplication of location state information across multiple
    protocols/agents.

    - simplifies recovery if a paging agent fails, since there is no
need
    to duplicate location state information at replicated agents (of
course,
    the mobility protocol still has to maintain this information, but it
    is only at one place).

The disadvantages are;

    - Need to spe
cify how dormant mode location updating is performed
    for each individual protocol.

    - Possible security implications of having an agent which is not
    the host do location updating, because requiring the host
    to do it would impact dormant mode too heavily, and
    thus be a power sink.

With further study, accepatable solutions could
be found to these problems.

  Instead would it not make sense to define separate drafts for each?
Then interoperability can easily be tested. Also the drafts would be
much easier to evaluate by WG members. So a better selection can be
made.
  I think that Mobile IP can be extended by other WGs, I know at least
one by AAA WG.
  So let us make some slight changes in RFC 3154 to make this
possible.
Profiting the occasion, we also could make the typographical
corrections
pointed out earlier.

I don't think we need to make any changes to RFC 3154, since the
functional
architecture doesn't specify a particular protocol implementation.

I think we need to agree that there is an IP paging protocol that covers
DMA and Paging functionality, and that dormant mode location
updating is the function of the mobility protocol. Of course, there
may need to be some hooks for the paging agent to assist
in dormant mode location updating.

In addition, we would need to specify how the exisiting mobility
protocols, MIPv4 and MIPv6, handle dormant mode location
updating.

Whether these should be in the same draft or separate drafts
is another discussion.

   For the security requirements some comments were made before, one
point here is the mip based protocol can make use of mip security
which
is being worked out at MIP WG so we should make this possible.

I don't think we want to depend on MIP security, but the discussion
in the MIP WG is relevent. In particular, there has been some discussion
there and I've had some discussion offline with some members
of the MIP BU security design team about using CGAs for
general IP signaling security. There is some interest in this, and there
may be some attempt to pull together some activity in this area.
Fortunately, the paging work is not under as much of a time
pressure as MIPv6, so we do not have to decide this issue
right now.

            jak


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

-- 
Behcet

--------------090502000402080709060805-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 03:47:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23617 for ; Wed, 13 Feb 2002 03:47:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20943; Wed, 13 Feb 2002 03:31:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20913 for ; Wed, 13 Feb 2002 03:31:03 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23215 for ; Wed, 13 Feb 2002 03:30:53 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1D8UMB26439 for ; Wed, 13 Feb 2002 09:30:22 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Feb 13 09:30:15 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 09:29:43 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538032585E9@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: James Kempf , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements Date: Wed, 13 Feb 2002 09:29:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org I haven't read the draft yet, so I can't object to it being a WG item. But isn't it too quick to have a concensus call for a draft to become a WG draft and WG last call at the same time? Normally WG members are given two weeks for each call. Or is this a concensus call for the draft to be a WG item and not a last call on the draft? Hesham > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, February 11, 2002 10:30 PM > To: seamoby@ietf.org > Subject: [Seamoby] Moving forward on CAR Discovery Requirements > > > Folks, > > We would like to move the CAR requirements draft to WG status, with > Govind as the editor. The draft is not accessable through the IETF > drafts search engine for some reason, but can be found through the > following URL: > > > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam > oby-car-requ > irements-00.txt > > so it is in the drafts directory. > > If there is no objection to this, then we would like to > start WG Last > Call for the CAR discovery > requirements draft today and run until Feb. 25. This gives Govind a > couple days to get in a 01 > draft with comments before the March 1 deadline. > > So, please send any comments you may have on the CAR discovery > requirements draft to the list. > Thanx. > > 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 From seamoby-admin@ietf.org Wed Feb 13 11:22:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10474 for ; Wed, 13 Feb 2002 11:22:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13179; Wed, 13 Feb 2002 11:07:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13150 for ; Wed, 13 Feb 2002 11:07:28 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09145 for ; Wed, 13 Feb 2002 11:07:25 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7RZNQ>; Wed, 13 Feb 2002 08:06:57 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Hesham Soliman (ERA)'" , James Kempf , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements Date: Wed, 13 Feb 2002 08:06:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4A8.75AC5C20" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B4A8.75AC5C20 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The document has been available for some time, and as history has shown, performing a last call on a document guarantees comments. If folks believe that we can get the same amount of review without the last call, that is an option as well. Given our current milestones, I'd prefer to do both simultaneously. PatC - -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, February 13, 2002 12:30 AM To: James Kempf; seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements I haven't read the draft yet, so I can't object to it being a WG item. But isn't it too quick to have a concensus call for a draft to become a WG draft and WG last call at the same time? Normally WG members are given two weeks for each call. Or is this a concensus call for the draft to be a WG item and not a last call on the draft? Hesham > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, February 11, 2002 10:30 PM > To: seamoby@ietf.org > Subject: [Seamoby] Moving forward on CAR Discovery Requirements > > > Folks, > > We would like to move the CAR requirements draft to WG status, with > Govind as the editor. The draft is not accessable through the IETF > drafts search engine for some reason, but can be found through the > following URL: > > > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam > oby-car-requ > irements-00.txt > > so it is in the drafts directory. > > If there is no objection to this, then we would like to > start WG Last > Call for the CAR discovery > requirements draft today and run until Feb. 25. This gives Govind a > couple days to get in a 01 > draft with comments before the March 1 deadline. > > So, please send any comments you may have on the CAR discovery > requirements draft to the list. > Thanx. > > 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 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR 5flsrH10kBKWgaZF3mmeGs7j =a4g2 -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B4A8.75AC5C20 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Moving forward on CAR Discovery = Requirements

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The document has been available for some time, and as = history has
shown, performing a last call on a document = guarantees comments. If
folks believe that we can get the same amount of = review without the
last call, that is an option as well.

Given our current milestones, I'd prefer to do both = simultaneously.

PatC

- -----Original Message-----
From: Hesham Soliman (ERA) [mailto:hesham.soliman@era= .ericsson.se]
Sent: Wednesday, February 13, 2002 12:30 AM
To: James Kempf; seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on CAR = Discovery Requirements


I haven't read the draft yet, so I can't
object to it being a WG item. But isn't
it too quick to have a concensus call
for a draft to become a WG draft and
WG last call at the same time?
Normally WG members are given two weeks
for each call.
Or is this a concensus call for the draft
to be a WG item and not a last call on
the draft?


Hesham

  > -----Original Message-----
  > From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
  > Sent: Monday, February 11, 2002 10:30 = PM
  > To: seamoby@ietf.org
  > Subject: [Seamoby] Moving forward on CAR = Discovery Requirements
  >
  >
  > Folks,
  >
  > We would like to move the CAR = requirements draft to WG status,
with
  > Govind as the editor. The draft is not = accessable through the
IETF
  > drafts search engine for some reason, = but can be found through
the
  > following URL:
  >
  >
  > http://www.ietf.org/internet-drafts/draft-krishnamurth= i-seam
  > oby-car-requ
  > irements-00.txt
  >
  > so it is in the drafts directory.
  >
  > If there is no objection to this, then = we would like to
  > start WG Last
  > Call for the CAR discovery
  > requirements draft today and run until = Feb. 25. This gives Govind
a
  > couple days to get in a 01
  > draft with comments before the March 1 = deadline.
  >
  > So, please send any comments you may = have on the CAR discovery
  > requirements draft to the list.
  > Thanx.
  >
  = >           &n= bsp; 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

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPh= R
5flsrH10kBKWgaZF3mmeGs7j
=3Da4g2
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B4A8.75AC5C20-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 12:08:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13478 for ; Wed, 13 Feb 2002 12:08:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15566; Wed, 13 Feb 2002 11:54:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15541 for ; Wed, 13 Feb 2002 11:54:33 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11442 for ; Wed, 13 Feb 2002 11:54:29 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1DGs0e19918; Wed, 13 Feb 2002 08:54:00 -0800 (PST) Message-ID: <005301c1b4ae$d05057c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , References: <4DA6EA82906FD511BE2F00508BCF0538032585E9@Esealnt861.al.sw.ericsson.se> Subject: Re: [Seamoby] Moving forward on CAR Discovery Requirements Date: Wed, 13 Feb 2002 08:52:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hesham, Since the draft deadline is rapidly approaching, we wanted to get some debate going about the requirements so that we could get people's comments in before the next meeting. If you think you need more time to consider whether the draft should be a WG draft or not, we can certainly allow that, but I would really like to get some discussion going about the content so that Govind can submit an update prior to the March 1 deadline. jak ----- Original Message ----- From: "Hesham Soliman (ERA)" To: "James Kempf" ; Sent: Wednesday, February 13, 2002 12:29 AM Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > I haven't read the draft yet, so I can't > object to it being a WG item. But isn't > it too quick to have a concensus call > for a draft to become a WG draft and > WG last call at the same time? > Normally WG members are given two weeks > for each call. > Or is this a concensus call for the draft > to be a WG item and not a last call on > the draft? > > > Hesham > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Monday, February 11, 2002 10:30 PM > > To: seamoby@ietf.org > > Subject: [Seamoby] Moving forward on CAR Discovery Requirements > > > > > > Folks, > > > > We would like to move the CAR requirements draft to WG status, with > > Govind as the editor. The draft is not accessable through the IETF > > drafts search engine for some reason, but can be found through the > > following URL: > > > > > > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam > > oby-car-requ > > irements-00.txt > > > > so it is in the drafts directory. > > > > If there is no objection to this, then we would like to > > start WG Last > > Call for the CAR discovery > > requirements draft today and run until Feb. 25. This gives Govind a > > couple days to get in a 01 > > draft with comments before the March 1 deadline. > > > > So, please send any comments you may have on the CAR discovery > > requirements draft to the list. > > Thanx. > > > > 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 From seamoby-admin@ietf.org Wed Feb 13 12:32:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14785 for ; Wed, 13 Feb 2002 12:32:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18043; Wed, 13 Feb 2002 12:17:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18014 for ; Wed, 13 Feb 2002 12:17:57 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14337 for ; Wed, 13 Feb 2002 12:17:53 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1DHHMhM004788 for ; Wed, 13 Feb 2002 18:17:22 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Feb 13 18:17:15 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 18:07:54 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA09@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pat R. Calhoun'" , "Hesham Soliman (ERA)" , James Kempf , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements Date: Wed, 13 Feb 2002 18:16:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4B2.394228A0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B4B2.394228A0 Content-Type: text/plain; charset="iso-8859-1" Pat, I'm not against soliciting for comments, I just think a last call is very quick. How long has the draft existed 2 weeks ? that's not a very long time. I would like to send comments on the draft and I'm not suggesting that the WG halts till I do so, but why go at rocket speed? It's a good way of activating people to send comments but it can also be a good way of making sure no one has enough time to comment. I'm sure you don't want that. Hesham -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Wednesday, February 13, 2002 5:07 PM To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The document has been available for some time, and as history has shown, performing a last call on a document guarantees comments. If folks believe that we can get the same amount of review without the last call, that is an option as well. Given our current milestones, I'd prefer to do both simultaneously. PatC - -----Original Message----- From: Hesham Soliman (ERA) [ mailto:hesham.soliman@era.ericsson.se ] Sent: Wednesday, February 13, 2002 12:30 AM To: James Kempf; seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements I haven't read the draft yet, so I can't object to it being a WG item. But isn't it too quick to have a concensus call for a draft to become a WG draft and WG last call at the same time? Normally WG members are given two weeks for each call. Or is this a concensus call for the draft to be a WG item and not a last call on the draft? Hesham > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: Monday, February 11, 2002 10:30 PM > To: seamoby@ietf.org > Subject: [Seamoby] Moving forward on CAR Discovery Requirements > > > Folks, > > We would like to move the CAR requirements draft to WG status, with > Govind as the editor. The draft is not accessable through the IETF > drafts search engine for some reason, but can be found through the > following URL: > > > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam > oby-car-requ > irements-00.txt > > so it is in the drafts directory. > > If there is no objection to this, then we would like to > start WG Last > Call for the CAR discovery > requirements draft today and run until Feb. 25. This gives Govind a > couple days to get in a 01 > draft with comments before the March 1 deadline. > > So, please send any comments you may have on the CAR discovery > requirements draft to the list. > Thanx. > > 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 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR 5flsrH10kBKWgaZF3mmeGs7j =a4g2 -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B4B2.394228A0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Moving forward on CAR Discovery Requirements
Pat,
 
I'm not against soliciting for comments, I just think
a last call is very quick. How long has the
draft existed 2 weeks ? that's not a very long time.
 
I would like to send comments on the draft and I'm
not suggesting that the WG halts till I do so, but
why go at rocket speed? It's a good way of activating
people to send comments but it can also be a good way
of making sure no one has enough time to comment.
I'm sure you don't want that.
 
Hesham
 
-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
Sent: Wednesday, February 13, 2002 5:07 PM
To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The document has been available for some time, and as history has
shown, performing a last call on a document guarantees comments. If
folks believe that we can get the same amount of review without the
last call, that is an option as well.

Given our current milestones, I'd prefer to do both simultaneously.

PatC

- -----Original Message-----
From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
Sent: Wednesday, February 13, 2002 12:30 AM
To: James Kempf; seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements


I haven't read the draft yet, so I can't
object to it being a WG item. But isn't
it too quick to have a concensus call
for a draft to become a WG draft and
WG last call at the same time?
Normally WG members are given two weeks
for each call.
Or is this a concensus call for the draft
to be a WG item and not a last call on
the draft?


Hesham

  > -----Original Message-----
  > From: James Kempf [mailto:kempf@docomolabs-usa.com]
  > Sent: Monday, February 11, 2002 10:30 PM
  > To: seamoby@ietf.org
  > Subject: [Seamoby] Moving forward on CAR Discovery Requirements
  >
  >
  > Folks,
  >
  > We would like to move the CAR requirements draft to WG status,
with
  > Govind as the editor. The draft is not accessable through the
IETF
  > drafts search engine for some reason, but can be found through
the
  > following URL:
  >
  >
  > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam
  > oby-car-requ
  > irements-00.txt
  >
  > so it is in the drafts directory.
  >
  > If there is no objection to this, then we would like to
  > start WG Last
  > Call for the CAR discovery
  > requirements draft today and run until Feb. 25. This gives Govind
a
  > couple days to get in a 01
  > draft with comments before the March 1 deadline.
  >
  > So, please send any comments you may have on the CAR discovery
  > requirements draft to the list.
  > Thanx.
  >
  >             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

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR
5flsrH10kBKWgaZF3mmeGs7j
=a4g2
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B4B2.394228A0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 12:37:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14950 for ; Wed, 13 Feb 2002 12:37:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18280; Wed, 13 Feb 2002 12:23:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18213 for ; Wed, 13 Feb 2002 12:23:22 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14495 for ; Wed, 13 Feb 2002 12:23:14 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1DHMkhM006110 for ; Wed, 13 Feb 2002 18:22:46 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Feb 13 18:22:46 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 18:22:45 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA0A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pat R. Calhoun'" , "Hesham Soliman (ERA)" , James Kempf , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements Date: Wed, 13 Feb 2002 18:22:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4B2.F9C80C20" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B4B2.F9C80C20 Content-Type: text/plain; charset="iso-8859-1" to be extra clear I have no objections to making it a WG item. Hesham -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Wednesday, February 13, 2002 6:21 PM To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You are correct. We want folks to have time to comment, so I understand your relunctance. The goal, though, is to provide enough time for the editor to send an update by the I-D deadline. If others agree with Hesham, we can push back on the last call, and just ask for comments. PatC - -----Original Message----- From: Hesham Soliman (ERA) [ mailto:hesham.soliman@era.ericsson.se ] Sent: Wednesday, February 13, 2002 9:17 AM To: Pat R. Calhoun; Hesham Soliman (ERA); James Kempf; seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements Pat, I'm not against soliciting for comments, I just think a last call is very quick. How long has the draft existed 2 weeks ? that's not a very long time. I would like to send comments on the draft and I'm not suggesting that the WG halts till I do so, but why go at rocket speed? It's a good way of activating people to send comments but it can also be a good way of making sure no one has enough time to comment. I'm sure you don't want that. Hesham - -----Original Message----- From: Pat R. Calhoun [ mailto:pcalhoun@bstormnetworks.com ] Sent: Wednesday, February 13, 2002 5:07 PM To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The document has been available for some time, and as history has shown, performing a last call on a document guarantees comments. If folks believe that we can get the same amount of review without the last call, that is an option as well. Given our current milestones, I'd prefer to do both simultaneously. PatC - - -----Original Message----- From: Hesham Soliman (ERA) [ mailto:hesham.soliman@era.ericsson.se ] Sent: Wednesday, February 13, 2002 12:30 AM To: James Kempf; seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements I haven't read the draft yet, so I can't object to it being a WG item. But isn't it too quick to have a concensus call for a draft to become a WG draft and WG last call at the same time? Normally WG members are given two weeks for each call. Or is this a concensus call for the draft to be a WG item and not a last call on the draft? Hesham > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: Monday, February 11, 2002 10:30 PM > To: seamoby@ietf.org > Subject: [Seamoby] Moving forward on CAR Discovery Requirements > > > Folks, > > We would like to move the CAR requirements draft to WG status, with > Govind as the editor. The draft is not accessable through the IETF > drafts search engine for some reason, but can be found through the > following URL: > > > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam > oby-car-requ > irements-00.txt > > so it is in the drafts directory. > > If there is no objection to this, then we would like to > start WG Last > Call for the CAR discovery > requirements draft today and run until Feb. 25. This gives Govind a > couple days to get in a 01 > draft with comments before the March 1 deadline. > > So, please send any comments you may have on the CAR discovery > requirements draft to the list. > Thanx. > > 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 - -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR 5flsrH10kBKWgaZF3mmeGs7j =a4g2 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > iQA/AwUBPGqgbzN1fXKoxmisEQL9FwCcDIKnE37zWfLaOsU1tLqa1h3HQAAAnRb9 NtkRQAk2gIZTvQ8uhixHhfAj =Vj2J -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B4B2.F9C80C20 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Moving forward on CAR Discovery Requirements
to be extra clear I have no objections to making it
a WG item.
 
Hesham
-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
Sent: Wednesday, February 13, 2002 6:21 PM
To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You are correct. We want folks to have time to comment, so I
understand your relunctance. The goal, though, is to provide enough
time for the editor to send an update by the I-D deadline.

If others agree with Hesham, we can push back on the last call, and
just ask for comments.

PatC
- -----Original Message-----
From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
Sent: Wednesday, February 13, 2002 9:17 AM
To: Pat R. Calhoun; Hesham Soliman (ERA); James Kempf;
seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements


Pat,

I'm not against soliciting for comments, I just think
a last call is very quick. How long has the
draft existed 2 weeks ? that's not a very long time.

I would like to send comments on the draft and I'm
not suggesting that the WG halts till I do so, but
why go at rocket speed? It's a good way of activating
people to send comments but it can also be a good way
of making sure no one has enough time to comment.
I'm sure you don't want that.

Hesham

- -----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
Sent: Wednesday, February 13, 2002 5:07 PM
To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements



- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The document has been available for some time, and as history has
shown, performing a last call on a document guarantees comments. If
folks believe that we can get the same amount of review without the
last call, that is an option as well.
Given our current milestones, I'd prefer to do both simultaneously.
PatC
- - -----Original Message-----
From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
Sent: Wednesday, February 13, 2002 12:30 AM
To: James Kempf; seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements


I haven't read the draft yet, so I can't
object to it being a WG item. But isn't
it too quick to have a concensus call
for a draft to become a WG draft and
WG last call at the same time?
Normally WG members are given two weeks
for each call.
Or is this a concensus call for the draft
to be a WG item and not a last call on
the draft?


Hesham
  > -----Original Message-----
  > From: James Kempf [mailto:kempf@docomolabs-usa.com]
  > Sent: Monday, February 11, 2002 10:30 PM
  > To: seamoby@ietf.org
  > Subject: [Seamoby] Moving forward on CAR Discovery Requirements
  >
  >
  > Folks,
  >
  > We would like to move the CAR requirements draft to WG status,
with
  > Govind as the editor. The draft is not accessable through the
IETF
  > drafts search engine for some reason, but can be found through
the
  > following URL:
  >
  >
  > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam
  > oby-car-requ
  > irements-00.txt
  >
  > so it is in the drafts directory.
  >
  > If there is no objection to this, then we would like to
  > start WG Last
  > Call for the CAR discovery
  > requirements draft today and run until Feb. 25. This gives Govind
a
  > couple days to get in a 01
  > draft with comments before the March 1 deadline.
  >
  > So, please send any comments you may have on the CAR discovery
  > requirements draft to the list.
  > Thanx.
  >
  >             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
- -----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use
<http://www.pgp.com>
iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR
5flsrH10kBKWgaZF3mmeGs7j
=a4g2
- -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPGqgbzN1fXKoxmisEQL9FwCcDIKnE37zWfLaOsU1tLqa1h3HQAAAnRb9
NtkRQAk2gIZTvQ8uhixHhfAj
=Vj2J
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B4B2.F9C80C20-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 12:47:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15199 for ; Wed, 13 Feb 2002 12:47:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18172; Wed, 13 Feb 2002 12:21:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18138 for ; Wed, 13 Feb 2002 12:21:20 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14402 for ; Wed, 13 Feb 2002 12:21:16 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7RZQA>; Wed, 13 Feb 2002 09:20:49 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Hesham Soliman (ERA)'" , James Kempf , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements Date: Wed, 13 Feb 2002 09:20:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4B2.C71CDB20" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B4B2.C71CDB20 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You are correct. We want folks to have time to comment, so I understand your relunctance. The goal, though, is to provide enough time for the editor to send an update by the I-D deadline. If others agree with Hesham, we can push back on the last call, and just ask for comments. PatC - -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, February 13, 2002 9:17 AM To: Pat R. Calhoun; Hesham Soliman (ERA); James Kempf; seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements Pat, I'm not against soliciting for comments, I just think a last call is very quick. How long has the draft existed 2 weeks ? that's not a very long time. I would like to send comments on the draft and I'm not suggesting that the WG halts till I do so, but why go at rocket speed? It's a good way of activating people to send comments but it can also be a good way of making sure no one has enough time to comment. I'm sure you don't want that. Hesham - -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Wednesday, February 13, 2002 5:07 PM To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The document has been available for some time, and as history has shown, performing a last call on a document guarantees comments. If folks believe that we can get the same amount of review without the last call, that is an option as well. Given our current milestones, I'd prefer to do both simultaneously. PatC - - -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, February 13, 2002 12:30 AM To: James Kempf; seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements I haven't read the draft yet, so I can't object to it being a WG item. But isn't it too quick to have a concensus call for a draft to become a WG draft and WG last call at the same time? Normally WG members are given two weeks for each call. Or is this a concensus call for the draft to be a WG item and not a last call on the draft? Hesham > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, February 11, 2002 10:30 PM > To: seamoby@ietf.org > Subject: [Seamoby] Moving forward on CAR Discovery Requirements > > > Folks, > > We would like to move the CAR requirements draft to WG status, with > Govind as the editor. The draft is not accessable through the IETF > drafts search engine for some reason, but can be found through the > following URL: > > > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam > oby-car-requ > irements-00.txt > > so it is in the drafts directory. > > If there is no objection to this, then we would like to > start WG Last > Call for the CAR discovery > requirements draft today and run until Feb. 25. This gives Govind a > couple days to get in a 01 > draft with comments before the March 1 deadline. > > So, please send any comments you may have on the CAR discovery > requirements draft to the list. > Thanx. > > 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 - -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR 5flsrH10kBKWgaZF3mmeGs7j =a4g2 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGqgbzN1fXKoxmisEQL9FwCcDIKnE37zWfLaOsU1tLqa1h3HQAAAnRb9 NtkRQAk2gIZTvQ8uhixHhfAj =Vj2J -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B4B2.C71CDB20 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Moving forward on CAR Discovery = Requirements

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You are correct. We want folks to have time to = comment, so I
understand your relunctance. The goal, though, is to = provide enough
time for the editor to send an update by the I-D = deadline.

If others agree with Hesham, we can push back on the = last call, and
just ask for comments.

PatC
- -----Original Message-----
From: Hesham Soliman (ERA) [mailto:hesham.soliman@era= .ericsson.se]
Sent: Wednesday, February 13, 2002 9:17 AM
To: Pat R. Calhoun; Hesham Soliman (ERA); James = Kempf;
seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on CAR = Discovery Requirements


Pat,

I'm not against soliciting for comments, I just think =
a last call is very quick. How long has the
draft existed 2 weeks ? that's not a very long time. =

I would like to send comments on the draft and = I'm
not suggesting that the WG halts till I do so, = but
why go at rocket speed? It's a good way of = activating
people to send comments but it can also be a good = way
of making sure no one has enough time to comment. =
I'm sure you don't want that.

Hesham

- -----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@bstormnetwor= ks.com]
Sent: Wednesday, February 13, 2002 5:07 PM
To: 'Hesham Soliman (ERA)'; James Kempf; = seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on CAR = Discovery Requirements



- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The document has been available for some time, and = as history has
shown, performing a last call on a document = guarantees comments. If
folks believe that we can get the same amount of = review without the
last call, that is an option as well.
Given our current milestones, I'd prefer to do both = simultaneously.
PatC
- - -----Original Message-----
From: Hesham Soliman (ERA) [mailto:hesham.soliman@era= .ericsson.se]
Sent: Wednesday, February 13, 2002 12:30 AM
To: James Kempf; seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on CAR = Discovery Requirements


I haven't read the draft yet, so I can't
object to it being a WG item. But isn't
it too quick to have a concensus call
for a draft to become a WG draft and
WG last call at the same time?
Normally WG members are given two weeks
for each call.
Or is this a concensus call for the draft
to be a WG item and not a last call on
the draft?


Hesham
  > -----Original Message-----
  > From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
  > Sent: Monday, February 11, 2002 10:30 PM =
  > To: seamoby@ietf.org
  > Subject: [Seamoby] Moving forward on CAR = Discovery Requirements
  >
  >
  > Folks,
  >
  > We would like to move the CAR = requirements draft to WG status,
with
  > Govind as the editor. The draft is not = accessable through the
IETF
  > drafts search engine for some reason, = but can be found through
the
  > following URL:
  >
  >
  > http://www.ietf.org/internet-drafts/draft-krishnamurth= i-seam
  > oby-car-requ
  > irements-00.txt
  >
  > so it is in the drafts directory. =
  >
  > If there is no objection to this, then = we would like to
  > start WG Last
  > Call for the CAR discovery
  > requirements draft today and run until = Feb. 25. This gives Govind
a
  > couple days to get in a 01
  > draft with comments before the March 1 = deadline.
  >
  > So, please send any comments you may = have on the CAR discovery
  > requirements draft to the list.
  > Thanx.
  >
  = >           &n= bsp; 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 =
- -----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial = use
<http://www.pgp.com>
iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPh= R
5flsrH10kBKWgaZF3mmeGs7j
=3Da4g2
- -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPGqgbzN1fXKoxmisEQL9FwCcDIKnE37zWfLaOsU1tLqa1h3HQAAAnRb= 9
NtkRQAk2gIZTvQ8uhixHhfAj
=3DVj2J
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B4B2.C71CDB20-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 13:15:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16006 for ; Wed, 13 Feb 2002 13:15:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20464; Wed, 13 Feb 2002 13:02:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20419 for ; Wed, 13 Feb 2002 13:01:59 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15619 for ; Wed, 13 Feb 2002 13:01:56 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1DI1Pe23171; Wed, 13 Feb 2002 10:01:25 -0800 (PST) Message-ID: <011601c1b4b8$3b5c9570$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "'Pat R. Calhoun'" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AA0A@Esealnt861.al.sw.ericsson.se> Subject: Re: [Seamoby] Moving forward on CAR Discovery Requirements Date: Wed, 13 Feb 2002 09:59:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit OK. So let's get some comment on content so that Govind can submit an update. jak ----- Original Message ----- From: "Hesham Soliman (ERA)" To: "'Pat R. Calhoun'" ; "Hesham Soliman (ERA)" ; "James Kempf" ; Sent: Wednesday, February 13, 2002 9:22 AM Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > to be extra clear I have no objections to making it > a WG item. > > Hesham > > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com] > Sent: Wednesday, February 13, 2002 6:21 PM > To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org > Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > You are correct. We want folks to have time to comment, so I > understand your relunctance. The goal, though, is to provide enough > time for the editor to send an update by the I-D deadline. > > If others agree with Hesham, we can push back on the last call, and > just ask for comments. > > PatC > - -----Original Message----- > From: Hesham Soliman (ERA) [ mailto:hesham.soliman@era.ericsson.se ] > Sent: Wednesday, February 13, 2002 9:17 AM > To: Pat R. Calhoun; Hesham Soliman (ERA); James Kempf; > seamoby@ietf.org > Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > > Pat, > > I'm not against soliciting for comments, I just think > a last call is very quick. How long has the > draft existed 2 weeks ? that's not a very long time. > > I would like to send comments on the draft and I'm > not suggesting that the WG halts till I do so, but > why go at rocket speed? It's a good way of activating > people to send comments but it can also be a good way > of making sure no one has enough time to comment. > I'm sure you don't want that. > > Hesham > > - -----Original Message----- > From: Pat R. Calhoun [ mailto:pcalhoun@bstormnetworks.com ] > Sent: Wednesday, February 13, 2002 5:07 PM > To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org > Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > > > - -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > The document has been available for some time, and as history has > shown, performing a last call on a document guarantees comments. If > folks believe that we can get the same amount of review without the > last call, that is an option as well. > Given our current milestones, I'd prefer to do both simultaneously. > PatC > - - -----Original Message----- > From: Hesham Soliman (ERA) [ mailto:hesham.soliman@era.ericsson.se ] > Sent: Wednesday, February 13, 2002 12:30 AM > To: James Kempf; seamoby@ietf.org > Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > > I haven't read the draft yet, so I can't > object to it being a WG item. But isn't > it too quick to have a concensus call > for a draft to become a WG draft and > WG last call at the same time? > Normally WG members are given two weeks > for each call. > Or is this a concensus call for the draft > to be a WG item and not a last call on > the draft? > > > Hesham > > -----Original Message----- > > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > > Sent: Monday, February 11, 2002 10:30 PM > > To: seamoby@ietf.org > > Subject: [Seamoby] Moving forward on CAR Discovery Requirements > > > > > > Folks, > > > > We would like to move the CAR requirements draft to WG status, > with > > Govind as the editor. The draft is not accessable through the > IETF > > drafts search engine for some reason, but can be found through > the > > following URL: > > > > > > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam > > oby-car-requ > > irements-00.txt > > > > so it is in the drafts directory. > > > > If there is no objection to this, then we would like to > > start WG Last > > Call for the CAR discovery > > requirements draft today and run until Feb. 25. This gives Govind > a > > couple days to get in a 01 > > draft with comments before the March 1 deadline. > > > > So, please send any comments you may have on the CAR discovery > > requirements draft to the list. > > Thanx. > > > > 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 > - -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use > < http://www.pgp.com > > iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR > 5flsrH10kBKWgaZF3mmeGs7j > =a4g2 > - -----END PGP SIGNATURE----- > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > > > iQA/AwUBPGqgbzN1fXKoxmisEQL9FwCcDIKnE37zWfLaOsU1tLqa1h3HQAAAnRb9 > NtkRQAk2gIZTvQ8uhixHhfAj > =Vj2J > -----END PGP SIGNATURE----- > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 13:16:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16028 for ; Wed, 13 Feb 2002 13:16:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19789; Wed, 13 Feb 2002 12:55:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19764 for ; Wed, 13 Feb 2002 12:55:16 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15475 for ; Wed, 13 Feb 2002 12:55:13 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DHv4Q08765 for ; Wed, 13 Feb 2002 11:57:04 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Feb 2002 11:55:10 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Feb 2002 11:55:00 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4B7.8C4E7DE9" Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 13 Feb 2002 12:54:56 -0500 Message-ID: Thread-Topic: [Seamoby] Moving forward on CAR Discovery Requirements Thread-Index: AcG0szFytqg3Lz6ZSrSwww7NrN1/dgAAdaLQ To: , , , X-OriginalArrivalTime: 13 Feb 2002 17:55:00.0473 (UTC) FILETIME=[8E6EDE90:01C1B4B7] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1B4B7.8C4E7DE9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 the requirements as a list have been out for quite a while now (actually = since SLC) and were put in draft form indeed 2 weeks ago. However, there has = already been=20 discussion on this issue on this list which has been incorporated into = the draft. So=20 we're not talking about new stars on the firmament here. =20 If the last call will bring up topics and issues that are considered to = be addressed in the=20 draft, this will be done, that's why we have a last call in the IETF. = And from my point of view,=20 two weeks are certainly enough to come up with comments to a 5 page = document, especially under the light that comments have already been provided to the list = before on this issue. =20 One comment regarding the decision whether or not the draft should be a = WG document.=20 If I understand the IETF procedures correctly, the IETF secretariat asks = the WG chairs if the submitted=20 document is to be considered as a WG document. Since we agreed (on the = list and in the discussions=20 during the past months) that this item has to be addressed, I don't see = the point why we have to explicitly=20 decide on the list whether this document is a WG document or not. It is = the only one addressing the requirements and is a result of the recent discussion on the list = regarding this issue. For me, these are the best criteria to be a WG document. =20 Regards, =20 =20 =20 Dirk =20 -----Original Message----- From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday,February 13,2002 12:22 PM To: 'Pat R. Calhoun'; Hesham Soliman (ERA); James Kempf; = seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements to be extra clear I have no objections to making it=20 a WG item. =20 Hesham -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Wednesday, February 13, 2002 6:21 PM To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements -----BEGIN PGP SIGNED MESSAGE-----=20 Hash: SHA1=20 You are correct. We want folks to have time to comment, so I=20 understand your relunctance. The goal, though, is to provide enough=20 time for the editor to send an update by the I-D deadline.=20 If others agree with Hesham, we can push back on the last call, and=20 just ask for comments.=20 PatC=20 - -----Original Message-----=20 From: Hesham Soliman (ERA) [ mailto:hesham.soliman@era.ericsson.se]=20 Sent: Wednesday, February 13, 2002 9:17 AM=20 To: Pat R. Calhoun; Hesham Soliman (ERA); James Kempf;=20 seamoby@ietf.org=20 Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements=20 Pat,=20 I'm not against soliciting for comments, I just think=20 a last call is very quick. How long has the=20 draft existed 2 weeks ? that's not a very long time.=20 I would like to send comments on the draft and I'm=20 not suggesting that the WG halts till I do so, but=20 why go at rocket speed? It's a good way of activating=20 people to send comments but it can also be a good way=20 of making sure no one has enough time to comment.=20 I'm sure you don't want that.=20 Hesham=20 - -----Original Message-----=20 From: Pat R. Calhoun [ mailto:pcalhoun@bstormnetworks.com]=20 Sent: Wednesday, February 13, 2002 5:07 PM=20 To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org=20 Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements=20 - -----BEGIN PGP SIGNED MESSAGE-----=20 Hash: SHA1=20 The document has been available for some time, and as history has=20 shown, performing a last call on a document guarantees comments. If=20 folks believe that we can get the same amount of review without the=20 last call, that is an option as well.=20 Given our current milestones, I'd prefer to do both simultaneously.=20 PatC=20 - - -----Original Message-----=20 From: Hesham Soliman (ERA) [ mailto:hesham.soliman@era.ericsson.se]=20 Sent: Wednesday, February 13, 2002 12:30 AM=20 To: James Kempf; seamoby@ietf.org=20 Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements=20 I haven't read the draft yet, so I can't=20 object to it being a WG item. But isn't=20 it too quick to have a concensus call=20 for a draft to become a WG draft and=20 WG last call at the same time?=20 Normally WG members are given two weeks=20 for each call.=20 Or is this a concensus call for the draft=20 to be a WG item and not a last call on=20 the draft?=20 Hesham=20 > -----Original Message-----=20 > From: James Kempf [ mailto:kempf@docomolabs-usa.com]=20 > Sent: Monday, February 11, 2002 10:30 PM=20 > To: seamoby@ietf.org=20 > Subject: [Seamoby] Moving forward on CAR Discovery Requirements=20 >=20 >=20 > Folks,=20 >=20 > We would like to move the CAR requirements draft to WG status,=20 with=20 > Govind as the editor. The draft is not accessable through the=20 IETF=20 > drafts search engine for some reason, but can be found through=20 the=20 > following URL:=20 >=20 >=20 > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam=20 > oby-car-requ=20 > irements-00.txt=20 >=20 > so it is in the drafts directory.=20 >=20 > If there is no objection to this, then we would like to=20 > start WG Last=20 > Call for the CAR discovery=20 > requirements draft today and run until Feb. 25. This gives Govind=20 a=20 > couple days to get in a 01=20 > draft with comments before the March 1 deadline.=20 >=20 > So, please send any comments you may have on the CAR discovery=20 > requirements draft to the list.=20 > Thanx.=20 >=20 > jak=20 >=20 >=20 >=20 > _______________________________________________=20 > Seamoby mailing list=20 > Seamoby@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/seamoby=20 >=20 _______________________________________________=20 Seamoby mailing list=20 Seamoby@ietf.org=20 https://www1.ietf.org/mailman/listinfo/seamoby=20 - -----BEGIN PGP SIGNATURE-----=20 Version: PGPfreeware 7.0.3 for non-commercial use=20 < http://www.pgp.com>=20 iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR=20 5flsrH10kBKWgaZF3mmeGs7j=20 =3Da4g2=20 - -----END PGP SIGNATURE-----=20 -----BEGIN PGP SIGNATURE-----=20 Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com>=20 iQA/AwUBPGqgbzN1fXKoxmisEQL9FwCcDIKnE37zWfLaOsU1tLqa1h3HQAAAnRb9=20 NtkRQAk2gIZTvQ8uhixHhfAj=20 =3DVj2J=20 -----END PGP SIGNATURE-----=20 ------_=_NextPart_001_01C1B4B7.8C4E7DE9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Moving forward on CAR Discovery = Requirements
Hi,
 
the=20 requirements as a list have been out for quite a while now (actually = since=20 SLC)
and=20 were put in draft form indeed 2 weeks ago. However, there = has=20 already been
discussion on this issue on this = list which has=20 been incorporated into the draft. So
we're=20 not talking about new stars on the firmament=20 here.
 
If the=20 last call will bring up topics and issues that are considered to be = addressed in=20 the
draft,=20 this will be done, that's why we have a last call in the IETF. And from = my point=20 of view,
two  weeks are certainly enough to = come up with=20 comments to a 5 page document, especially
under=20 the light that comments have already been provided to the list before on = this=20 issue.
 
One=20 comment regarding the decision whether or not the draft should be a WG = document.=20
If I=20 understand the IETF procedures correctly, the IETF = secretariat asks=20 the WG chairs if the submitted =
document is to be considered as a WG = document.=20 Since we agreed (on the list and in the discussions=20
during=20 the past months) that this item has to be = addressed, I=20 don't see the point why we have to explicitly=20
decide on the list whether this document = is a WG=20 document or not. It is the only one addressing the
requirements and is a result of the recent = discussion=20 on the list regarding this issue. For me, these
are=20 the best criteria to be a WG document.
 
Regards,
 
 
 
Dirk
 
 -----Original = Message-----
From:=20 ext Hesham Soliman (ERA) = [mailto:hesham.soliman@era.ericsson.se]
Sent:=20 Wednesday,February 13,2002 12:22 PM
To: 'Pat R. Calhoun'; = Hesham=20 Soliman (ERA); James Kempf; seamoby@ietf.org
Subject: RE: = [Seamoby]=20 Moving forward on CAR Discovery Requirements

to=20 be extra clear I have no objections to making it
a WG=20 item.
 
Hesham
-----Original Message-----
From: Pat R. Calhoun=20 [mailto:pcalhoun@bstormnetworks.com]
Sent: Wednesday, = February 13,=20 2002 6:21 PM
To: 'Hesham Soliman (ERA)'; James Kempf;=20 seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on = CAR=20 Discovery Requirements


-----BEGIN PGP SIGNED=20 MESSAGE-----
Hash: SHA1

You are correct. We want folks to have time to = comment, so=20 I
understand your relunctance. The goal, = though, is=20 to provide enough
time for the editor to = send an=20 update by the I-D deadline.

If others agree with Hesham, we can push back on = the last=20 call, and
just ask for comments. =

PatC
- -----Original=20 Message-----
From: Hesham Soliman (ERA) = [mailto:hesham.soliman@era.= ericsson.se]=20
Sent: Wednesday, February 13, 2002 9:17 = AM=20
To: Pat R. Calhoun; Hesham Soliman (ERA); James=20 Kempf;
seamoby@ietf.org
Subject: RE: [Seamoby] Moving forward on CAR Discovery=20 Requirements


Pat,

I'm not against soliciting for comments, I just = think=20
a last call is very quick. How long has = the=20
draft existed 2 weeks ? that's not a very = long time.=20

I would like to send comments on the draft and = I'm=20
not suggesting that the WG halts till I do so, = but=20
why go at rocket speed? It's a good way of = activating=20
people to send comments but it can also be = a good=20 way
of making sure no one has enough time = to=20 comment.
I'm sure you don't want = that.

Hesham

- -----Original Message-----
From:=20 Pat R. Calhoun [mailto:pcalhoun@bstormnetwork= s.com]=20
Sent: Wednesday, February 13, 2002 5:07 PM =
To: 'Hesham Soliman (ERA)'; James Kempf; = seamoby@ietf.org=20
Subject: RE: [Seamoby] Moving forward on CAR = Discovery=20 Requirements



- -----BEGIN PGP SIGNED MESSAGE----- =
Hash: SHA1
The document has been = available=20 for some time, and as history has
shown, = performing=20 a last call on a document guarantees comments. If
folks believe that we can get the same amount of review = without the=20
last call, that is an option as well.=20
Given our current milestones, I'd prefer = to do both=20 simultaneously.
PatC
- -=20 -----Original Message-----
From: Hesham = Soliman=20 (ERA) [mailto:hesham.soliman@era.= ericsson.se]=20
Sent: Wednesday, February 13, 2002 12:30 = AM=20
To: James Kempf; seamoby@ietf.org =
Subject: RE: [Seamoby] Moving forward on CAR Discovery = Requirements=20


I haven't read the draft yet, so I can't =
object to it being a WG item. But isn't
it=20 too quick to have a concensus call
for a = draft to=20 become a WG draft and
WG last call at the = same time?=20
Normally WG members are given two weeks=20
for each call.
Or is this a=20 concensus call for the draft
to be a WG = item and not=20 a last call on
the draft?


Hesham
  > = -----Original=20 Message-----
  > From: James Kempf = [mailto:kempf@docomolabs-usa.com<= /A>]=20
  > Sent: Monday, February 11, = 2002 10:30 PM=20
  > To: seamoby@ietf.org =
  > Subject: [Seamoby] Moving forward on CAR = Discovery=20 Requirements
  >
  >
  > Folks,=20
  >
  > We=20 would like to move the CAR requirements draft to WG status, =
with
  > Govind as the = editor. The=20 draft is not accessable through the
IETF=20
  > drafts search engine for some = reason,=20 but can be found through
the =
  > following URL:
  = >=20
  >
  > http://www.ietf.org/internet-drafts/draft-krishnamurthi-s= eam=20
  > oby-car-requ
  > irements-00.txt
  >=20
  > so it is in the drafts = directory.=20
  >
  > If=20 there is no objection to this, then we would like to =
  > start WG Last
  = > Call=20 for the CAR discovery
  > = requirements draft=20 today and run until Feb. 25. This gives Govind
a=20
  > couple days to get in a 01=20
  > draft with comments before the = March 1=20 deadline.
  >
 =20 > So, please send any comments you may have on the CAR discovery=20
  > requirements draft to the = list.=20
  > Thanx.
 =20 >
 =20 = >           &nb= sp;=20 jak
  >
  >=20
  >
  >=20 _______________________________________________
  > Seamoby mailing list
  >=20 Seamoby@ietf.org
  > https://www1.ietf.org/mailman/listinfo/seamoby=20
  >
_______________________________________________ =
Seamoby mailing list
Seamoby@ietf.org=20
https://www1.ietf.org/mailman/listinfo/seamoby=20
- -----BEGIN PGP SIGNATURE----- =
Version: PGPfreeware 7.0.3 for non-commercial use =
<http://www.pgp.com>
iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR= =20
5flsrH10kBKWgaZF3mmeGs7j
=3Da4g2
- -----END PGP = SIGNATURE-----=20

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>=20

iQA/AwUBPGqgbzN1fXKoxmisEQL9FwCcDIKnE37zWfLaOsU1tLqa1h3HQAAAnRb9= =20
NtkRQAk2gIZTvQ8uhixHhfAj
=3DVj2J
-----END PGP = SIGNATURE-----=20

------_=_NextPart_001_01C1B4B7.8C4E7DE9-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 13:21:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16118 for ; Wed, 13 Feb 2002 13:21:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20665; Wed, 13 Feb 2002 13:05:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20596 for ; Wed, 13 Feb 2002 13:05:07 -0500 (EST) Received: from hotmail.com (f268.law9.hotmail.com [64.4.8.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15711 for ; Wed, 13 Feb 2002 13:05:04 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Feb 2002 10:04:35 -0800 Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 13 Feb 2002 18:04:35 GMT X-Originating-IP: [63.78.179.4] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, pcalhoun@bstormnetworks.com, kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements Date: Wed, 13 Feb 2002 13:04:35 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Feb 2002 18:04:35.0813 (UTC) FILETIME=[E55CC950:01C1B4B8] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello all, First, I have no objections with pushing back the deadline for WG last call on the requirements draft if the WG so desires. Second, I wish to point out that even though the requirements in a draft version appeared just two weeks ago, the requirements themselves (except the last one) were posted on the mailing list after the last IETF. The draft version is just the same requirements + the logic behind having them as requirements while incorporating the comments in the mailing list. Regards, Govind. >Pat, > >I'm not against soliciting for comments, I just think >a last call is very quick. How long has the >draft existed 2 weeks ? that's not a very long time. > >I would like to send comments on the draft and I'm >not suggesting that the WG halts till I do so, but >why go at rocket speed? It's a good way of activating >people to send comments but it can also be a good way >of making sure no one has enough time to comment. >I'm sure you don't want that. > >Hesham > > >-----Original Message----- >From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com] >Sent: Wednesday, February 13, 2002 5:07 PM >To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org >Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > > > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >The document has been available for some time, and as history has >shown, performing a last call on a document guarantees comments. If >folks believe that we can get the same amount of review without the >last call, that is an option as well. > >Given our current milestones, I'd prefer to do both simultaneously. > >PatC > >- -----Original Message----- >From: Hesham Soliman (ERA) [ mailto:hesham.soliman@era.ericsson.se > ] >Sent: Wednesday, February 13, 2002 12:30 AM >To: James Kempf; seamoby@ietf.org >Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > >I haven't read the draft yet, so I can't >object to it being a WG item. But isn't >it too quick to have a concensus call >for a draft to become a WG draft and >WG last call at the same time? >Normally WG members are given two weeks >for each call. >Or is this a concensus call for the draft >to be a WG item and not a last call on >the draft? > > >Hesham > > > -----Original Message----- > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > ] > > Sent: Monday, February 11, 2002 10:30 PM > > To: seamoby@ietf.org > > Subject: [Seamoby] Moving forward on CAR Discovery Requirements > > > > > > Folks, > > > > We would like to move the CAR requirements draft to WG status, >with > > Govind as the editor. The draft is not accessable through the >IETF > > drafts search engine for some reason, but can be found through >the > > following URL: > > > > > > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam > > > oby-car-requ > > irements-00.txt > > > > so it is in the drafts directory. > > > > If there is no objection to this, then we would like to > > start WG Last > > Call for the CAR discovery > > requirements draft today and run until Feb. 25. This gives Govind >a > > couple days to get in a 01 > > draft with comments before the March 1 deadline. > > > > So, please send any comments you may have on the CAR discovery > > requirements draft to the list. > > Thanx. > > > > 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 > > >-----BEGIN PGP SIGNATURE----- >Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > > > >iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR >5flsrH10kBKWgaZF3mmeGs7j >=a4g2 >-----END PGP SIGNATURE----- > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 15:32:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19961 for ; Wed, 13 Feb 2002 15:32:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28166; Wed, 13 Feb 2002 15:03:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28138 for ; Wed, 13 Feb 2002 15:03:44 -0500 (EST) Received: from hotmail.com (f110.law7.hotmail.com [216.33.237.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19330 for ; Wed, 13 Feb 2002 15:03:40 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Feb 2002 12:03:08 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 13 Feb 2002 20:03:08 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward on CAR Discovery Requirements Date: Wed, 13 Feb 2002 20:03:08 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Feb 2002 20:03:08.0596 (UTC) FILETIME=[74E95740:01C1B4C9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi WG Chairs: Please let the WG know as to what is the final word on the document status: WG document or individual submission? Given the fact that requirements spec is needed; this draft is the only one so far listing out the requirements; and that the content has been discussed in one IETF meeting as well as on the mailing list, IMHO this draft meets the criteria for WG status. Let us at least make it a WG document before Minneapolis submission deadline. Hemant >From: "James Kempf" >To: "Hesham Soliman \(ERA\)" , "'Pat >R. Calhoun'" , >Subject: Re: [Seamoby] Moving forward on CAR Discovery Requirements >Date: Wed, 13 Feb 2002 09:59:50 -0800 > >OK. > >So let's get some comment on content so that Govind can submit an >update. > > jak > >----- Original Message ----- >From: "Hesham Soliman (ERA)" >To: "'Pat R. Calhoun'" ; "Hesham Soliman >(ERA)" ; "James Kempf" >; >Sent: Wednesday, February 13, 2002 9:22 AM >Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > > > to be extra clear I have no objections to making it > > a WG item. > > > > Hesham > > > > -----Original Message----- > > From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com] > > Sent: Wednesday, February 13, 2002 6:21 PM > > To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org > > Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > You are correct. We want folks to have time to comment, so I > > understand your relunctance. The goal, though, is to provide enough > > time for the editor to send an update by the I-D deadline. > > > > If others agree with Hesham, we can push back on the last call, and > > just ask for comments. > > > > PatC > > - -----Original Message----- > > From: Hesham Soliman (ERA) [ mailto:hesham.soliman@era.ericsson.se > ] > > Sent: Wednesday, February 13, 2002 9:17 AM > > To: Pat R. Calhoun; Hesham Soliman (ERA); James Kempf; > > seamoby@ietf.org > > Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > > > > > Pat, > > > > I'm not against soliciting for comments, I just think > > a last call is very quick. How long has the > > draft existed 2 weeks ? that's not a very long time. > > > > I would like to send comments on the draft and I'm > > not suggesting that the WG halts till I do so, but > > why go at rocket speed? It's a good way of activating > > people to send comments but it can also be a good way > > of making sure no one has enough time to comment. > > I'm sure you don't want that. > > > > Hesham > > > > - -----Original Message----- > > From: Pat R. Calhoun [ mailto:pcalhoun@bstormnetworks.com > ] > > Sent: Wednesday, February 13, 2002 5:07 PM > > To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org > > Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > > > > > > > - -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > The document has been available for some time, and as history has > > shown, performing a last call on a document guarantees comments. If > > folks believe that we can get the same amount of review without the > > last call, that is an option as well. > > Given our current milestones, I'd prefer to do both simultaneously. > > PatC > > - - -----Original Message----- > > From: Hesham Soliman (ERA) [ mailto:hesham.soliman@era.ericsson.se > ] > > Sent: Wednesday, February 13, 2002 12:30 AM > > To: James Kempf; seamoby@ietf.org > > Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > > > > > I haven't read the draft yet, so I can't > > object to it being a WG item. But isn't > > it too quick to have a concensus call > > for a draft to become a WG draft and > > WG last call at the same time? > > Normally WG members are given two weeks > > for each call. > > Or is this a concensus call for the draft > > to be a WG item and not a last call on > > the draft? > > > > > > Hesham > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > ] > > > Sent: Monday, February 11, 2002 10:30 PM > > > To: seamoby@ietf.org > > > Subject: [Seamoby] Moving forward on CAR Discovery Requirements > > > > > > > > > Folks, > > > > > > We would like to move the CAR requirements draft to WG status, > > with > > > Govind as the editor. The draft is not accessable through the > > IETF > > > drafts search engine for some reason, but can be found through > > the > > > following URL: > > > > > > > > > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam > > > > oby-car-requ > > > irements-00.txt > > > > > > so it is in the drafts directory. > > > > > > If there is no objection to this, then we would like to > > > start WG Last > > > Call for the CAR discovery > > > requirements draft today and run until Feb. 25. This gives Govind > > a > > > couple days to get in a 01 > > > draft with comments before the March 1 deadline. > > > > > > So, please send any comments you may have on the CAR discovery > > > requirements draft to the list. > > > Thanx. > > > > > > 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 > > > - -----BEGIN PGP SIGNATURE----- > > Version: PGPfreeware 7.0.3 for non-commercial use > > < http://www.pgp.com > > > iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR > > 5flsrH10kBKWgaZF3mmeGs7j > > =a4g2 > > - -----END PGP SIGNATURE----- > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > > > > > > iQA/AwUBPGqgbzN1fXKoxmisEQL9FwCcDIKnE37zWfLaOsU1tLqa1h3HQAAAnRb9 > > NtkRQAk2gIZTvQ8uhixHhfAj > > =Vj2J > > -----END PGP SIGNATURE----- > > > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 15:34:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20023 for ; Wed, 13 Feb 2002 15:34:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28964; Wed, 13 Feb 2002 15:20:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28930 for ; Wed, 13 Feb 2002 15:20:31 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19725 for ; Wed, 13 Feb 2002 15:20:27 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1DKJpe29494; Wed, 13 Feb 2002 12:19:52 -0800 (PST) Message-ID: <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> Subject: Re: [Seamoby] Moving forward with paging Date: Wed, 13 Feb 2002 12:18:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Behcet, > Only if we combine paging with MIP then your analysis applies. > Unfortunately we won't have a MIP independent paging protocol. > Originally this was what I had argued for if you remember the > discussions we had last March. > Then the requirement 4.7 will be violated. I don't see how that conclusion follows from what I sent in the original message. My proposal was: Mobility Independent Paging + Mobility Protocol Support = Paging for Dormant Mode Mobility What comes under the first term above is: - Actual dormant mode alerting - Advertising of IP paging areas - Interface with L2 paging - Mobility protocol independent hooks for supporting dormant mode mobility. What comes under the second term above is: - Enhancements to the mobility protocol to allow dormant mode registration of node movement. The first term abides by requirement 4.7. The second doesn't, but I don't think anybody thought that paging would not exert some requirements on the mobility protocol. > If we are talking about mobility protocol independent IP Paging > protocol as there are two IPs it makes two right there. I believe that > MIP independent IP Paging protocols for v4 and v6 have to be defined > because there will be demand and interest for cases like Simple IP > service of CDMA2000, etc. IPv4 and IPv6 being fairly diferent means we'd > better define them in separate IDs, although one approach could be to > concentrate on one first (maybe v6 version). > Then the requirement 4.8 will be violated. > I am even more puzzled by this conclusion. What is Simple IP? What does that and the fact that IPv4 and IPv6 are different have to do with supporting existing mobility protocols, which is what requirement 4.8 is about? > This is the problem with RFC 3154. > If RFC3154bis could state 4.7 or 4.8 as the requirements, then this > would pave the way to the development of possibly 4 different IDs. > What do you think? > I'd rather get agreement on the technical point of whether it makes sense to partition paging functionality as I've outlined above before we get into counting how many drafts we'll have. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 16:29:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21878 for ; Wed, 13 Feb 2002 16:29:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02186; Wed, 13 Feb 2002 16:18:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02159 for ; Wed, 13 Feb 2002 16:18:27 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20971 for ; Wed, 13 Feb 2002 16:18:24 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1DLHue27241 for ; Wed, 13 Feb 2002 15:17:56 -0600 (CST) Message-ID: <3C6AD7FD.5050705@alcatel.com> Date: Wed, 13 Feb 2002 15:17:49 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------050701040905080400070300" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------050701040905080400070300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jim, Here is what 4.7 of RFC3154 says: 4.7. Independence of Mobility Protocol Recognizing that IETF may support multiple mobility protocols in the future and that paging may be of value to hosts that do not support a mobility protocol, the IP paging protocol MUST be designed so there is no dependence on the underlying mobility protocol or on any mobility protocol at all. The protocol SHOULD specify and provide support for a mobility protocol, if the Host supports one. The Hosts of Simple IP service of CDMA2000 or any Host of UMTS DO NOT SUPPORT a mobility protocol (developed by IETF). Hope this clarifies. James Kempf wrote: >Behcet, > >> Only if we combine paging with MIP then your analysis applies. >>Unfortunately we won't have a MIP independent paging protocol. >>Originally this was what I had argued for if you remember the >>discussions we had last March. >>Then the requirement 4.7 will be violated. >> > >I don't see how that conclusion follows from what I sent in the >original message. My proposal was: > > Mobility Independent Paging + Mobility Protocol Support = Paging > for Dormant Mode > Mobility > >What comes under the first term above is: > > - Actual dormant mode alerting > - Advertising of IP paging areas > - Interface with L2 paging > - Mobility protocol independent hooks for > supporting dormant mode mobility. > >What comes under the second term above is: > > - Enhancements to the mobility protocol to > allow dormant mode registration of node > movement. > >The first term abides by requirement 4.7. The second >doesn't, but I don't think anybody thought that >paging would not exert some requirements on >the mobility protocol. > >> If we are talking about mobility protocol independent IP Paging >>protocol as there are two IPs it makes two right there. I believe that >>MIP independent IP Paging protocols for v4 and v6 have to be defined >>because there will be demand and interest for cases like Simple IP >>service of CDMA2000, etc. IPv4 and IPv6 being fairly diferent means >> >we'd > >>better define them in separate IDs, although one approach could be to >>concentrate on one first (maybe v6 version). >>Then the requirement 4.8 will be violated. >> > >I am even more puzzled by this conclusion. What is Simple IP? >What does that and the fact that IPv4 and IPv6 are different have to >do with supporting existing mobility protocols, which is what >requirement 4.8 is about? > >>This is the problem with RFC 3154. >> If RFC3154bis could state 4.7 or 4.8 as the requirements, then this >>would pave the way to the development of possibly 4 different IDs. >> What do you think? >> > >I'd rather get agreement on the technical point of whether it makes >sense >to partition paging functionality as I've outlined above before we get >into counting how many drafts we'll have. > > jak > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > -- Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S 026 1000 Coit Road PB7 Plano, TX 75075 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 477 2794 Fax: (972) 519 2460 --------------050701040905080400070300 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jim,
  Here is what 4.7 of RFC3154 says:
4.7. Independence of Mobility Protocol

   Recognizing that IETF may support multiple mobility protocols in the
   future and that paging may be of value to hosts that do not support a
   mobility protocol, the IP paging protocol MUST be designed so there
   is no dependence on the underlying mobility protocol or on any
   mobility protocol at all.  The protocol SHOULD specify and provide
   support for a mobility protocol, if the Host supports one.


The Hosts of Simple IP service of CDMA2000 or any Host of UMTS
DO NOT SUPPORT a mobility protocol (developed by IETF).

Hope this clarifies.


James Kempf wrote:
Behcet,

 Only if we combine paging with MIP then your analysis applies.
Unfortunately we won't have a MIP independent paging protocol.
Originally this was what I had argued for if you remember the
discussions we had last March.
Then the requirement 4.7 will be violated.

I don't see how that conclusion follows from what I sent in the
original message. My proposal was:

   Mobility Independent Paging  + Mobility Protocol Support  = Paging
                                                       for Dormant Mode
                                                           Mobility

What comes under the first term above is:

    - Actual dormant mode alerting
    - Advertising of IP paging areas
    - Interface with L2 paging
    - Mobility protocol independent hooks for
       supporting dormant mode mobility.

What comes under the second term above is:

    - Enhancements to the mobility protocol to
       allow dormant mode registration of node
       movement.

The first term abides by requirement 4.7. The second
doesn't, but I don't think anybody thought that
paging would not exert some requirements on
the mobility protocol.

  If we are talking about mobility protocol independent IP Paging
protocol as there are two IPs it makes two right there. I believe that
MIP independent IP Paging protocols for v4 and v6 have to be defined
because there will be demand and interest for cases like Simple IP
service of CDMA2000, etc. IPv4 and IPv6 being fairly diferent means
we'd
better define them in separate IDs, although one approach could be to
concentrate on one first (maybe v6 version).
Then the requirement 4.8 will be violated.


I am even more puzzled by this conclusion. What is Simple IP?
What does that and the fact that IPv4 and IPv6 are different have to
do with supporting existing mobility protocols, which is what
requirement 4.8 is about?

This is the problem with RFC 3154.
  If RFC3154bis could state 4.7 or 4.8 as the requirements, then this
would pave the way to the development of possibly 4 different IDs.
  What do you think?


I'd rather get agreement on the technical point of whether it makes
sense
to partition paging functionality as I've outlined above before we get
into counting how many drafts we'll have.

            jak



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

-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460

--------------050701040905080400070300-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 16:44:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22186 for ; Wed, 13 Feb 2002 16:44:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02446; Wed, 13 Feb 2002 16:24:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02420 for ; Wed, 13 Feb 2002 16:24:15 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21527 for ; Wed, 13 Feb 2002 16:24:12 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7RZ5D>; Wed, 13 Feb 2002 13:23:45 -0800 Message-ID: From: "Pat R. Calhoun" To: "'James Kempf'" , Behcet Sarikaya , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward with paging Date: Wed, 13 Feb 2002 13:23:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4D4.B7292D00" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B4D4.B7292D00 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simple IP is a CDMA2000 service. It requires a nailed up PPP connection to gain IP access to the network, and doesn't provide roaming capabilities. Do we need to care about stationary mobiles (as viewed by the network)? PatC - -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, February 13, 2002 12:18 PM To: Behcet Sarikaya; seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging [...] > If we are talking about mobility protocol independent IP Paging > protocol as there are two IPs it makes two right there. I believe > that MIP independent IP Paging protocols for v4 and v6 have to be > defined because there will be demand and interest for cases like > Simple IP service of CDMA2000, etc. IPv4 and IPv6 being fairly > diferent means we'd > better define them in separate IDs, although one approach could be > to concentrate on one first (maybe v6 version). Then the > requirement 4.8 will be violated. > I am even more puzzled by this conclusion. What is Simple IP? What does that and the fact that IPv4 and IPv6 are different have to do with supporting existing mobility protocols, which is what requirement 4.8 is about? -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGrZYDN1fXKoxmisEQI+OwCg98ix/WdyHEtwjBiX83p2rb/i+/UAn2DJ FfBx61qsGg/QgqJkXxlezgFt =HWi/ -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B4D4.B7292D00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simple IP is a CDMA2000 service. It requires a nailed = up PPP
connection to gain IP access to the network, and = doesn't provide
roaming capabilities.

Do we need to care about stationary mobiles (as = viewed by the
network)?

PatC

- -----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
Sent: Wednesday, February 13, 2002 12:18 PM
To: Behcet Sarikaya; seamoby@ietf.org
Subject: Re: [Seamoby] Moving forward with = paging


[...]
>   If we are talking about mobility = protocol independent IP Paging
> protocol as there are two IPs it makes two = right there. I believe
> that  MIP independent IP Paging protocols = for v4 and v6 have to be
> defined  because there will be demand and = interest for cases like
> Simple IP  service of CDMA2000, etc. IPv4 = and IPv6 being fairly
> diferent means
we'd
> better define them in separate IDs, although = one approach could be
> to  concentrate on one first (maybe v6 = version). Then the
> requirement 4.8  will be violated.
>

I am even more puzzled by this conclusion. What is = Simple IP? What
does that and the fact that IPv4 and IPv6 are = different have to do
with supporting existing mobility protocols, which = is what
requirement 4.8 is about?

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPGrZYDN1fXKoxmisEQI+OwCg98ix/WdyHEtwjBiX83p2rb/i+/UAn2D= J
FfBx61qsGg/QgqJkXxlezgFt
=3DHWi/
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B4D4.B7292D00-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 16:44:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22198 for ; Wed, 13 Feb 2002 16:44:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02562; Wed, 13 Feb 2002 16:25:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02496 for ; Wed, 13 Feb 2002 16:25:47 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21733 for ; Wed, 13 Feb 2002 16:25:44 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7RZ5G>; Wed, 13 Feb 2002 13:25:17 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements Date: Wed, 13 Feb 2002 13:25:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4D4.EE0B7800" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B4D4.EE0B7800 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As we discussed at the IETF meeting (and as shown in the published minutes), the document is a WG document. PatC - -----Original Message----- From: Hemant Chaskar [mailto:hchaskar@hotmail.com] Sent: Wednesday, February 13, 2002 12:03 PM To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward on CAR Discovery Requirements Hi WG Chairs: Please let the WG know as to what is the final word on the document status: WG document or individual submission? Given the fact that requirements spec is needed; this draft is the only one so far listing out the requirements; and that the content has been discussed in one IETF meeting as well as on the mailing list, IMHO this draft meets the criteria for WG status. Let us at least make it a WG document before Minneapolis submission deadline. Hemant >From: "James Kempf" >To: "Hesham Soliman \(ERA\)" , > "'Pat R. Calhoun'" , > >Subject: Re: [Seamoby] Moving forward on CAR Discovery Requirements >Date: Wed, 13 Feb 2002 09:59:50 -0800 > >OK. > >So let's get some comment on content so that Govind can submit an >update. > > jak > >----- Original Message ----- >From: "Hesham Soliman (ERA)" >To: "'Pat R. Calhoun'" ; "Hesham >Soliman (ERA)" ; "James Kempf" >; >Sent: Wednesday, February 13, 2002 9:22 AM >Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements > > > > to be extra clear I have no objections to making it > > a WG item. > > > > Hesham > > > > -----Original Message----- > > From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com] > > Sent: Wednesday, February 13, 2002 6:21 PM > > To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org > > Subject: RE: [Seamoby] Moving forward on CAR Discovery > > Requirements > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > You are correct. We want folks to have time to comment, so I > > understand your relunctance. The goal, though, is to provide > > enough time for the editor to send an update by the I-D > > deadline. > > > > If others agree with Hesham, we can push back on the last call, > > and just ask for comments. > > > > PatC > > - -----Original Message----- > > From: Hesham Soliman (ERA) [ > > mailto:hesham.soliman@era.ericsson.se > ] > > Sent: Wednesday, February 13, 2002 9:17 AM > > To: Pat R. Calhoun; Hesham Soliman (ERA); James Kempf; > > seamoby@ietf.org > > Subject: RE: [Seamoby] Moving forward on CAR Discovery > > Requirements > > > > > > Pat, > > > > I'm not against soliciting for comments, I just think > > a last call is very quick. How long has the > > draft existed 2 weeks ? that's not a very long time. > > > > I would like to send comments on the draft and I'm > > not suggesting that the WG halts till I do so, but > > why go at rocket speed? It's a good way of activating people to > > send comments but it can also be a good way of making sure no > > one has enough time to comment. I'm sure you don't want that. > > > > Hesham > > > > - -----Original Message----- > > From: Pat R. Calhoun [ mailto:pcalhoun@bstormnetworks.com > ] > > Sent: Wednesday, February 13, 2002 5:07 PM > > To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org > > Subject: RE: [Seamoby] Moving forward on CAR Discovery > > Requirements > > > > > > > > - -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > The document has been available for some time, and as history has > > shown, performing a last call on a document guarantees comments. > > If folks believe that we can get the same amount of review > > without the last call, that is an option as well. Given our > > current milestones, I'd prefer to do both simultaneously. PatC > > - - -----Original Message----- > > From: Hesham Soliman (ERA) [ > > mailto:hesham.soliman@era.ericsson.se > ] > > Sent: Wednesday, February 13, 2002 12:30 AM > > To: James Kempf; seamoby@ietf.org > > Subject: RE: [Seamoby] Moving forward on CAR Discovery > > Requirements > > > > > > I haven't read the draft yet, so I can't > > object to it being a WG item. But isn't > > it too quick to have a concensus call > > for a draft to become a WG draft and > > WG last call at the same time? > > Normally WG members are given two weeks > > for each call. > > Or is this a concensus call for the draft > > to be a WG item and not a last call on > > the draft? > > > > > > Hesham > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > ] > > > Sent: Monday, February 11, 2002 10:30 PM > > > To: seamoby@ietf.org > > > Subject: [Seamoby] Moving forward on CAR Discovery > > Requirements > > > > > > > > > Folks, > > > > > > We would like to move the CAR requirements draft to WG > > status, with > > > Govind as the editor. The draft is not accessable through the > > IETF > > > drafts search engine for some reason, but can be found > > through the > > > following URL: > > > > > > > > > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam > > > > oby-car-requ > > > irements-00.txt > > > > > > so it is in the drafts directory. > > > > > > If there is no objection to this, then we would like to > > > start WG Last > > > Call for the CAR discovery > > > requirements draft today and run until Feb. 25. This gives > > Govind a > > > couple days to get in a 01 > > > draft with comments before the March 1 deadline. > > > > > > So, please send any comments you may have on the CAR > > discovery > > > requirements draft to the list. > > > Thanx. > > > > > > 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 > > > - -----BEGIN PGP SIGNATURE----- > > Version: PGPfreeware 7.0.3 for non-commercial use > > < http://www.pgp.com > > > iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR > > 5flsrH10kBKWgaZF3mmeGs7j > > =a4g2 > > - -----END PGP SIGNATURE----- > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGPfreeware 7.0.3 for non-commercial use < > > http://www.pgp.com > > > > > > iQA/AwUBPGqgbzN1fXKoxmisEQL9FwCcDIKnE37zWfLaOsU1tLqa1h3HQAAAnRb9 > > NtkRQAk2gIZTvQ8uhixHhfAj > > =Vj2J > > -----END PGP SIGNATURE----- > > > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGrZvDN1fXKoxmisEQLbxgCeOg+logAnnXoQf3yzzue6/8XvvS8AoKEk lVGoSViDbcUGQJDArnaq+Z2v =I10V -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B4D4.EE0B7800 Content-Type: text/html RE: [Seamoby] Moving forward on CAR Discovery Requirements

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As we discussed at the IETF meeting (and as shown in the published
minutes), the document is a WG document.

PatC

- -----Original Message-----
From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
Sent: Wednesday, February 13, 2002 12:03 PM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Moving forward on CAR Discovery Requirements


Hi WG Chairs:

Please let the WG know as to what is the final word on the document
status:
WG document or individual submission?

Given the fact that requirements spec is needed; this draft is the
only one
so far listing out the requirements; and that the content has been
discussed
in one IETF meeting as well as on the mailing list, IMHO this draft
meets
the criteria for WG status. Let us at least make it a WG document
before
Minneapolis submission deadline.

Hemant




>From: "James Kempf" <kempf@docomolabs-usa.com>
>To: "Hesham Soliman \(ERA\)" <hesham.soliman@era.ericsson.se>,     
> "'Pat  R. Calhoun'" <pcalhoun@bstormnetworks.com>,
><seamoby@ietf.org>
>Subject: Re: [Seamoby] Moving forward on CAR Discovery Requirements
>Date: Wed, 13 Feb 2002 09:59:50 -0800
>
>OK.
>
>So let's get some comment on content so that Govind can submit an
>update.
>
>             jak
>
>----- Original Message -----
>From: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>
>To: "'Pat R. Calhoun'" <pcalhoun@bstormnetworks.com>; "Hesham
>Soliman  (ERA)" <hesham.soliman@era.ericsson.se>; "James Kempf"
><kempf@docomolabs-usa.com>; <seamoby@ietf.org>
>Sent: Wednesday, February 13, 2002 9:22 AM
>Subject: RE: [Seamoby] Moving forward on CAR Discovery Requirements
>
>
> > to be extra clear I have no objections to making it
> > a WG item.
> >
> > Hesham
> >
> > -----Original Message-----
> > From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
> > Sent: Wednesday, February 13, 2002 6:21 PM
> > To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org
> > Subject: RE: [Seamoby] Moving forward on CAR Discovery
> > Requirements
> >
> >
> >
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > You are correct. We want folks to have time to comment, so I
> > understand your relunctance. The goal, though, is to provide
> > enough  time for the editor to send an update by the I-D
> > deadline.
> >
> > If others agree with Hesham, we can push back on the last call,
> > and  just ask for comments.
> >
> > PatC
> > - -----Original Message-----
> > From: Hesham Soliman (ERA) [
> > mailto:hesham.soliman@era.ericsson.se
><mailto:hesham.soliman@era.ericsson.se> ]
> > Sent: Wednesday, February 13, 2002 9:17 AM
> > To: Pat R. Calhoun; Hesham Soliman (ERA); James Kempf;
> > seamoby@ietf.org
> > Subject: RE: [Seamoby] Moving forward on CAR Discovery
> > Requirements
> >
> >
> > Pat,
> >
> > I'm not against soliciting for comments, I just think
> > a last call is very quick. How long has the
> > draft existed 2 weeks ? that's not a very long time.
> >
> > I would like to send comments on the draft and I'm
> > not suggesting that the WG halts till I do so, but
> > why go at rocket speed? It's a good way of activating people to
> > send  comments but it can also be a good way of making sure no
> > one has  enough time to comment. I'm sure you don't want that.
> >
> > Hesham
> >
> > - -----Original Message-----
> > From: Pat R. Calhoun [ mailto:pcalhoun@bstormnetworks.com
><mailto:pcalhoun@bstormnetworks.com> ]
> > Sent: Wednesday, February 13, 2002 5:07 PM
> > To: 'Hesham Soliman (ERA)'; James Kempf; seamoby@ietf.org
> > Subject: RE: [Seamoby] Moving forward on CAR Discovery
> > Requirements
> >
> >
> >
> > - -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > The document has been available for some time, and as history has
> >  shown, performing a last call on a document guarantees comments.
> > If  folks believe that we can get the same amount of review
> > without the  last call, that is an option as well. Given our
> > current milestones,  I'd prefer to do both simultaneously. PatC
> > - - -----Original Message-----
> > From: Hesham Soliman (ERA) [
> > mailto:hesham.soliman@era.ericsson.se
><mailto:hesham.soliman@era.ericsson.se> ]
> > Sent: Wednesday, February 13, 2002 12:30 AM
> > To: James Kempf; seamoby@ietf.org
> > Subject: RE: [Seamoby] Moving forward on CAR Discovery
> > Requirements
> >
> >
> > I haven't read the draft yet, so I can't
> > object to it being a WG item. But isn't
> > it too quick to have a concensus call
> > for a draft to become a WG draft and
> > WG last call at the same time?
> > Normally WG members are given two weeks
> > for each call.
> > Or is this a concensus call for the draft
> > to be a WG item and not a last call on
> > the draft?
> >
> >
> > Hesham
> >   > -----Original Message-----
> >   > From: James Kempf [ mailto:kempf@docomolabs-usa.com
><mailto:kempf@docomolabs-usa.com> ]
> >   > Sent: Monday, February 11, 2002 10:30 PM
> >   > To: seamoby@ietf.org
> >   > Subject: [Seamoby] Moving forward on CAR Discovery
> > Requirements
> >   >
> >   >
> >   > Folks,
> >   >
> >   > We would like to move the CAR requirements draft to WG
> > status,  with
> >   > Govind as the editor. The draft is not accessable through the
> >  IETF
> >   > drafts search engine for some reason, but can be found
> > through  the
> >   > following URL:
> >   >
> >   >
> >   > http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam
><http://www.ietf.org/internet-drafts/draft-krishnamurthi-seam>
> >   > oby-car-requ
> >   > irements-00.txt
> >   >
> >   > so it is in the drafts directory.
> >   >
> >   > If there is no objection to this, then we would like to
> >   > start WG Last
> >   > Call for the CAR discovery
> >   > requirements draft today and run until Feb. 25. This gives
> > Govind a
> >   > couple days to get in a 01
> >   > draft with comments before the March 1 deadline.
> >   >
> >   > So, please send any comments you may have on the CAR
> > discovery
> >   > requirements draft to the list.
> >   > Thanx.
> >   >
> >   >             jak
> >   >
> >   >
> >   >
> >   > _______________________________________________
> >   > Seamoby mailing list
> >   > Seamoby@ietf.org
> >   > https://www1.ietf.org/mailman/listinfo/seamoby
><https://www1.ietf.org/mailman/listinfo/seamoby>
> >   >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby
><https://www1.ietf.org/mailman/listinfo/seamoby>
> > - -----BEGIN PGP SIGNATURE-----
> > Version: PGPfreeware 7.0.3 for non-commercial use
> > < http://www.pgp.com <http://www.pgp.com> >
> > iQA/AwUBPGqPIDN1fXKoxmisEQKN0gCgy3xY2U9hL1PtFktlAjzzppxyKO4AoPhR
> > 5flsrH10kBKWgaZF3mmeGs7j
> > =a4g2
> > - -----END PGP SIGNATURE-----
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGPfreeware 7.0.3 for non-commercial use <
> > http://www.pgp.com
><http://www.pgp.com> >
> >
> > iQA/AwUBPGqgbzN1fXKoxmisEQL9FwCcDIKnE37zWfLaOsU1tLqa1h3HQAAAnRb9
> > NtkRQAk2gIZTvQ8uhixHhfAj
> > =Vj2J
> > -----END PGP SIGNATURE-----
> >
> >
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx


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

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPGrZvDN1fXKoxmisEQLbxgCeOg+logAnnXoQf3yzzue6/8XvvS8AoKEk
lVGoSViDbcUGQJDArnaq+Z2v
=I10V
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B4D4.EE0B7800-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 17:11:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22666 for ; Wed, 13 Feb 2002 17:11:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03982; Wed, 13 Feb 2002 16:55:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03925 for ; Wed, 13 Feb 2002 16:55:13 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22357 for ; Wed, 13 Feb 2002 16:55:10 -0500 (EST) Received: from T23KEMPF (dhcp169.docomolabs-usa.com [172.21.96.169]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1DLsfe03528; Wed, 13 Feb 2002 13:54:41 -0800 (PST) Message-ID: <01ba01c1b4d8$d0b0fc40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Pat R. Calhoun" , "Behcet Sarikaya" , References: Subject: Re: [Seamoby] Moving forward with paging Date: Wed, 13 Feb 2002 13:48:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Simple IP is a CDMA2000 service. It requires a nailed up PPP > connection to gain IP access to the network, and doesn't provide > roaming capabilities. > So this sounds like an L2 issue to me, right? > Do we need to care about stationary mobiles (as viewed by the > network)? > There is some interest in supporting paging for nonmobile hosts. I think this would be easy to support with the architecture I outlined, since the host essentially has no mobility protocol, is not moving, and so any mobility hooks simply don't get used. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 17:12:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22694 for ; Wed, 13 Feb 2002 17:12:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03959; Wed, 13 Feb 2002 16:55:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03917 for ; Wed, 13 Feb 2002 16:55:13 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22355 for ; Wed, 13 Feb 2002 16:55:10 -0500 (EST) Received: from T23KEMPF (dhcp169.docomolabs-usa.com [172.21.96.169]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1DLsfe03531; Wed, 13 Feb 2002 13:54:41 -0800 (PST) Message-ID: <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> Subject: Re: [Seamoby] Moving forward with paging Date: Wed, 13 Feb 2002 13:52:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Behcet, > Here is what 4.7 of RFC3154 says: > 4.7. Independence of Mobility Protocol > > Recognizing that IETF may support multiple mobility protocols in the > future and that paging may be of value to hosts that do not support a > mobility protocol, the IP paging protocol MUST be designed so there > is no dependence on the underlying mobility protocol or on any > mobility protocol at all. The protocol SHOULD specify and provide > support for a mobility protocol, if the Host supports one. > > > The Hosts of Simple IP service of CDMA2000 or any Host of UMTS > DO NOT SUPPORT a mobility protocol (developed by IETF). > > Hope this clarifies. > Now I am even more confused. Your orginal comment was that Simple IP was a counterexample to Requirement 4.8: > >> If we are talking about mobility protocol independent IP Paging > >>protocol as there are two IPs it makes two right there. I believe that > >>MIP independent IP Paging protocols for v4 and v6 have to be defined > >>because there will be demand and interest for cases like Simple IP > >>service of CDMA2000, etc. IPv4 and IPv6 being fairly diferent means > >>we'd better define them in separate IDs, although one approach could be to > >>concentrate on one first (maybe v6 version). > >>Then the requirement 4.8 will be violated. Now you are saying it is a counterexample to Requirement 4.7. Which one do you mean? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 17:51:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23434 for ; Wed, 13 Feb 2002 17:51:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05657; Wed, 13 Feb 2002 17:22:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05631 for ; Wed, 13 Feb 2002 17:22:00 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22867 for ; Wed, 13 Feb 2002 17:21:57 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1DMLUv15765 for ; Wed, 13 Feb 2002 16:21:30 -0600 (CST) Message-ID: <3C6AE6E3.1050303@alcatel.com> Date: Wed, 13 Feb 2002 16:21:23 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Jim, let me quote 4.7 and 4.8 below: 4.7. Independence of Mobility Protocol Recognizing that IETF may support multiple mobility protocols in the future and that paging may be of value to hosts that do not support a mobility protocol, the IP paging protocol MUST be designed so there is no dependence on the underlying mobility protocol or on any mobility protocol at all. The protocol SHOULD specify and provide support for a mobility protocol, if the Host supports one. 4.8. Support for Existing Mobility Protocols The IP paging protocol MUST specify the binding to the existing IP mobility protocols, namely mobile IPv4 [2] and mobile IPv6 [3]. The IP paging protocol SHOULD make use of existing registration support. -------- Let's forget Simple IP. If we take 4.8 only then we can develop IP paging protocols for v4 and v6 as extensions to mipv4 and mipv6 (as had been done on many drafts). Then the problem is that requirement 4.7 is violated. So these protocols are not acceptable as far as RFC 3154 is concerned. If we take 4.7 only then we can develop IP paging protocols for v4 and v6 independent of mipv4/mipv6 (as had been done on one draft). Then the problem is that requirement 4.8 is violated. So these protocols are not acceptable as far as RFC 3154 is concerned. Trying to satisfy both 4.7 and 4.8 in one draft is like defining 4 protocols in one draft and each protocol considered in isolation would violate either 4.7 or 4.8. This is wrong, the implementations of such drafts can not be interoperability tested. This was my main point, I had been writing so many mails to explain it over and over again. SOLUTION is 4.7 or 4.8 should be the requirement not 4.7 and 4.8. Regards, -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 13 21:35:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26928 for ; Wed, 13 Feb 2002 21:35:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15769; Wed, 13 Feb 2002 21:16:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15732 for ; Wed, 13 Feb 2002 21:16:22 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25847 for ; Wed, 13 Feb 2002 21:16:18 -0500 (EST) Received: from T23KEMPF (dhcp140.docomolabs-usa.com [172.21.96.140]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1E2Fne13205; Wed, 13 Feb 2002 18:15:49 -0800 (PST) Message-ID: <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> Subject: Re: [Seamoby] Moving forward with paging Date: Wed, 13 Feb 2002 18:07:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Let's forget Simple IP. > If we take 4.8 only then we can develop IP paging protocols for v4 > and v6 as extensions to mipv4 and mipv6 (as had been done on many drafts). > Then the problem is that requirement 4.7 is violated. So these > protocols are not acceptable as far as RFC 3154 is concerned. > If we take 4.7 only then we can develop IP paging protocols for v4 > and v6 independent of mipv4/mipv6 (as had been done on one draft). > Then the problem is that requirement 4.8 is violated. So these > protocols are not acceptable as far as RFC 3154 is concerned. > Trying to satisfy both 4.7 and 4.8 in one draft is like defining 4 > protocols in one draft and each protocol considered in isolation would > violate either 4.7 or 4.8. This is wrong, the implementations of such > drafts can not be interoperability tested. > This was my main point, I had been writing so many mails to explain it > over and over again. > SOLUTION is > 4.7 or 4.8 should be the requirement > not 4.7 and 4.8. > OK, now I think I understand. I think it is possible to support both requirements by partitioning the paging protocol as I described in the original message. The core protocol is independent of mobility protocol with hooks for particular mobility management protocols to handle dormant mode mobility. How the mobility management protocols handle dormant mode mobility is specified separately. Does this make sense? W.r.t. IPv4/IPv6, there are issues here with features of one not available in the other. The requirements don't say anything about this, so I think we need to open this up for discussion. Would the working group like to allow differences in the protocol design for IPv4/IPv6 or should we try for a protocol design that spans both (note that I'm not talking about trival differences like address formats)? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 11:25:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26048 for ; Thu, 14 Feb 2002 11:25:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07228; Thu, 14 Feb 2002 11:10:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07193 for ; Thu, 14 Feb 2002 11:10:18 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25613 for ; Thu, 14 Feb 2002 11:10:15 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EG9kY04582; Thu, 14 Feb 2002 11:09:46 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EG9ia13662; Thu, 14 Feb 2002 11:09:44 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J3PD46F>; Thu, 14 Feb 2002 11:09:43 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4858@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'George Tsirtsis'" , "'James Kempf'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: Removing CT Requirements Date: Thu, 14 Feb 2002 11:09:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B572.038AECE0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B572.038AECE0 Content-Type: text/plain; charset="iso-8859-1" And what if the link is wireless? -----Original Message----- From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] Sent: January 7, 2002 05:41 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; George Tsirtsis Cc: seamoby@ietf.org Subject: [Seamoby] RE: Removing CT Requirements yes I could say this is ambiguous and unnecessary since I can clearly claim that error rates provided by almost all links today are good enough.... George -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, January 04, 2002 6:04 PM To: 'James Kempf'; George Tsirtsis Cc: seamoby@ietf.org Subject: RE: Removing CT Requirements I would like to know from George if he believes 5.5.2 is irrelevant, or simply ambiguously worded. I believe (and I suspect that George may concur) that error protection for the context is required (consider the possible impact of attempting to install or use erroneous context at an AR), and that it is important to clearly identify that requirement (particularly given that there are no transport requirements in the id). Gary > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: January 4, 2002 12:31 > To: Kenward, Gary [WDLN2:AN10:EXCH]; George Tsirtsis > Cc: seamoby@ietf.org > Subject: Removing CT Requirements > > > It seems to me like George is making a specific request as part of the > WG last call that the following > requirements be removed from the document: > > 4.12 The context information to be transferred MUST be > available at the > AR performing the transfer, prior to the initiation of a > given phase of > the context transfer. > 4.13 The context transfer solution WILL NOT verify the context > information prior to transfer. > 4.15 The context transfer solution MAY include methods for > interworking > with non-IETF mobility solutions. > 5.5.2 A context update MUST preserve the integrity, and thus the > meaning, of the context at each receiving AR." > > > based on their being impossible to interpret meaningfully in an > implementation and deployment context or to their being obvious. > > Rather than spend another week exchanging email on this > topic, I'd like > to ask the WG at this time if there > is anyone else who feels that one or several of these requirements > should be removed before we send this document to the IESG? > > jak > > ------_=_NextPart_001_01C1B572.038AECE0 Content-Type: text/html; charset="iso-8859-1" RE: Removing CT Requirements
And what if the link is wireless?
-----Original Message-----
From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com]
Sent: January 7, 2002 05:41
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; George Tsirtsis
Cc: seamoby@ietf.org
Subject: [Seamoby] RE: Removing CT Requirements

yes I could say this is ambiguous and unnecessary since I can clearly claim that error rates provided by almost all links today are good enough....
 
George
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, January 04, 2002 6:04 PM
To: 'James Kempf'; George Tsirtsis
Cc: seamoby@ietf.org
Subject: RE: Removing CT Requirements

I would like to know from George if he believes
5.5.2 is irrelevant, or simply ambiguously worded.
I believe (and I suspect that George may concur)
that error protection for the context is
required (consider the possible impact of attempting
to install or use erroneous context at an AR), and
that it is important to clearly identify that requirement
(particularly given that there are no transport
requirements in the id).

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: January 4, 2002 12:31
> To: Kenward, Gary [WDLN2:AN10:EXCH]; George Tsirtsis
> Cc: seamoby@ietf.org
> Subject: Removing CT Requirements
>
>
> It seems to me like George is making a specific request as part of the
> WG last call that the following
> requirements be removed from the document:
>
> 4.12 The context information to be transferred MUST be
> available at the
> AR performing the transfer, prior to the initiation of a
> given phase of
> the context transfer.
> 4.13 The context transfer solution WILL NOT verify the context
> information prior to transfer.
> 4.15 The context transfer solution MAY include methods for
> interworking
> with non-IETF mobility solutions.
> 5.5.2 A context update MUST preserve the integrity, and thus the
> meaning, of the context at each receiving AR."
>
>
> based on their being impossible to interpret meaningfully in an
> implementation and deployment context or to their being obvious.
>
> Rather than spend another week exchanging email on this
> topic, I'd like
> to ask the WG at this time if there
> is anyone else who feels that one or several of these requirements
> should be removed before we send this document to the IESG?
>
>                 jak
>
>

------_=_NextPart_001_01C1B572.038AECE0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 11:25:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26060 for ; Thu, 14 Feb 2002 11:25:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07370; Thu, 14 Feb 2002 11:11:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07343 for ; Thu, 14 Feb 2002 11:11:22 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25658 for ; Thu, 14 Feb 2002 11:11:19 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EGAoY04668; Thu, 14 Feb 2002 11:10:50 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EGAlo28170; Thu, 14 Feb 2002 11:10:47 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J3PD469>; Thu, 14 Feb 2002 11:10:47 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4859@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'George Tsirtsis'" , "'James Kempf'" Cc: "'seamoby@ietf.org'" Subject: Recall: [Seamoby] RE: Removing CT Requirements Date: Thu, 14 Feb 2002 11:10:45 -0500 Expiry-Date: Sat, 16 Feb 2002 11:17:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B572.28BB0950" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B572.28BB0950 Content-Type: text/plain Kenward, Gary [WDLN2:AN10:EXCH] would like to recall the message, "[Seamoby] RE: Removing CT Requirements". ------_=_NextPart_001_01C1B572.28BB0950 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Recall: [Seamoby] RE: Removing CT Requirements

Kenward, Gary [WDLN2:AN10:EXCH] would like to recall = the message, "[Seamoby] RE: Removing CT Requirements".

------_=_NextPart_001_01C1B572.28BB0950-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 11:26:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26096 for ; Thu, 14 Feb 2002 11:26:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07097; Thu, 14 Feb 2002 11:10:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07027 for ; Thu, 14 Feb 2002 11:10:01 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25603 for ; Thu, 14 Feb 2002 11:09:57 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EG9SY04557; Thu, 14 Feb 2002 11:09:28 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EG9Qa13648; Thu, 14 Feb 2002 11:09:26 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J3PD457>; Thu, 14 Feb 2002 11:09:25 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4857@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'George Tsirtsis'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Minutes of Meeting at IETF 52 Date: Thu, 14 Feb 2002 11:09:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B571.F7B6F8A0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B571.F7B6F8A0 Content-Type: text/plain; charset="iso-8859-1" George: -----Original Message----- From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] Sent: January 4, 2002 10:49 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] Minutes of Meeting at IETF 52 Gary, We agree in essence but disagree on action...as it has been for some time on this issue. I will thus try once again and see how it goes. Data validation was at some point suggested....and unfortunately accepted as a requirement. After some thought and multiple complaints people realized that this can not be a requirement....yet the idea of *removing* the requirement was for some, to me still weird, reason dismissed as utterly impossible! The authors in an attempt to correct the situation reworded this and made non-validation a requirement which brought a smile to my face :) and the issue again on the table [gwk] The issue is on the table because you brought it up. Is it whimsy, or are you having fun ;^}? Non-validation was put into the requirements simply because, like sooooo many issues discussed and thought to be resolved, data validation kept being re-introduced. Making non-validation a requirement based upon the general agreement of those involved in the discussions did stop that discussion, until now. I do not understand the reluctance of this group to *remove* requirements. Removing a requirement DOES NOT....I repeat DOES NOT mean that the thing removed is now illegal or must not be supported...it just means that a proposal does not HAVE to cover it to be a valid proposal. [gwk] Deja vu all over again. There are reasons behind everyone on of the requirements. In some cases the discussion was long, laborious, and inconclusive, and so esseentially, not worth repeating. This has resulted in a document littered with semi-irrelevant and ambiguous requirements such as: "4.12 The context information to be transferred MUST be available at the AR performing the transfer, prior to the initiation of a given phase of the context transfer. [gwk] Actually, this is one of the more important requirements. In reality, the decision made was that "CT WILL NOT be a distributed protocol for information gathering NOR will CT be responsible for fetching the context from a central server". Both ideas where proposed. 4.13 The context transfer solution WILL NOT verify the context information prior to transfer. [gwk] Again, some wanted to have CT validate the context prior to transmission. The group decided that this was not part of the scope of the CT solution. So how would you capture it? 4.15 The context transfer solution MAY include methods for interworking with non-IETF mobility solutions. [gwk] Again, a number of us do not believe that CT should be a MIP extension. If the only interest is in defining a CT extension to MIP, then CT should be in the MIP wg, not SeaMoby. 5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context at each receiving AR." [gwk] As Madjid has pointed out: this is the summary of many hours of debate about error control and the use of "light weight" protocols. I don't understand your pre-occupation with these requirements. I have no idea how one captures the discussion and effort that went into the debates around these issues except by including them in the requirements. Perhaps there should have been a general discussion section (check out the brunner NSIS requirements draft for an example). However, if you are a student of requirements analysis and specification, you would know that general discussions sections are not verifiable and thus are not requirements. All of the above requirements are verifiable. At worst, these requirements can be perceived as innocuous. I have not heard any argument that they are false, or limiting. There are plenty of examples of RFCs that waste words, so I don't think that terseness is a real issue. I sound like a broken record I know...sorry. [gwk] No you don't. [gwk] No you don't. [gwk] No you don't. [gwk] No you don't. [gwk] No you don't. [gwk] No you don't. IMHO, CT will never happen because everyone seems pre-occupied with defining the solution within the requirements document. As I understand the IESGs view of the role of requirements, nothing is being cast in stone. The requirements form a set of agreed upon guidelines that should hopefully help everyone focus on a finite problem set. If a requirement turns out to be very wrong, then the wg can and should revise it. If a requirement turns out to be useless, then everyone can, should and will ignore it. Gary George -----Original Message----- From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] Sent: Friday, January 04, 2002 3:11 PM To: 'George Tsirtsis'; 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] Minutes of Meeting at IETF 52 George: Clearly there is much confusion over this particular requirement, and I promptly admit that it is odd. I am concerned that old issues will continue to be re-hashed if we start throwing out decisions that were made, in this case, almost a year ago. Someone, early last year, suggested that ct should check to ensure that the context it was sending was valid context. I cannot reproduce the whole conversation, but yes, the suggestion was to check semantics as well as syntax of the context. I personally could not see how this validation function could be provided without an enormous amount of complexity. Most of the participants in this conversation agreed, and to avoid any further discussion (the debate actually went on for a while), it was stated as a requirement that the ct solution would not attempt to perform validation of the context. This still leaves open the possibility that a router manufacturer could attempt validation (and probably should, to some degree, as part of the building of the feature context). Given that the IETF defines protocols, and validation does not seem to require a protocol capability, you are right in that this requirement does not really belong. However, past experience has repeatedly shown that this working group will repeatedly re-visit old issues if they are not clearly capture. Perhaps you, or someone else could think of better wording and propose it. Gary "To introduce something altogether new would mean to begin all over, to become ignorant again, and to run the old, old risk of failing to learn." (Isaac Asimov) > -----Original Message----- > From: George Tsirtsis [ mailto:G.Tsirtsis@flarion.com ] > Sent: January 3, 2002 15:43 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] Minutes of Meeting at IETF 52 > > > James, > > From the minutes.... > > "Section 4.13 expanded greatly. > Q: Is WILL NOT part of the standard terms? > A: No, is SHOULD be a MUST NOT. > Q: So if the CT solution verifies the CT info prior to > transfer it is NOT > acceptable? > A: We'll take that up on the mailing list." > > To remind you 4.13 is "4.13 The context transfer solution > WILL NOT verify > the context information prior to transfer." > > The old "SHOULD" was clearly not acceptable. The new "MUST > NOT" suggestion > was an obvious and a bit funny :-) mistake...As I pointed out > long time ago > this requirement should just be removed...it just makes no > sense....if only > it was the only one... ooops! I did not say that :-0 > > George > > > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: Thursday, January 03, 2002 7:24 PM > To: seamoby@ietf.org > Subject: [Seamoby] Minutes of Meeting at IETF 52 > > > Attached. There is a one week comment period, ending on January 10. > > jak > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1B571.F7B6F8A0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Minutes of Meeting at IETF 52
George:
-----Original Message-----
From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com]
Sent: January 4, 2002 10:49
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; seamoby@ietf.org
Subject: RE: [Seamoby] Minutes of Meeting at IETF 52

Gary,
 
We agree in essence but disagree on action...as it has been for some time on this issue. I will thus try once again and see how it goes.
 
Data validation was at some point suggested....and unfortunately accepted as a requirement. After some thought and multiple complaints people realized that this can not be a requirement....yet the idea of *removing* the requirement was for some, to me still weird, reason dismissed as utterly impossible! The authors in an attempt to correct the situation reworded this and made non-validation a requirement which brought a smile to my face :) and the issue again on the table
[gwk] The issue is on the table because you brought it up. Is it whimsy, or are you having fun ;^}?
 
Non-validation was put into the requirements simply because, like sooooo many issues discussed and thought to be resolved, data validation kept being re-introduced. Making non-validation a requirement based upon the 
general agreement of those involved in the discussions did stop that discussion, until now. 
 
I do not understand the reluctance of this group to *remove* requirements. Removing a requirement DOES NOT....I repeat DOES NOT mean that the thing removed is now illegal or must not be supported...it  just means that a proposal does not HAVE to cover it to be a valid proposal.
[gwk] Deja vu all over again. There are reasons behind everyone on of the requirements. In some cases the discussion was long, laborious, and inconclusive, and so esseentially, not worth repeating. 
 
This has resulted in a document littered with semi-irrelevant and ambiguous requirements such as:
"4.12 The context information to be transferred MUST be available at the AR performing the transfer, prior to the initiation of a given phase of the context transfer.
[gwk] Actually, this is one of the more important requirements. In reality, the decision made was that "CT WILL NOT be a distributed protocol for information gathering NOR  will CT be responsible for fetching the context from a central server". Both ideas where proposed.
 
4.13 The context transfer solution WILL NOT verify the context information prior to transfer.
[gwk] Again, some wanted to have CT validate the context prior to transmission. The group decided that this was not part of the scope of the CT solution. So how would you capture it? 
4.15 The context transfer solution MAY include methods for interworking with non-IETF mobility solutions.
[gwk] Again, a number of us do not believe that CT should be a MIP extension. If the only interest is in
defining a CT extension to MIP, then CT should be in the MIP wg, not SeaMoby. 
5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context at each receiving AR."
[gwk] As Madjid has pointed out: this is the summary of many hours of debate about error control and the
use of "light weight" protocols. 
 
I don't understand your pre-occupation with these requirements. I have no idea how one captures the discussion and effort that went into  the debates around these issues except by including them in the requirements. Perhaps there should have been a general discussion section (check out the brunner NSIS requirements draft for an example). However, if you are a student of requirements analysis and specification, you would know that
general discussions sections are not verifiable and thus are not requirements. All of the above requirements
are verifiable.
 
At worst, these requirements can be perceived as innocuous. I have not heard any argument that they are false, or limiting. There are plenty of examples of RFCs that waste words, so I don't think that terseness
is a real issue.
 
I sound like a broken record I know...sorry.
[gwk] No you don't. 
[gwk] No you don't. 
[gwk] No you don't. 
[gwk] No you don't. 
[gwk] No you don't. 
[gwk] No you don't. 
 
IMHO, CT will never happen because everyone seems pre-occupied with defining the solution within the
requirements document. As I understand the IESGs view of the role of requirements, nothing is being cast in
stone. The requirements form a set of agreed upon guidelines that should hopefully help everyone focus on
a finite problem set. If a requirement turns out to be very wrong, then the wg can and should revise it.
If a requirement turns out to be useless, then everyone can, should and will ignore it.
 
Gary
 
George
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, January 04, 2002 3:11 PM
To: 'George Tsirtsis'; 'James Kempf'; seamoby@ietf.org
Subject: RE: [Seamoby] Minutes of Meeting at IETF 52

George:

  Clearly there is much confusion over this particular requirement,
and I promptly admit that it is odd. I am concerned that old issues
will continue to be re-hashed if we start throwing out decisions that
were made, in this case, almost a year ago.

  Someone, early last year, suggested that ct should check to ensure
that the context it was sending was valid context. I cannot reproduce
the whole conversation, but yes, the suggestion was to check semantics
as well as syntax of the context.

  I personally could not see how this validation function could be
provided without an enormous amount of complexity. Most of the participants
in this conversation agreed, and to avoid any further discussion (the
debate actually went on for a while), it was stated as a requirement that
the ct solution would not attempt to perform validation of the context.
This still leaves open the possibility that a router manufacturer could
attempt validation (and probably should, to some degree, as part of the
building of the feature context).

  Given that the IETF defines protocols, and validation does not seem
to require a protocol capability, you are right in that this requirement
does not really belong. However, past experience has repeatedly shown that
this working group will repeatedly re-visit old issues if they are not
clearly capture.

  Perhaps you, or someone else could think of better wording and propose
it.

Gary

"To introduce something altogether new would mean to begin all over, to
become ignorant again, and to run the old, old risk of failing to learn."
(Isaac Asimov)

> -----Original Message-----
> From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com]
> Sent: January 3, 2002 15:43
> To: 'James Kempf'; seamoby@ietf.org
> Subject: RE: [Seamoby] Minutes of Meeting at IETF 52
>
>
> James,
>
> From the minutes....
>
> "Section 4.13 expanded greatly.
> Q: Is WILL NOT part of the standard terms?
> A: No, is SHOULD be a MUST NOT.
> Q: So if the CT solution verifies the CT info prior to
> transfer it is NOT
> acceptable?
> A: We'll take that up on the mailing list."
>
> To remind you 4.13 is "4.13 The context transfer solution
> WILL NOT verify
> the context information prior to transfer."
>
> The old "SHOULD" was clearly not acceptable. The new "MUST
> NOT" suggestion
> was an obvious and a bit funny :-) mistake...As I pointed out
> long time ago
> this requirement should just be removed...it just makes no
> sense....if only
> it was the only one... ooops! I did not say that :-0
>
> George
>
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Thursday, January 03, 2002 7:24 PM
> To: seamoby@ietf.org
> Subject: [Seamoby] Minutes of Meeting at IETF 52
>
>
> Attached. There is a one week comment period, ending on January 10.
>
>             jak
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1B571.F7B6F8A0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 11:26:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26132 for ; Thu, 14 Feb 2002 11:26:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07508; Thu, 14 Feb 2002 11:12:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07483 for ; Thu, 14 Feb 2002 11:12:35 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25689 for ; Thu, 14 Feb 2002 11:12:32 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EGC3Y04792; Thu, 14 Feb 2002 11:12:03 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EGC1a13764; Thu, 14 Feb 2002 11:12:01 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J3PD48A>; Thu, 14 Feb 2002 11:12:00 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA485B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'George Tsirtsis'" , "'James Kempf'" , "'seamoby@ietf.org'" Subject: Recall: [Seamoby] Minutes of Meeting at IETF 52 Date: Thu, 14 Feb 2002 11:11:59 -0500 Expiry-Date: Sat, 16 Feb 2002 11:18:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B572.54FCAFF0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B572.54FCAFF0 Content-Type: text/plain Kenward, Gary [WDLN2:AN10:EXCH] would like to recall the message, "[Seamoby] Minutes of Meeting at IETF 52". ------_=_NextPart_001_01C1B572.54FCAFF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Recall: [Seamoby] Minutes of Meeting at IETF 52

Kenward, Gary [WDLN2:AN10:EXCH] would like to recall = the message, "[Seamoby] Minutes of Meeting at IETF = 52".

------_=_NextPart_001_01C1B572.54FCAFF0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 11:26:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26164 for ; Thu, 14 Feb 2002 11:26:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07550; Thu, 14 Feb 2002 11:12:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07525 for ; Thu, 14 Feb 2002 11:12:42 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25691 for ; Thu, 14 Feb 2002 11:12:39 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EGCAY04822; Thu, 14 Feb 2002 11:12:10 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EGC7o28247; Thu, 14 Feb 2002 11:12:08 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J3PD48G>; Thu, 14 Feb 2002 11:12:08 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA485C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'George Tsirtsis'" , "'James Kempf'" Cc: "'seamoby@ietf.org'" Subject: Recall: [Seamoby] RE: Removing CT Requirements Date: Thu, 14 Feb 2002 11:12:07 -0500 Expiry-Date: Sat, 16 Feb 2002 11:18:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B572.5947C720" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B572.5947C720 Content-Type: text/plain Kenward, Gary [WDLN2:AN10:EXCH] would like to recall the message, "[Seamoby] RE: Removing CT Requirements". ------_=_NextPart_001_01C1B572.5947C720 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Recall: [Seamoby] RE: Removing CT Requirements

Kenward, Gary [WDLN2:AN10:EXCH] would like to recall = the message, "[Seamoby] RE: Removing CT Requirements".

------_=_NextPart_001_01C1B572.5947C720-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 11:29:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26273 for ; Thu, 14 Feb 2002 11:29:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07419; Thu, 14 Feb 2002 11:11:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07390 for ; Thu, 14 Feb 2002 11:11:29 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25674 for ; Thu, 14 Feb 2002 11:11:26 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EGAvY04694; Thu, 14 Feb 2002 11:10:57 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EGAta13716; Thu, 14 Feb 2002 11:10:55 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J3PD47C>; Thu, 14 Feb 2002 11:10:54 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA485A@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'George Tsirtsis'" , "'James Kempf'" , "'seamoby@ietf.org'" Subject: Recall: [Seamoby] Minutes of Meeting at IETF 52 Date: Thu, 14 Feb 2002 11:10:53 -0500 Expiry-Date: Sat, 16 Feb 2002 11:17:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B572.2D73AF60" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B572.2D73AF60 Content-Type: text/plain Kenward, Gary [WDLN2:AN10:EXCH] would like to recall the message, "[Seamoby] Minutes of Meeting at IETF 52". ------_=_NextPart_001_01C1B572.2D73AF60 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Recall: [Seamoby] Minutes of Meeting at IETF 52

Kenward, Gary [WDLN2:AN10:EXCH] would like to recall = the message, "[Seamoby] Minutes of Meeting at IETF = 52".

------_=_NextPart_001_01C1B572.2D73AF60-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 11:40:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26811 for ; Thu, 14 Feb 2002 11:40:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08577; Thu, 14 Feb 2002 11:26:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08550 for ; Thu, 14 Feb 2002 11:26:37 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26146 for ; Thu, 14 Feb 2002 11:26:34 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1EGQ2jP013076; Thu, 14 Feb 2002 11:26:03 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA06011; Thu, 14 Feb 2002 11:25:56 -0500 (EST) Date: Thu, 14 Feb 2002 11:26:01 -0500 To: James Kempf Cc: Behcet Sarikaya , seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging Message-ID: <20020214162601.GB819@catfish> Mail-Followup-To: James Kempf , Behcet Sarikaya , seamoby@ietf.org References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 119 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Jim, On Wed, Feb 13, 2002 at 06:07:19PM -0800, James Kempf wrote: > > Let's forget Simple IP. > > If we take 4.8 only then we can develop IP paging protocols for > v4 > > and v6 as extensions to mipv4 and mipv6 (as had been done on many > drafts). > > Then the problem is that requirement 4.7 is violated. So these > > protocols are not acceptable as far as RFC 3154 is concerned. > > If we take 4.7 only then we can develop IP paging protocols for v4 > > and v6 independent of mipv4/mipv6 (as had been done on one draft). > > Then the problem is that requirement 4.8 is violated. So these > > protocols are not acceptable as far as RFC 3154 is concerned. > > Trying to satisfy both 4.7 and 4.8 in one draft is like defining 4 > > protocols in one draft and each protocol considered in isolation would > > violate either 4.7 or 4.8. This is wrong, the implementations of such > > drafts can not be interoperability tested. > > This was my main point, I had been writing so many mails to explain > it > > over and over again. > > SOLUTION is > > 4.7 or 4.8 should be the requirement > > not 4.7 and 4.8. > > > > OK, now I think I understand. > > I think it is possible to support both requirements by > partitioning the paging protocol as I described in the original > message. The core protocol is independent of mobility > protocol with hooks for particular mobility management > protocols to handle dormant mode mobility. How the > mobility management protocols handle dormant mode > mobility is specified separately. > > Does this make sense? I think this would make sense. But I don't think the hooks described in draft-renker really satisfies the requirements 4.7 and 4.8 even with Explicit Mode (see below). > > W.r.t. IPv4/IPv6, there are issues here with features > of one not available in the other. The requirements > don't say anything about this, so I think we need > to open this up for discussion. > The scheme described in draft-renker relies on using the PA's address as the alternate CoA in order to redirect packets for the dormant host to the PA. However, when a redirected data packet is received by the PA, the PA must look into the inner IP header (or the final entry of Routing Header if route opmization is used) in which the MN's Home Address is contained in the destination IP address field in order to distinguish the MN, as described in the draft. This is very unnatural way of dealing with IP-in-IP packet (or Routing Header) at an intermediary node. This is also related to the following comments from the assessment team: 2) There is no description of how the mobility management is completed after the paging request is received. There must be some coordination on when the deregistration is sent to PA. I think that the coordination is very difficult (especially in terms of security) as long as the solution relies on the use of the MN's Home Address at PA. (Note: Even if such an unusual packet processing at PA is considered to be acceptable (I don't think it is acceptable), Idle Mode Request message (used for explicit mode registration) must contain the Home Address of the MN in order maintain the mapping between the Home Address and CoA of the MN at the PA (this is not specified in draft-renker), otherwise the packet would be forwarded back toward the Home Agent's subnet based on the normal IP routing, which would not trigger paging operation but rather result in ping-pong between the Home Agent and PA. Since explicit mode registration has to carry the Home Address information, it seems that the scheme is not really independent of mobility management protocol.) In order to avoid this situation, an HMIPv6-like solution based on Regional CoA would be necessary for draft-renker, but this feature is not available for MIPv4. This means that the scheme is not really independent of a mobility management protocol. On the other hand, the degree of "independency of mobility managenent protocol" specified in draft-ohba is the highest among all the proposals, and thus there is no problem of this kind with draft-ohba. I think this is a very important point. Although I don't much care whichever protocol is selected as a starting point, I think very careful investigation is necessary for draft-renker. > Would the working group like to allow differences > in the protocol design for IPv4/IPv6 or should we try > for a protocol design that spans both (note that I'm > not talking about trival differences like address formats)? I would like trying for a protocol design that spans both, which would lead us to highly modular design and would also be good for supporting a new mobility management protocol in the future. Thanks, Yoshihiro Ohba > > 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 From seamoby-admin@ietf.org Thu Feb 14 11:43:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26960 for ; Thu, 14 Feb 2002 11:43:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08768; Thu, 14 Feb 2002 11:29:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08737 for ; Thu, 14 Feb 2002 11:29:43 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26284 for ; Thu, 14 Feb 2002 11:29:40 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1EGTCg32632; Thu, 14 Feb 2002 17:29:13 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00451; Thu, 14 Feb 2002 17:29:12 +0100 Message-ID: <3C6BE5D8.D720132E@ccrle.nec.de> Date: Thu, 14 Feb 2002 17:29:12 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Behcet Sarikaya , seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James, James Kempf wrote: > > Let's forget Simple IP. > > If we take 4.8 only then we can develop IP paging protocols for > v4 > > and v6 as extensions to mipv4 and mipv6 (as had been done on many > drafts). > > Then the problem is that requirement 4.7 is violated. So these > > protocols are not acceptable as far as RFC 3154 is concerned. > > If we take 4.7 only then we can develop IP paging protocols for v4 > > and v6 independent of mipv4/mipv6 (as had been done on one draft). > > Then the problem is that requirement 4.8 is violated. So these > > protocols are not acceptable as far as RFC 3154 is concerned. > > Trying to satisfy both 4.7 and 4.8 in one draft is like defining 4 > > protocols in one draft and each protocol considered in isolation would > > violate either 4.7 or 4.8. This is wrong, the implementations of such > > drafts can not be interoperability tested. > > This was my main point, I had been writing so many mails to explain > it > > over and over again. > > SOLUTION is > > 4.7 or 4.8 should be the requirement > > not 4.7 and 4.8. > > > > OK, now I think I understand. > > I think it is possible to support both requirements by > partitioning the paging protocol as I described in the original > message. The core protocol is independent of mobility > protocols with hooks for particular mobility management > protocols to handle dormant mode mobility. How the > mobility management protocols handle dormant mode > mobility is specified separately. > Does this make sense? > I think yes. Isn't it what we intended to have in a first WG framework draft anyway, a generic part, which is independent, and an optimization part, which might make use of MIPvx specifics for optimization purposes. I think the design of the architecture and the core protocol can be that generic in most areas. For specific mobility management approaches, requirement 4.8 can be met by keeping te paging process and state maintenance transparent to the mobility part, but make use of available registration mechansims (like alternate CoA registration in MIPv6 in order to allow directed forwarding of paging trigger packets ). > > W.r.t. IPv4/IPv6, there are issues here with features > of one not available in the other. The requirements > don't say anything about this, so I think we need > to open this up for discussion. > > Would the working group like to allow differences > in the protocol design for IPv4/IPv6 or should we try > for a protocol design that spans both (note that I'm > not talking about trival differences like address formats)? > In my opinion, keeping some protocol specifics in kern parts is reasonable in some cases. So, why, as an example, not to make use of IPv6 specifics like Extension Headers (as MIPv6 does)? An alternative generic mode for IPv4 and IPv6 must be specified without a requirement to change the entire format (e.g. TLV encoded messages and (sub) options). Regards, Marco > > 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 From seamoby-admin@ietf.org Thu Feb 14 12:00:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27698 for ; Thu, 14 Feb 2002 12:00:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10362; Thu, 14 Feb 2002 11:49:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10336 for ; Thu, 14 Feb 2002 11:49:20 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27183 for ; Thu, 14 Feb 2002 11:49:17 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1EGmhL28800 for ; Thu, 14 Feb 2002 10:48:43 -0600 (CST) Message-ID: <3C6BEA64.6040001@alcatel.com> Date: Thu, 14 Feb 2002 10:48:36 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> <20020214162601.GB819@catfish> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello all, Yoshihiro Ohba wrote: >Jim, > >On Wed, Feb 13, 2002 at 06:07:19PM -0800, James Kempf wrote: > >>>Let's forget Simple IP. >>> If we take 4.8 only then we can develop IP paging protocols for >>> >>v4 >> >>>and v6 as extensions to mipv4 and mipv6 (as had been done on many >>> >>drafts). >> >>> Then the problem is that requirement 4.7 is violated. So these >>>protocols are not acceptable as far as RFC 3154 is concerned. >>> If we take 4.7 only then we can develop IP paging protocols for v4 >>>and v6 independent of mipv4/mipv6 (as had been done on one draft). >>> Then the problem is that requirement 4.8 is violated. So these >>>protocols are not acceptable as far as RFC 3154 is concerned. >>> Trying to satisfy both 4.7 and 4.8 in one draft is like defining 4 >>>protocols in one draft and each protocol considered in isolation would >>>violate either 4.7 or 4.8. This is wrong, the implementations of such >>>drafts can not be interoperability tested. >>> This was my main point, I had been writing so many mails to explain >>> >>it >> >>>over and over again. >>>SOLUTION is >>>4.7 or 4.8 should be the requirement >>>not 4.7 and 4.8. >>> >>OK, now I think I understand. >> >>I think it is possible to support both requirements by >>partitioning the paging protocol as I described in the original >>message. The core protocol is independent of mobility >>protocol with hooks for particular mobility management >>protocols to handle dormant mode mobility. How the >>mobility management protocols handle dormant mode >>mobility is specified separately. >> >>Does this make sense? >> No, it does not. Can someone point to me an RFC of standard status which defines multiple protocols? IPv4/IPv6 are implemented in different stacks in todays technology. Mipv4/6 run using those stacks. I think that we should ask people to write their protocols in diferent drafts. What is wrong with this? WG can better judge such drafts. We all know the controversy over draft-renker, implicit explicit mode, what it support and what it does not. If they could rewrite it in separate drafts then people would be able to see clearly what each draft supports. What is wrong with this? I agree with Yoshi on his other points. -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 12:16:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29360 for ; Thu, 14 Feb 2002 12:16:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12517; Thu, 14 Feb 2002 12:05:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12488 for ; Thu, 14 Feb 2002 12:05:02 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27794 for ; Thu, 14 Feb 2002 12:04:58 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7R5XA>; Thu, 14 Feb 2002 09:04:31 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Behcet Sarikaya'" , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward with paging Date: Thu, 14 Feb 2002 09:04:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B579.A6975390" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B579.A6975390 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > No, it does not. Can someone point to me an RFC of standard status > which defines multiple protocols? IPv4/IPv6 are implemented in > different stacks in todays technology. Mipv4/6 run using those > stacks. I think that we should ask people to write their protocols > in diferent drafts. What is wrong with this? I see absolutely no reason why applications cannot run over both transports, Diameter is one such example of a protocol that can handle both (as is SLP). I don't think we should be using MIP as the example to follow. PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGvuFzN1fXKoxmisEQIfigCeNA846vRXtrZtQFm58aK72R5JE/kAoIPb 8cbRztEuqh6Hj0MJGm9rubqK =bSOk -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B579.A6975390 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> No, it does not. Can someone point to me an RFC = of standard status
> which defines multiple protocols?  = IPv4/IPv6 are implemented in
> different stacks in todays technology. Mipv4/6 = run using those
> stacks. I  think that we should ask people = to write their protocols
> in diferent drafts. What is wrong with = this?  

I see absolutely no reason why applications cannot = run over both
transports, Diameter is one such example of a = protocol that can
handle both (as is SLP). I don't think we should be = using MIP as the
example to follow.

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPGvuFzN1fXKoxmisEQIfigCeNA846vRXtrZtQFm58aK72R5JE/kAoIP= b
8cbRztEuqh6Hj0MJGm9rubqK
=3DbSOk
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B579.A6975390-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 12:37:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00825 for ; Thu, 14 Feb 2002 12:37:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13173; Thu, 14 Feb 2002 12:22:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13148 for ; Thu, 14 Feb 2002 12:22:39 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00106 for ; Thu, 14 Feb 2002 12:22:35 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1EHM8g35941; Thu, 14 Feb 2002 18:22:08 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA01095; Thu, 14 Feb 2002 18:22:08 +0100 Message-ID: <3C6BF240.1B459AB0@ccrle.nec.de> Date: Thu, 14 Feb 2002 18:22:08 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshihiro Ohba CC: James Kempf , Behcet Sarikaya , seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> <20020214162601.GB819@catfish> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Yoshi, Yoshihiro Ohba wrote: > Jim, > > On Wed, Feb 13, 2002 at 06:07:19PM -0800, James Kempf wrote: > > > Let's forget Simple IP. > > > If we take 4.8 only then we can develop IP paging protocols for > > v4 > > > and v6 as extensions to mipv4 and mipv6 (as had been done on many > > drafts). > > > Then the problem is that requirement 4.7 is violated. So these > > > protocols are not acceptable as far as RFC 3154 is concerned. > > > If we take 4.7 only then we can develop IP paging protocols for v4 > > > and v6 independent of mipv4/mipv6 (as had been done on one draft). > > > Then the problem is that requirement 4.8 is violated. So these > > > protocols are not acceptable as far as RFC 3154 is concerned. > > > Trying to satisfy both 4.7 and 4.8 in one draft is like defining 4 > > > protocols in one draft and each protocol considered in isolation would > > > violate either 4.7 or 4.8. This is wrong, the implementations of such > > > drafts can not be interoperability tested. > > > This was my main point, I had been writing so many mails to explain > > it > > > over and over again. > > > SOLUTION is > > > 4.7 or 4.8 should be the requirement > > > not 4.7 and 4.8. > > > > > > > OK, now I think I understand. > > > > I think it is possible to support both requirements by > > partitioning the paging protocol as I described in the original > > message. The core protocol is independent of mobility > > protocol with hooks for particular mobility management > > protocols to handle dormant mode mobility. How the > > mobility management protocols handle dormant mode > > mobility is specified separately. > > > > Does this make sense? > > I think this would make sense. > > But I don't think the hooks described in draft-renker really satisfies > the requirements 4.7 and 4.8 even with Explicit Mode (see below). > > > > > W.r.t. IPv4/IPv6, there are issues here with features > > of one not available in the other. The requirements > > don't say anything about this, so I think we need > > to open this up for discussion. > > > > The scheme described in draft-renker relies on using the PA's address > as the alternate CoA in order to redirect packets for the dormant host > to the PA. However, when a redirected data packet is received by the > PA, the PA must look into the inner IP header (or the final entry of > Routing Header if route opmization is used) in which the MN's Home > Address is contained in the destination IP address field in order to > distinguish the MN, as described in the draft. Outer IP header is sripped away, since it addresses the PA in case of making use of the alternate CoA in MIPv6. Then the PA has to check the dest. addr. of the IP header, that's correct. In order systems, another identifier carried with paging trigger packets might be checked. In case of route optimization with MIPv6, the draft provides a statement, that no bindings should be valid at CNs anymore when entering idle mode. But for this specific case and for MIPv6, you are right, the PA has to check the Home Address, since it is used as a more or less static identifier. > This is very unnatural > way of dealing with IP-in-IP packet (or Routing Header) at an > intermediary node. This is also related to the following comments > from the assessment team: > > 2) There is no description of how the mobility management is > completed after the paging request is received. There must be > some coordination on when the deregistration is sent to PA. > > I think that the coordination is very difficult (especially in terms > of security) as long as the solution relies on the use of the MN's > Home Address at PA. > The Homne address comes with the Idle State Request message sent from MN to PA. Paging trigger packets are buffered until PA has resolved MN's CoA (after wake up). The draft refers to more identifiers, allowing the MN to tell to the PA. During active registration, MN first tells the mobility agent of its current location, then the PA (in order to avoid packet loss). Regards, Marco > > (Note: Even if such an unusual packet processing at PA is considered > to be acceptable (I don't think it is acceptable), Idle Mode Request > message (used for explicit mode registration) must contain the Home > Address of the MN in order maintain the mapping between the Home > Address and CoA of the MN at the PA (this is not specified in > draft-renker), otherwise the packet would be forwarded back toward the > Home Agent's subnet based on the normal IP routing, which would not > trigger paging operation but rather result in ping-pong between the > Home Agent and PA. Since explicit mode registration has to carry the > Home Address information, it seems that the scheme is not really > independent of mobility management protocol.) > > In order to avoid this situation, an HMIPv6-like solution based on > Regional CoA would be necessary for draft-renker, but this feature is > not available for MIPv4. This means that the scheme is not really > independent of a mobility management protocol. > > On the other hand, the degree of "independency of mobility managenent > protocol" specified in draft-ohba is the highest among all the > proposals, and thus there is no problem of this kind with draft-ohba. > I think this is a very important point. > > Although I don't much care whichever protocol is selected as a > starting point, I think very careful investigation is necessary for > draft-renker. > > > Would the working group like to allow differences > > in the protocol design for IPv4/IPv6 or should we try > > for a protocol design that spans both (note that I'm > > not talking about trival differences like address formats)? > > I would like trying for a protocol design that spans both, which > would lead us to highly modular design and would also be good > for supporting a new mobility management protocol in the future. > > > Thanks, > Yoshihiro Ohba > > > > > 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 -- _____________________________________________ Marco Liebsch Network Laboratories Heidelberg NEC Europe Ltd Friedrich-Ebert-Anlage 1 D-69115 Heidelberg Tel: +49/ (0)6221/13708-11 Fax: +49/ (0)6221/13708-28 E-Mail: Marco.Liebsch@ccrle.nec.de http://www.ccrle.nec.de _____________________________________________ _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 13:25:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05363 for ; Thu, 14 Feb 2002 13:25:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15684; Thu, 14 Feb 2002 13:14:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15656 for ; Thu, 14 Feb 2002 13:14:39 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05066 for ; Thu, 14 Feb 2002 13:14:37 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EIElQ24323 for ; Thu, 14 Feb 2002 12:14:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 14 Feb 2002 12:14:30 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 12:14:29 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 14 Feb 2002 13:14:28 -0500 Message-ID: Thread-Topic: Comment on CAR requirements Thread-Index: AcG1g3EjgcnMeiFmEdaoMwACVQJbGw== To: X-OriginalArrivalTime: 14 Feb 2002 18:14:29.0411 (UTC) FILETIME=[71966730:01C1B583] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA15658 Subject: [Seamoby] Comment on CAR requirements Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi all, I've got a comment regarding requirement 3.9 Just for recalling: --------- 3.9. DEPENDENCE ON A MOBILITY MANAGEMENT PROTOCOL CAR discovery MUST NOT depend on a particular mobility management protocol. In other words, it MUST NOT utilize a feature which is unique to a particular mobility management protocol. The output of CAR discovery, however, MUST be usable by mobility management protocols. CAR discovery MUST NOT deteriorate the performance of the underlying mobility management protocol. --------- In the second sentence, shouldn't it be '...it MUST NOT depend on a feature which is unique...' rather than 'utilize'? Here's my thought: Assuming a CAR solution that has an MIPV6 mode and a non-MIPV6 mode, and maybe a mixed mode. The first one specifically utilizes MIPV6 if possible to implement CAR efficiently. If the environment were non-MIPV6 (or we have a mixed environment in the sense that some of the neighbors are MIPV6, the others are not), the non-MIPv6 or the mixed mode are used. This should be a viable, albeit probably rather complex, solution, shouldn't it? However, the solution must not depend on this feature in the sense that it does not work if the specific MM feature is not present, i.e., the other non-MIPV6 nodes are simply not discovered. That's how I understood the dependence titel of this requirement. Any comments? Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 14:29:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07321 for ; Thu, 14 Feb 2002 14:29:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20250; Thu, 14 Feb 2002 14:18:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20221 for ; Thu, 14 Feb 2002 14:18:50 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06964 for ; Thu, 14 Feb 2002 14:18:47 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1EJIGe17761; Thu, 14 Feb 2002 11:18:16 -0800 (PST) Message-ID: <01d001c1b58c$21e9e4b0$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] Comment on CAR requirements Date: Thu, 14 Feb 2002 11:16:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > > Just for recalling: > --------- > 3.9. DEPENDENCE ON A MOBILITY MANAGEMENT PROTOCOL > > CAR discovery MUST NOT depend on a particular mobility management > protocol. In other words, it MUST NOT utilize a feature which is unique > to a particular mobility management protocol. The output of CAR > discovery, however, MUST be usable by mobility management protocols. CAR > discovery MUST NOT deteriorate the performance of the underlying > mobility management protocol. > --------- > > In the second sentence, shouldn't it be '...it MUST NOT depend on a feature which is > unique...' rather than 'utilize'? Here's my thought: > Assuming a CAR solution that has an MIPV6 mode and a non-MIPV6 mode, and maybe a mixed > mode. The first one specifically utilizes MIPV6 if possible to implement CAR efficiently. > If the environment were non-MIPV6 (or we have a mixed environment in the sense > that some of the neighbors are MIPV6, the others are not), the non-MIPv6 or the mixed mode > are used. This should be a viable, albeit probably rather complex, solution, shouldn't it? > > However, the solution must not depend on this feature in the sense that it does not > work if the specific MM feature is not present, i.e., the other non-MIPV6 nodes are > simply not discovered. That's how I understood the dependence titel of this requirement. > > Any comments? > > Well, I suppose if you want to be precise, you have a point. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 15:05:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08398 for ; Thu, 14 Feb 2002 15:05:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22093; Thu, 14 Feb 2002 14:55:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22064 for ; Thu, 14 Feb 2002 14:55:05 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08104 for ; Thu, 14 Feb 2002 14:55:01 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1EJrojP003120; Thu, 14 Feb 2002 14:53:50 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA06594; Thu, 14 Feb 2002 14:53:44 -0500 (EST) Date: Thu, 14 Feb 2002 14:53:49 -0500 To: Marco Liebsch Cc: Yoshihiro Ohba , James Kempf , Behcet Sarikaya , seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging Message-ID: <20020214195349.GA1140@catfish> Mail-Followup-To: Marco Liebsch , Yoshihiro Ohba , James Kempf , Behcet Sarikaya , seamoby@ietf.org References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> <20020214162601.GB819@catfish> <3C6BF240.1B459AB0@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3C6BF240.1B459AB0@ccrle.nec.de> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 139 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Marco, On Thu, Feb 14, 2002 at 06:22:08PM +0100, Marco Liebsch wrote: > Yoshi, > > Yoshihiro Ohba wrote: > > > Jim, > > > > On Wed, Feb 13, 2002 at 06:07:19PM -0800, James Kempf wrote: > > > > Let's forget Simple IP. > > > > If we take 4.8 only then we can develop IP paging protocols for > > > v4 > > > > and v6 as extensions to mipv4 and mipv6 (as had been done on many > > > drafts). > > > > Then the problem is that requirement 4.7 is violated. So these > > > > protocols are not acceptable as far as RFC 3154 is concerned. > > > > If we take 4.7 only then we can develop IP paging protocols for v4 > > > > and v6 independent of mipv4/mipv6 (as had been done on one draft). > > > > Then the problem is that requirement 4.8 is violated. So these > > > > protocols are not acceptable as far as RFC 3154 is concerned. > > > > Trying to satisfy both 4.7 and 4.8 in one draft is like defining 4 > > > > protocols in one draft and each protocol considered in isolation would > > > > violate either 4.7 or 4.8. This is wrong, the implementations of such > > > > drafts can not be interoperability tested. > > > > This was my main point, I had been writing so many mails to explain > > > it > > > > over and over again. > > > > SOLUTION is > > > > 4.7 or 4.8 should be the requirement > > > > not 4.7 and 4.8. > > > > > > > > > > OK, now I think I understand. > > > > > > I think it is possible to support both requirements by > > > partitioning the paging protocol as I described in the original > > > message. The core protocol is independent of mobility > > > protocol with hooks for particular mobility management > > > protocols to handle dormant mode mobility. How the > > > mobility management protocols handle dormant mode > > > mobility is specified separately. > > > > > > Does this make sense? > > > > I think this would make sense. > > > > But I don't think the hooks described in draft-renker really satisfies > > the requirements 4.7 and 4.8 even with Explicit Mode (see below). > > > > > > > > W.r.t. IPv4/IPv6, there are issues here with features > > > of one not available in the other. The requirements > > > don't say anything about this, so I think we need > > > to open this up for discussion. > > > > > > > The scheme described in draft-renker relies on using the PA's address > > as the alternate CoA in order to redirect packets for the dormant host > > to the PA. However, when a redirected data packet is received by the > > PA, the PA must look into the inner IP header (or the final entry of > > Routing Header if route opmization is used) in which the MN's Home > > Address is contained in the destination IP address field in order to > > distinguish the MN, as described in the draft. > > Outer IP header is sripped away, since it addresses the PA in case of > making use of the alternate CoA in MIPv6. Then the PA has to check > the dest. addr. of the IP header, that's correct. In order systems, another > identifier carried with paging trigger packets might be checked. In case of > route optimization with MIPv6, the draft provides a statement, that > no bindings should be valid at CNs anymore when entering idle mode. > But for this specific case and for MIPv6, you are right, the PA has to > check the Home Address, since it is used as a more or less static identifier. > > > > > This is very unnatural > > way of dealing with IP-in-IP packet (or Routing Header) at an > > intermediary node. This is also related to the following comments > > from the assessment team: > > > > 2) There is no description of how the mobility management is > > completed after the paging request is received. There must be > > some coordination on when the deregistration is sent to PA. > > > > I think that the coordination is very difficult (especially in terms > > of security) as long as the solution relies on the use of the MN's > > Home Address at PA. > > > > The Homne address comes with the Idle State Request message > sent from MN to PA. Paging trigger packets are buffered until PA > has resolved MN's CoA (after wake up). The draft refers to more > identifiers, allowing the MN to tell to the PA. During active registration, > MN first tells the mobility agent of its current location, then the PA (in > order to avoid packet loss). That's the point. I don't understand how the PA delivers the buffered packets to the resolved MN's CoA by using the Home Address of the buffered packets for identifing the MN at PA especially when the PA is not co-located with the home agent corresponding to the Home Address. As far as I know, when a MIPv6 "home agent" transfers a packet to the MN, "home address" (i.e., the destination address of the IP packet before it is tunneled) always is "on-link" to the home agent. But when the PA is used for a MIPv6 "home agent" in the visiting network to transfer the buffered packet to the MN after paging, the "home address" is not "on-link" to the PA. So I'm wandering what is the magic behind it. Moreover, I think specifying the PA's address as an Alternate Care-of Address is NOT consistent with the following description in section 10.9 of draft-ietf-mobileip-ipv6-15.txt: In any Binding Update sent by a mobile node, the care-of address (either the Source Address in the packet's IPv6 header or the Care-of Address in the Alternate Care-of Address Sub-Option of the Binding Update) MUST be set to one of the care-of addresses currently in use by the mobile node or to the mobile node's home address. I think one-to-one mapping between the (Alternate) CoA and home address is necessary for Mobile IP to work, and Alternate Care-of Address in draft-renker is misused. That's why I mentioned: > In order to avoid this situation, an HMIPv6-like solution based on > Regional CoA would be necessary for draft-renker, but this feature is > not available for MIPv4. This means that the scheme is not really > independent of a mobility management protocol. > > Regards, > > Marco > What do you think? Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 15:32:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09020 for ; Thu, 14 Feb 2002 15:32:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23801; Thu, 14 Feb 2002 15:20:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23772 for ; Thu, 14 Feb 2002 15:20:06 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08722 for ; Thu, 14 Feb 2002 15:20:02 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1EKJ2e20623; Thu, 14 Feb 2002 12:19:02 -0800 (PST) Message-ID: <028101c1b594$9f3ff280$7e6015ac@T23KEMPF> From: "James Kempf" To: "Yoshihiro Ohba" Cc: "Behcet Sarikaya" , References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> <20020214162601.GB819@catfish> Subject: Re: [Seamoby] Moving forward with paging Date: Thu, 14 Feb 2002 12:17:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Yoshi, > But I don't think the hooks described in draft-renker really satisfies > the requirements 4.7 and 4.8 even with Explicit Mode (see below). > I wasn't proposing that these be used without any modification. > The scheme described in draft-renker relies on using the PA's address > as the alternate CoA in order to redirect packets for the dormant host > to the PA. However, when a redirected data packet is received by the > PA, the PA must look into the inner IP header (or the final entry of > Routing Header if route opmization is used) in which the MN's Home > Address is contained in the destination IP address field in order to > distinguish the MN, as described in the draft. This is very unnatural > way of dealing with IP-in-IP packet (or Routing Header) at an > intermediary node. What about simply using a Deering-Zill tunnel from the HA? Also, I'm not sure why a Routing Header wouldn't work. Suppose there is a Routing Header with the PA's address in it at some point, and what the PA does when it sees that header is to issue an IP page. Then, when the MN replies, it sends along the packet. It is up to the MN to renew it's mobility binding at the HA. >This is also related to the following comments > from the assessment team: > > 2) There is no description of how the mobility management is > completed after the paging request is received. There must be > some coordination on when the deregistration is sent to PA. > > I think that the coordination is very difficult (especially in terms > of security) as long as the solution relies on the use of the MN's > Home Address at PA. > I agree that security is difficult. It essentially requires constructing a trust relationship between the HA and PA that allows the PA to issue binding updates to the HA when the MN moves in dormant mode, on the mobile's behalf. But this is no different in principle than HMIPv6. The benefit is that there is no state on the mobile's location maintained in the foreign network, it is all with the HA. > In order to avoid this situation, an HMIPv6-like solution based on > Regional CoA would be necessary for draft-renker, but this feature is > not available for MIPv4. This means that the scheme is not really > independent of a mobility management protocol. > The issue I have with this is that the MNs location state gets maintained at a "routing proxy." This is a potential source of failure that needs to be replicated. Replication means expense. I think we want a solution that looks like routing, where nearby routers take over if one fails. I would rather confine an expensive replicated agent to the HA, where it is unavoidable, rather than introduce one into the foreign network. And, when the IRTF Micromobility Task Force comes up with a micromobility routing protocol, there will be no expensive routing proxy at all. W.r.t. MIPv4, I think Regional Registration is now Informational, though doesn't have an RFC number yet, it is like HMIPv6. But I don't think it should be used either. > On the other hand, the degree of "independency of mobility managenent > protocol" specified in draft-ohba is the highest among all the > proposals, and thus there is no problem of this kind with draft-ohba. > I think this is a very important point. > draft-ohba doesn't specify where the tracking agent is, in particular, it doesn't specify that it is handled by the mobility protocol. In addition, the security issue isn't discussed. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 15:54:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09413 for ; Thu, 14 Feb 2002 15:54:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25548; Thu, 14 Feb 2002 15:43:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25519 for ; Thu, 14 Feb 2002 15:43:49 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09210 for ; Thu, 14 Feb 2002 15:43:45 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1EKgje21397; Thu, 14 Feb 2002 12:42:45 -0800 (PST) Message-ID: <02ca01c1b597$ef5ca580$7e6015ac@T23KEMPF> From: "James Kempf" To: "James Kempf" , "Yoshihiro Ohba" Cc: "Behcet Sarikaya" , References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> <20020214162601.GB819@catfish> <028101c1b594$9f3ff280$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Moving forward with paging Date: Thu, 14 Feb 2002 12:41:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > draft-ohba doesn't specify where the tracking agent is, in particular, > it doesn't specify that it is handled by the mobility protocol. In > addition, > the security issue isn't discussed. > OK, I see in Section 8 the DMA can be an HA. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 16:45:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10771 for ; Thu, 14 Feb 2002 16:45:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28546; Thu, 14 Feb 2002 16:35:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28479 for ; Thu, 14 Feb 2002 16:35:00 -0500 (EST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10380 for ; Thu, 14 Feb 2002 16:34:56 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1ELYQ728178 for ; Thu, 14 Feb 2002 15:34:26 -0600 (CST) Message-ID: <3C6C2D5A.10702@alcatel.com> Date: Thu, 14 Feb 2002 15:34:18 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: Content-Type: multipart/alternative; boundary="------------060201020306090403070401" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------060201020306090403070401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pat and all, IP Paging is not an application like diameter not even transport layer like TCP, it is an IP level protocol. All the drafts that I know of including draft-renker and draft-ohba define IP Paging this way. I know that even IPv4/v6 are defined in so many RFCs, for the main protocol and its constituents such as ICMP, neighbor discovery, etc. I do not think that we are talking about publishing them together in a book which is always possible. Standards track RFCs have certain implications such as interoperability testing. IP Paging protocol for IPv4/v6 that is independent of MIPv4/v6 uses an architecture (which could be the same for v4/v6?) and MIPv4 has a DIFFERENT architecture and MIPv6 has another DIFFERENT architecture. How can one define protocols with different architectures/ messaging structures in one draft? (of course except for bundling them together as did draft-renker and draft-ohba) So let me ask again, is there any RFC of standard track that defines multiple protocols? I am curious to know this. Regards, Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > No, it does not. Can someone point to me an RFC of standard status > > which defines multiple protocols? IPv4/IPv6 are implemented in > > different stacks in todays technology. Mipv4/6 run using those > > stacks. I think that we should ask people to write their protocols > > in diferent drafts. What is wrong with this? > > I see absolutely no reason why applications cannot run over both > transports, Diameter is one such example of a protocol that can > handle both (as is SLP). I don't think we should be using MIP as the > example to follow. > > PatC > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > > > iQA/AwUBPGvuFzN1fXKoxmisEQIfigCeNA846vRXtrZtQFm58aK72R5JE/kAoIPb > 8cbRztEuqh6Hj0MJGm9rubqK > =bSOk > -----END PGP SIGNATURE----- > -- Behcet --------------060201020306090403070401 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Pat and all,
  IP Paging is not an application like diameter not even transport layer like TCP, it is an IP level protocol. All the drafts that I know of including draft-renker and draft-ohba define IP Paging this way.
  I know that even IPv4/v6 are defined in so many RFCs, for the main protocol and its constituents such as ICMP, neighbor discovery, etc. I do not think that we are talking about publishing them together in a book which is always possible.
   Standards track RFCs have certain implications such as interoperability testing.
  IP Paging protocol for IPv4/v6  that is independent of MIPv4/v6  uses an architecture (which could be the same for v4/v6?) and
  MIPv4 has a DIFFERENT architecture and MIPv6 has another DIFFERENT architecture.
  How can one define protocols with different architectures/ messaging structures in one draft? (of course except for bundling them together as did draft-renker and draft-ohba)
  So let me ask again, is there any RFC of standard track that defines multiple protocols? I am curious to know this.

Regards,

Pat R. Calhoun wrote:
RE: [Seamoby] Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> No, it does not. Can someone point to me an RFC of standard status
> which defines multiple protocols?  IPv4/IPv6 are implemented in
> different stacks in todays technology. Mipv4/6 run using those
> stacks. I  think that we should ask people to write their protocols
> in diferent drafts. What is wrong with this?  

I see absolutely no reason why applications cannot run over both
transports, Diameter is one such example of a protocol that can
handle both (as is SLP). I don't think we should be using MIP as the
example to follow.

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com >

iQA/AwUBPGvuFzN1fXKoxmisEQIfigCeNA846vRXtrZtQFm58aK72R5JE/kAoIPb
8cbRztEuqh6Hj0MJGm9rubqK
=bSOk
-----END PGP SIGNATURE-----


-- 
Behcet 

--------------060201020306090403070401-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 19:42:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13707 for ; Thu, 14 Feb 2002 19:42:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05415; Thu, 14 Feb 2002 19:21:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05371 for ; Thu, 14 Feb 2002 19:21:49 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13346 for ; Thu, 14 Feb 2002 19:21:47 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1F0LIs15111 for ; Thu, 14 Feb 2002 18:21:18 -0600 (CST) Message-ID: <3C6C5476.5080802@alcatel.com> Date: Thu, 14 Feb 2002 18:21:10 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> <20020214162601.GB819@catfish> <3C6BF240.1B459AB0@ccrle.nec.de> <20020214195349.GA1140@catfish> Content-Type: multipart/alternative; boundary="------------030406000504080107000400" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------030406000504080107000400 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit To Yoshi: Sorry but I downplay the technicality here as draft-renker in its MIP independent architecture uses PA only, and later on in the draft's implicit or explicit mode it tries to do every thing (packet capturing and paging, two distict functions ) using PA which is simply wrong architecturally. To James: I appreciate your solutions but can you please bundle them in a draft, like draft-kempf so that we can judge in its entirety? Regards, Yoshihiro Ohba wrote: >Hello Marco, > >On Thu, Feb 14, 2002 at 06:22:08PM +0100, Marco Liebsch wrote: > >>Yoshi, >> >>Yoshihiro Ohba wrote: >> >>>Jim, >>> >>>On Wed, Feb 13, 2002 at 06:07:19PM -0800, James Kempf wrote: >>> >>>>>Let's forget Simple IP. >>>>> If we take 4.8 only then we can develop IP paging protocols for >>>>> >>>>v4 >>>> >>>>>and v6 as extensions to mipv4 and mipv6 (as had been done on many >>>>> >>>>drafts). >>>> >>>>> Then the problem is that requirement 4.7 is violated. So these >>>>>protocols are not acceptable as far as RFC 3154 is concerned. >>>>> If we take 4.7 only then we can develop IP paging protocols for v4 >>>>>and v6 independent of mipv4/mipv6 (as had been done on one draft). >>>>> Then the problem is that requirement 4.8 is violated. So these >>>>>protocols are not acceptable as far as RFC 3154 is concerned. >>>>> Trying to satisfy both 4.7 and 4.8 in one draft is like defining 4 >>>>>protocols in one draft and each protocol considered in isolation would >>>>>violate either 4.7 or 4.8. This is wrong, the implementations of such >>>>>drafts can not be interoperability tested. >>>>> This was my main point, I had been writing so many mails to explain >>>>> >>>>it >>>> >>>>>over and over again. >>>>>SOLUTION is >>>>>4.7 or 4.8 should be the requirement >>>>>not 4.7 and 4.8. >>>>> >>>>OK, now I think I understand. >>>> >>>>I think it is possible to support both requirements by >>>>partitioning the paging protocol as I described in the original >>>>message. The core protocol is independent of mobility >>>>protocol with hooks for particular mobility management >>>>protocols to handle dormant mode mobility. How the >>>>mobility management protocols handle dormant mode >>>>mobility is specified separately. >>>> >>>>Does this make sense? >>>> >>>I think this would make sense. >>> >>>But I don't think the hooks described in draft-renker really satisfies >>>the requirements 4.7 and 4.8 even with Explicit Mode (see below). >>> >>>>W.r.t. IPv4/IPv6, there are issues here with features >>>>of one not available in the other. The requirements >>>>don't say anything about this, so I think we need >>>>to open this up for discussion. >>>> >>>The scheme described in draft-renker relies on using the PA's address >>>as the alternate CoA in order to redirect packets for the dormant host >>>to the PA. However, when a redirected data packet is received by the >>>PA, the PA must look into the inner IP header (or the final entry of >>>Routing Header if route opmization is used) in which the MN's Home >>>Address is contained in the destination IP address field in order to >>>distinguish the MN, as described in the draft. >>> >>Outer IP header is sripped away, since it addresses the PA in case of >>making use of the alternate CoA in MIPv6. Then the PA has to check >>the dest. addr. of the IP header, that's correct. In order systems, another >>identifier carried with paging trigger packets might be checked. In case of >>route optimization with MIPv6, the draft provides a statement, that >>no bindings should be valid at CNs anymore when entering idle mode. >>But for this specific case and for MIPv6, you are right, the PA has to >>check the Home Address, since it is used as a more or less static identifier. >> >> >> >>> This is very unnatural >>>way of dealing with IP-in-IP packet (or Routing Header) at an >>>intermediary node. This is also related to the following comments >>>from the assessment team: >>> >>> 2) There is no description of how the mobility management is >>> completed after the paging request is received. There must be >>> some coordination on when the deregistration is sent to PA. >>> >>>I think that the coordination is very difficult (especially in terms >>>of security) as long as the solution relies on the use of the MN's >>>Home Address at PA. >>> >>The Homne address comes with the Idle State Request message >>sent from MN to PA. Paging trigger packets are buffered until PA >>has resolved MN's CoA (after wake up). The draft refers to more >>identifiers, allowing the MN to tell to the PA. During active registration, >>MN first tells the mobility agent of its current location, then the PA (in >>order to avoid packet loss). >> > >That's the point. I don't understand how the PA delivers the buffered >packets to the resolved MN's CoA by using the Home Address of the >buffered packets for identifing the MN at PA especially when the PA is >not co-located with the home agent corresponding to the Home Address. > >As far as I know, when a MIPv6 "home agent" transfers a packet to the >MN, "home address" (i.e., the destination address of the IP packet >before it is tunneled) always is "on-link" to the home agent. But >when the PA is used for a MIPv6 "home agent" in the visiting network >to transfer the buffered packet to the MN after paging, the "home >address" is not "on-link" to the PA. So I'm wandering what is the >magic behind it. > >Moreover, I think specifying the PA's address as an Alternate Care-of >Address is NOT consistent with the following description in section >10.9 of draft-ietf-mobileip-ipv6-15.txt: > > In any Binding Update > sent by a mobile node, the care-of address (either the Source Address > in the packet's IPv6 header or the Care-of Address in the Alternate > Care-of Address Sub-Option of the Binding Update) MUST be set to one > of the care-of addresses currently in use by the mobile node or to > the mobile node's home address. > >I think one-to-one mapping between the (Alternate) CoA and home >address is necessary for Mobile IP to work, and Alternate Care-of >Address in draft-renker is misused. That's why I mentioned: > >>In order to avoid this situation, an HMIPv6-like solution based on >>Regional CoA would be necessary for draft-renker, but this feature is >>not available for MIPv4. This means that the scheme is not really >>independent of a mobility management protocol. >> > >>Regards, >> >>Marco >> > >What do you think? > >Yoshihiro Ohba > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > -- Behcet --------------030406000504080107000400 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit To Yoshi:
  Sorry but I downplay the technicality here as draft-renker in its MIP independent architecture uses PA only, and later on in the draft's implicit or explicit mode it tries to do every thing (packet capturing and paging, two distict functions ) using PA which is simply wrong architecturally.
 
To James:
  I appreciate your solutions but can you please bundle them in a draft, like draft-kempf so that we can judge in its entirety?

Regards,

Yoshihiro Ohba wrote:
Hello Marco,

On Thu, Feb 14, 2002 at 06:22:08PM +0100, Marco Liebsch wrote:
Yoshi,

Yoshihiro Ohba wrote:

Jim,

On Wed, Feb 13, 2002 at 06:07:19PM -0800, James Kempf wrote:
Let's forget Simple IP.
      If we take 4.8 only then we can develop IP paging protocols for
v4
and v6 as extensions to mipv4 and mipv6 (as had been done on many
drafts).
     Then the problem is that requirement 4.7 is violated. So these
protocols are not acceptable as far as RFC 3154 is concerned.
   If we take 4.7 only then we can develop IP paging protocols for v4
and v6  independent of mipv4/mipv6 (as had been done on one draft).
  Then the problem is that requirement 4.8 is violated. So these
protocols are not acceptable as far as RFC 3154 is concerned.
  Trying to satisfy both 4.7 and 4.8 in one draft is like defining 4
protocols in one draft and each protocol considered in isolation would
violate either 4.7 or 4.8. This is wrong, the implementations of such
drafts can not be interoperability tested.
  This was my main point, I had been writing so many mails to explain
it
over and over again.
SOLUTION is
4.7 or 4.8 should be the requirement
not 4.7 and 4.8.

OK, now I think I understand.

I think it is possible to support both requirements by
partitioning the paging protocol as I described in the original
message. The core protocol is independent of mobility
protocol with hooks for particular mobility management
protocols to handle dormant mode mobility. How the
mobility management protocols handle dormant mode
mobility is specified separately.

Does this make sense?
I think this would make sense.

But I don't think the hooks described in draft-renker really satisfies
the requirements 4.7 and 4.8 even with Explicit Mode (see below).

W.r.t. IPv4/IPv6, there are issues here with features
of one not available in the other. The requirements
don't say anything about this, so I think we need
to open this up for discussion.

The scheme described in draft-renker relies on using the PA's address
as the alternate CoA in order to redirect packets for the dormant host
to the PA.  However, when a redirected data packet is received by the
PA, the PA must look into the inner IP header (or the final entry of
Routing Header if route opmization is used) in which the MN's Home
Address is contained in the destination IP address field in order to
distinguish the MN, as described in the draft.
Outer IP header is sripped away, since it addresses the PA in case of
making use of the alternate CoA in MIPv6. Then the PA has to check
the dest. addr. of the IP header, that's correct. In order systems, another
identifier carried with paging trigger packets might be checked. In case of
route optimization with MIPv6, the draft provides a statement, that
no bindings should be valid at CNs anymore when entering idle mode.
But for this specific case and for MIPv6, you are right, the PA has to
check the Home Address, since it is used as a more or less static identifier.



 This is very unnatural
way of dealing with IP-in-IP packet (or Routing Header) at an
intermediary node.  This is also related to the following comments
from the assessment team:

  2) There is no description of how the mobility management is
     completed after the paging request is received.  There must be
     some coordination on when the deregistration is sent to PA.

I think that the coordination is very difficult (especially in terms
of security) as long as the solution relies on the use of the MN's
Home Address at PA.

The Homne address comes with the Idle State Request message
sent from MN to PA. Paging trigger packets are buffered until PA
has resolved MN's CoA (after wake up). The draft refers to more
identifiers, allowing the MN to tell to the PA. During active registration,
MN first tells the mobility agent of its current location, then the PA (in
order to avoid packet loss).

That's the point.  I don't understand how the PA delivers the buffered
packets to the resolved MN's CoA by using the Home Address of the
buffered packets for identifing the MN at PA especially when the PA is
not co-located with the home agent corresponding to the Home Address.

As far as I know, when a MIPv6 "home agent" transfers a packet to the
MN, "home address" (i.e., the destination address of the IP packet
before it is tunneled) always is "on-link" to the home agent.  But
when the PA is used for a MIPv6 "home agent" in the visiting network
to transfer the buffered packet to the MN after paging, the "home
address" is not "on-link" to the PA.  So I'm wandering what is the
magic behind it.

Moreover, I think specifying the PA's address as an Alternate Care-of
Address is NOT consistent with the following description in section
10.9 of draft-ietf-mobileip-ipv6-15.txt:

   In any B
inding Update
   sent by a mobile node, the care-of address (either the Source Address
   in the packet's IPv6 header or the Care-of Address in the Alternate
   Care-of Address Sub-Option of the Binding Update) MUST be set to one
   of the care-of addresses currently in use by the mobile node or to
   the mobile node's home address.

I think one-to-one mapping between the (Alternate) CoA and home
address is necessary for Mobile IP to work, and Alternate Care-of
Address in draft-renker is misused.  That's why I mentioned:

In order to avoid this situation, an HMIPv6-like solution based on
Regional CoA would be necessary for draft-renker, but this feature is
not available for MIPv4.  This means that the scheme is not really
independent of a mobility management protocol.

Regards,

Marco


What do you think?

Yoshihiro Ohba

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

-- 
Behcet

--------------030406000504080107000400-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 20:32:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14420 for ; Thu, 14 Feb 2002 20:32:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07456; Thu, 14 Feb 2002 20:18:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07429 for ; Thu, 14 Feb 2002 20:18:18 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14177 for ; Thu, 14 Feb 2002 20:18:16 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7R6GD>; Thu, 14 Feb 2002 17:17:48 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Behcet Sarikaya'" , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward with paging Date: Thu, 14 Feb 2002 17:17:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B5BE.91A1AC70" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B5BE.91A1AC70 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > To James: > I appreciate your solutions but can you please bundle them in a > draft, like draft-kempf > so that we can judge in its entirety? I somehow missed Jim's proposal, but we really should be discussing the drafts at hand, not additional proposals. Of course, as we get past this selection process, we will need to augment the starting point... PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGxhtzN1fXKoxmisEQLJzwCggz+MAIqBVn1QH+/BBh7dPF/NDYUAoKPK JzC/pJOjl8zgZfgAIU1eMeSp =veJD -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B5BE.91A1AC70 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 
> To James:
>  I appreciate your solutions but can you = please bundle them in a
> draft, like draft-kempf > so that we can = judge in its entirety? 

I somehow missed Jim's proposal, but we really should = be discussing
the drafts at hand, not additional proposals. Of = course, as we get
past this selection process, we will need to augment = the starting
point...

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPGxhtzN1fXKoxmisEQLJzwCggz+MAIqBVn1QH+/BBh7dPF/NDYUAoKP= K
JzC/pJOjl8zgZfgAIU1eMeSp
=3DveJD
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B5BE.91A1AC70-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 22:00:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16296 for ; Thu, 14 Feb 2002 22:00:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10514; Thu, 14 Feb 2002 21:50:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10486 for ; Thu, 14 Feb 2002 21:50:21 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16158 for ; Thu, 14 Feb 2002 21:50:17 -0500 (EST) Received: from T23KEMPF (dhcp149.docomolabs-usa.com [172.21.96.149]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1F2nme04584 for ; Thu, 14 Feb 2002 18:49:48 -0800 (PST) Message-ID: <000001c1b5cb$36514990$956015ac@T23KEMPF> From: "James Kempf" To: Date: Thu, 14 Feb 2002 14:20:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I'm separating out the thread about how to get packets from the HA to the dormant mode mobile so I can follow the issues. So my understanding of the primary issues are: 1) The alternate CoA won't work because the PA address doesn't belong to the MN. 2) Using Routing Headers and the Home Address Option to route packets from the HA to the PA results in awkward and unusual processing at the PA. 3) It is not clear how packets would get to the MN after it responds to the page, because the incoming packet has the MN's Home Address on the encapsulated packet, not the CoA. Here's a tenatitive suggestion about how to solve this. This requires an extension to MIP and a MIP binding for the paging protocol, and assumes that the Paging Agent and DMA are bundled into a network element called the PA. 1) The MN or the PA (after the right trust relationship has been established) sends a BU to the HA when the MN goes into dormant mode or the PA detects that the MN has gone into dormant mode. The BU is not a standard BU, but a "paging BU", with maybe an additional option or flag. The address of the PA is included to indicate where the HA should send any packets. The HA maintains a "dormant mode binding" for the mobile. 2) When the MN changes paging area, either it or, if an L2 paging protocol is available, the AR where the L2 paging protocol is terminated informs the PA. The PA then sends the BU to the HA, the HA changes its dormant mode binding. (Note: there is some handwaving here about how the trust relationship gets transferred from the PA handling the orignal paging area and the PA handling the new, but this could be solved by having the PAs use a trust relationship between them to have the original PA do the actual location update). 3) When the HA receives a packet for a MN for which it has a dormant mode binding, it sets up a tunnel to the PA and sends the packet down the tunnel. 4) The PA executes paging, the MN responds after having re-established its routing by sending a BU to the HA with its new CoA. The response includes the CoA. 5) The PA then tunnels the packet to the MN at the new CoA. The tunnel looks exactly like the tunnel from the HA would. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 14 22:25:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16618 for ; Thu, 14 Feb 2002 22:25:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11566; Thu, 14 Feb 2002 22:15:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11534 for ; Thu, 14 Feb 2002 22:15:11 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16472 for ; Thu, 14 Feb 2002 22:15:07 -0500 (EST) Received: from T23KEMPF (dhcp149.docomolabs-usa.com [172.21.96.149]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1F3Ece05435; Thu, 14 Feb 2002 19:14:38 -0800 (PST) Message-ID: <006301c1b5ce$ae5b3d30$956015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> <20020214162601.GB819@catfish> <3C6BF240.1B459AB0@ccrle.nec.de> <20020214195349.GA1140@catfish> <3C6C5476.5080802@alcatel.com> Subject: Re: [Seamoby] Moving forward with paging Date: Thu, 14 Feb 2002 19:12:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Behcet, > I appreciate your solutions but can you please bundle them in a draft, > like draft-kempf so that we can judge in its entirety? > > As Yoshi pointed out, I didn't propose anything that draft-ohba and draft-renker didn't. What we are trying to sort out now is the mechanism. The proposal in draft-ohba isn't complete, and the proposal in draft-renker has some problems. Technical discussion of this sort is, after all, the intent of this mailing list. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 15 05:57:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01851 for ; Fri, 15 Feb 2002 05:57:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12179; Fri, 15 Feb 2002 05:42:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12109 for ; Fri, 15 Feb 2002 05:42:40 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01717 for ; Fri, 15 Feb 2002 05:42:37 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1FAgAg52002; Fri, 15 Feb 2002 11:42:10 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA09024; Fri, 15 Feb 2002 11:42:06 +0100 Message-ID: <3C6CE5FE.BDCEA3BD@ccrle.nec.de> Date: Fri, 15 Feb 2002 11:42:06 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshihiro Ohba CC: James Kempf , Behcet Sarikaya , seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> <20020214162601.GB819@catfish> <3C6BF240.1B459AB0@ccrle.nec.de> <20020214195349.GA1140@catfish> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi Yoshi, Yoshihiro Ohba wrote: > Hello Marco, > > On Thu, Feb 14, 2002 at 06:22:08PM +0100, Marco Liebsch wrote: > > Yoshi, > > > > Yoshihiro Ohba wrote: > > > > > Jim, > > > > > > On Wed, Feb 13, 2002 at 06:07:19PM -0800, James Kempf wrote: > > > > > Let's forget Simple IP. > > > > > If we take 4.8 only then we can develop IP paging protocols for > > > > v4 > > > > > and v6 as extensions to mipv4 and mipv6 (as had been done on many > > > > drafts). > > > > > Then the problem is that requirement 4.7 is violated. So these > > > > > protocols are not acceptable as far as RFC 3154 is concerned. > > > > > If we take 4.7 only then we can develop IP paging protocols for v4 > > > > > and v6 independent of mipv4/mipv6 (as had been done on one draft). > > > > > Then the problem is that requirement 4.8 is violated. So these > > > > > protocols are not acceptable as far as RFC 3154 is concerned. > > > > > Trying to satisfy both 4.7 and 4.8 in one draft is like defining 4 > > > > > protocols in one draft and each protocol considered in isolation would > > > > > violate either 4.7 or 4.8. This is wrong, the implementations of such > > > > > drafts can not be interoperability tested. > > > > > This was my main point, I had been writing so many mails to explain > > > > it > > > > > over and over again. > > > > > SOLUTION is > > > > > 4.7 or 4.8 should be the requirement > > > > > not 4.7 and 4.8. > > > > > > > > > > > > > OK, now I think I understand. > > > > > > > > I think it is possible to support both requirements by > > > > partitioning the paging protocol as I described in the original > > > > message. The core protocol is independent of mobility > > > > protocol with hooks for particular mobility management > > > > protocols to handle dormant mode mobility. How the > > > > mobility management protocols handle dormant mode > > > > mobility is specified separately. > > > > > > > > Does this make sense? > > > > > > I think this would make sense. > > > > > > But I don't think the hooks described in draft-renker really satisfies > > > the requirements 4.7 and 4.8 even with Explicit Mode (see below). > > > > > > > > > > > W.r.t. IPv4/IPv6, there are issues here with features > > > > of one not available in the other. The requirements > > > > don't say anything about this, so I think we need > > > > to open this up for discussion. > > > > > > > > > > The scheme described in draft-renker relies on using the PA's address > > > as the alternate CoA in order to redirect packets for the dormant host > > > to the PA. However, when a redirected data packet is received by the > > > PA, the PA must look into the inner IP header (or the final entry of > > > Routing Header if route opmization is used) in which the MN's Home > > > Address is contained in the destination IP address field in order to > > > distinguish the MN, as described in the draft. > > > > Outer IP header is sripped away, since it addresses the PA in case of > > making use of the alternate CoA in MIPv6. Then the PA has to check > > the dest. addr. of the IP header, that's correct. In order systems, another > > identifier carried with paging trigger packets might be checked. In case of > > route optimization with MIPv6, the draft provides a statement, that > > no bindings should be valid at CNs anymore when entering idle mode. > > But for this specific case and for MIPv6, you are right, the PA has to > > check the Home Address, since it is used as a more or less static identifier. > > > > > > > > > This is very unnatural > > > way of dealing with IP-in-IP packet (or Routing Header) at an > > > intermediary node. This is also related to the following comments > > > from the assessment team: > > > > > > 2) There is no description of how the mobility management is > > > completed after the paging request is received. There must be > > > some coordination on when the deregistration is sent to PA. > > > > > > I think that the coordination is very difficult (especially in terms > > > of security) as long as the solution relies on the use of the MN's > > > Home Address at PA. > > > > > > > The Homne address comes with the Idle State Request message > > sent from MN to PA. Paging trigger packets are buffered until PA > > has resolved MN's CoA (after wake up). The draft refers to more > > identifiers, allowing the MN to tell to the PA. During active registration, > > MN first tells the mobility agent of its current location, then the PA (in > > order to avoid packet loss). > > That's the point. I don't understand how the PA delivers the buffered > packets to the resolved MN's CoA by using the Home Address of the > buffered packets for identifing the MN at PA especially when the PA is > not co-located with the home agent corresponding to the Home Address. > As far as I know, when a MIPv6 "home agent" transfers a packet to the > MN, "home address" (i.e., the destination address of the IP packet > before it is tunneled) always is "on-link" to the home agent. But > when the PA is used for a MIPv6 "home agent" in the visiting network > to transfer the buffered packet to the MN after paging, the "home > address" is not "on-link" to the PA. So I'm wandering what is the > magic behind it. > No magic. What do you mean by 'on-link'? It's not the 'link-local' address, if you referred to this address. HA intercepts packets on behalf of the MN, addressed to its 'global' IPv6 address (registered as a binding with the HA). Than HA tunnels packets, inner packets address global address of CN (as source) and global home address of MN (as dest). Outer header identifies the HA's global address as source and the MN's CoA as dest. So, why should the MN not to be identified by its home address? It's at least a more static ID as CoA is. When going dormant, the MN registers as idle with the PA, telling him its ID(s), which is the home address in case of MIP. Other systems might identify the MN by different means. > > Moreover, I think specifying the PA's address as an Alternate Care-of > Address is NOT consistent with the following description in section > 10.9 of draft-ietf-mobileip-ipv6-15.txt: > > In any Binding Update > sent by a mobile node, the care-of address (either the Source Address > in the packet's IPv6 header or the Care-of Address in the Alternate > Care-of Address Sub-Option of the Binding Update) MUST be set to one > of the care-of addresses currently in use by the mobile node or to > the mobile node's home address. > Right. And in case of a MN going dormant, is uses the global PA address as CoA. Same as hierarchical approaches make use of, which is registration of, for example, a MAP with the HA, making use of the alternate CoA sub-option. In my opinion it is reasonable to allow a MN to register a CoA which is different to the source address of the IP packet carrying the BU. What is to ensure is that HA authenticates the BU coming from the MN. Therefore, only MN is allowed to send the BU, since only MN and HA have a security association (with stand. MIP). Regards, Marco > > I think one-to-one mapping between the (Alternate) CoA and home > address is necessary for Mobile IP to work, and Alternate Care-of > Address in draft-renker is misused. That's why I mentioned: > > > In order to avoid this situation, an HMIPv6-like solution based on > > Regional CoA would be necessary for draft-renker, but this feature is > > not available for MIPv4. This means that the scheme is not really > > independent of a mobility management protocol. > > > > > Regards, > > > > Marco > > > > What do you think? > > Yoshihiro Ohba > > _______________________________________________ > 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 Fri Feb 15 06:49:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02260 for ; Fri, 15 Feb 2002 06:49:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13821; Fri, 15 Feb 2002 06:30:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13781 for ; Fri, 15 Feb 2002 06:29:59 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02010 for ; Fri, 15 Feb 2002 06:29:58 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1FBTSg53599; Fri, 15 Feb 2002 12:29:28 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA09716; Fri, 15 Feb 2002 12:29:27 +0100 Message-ID: <3C6CF117.2A2CCA2C@ccrle.nec.de> Date: Fri, 15 Feb 2002 12:29:27 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Jim, James Kempf wrote: > I'm separating out the thread about how to get packets from the HA to > the dormant mode mobile so I can follow the issues. > > So my understanding of the primary issues are: > > 1) The alternate CoA won't work because the PA address doesn't belong to > the MN. > In case of MN going dormant, it acquires no CoA when entering a new lcoation. Therefore, PA address is the MN's CoA, registered with the HA. Same as hierarchical approaches intend to do. In my eyes it is reasonable to allow a MN to register a CoA, which is different to one or more addresses assigned to its local interface (e.g. PA, MAP, ...). Otherwise, what is the alt. CoA sub option then for? > > 2) Using Routing Headers and the Home Address Option to route packets > from the HA to the PA results in awkward and unusual processing at the > PA. > In case of capturing/intercepting packets on a DMA located 'somewhere', is this processing less unusual? DMA has to check IP-IP encapsulated packets (when tunnel set up by HA) as well and to re-address after getting CoA info in order to allow forwarding of buffered packets. I'm not sure. > > 3) It is not clear how packets would get to the MN after it responds to > the page, because the incoming packet has the MN's Home Address on the > encapsulated packet, not the CoA. > Idea was to register an identifyer with the PA when a MN enters dormant mode. This is the home address in case of MIPv6, as an example. After the paging trigger packet arrives at DMA FE (currently located in the PA node), the PA checks registration status and initiates polling the paging area. During active registration, MN notifies the PA of its CoA, allowing to forward paging trigger packets. > > Here's a tenatitive suggestion about how to solve this. This requires an > extension to MIP and a MIP binding for the paging protocol, and assumes > that the Paging Agent and DMA are bundled into a network element called > the PA. > > 1) The MN or the PA (after the right trust relationship has been > established) sends a BU to the HA when the MN goes into dormant mode or > the PA detects that the MN has gone into dormant mode. The BU is not a > standard BU, but a "paging BU", with maybe an additional option or flag. > The address of the PA is included to indicate where the HA should send > any packets. The HA maintains a "dormant mode binding" for the mobile. > 2) When the MN changes paging area, either it or, if an L2 paging > protocol is available, the AR where the L2 paging protocol is terminated > informs the PA. The PA then sends the BU to the HA, the HA changes its > dormant mode binding. > (Note: there is some handwaving here about how the trust relationship > gets transferred from the PA handling the orignal paging area and the PA > handling the new, but this could be solved by having the PAs use a trust > relationship between them to have the original PA do the actual location > update). > Intentionally, PA node might manage multiple paging areas. This has many advantages, like keeping PA registration with HA in case of entering a new paging area, dynamic paging area management (maybe individual paging areas).. Allowing the PA to send a BU to the HA is a very special case and requires establishment of a security association. > > 3) When the HA receives a packet for a MN for which it has a dormant > mode binding, it sets up a tunnel to the PA and sends the packet down > the tunnel. > > 4) The PA executes paging, the MN responds after having re-established > its routing by sending a BU to the HA with its new CoA. The response > includes the CoA. > That's how draft-renker intends to manage. > > 5) The PA then tunnels the packet to the MN at the new CoA. The tunnel > looks exactly like the tunnel from the HA would. > ...only that the source address of the outer IP header might be the PA address instead of the HA address. marco > > Comments? > > 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 From seamoby-admin@ietf.org Fri Feb 15 10:53:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08895 for ; Fri, 15 Feb 2002 10:53:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26328; Fri, 15 Feb 2002 10:40:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26299 for ; Fri, 15 Feb 2002 10:40:40 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08342 for ; Fri, 15 Feb 2002 10:40:38 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1FFeAL27599 for ; Fri, 15 Feb 2002 09:40:10 -0600 (CST) Message-ID: <3C6D2BCF.8010403@alcatel.com> Date: Fri, 15 Feb 2002 09:39:59 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> <20020214162601.GB819@catfish> <3C6BF240.1B459AB0@ccrle.nec.de> <20020214195349.GA1140@catfish> <3C6C5476.5080802@alcatel.com> <006301c1b5ce$ae5b3d30$956015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------070006040205020306070208" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------070006040205020306070208 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit James, Pat and all, I thought we should first sort out the problems in RFC3154 that I pointed out and so far no reply came. Therefore it is fair to conclude that RFC3154's requirements 4.7 and 4.8 are impossible to be satified in one protocol and according to well established rules in IETF it is possible to define several protocols in one draft of standards track and here is the mathematical proof that it is impossible to satisfy 4.7 and 4.8. Recalling back from the design team discussions, can I state that James insisted on puting these two requirements despite e.g. my comments and therefore led people like draft-renker, draft-ohba and even draft-koodli to come up with strange drafts in which a different protocol is presented as a mode? How can we continue to discuss the details in these two drafts? They do not in any way present viable solutions to the problem. it is just loss of time to do that. Regards, James Kempf wrote: >Behcet, > >>I appreciate your solutions but can you please bundle them in a draft, >>like draft-kempf so that we can judge in its entirety? >> >> > >As Yoshi pointed out, I didn't propose anything that draft-ohba and >draft-renker didn't. What we are trying to sort out now is the >mechanism. >The proposal in draft-ohba isn't complete, and the proposal in >draft-renker >has some problems. > >Technical discussion of this sort is, after all, the intent of this >mailing list. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > -- Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S 026 1000 Coit Road PB7 Plano, TX 75075 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 477 2794 Fax: (972) 519 2460 --------------070006040205020306070208 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit James, Pat and all,
  I thought we should first sort out the problems in RFC3154 that I pointed out and so far no reply came.
  Therefore it is fair to conclude that RFC3154's requirements 4.7 and 4.8 are impossible to be satified in one protocol and according to well established rules in IETF it is possible to define several protocols in one draft of standards track and here is the mathematical proof that it is impossible to satisfy 4.7 and 4.8.
  Recalling back from the design team discussions, can I state that James insisted on puting these two requirements despite e.g. my comments and therefore led people like draft-renker, draft-ohba and even draft-koodli to come up with strange drafts in which a different protocol is presented as a mode?
  How can we continue to discuss the details in these two drafts?  They do not in any way present viable solutions to the problem. it is just loss of time to do that.

Regards,
 

James Kempf wrote:
Behcet,

I appreciate your solutions but can you please bundle them in a draft,
like draft-kempf so that we can judge in its entirety?



As Yoshi pointed out, I didn't propose anything that draft-ohba and
draft-renker didn't. What we are trying to sort out now is the
mechanism.
The proposal in draft-ohba isn't complete, and the proposal in
draft-renker
has some problems.

Technical discussion of this sort is, after all, the intent of this
mailing list.

            jak


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

-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460

--------------070006040205020306070208-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 15 11:03:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09340 for ; Fri, 15 Feb 2002 11:03:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26968; Fri, 15 Feb 2002 10:51:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26893 for ; Fri, 15 Feb 2002 10:51:50 -0500 (EST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08800 for ; Fri, 15 Feb 2002 10:51:47 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1FFpJ705034 for ; Fri, 15 Feb 2002 09:51:19 -0600 (CST) Message-ID: <3C6D2E6C.3030809@alcatel.com> Date: Fri, 15 Feb 2002 09:51:08 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging -resending due to a small mistake in previous References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> <20020214162601.GB819@catfish> <3C6BF240.1B459AB0@ccrle.nec.de> <20020214195349.GA1140@catfish> <3C6C5476.5080802@alcatel.com> <006301c1b5ce$ae5b3d30$956015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------030202070804050908020004" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------030202070804050908020004 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit James, Pat and all, I thought we should first sort out the problems in RFC3154 that I pointed out and so far no reply came. Therefore it is fair to conclude that RFC3154's requirements 4.7 and 4.8 are impossible to be satified in one protocol and according to well established rules in IETF it is NOT possible to define several protocols in one draft of standards track and here is the mathematical proof that it is impossible to satisfy 4.7 and 4.8. Recalling back from the design team discussions, can I state that James insisted on puting these two requirements despite e.g. my comments and therefore led people like draft-renker, draft-ohba and even draft-koodli to come up with strange drafts in which a different protocol is presented as a mode? How can we continue to discuss the details in these two drafts? They do not in any way present viable solutions to the problem. it is just loss of time to do that. Regards, James Kempf wrote: >Behcet, > >>I appreciate your solutions but can you please bundle them in a draft, >>like draft-kempf so that we can judge in its entirety? >> >> > >As Yoshi pointed out, I didn't propose anything that draft-ohba and >draft-renker didn't. What we are trying to sort out now is the >mechanism. >The proposal in draft-ohba isn't complete, and the proposal in >draft-renker >has some problems. > >Technical discussion of this sort is, after all, the intent of this >mailing list. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > -- Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S 026 1000 Coit Road PB7 Plano, TX 75075 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 477 2794 Fax: (972) 519 2460 --------------030202070804050908020004 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit James, Pat and all,
  I thought we should first sort out the problems in RFC3154 that I pointed out and so far no reply came.
  Therefore it is fair to conclude that RFC3154's requirements 4.7 and 4.8 are impossible to be satified in one protocol and according to well established rules in IETF it is NOT possible to define several protocols in one draft of standards track and here is the mathematical proof that it is impossible to satisfy 4.7 and 4.8.
  Recalling back from the design team discussions, can I state that James insisted on puting these two requirements despite e.g. my comments and therefore led people like draft-renker, draft-ohba and even draft-koodli to come up with strange drafts in which a different protocol is presented as a mode?
  How can we continue to discuss the details in these two drafts?  They do not in any way present viable solutions to the problem. it is just loss of time to do that.

Regards,
 

James Kempf wrote:
Behcet,

I appreciate your solutions but can you please bundle them in a draft,
like draft-kempf so that we can judge in its entirety?



As Yoshi pointed out, I didn't propose anything that draft-ohba and
draft-renker didn't. What we are trying to sort out now is the
mechanism.
The proposal in draft-ohba isn't complete, and the proposal in
draft-renker
has some problems.

Technical discussion of this sort is, after all, the intent of this
mailing list.

            jak


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

-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460


--------------030202070804050908020004-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 15 11:11:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09694 for ; Fri, 15 Feb 2002 11:11:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27509; Fri, 15 Feb 2002 10:59:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27481 for ; Fri, 15 Feb 2002 10:59:13 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09142 for ; Fri, 15 Feb 2002 10:58:28 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7R634>; Fri, 15 Feb 2002 07:58:00 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Behcet Sarikaya'" , seamoby@ietf.org Subject: RE: [Seamoby] Moving forward with paging Date: Fri, 15 Feb 2002 07:57:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B639.84FE1640" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1B639.84FE1640 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think what it means is that we log this as a problem that must be resolved once we've selected the base. It is also quite acceptable to be discussing possible solutions at this time. I'm still not convinced that it means we need two separate protocols, but I could be wrong. PatC - -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Friday, February 15, 2002 7:40 AM To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging James, Pat and all, I thought we should first sort out the problems in RFC3154 that I pointed out and so far no reply came. Therefore it is fair to conclude that RFC3154's requirements 4.7 and 4.8 are impossible to be satified in one protocol and according to well established rules in IETF it is possible to define several protocols in one draft of standards track and here is the mathematical proof that it is impossible to satisfy 4.7 and 4.8. Recalling back from the design team discussions, can I state that James insisted on puting these two requirements despite e.g. my comments and therefore led people like draft-renker, draft-ohba and even draft-koodli to come up with strange drafts in which a different protocol is presented as a mode? How can we continue to discuss the details in these two drafts? They do not in any way present viable solutions to the problem. it is just loss of time to do that. Regards, James Kempf wrote: Behcet, I appreciate your solutions but can you please bundle them in a draft,like draft-kempf so that we can judge in its entirety? As Yoshi pointed out, I didn't propose anything that draft-ohba anddraft-renker didn't. What we are trying to sort out now is themechanism.The proposal in draft-ohba isn't complete, and the proposal indraft-renkerhas some problems.Technical discussion of this sort is, after all, the intent of thismailing list. jak_______________________________________________Seamoby mailing listSeamoby@ietf.orghttps://www1.ietf.org/mailman/listinfo/seamoby - -- Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S 026 1000 Coit Road PB7 Plano, TX 75075 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 477 2794 Fax: (972) 519 2460 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPG0v/jN1fXKoxmisEQJkfgCfd7B4D2ZBOIzKZ4ErHhhu9zmeQ10AoMdg 4G2qWLedt7EjGX15T0/P7f2L =M7NK -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B639.84FE1640 Content-Type: text/html RE: [Seamoby] Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think what it means is that we log this as a problem that must be
resolved once we've selected the base. It is also quite acceptable to
be discussing possible solutions at this time.

I'm still not convinced that it means we need two separate protocols,
but I could be wrong.

PatC
- -----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Friday, February 15, 2002 7:40 AM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Moving forward with paging


James, Pat and all,
  I thought we should first sort out the problems in RFC3154 that I
pointed out and so far no reply came.
  Therefore it is fair to conclude that RFC3154's requirements 4.7
and 4.8 are impossible to be satified in one protocol and according
to well established rules in IETF it is possible to define several
protocols in one draft of standards track and here is the
mathematical proof that it is impossible to satisfy 4.7 and 4.8.
  Recalling back from the design team discussions, can I state that
James insisted on puting these two requirements despite e.g. my
comments and therefore led people like draft-renker, draft-ohba and
even draft-koodli to come up with strange drafts in which a different
protocol is presented as a mode?
  How can we continue to discuss the details in these two drafts?
They do not in any way present viable solutions to the problem. it is
just loss of time to do that.

Regards,
 

James Kempf wrote:

Behcet,
I appreciate your solutions but can you please bundle them in a
draft,like draft-kempf so that we can judge in its entirety?
As Yoshi pointed out, I didn't propose anything that draft-ohba
anddraft-renker didn't. What we are trying to sort out now is
themechanism.The proposal in draft-ohba isn't complete, and the
proposal indraft-renkerhas some problems.Technical discussion of this
sort is, after all, the intent of thismailing list.          
jak_______________________________________________Seamoby mailing
listSeamoby@ietf.orghttps://www1.ietf.org/mailman/listinfo/seamoby


- --
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPG0v/jN1fXKoxmisEQJkfgCfd7B4D2ZBOIzKZ4ErHhhu9zmeQ10AoMdg
4G2qWLedt7EjGX15T0/P7f2L
=M7NK
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B639.84FE1640-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 15 12:02:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11428 for ; Fri, 15 Feb 2002 12:02:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01295; Fri, 15 Feb 2002 11:47:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01231 for ; Fri, 15 Feb 2002 11:47:24 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10945 for ; Fri, 15 Feb 2002 11:47:21 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1FGkrL16479 for ; Fri, 15 Feb 2002 10:46:53 -0600 (CST) Message-ID: <3C6D3B72.3000700@alcatel.com> Date: Fri, 15 Feb 2002 10:46:42 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: Content-Type: multipart/alternative; boundary="------------060100060703000209060502" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------060100060703000209060502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Even if it means the base draft will turn out to be ineligible? Because we are taking about a problem in the requirements upon which the assessment process was conducted. Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I think what it means is that we log this as a problem that must be > resolved once we've selected the base. It is also quite acceptable to > be discussing possible solutions at this time. > > I'm still not convinced that it means we need two separate protocols, > but I could be wrong. > > PatC > - -----Original Message----- > From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ] > Sent: Friday, February 15, 2002 7:40 AM > To: seamoby@ietf.org > Subject: Re: [Seamoby] Moving forward with paging > > > James, Pat and all, > I thought we should first sort out the problems in RFC3154 that I > pointed out and so far no reply came. > Therefore it is fair to conclude that RFC3154's requirements 4.7 > and 4.8 are impossible to be satified in one protocol and according > to well established rules in IETF it is possible to define several > protocols in one draft of standards track and here is the > mathematical proof that it is impossible to satisfy 4.7 and 4.8. > Recalling back from the design team discussions, can I state that > James insisted on puting these two requirements despite e.g. my > comments and therefore led people like draft-renker, draft-ohba and > even draft-koodli to come up with strange drafts in which a different > protocol is presented as a mode? > How can we continue to discuss the details in these two drafts? > They do not in any way present viable solutions to the problem. it is > just loss of time to do that. > > Regards, > > > James Kempf wrote: > > Behcet, > I appreciate your solutions but can you please bundle them in a > draft,like draft-kempf so that we can judge in its entirety? > As Yoshi pointed out, I didn't propose anything that draft-ohba > anddraft-renker didn't. What we are trying to sort out now is > themechanism.The proposal in draft-ohba isn't complete, and the > proposal indraft-renkerhas some problems.Technical discussion of this > sort is, after all, the intent of thismailing list. > jak_______________________________________________Seamoby mailing > listSeamoby@ietf.orghttps://www1.ietf.org/mailman/listinfo/seamoby > > > - -- > Behcet Sarikaya > Network Strategy Group, Mobile Networking Team > Alcatel USA M/S 026 > 1000 Coit Road PB7 > Plano, TX 75075 USA > Email: behcet.sarikaya@alcatel.com > Phone: (972) 477 2794 Fax: (972) 519 2460 > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > > > iQA/AwUBPG0v/jN1fXKoxmisEQJkfgCfd7B4D2ZBOIzKZ4ErHhhu9zmeQ10AoMdg > 4G2qWLedt7EjGX15T0/P7f2L > =M7NK > -----END PGP SIGNATURE----- > Regards, -- Behcet --------------060100060703000209060502 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Even if it means the base draft will turn out to be ineligible?
Because we are taking about a problem in the requirements upon which the assessment process was conducted.

Pat R. Calhoun wrote:
RE: [Seamoby] Moving forward with paging

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think what it means is that we log this as a problem that must be
resolved once we've selected the base. It is also quite acceptable to
be discussing possible solutions at this time.

I'm still not convinced that it means we need two separate protocols,
but I could be wrong.

PatC
- -----Original Message-----
From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ]
Sent: Friday, February 15, 2002 7:40 AM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Moving forward with paging


James, Pat and all,
  I thought we should first sort out the problems in RFC3154 that I
pointed out and so far no reply came.
  Therefore it is fair to conclude that RFC3154's requirements 4.7
and 4.8 are impossible to be satified in one protocol and according
to well established rules in IETF it is possible to define several
protocols in one draft of standards track and here is the
mathematical proof that it is impossible to satisfy 4.7 and 4.8.
  Recalling back from the design team discussions, can I state that
James insisted on puting these two requirements despite e.g. my
comments and therefore led people like draft-renker, draft-ohba and
even draft-koodli to come up with strange drafts in which a different
protocol is presented as a mode?
  How can we continue to discuss the details in these two drafts?
They do not in any way present viable solutions to the problem. it is
just loss of time to do that.

Regards,
 

James Kempf wrote:

Behcet,
I appreciate your solutions but can you please bundle them in a
draft,like draft-kempf so that we can judge in its entirety?
As Yoshi pointed out, I didn't propose anything that draft-ohba
anddraft-renker didn't. What we are trying to sort out now is
themechanism.The proposal in draft-ohba isn't complete, and the
proposal indraft-renkerhas some problems.Technical discussion of this
sort is, after all, the intent of thismailing list.          
jak_______________________________________________Seamoby mailing
listSeamoby@ietf.orghttps://www1.ietf.org/mailman/listinfo/seamoby


- --
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com >

iQA/AwUBPG0v/jN1fXKoxmisEQJkfgCfd7B4D2ZBOIzKZ4ErHhhu9zmeQ10AoMdg
4G2qWLedt7EjGX15T0/P7f2L
=M7NK
-----END PGP SIGNATURE-----

Regards,
-- 
Behcet

--------------060100060703000209060502-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 15 12:09:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11790 for ; Fri, 15 Feb 2002 12:09:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01801; Fri, 15 Feb 2002 11:54:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01773 for ; Fri, 15 Feb 2002 11:54:16 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11162 for ; Fri, 15 Feb 2002 11:54:14 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1FGrfjP000928; Fri, 15 Feb 2002 11:53:41 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA08746; Fri, 15 Feb 2002 11:53:32 -0500 (EST) Date: Fri, 15 Feb 2002 11:53:36 -0500 To: Marco Liebsch Cc: James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020215165336.GA593@catfish> Mail-Followup-To: Marco Liebsch , James Kempf , seamoby@ietf.org References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3C6CF117.2A2CCA2C@ccrle.nec.de> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 36 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Marco, On Fri, Feb 15, 2002 at 12:29:27PM +0100, Marco Liebsch wrote: > Jim, > > James Kempf wrote: > > > I'm separating out the thread about how to get packets from the HA to > > the dormant mode mobile so I can follow the issues. > > > > So my understanding of the primary issues are: > > > > 1) The alternate CoA won't work because the PA address doesn't belong to > > the MN. > > > > In case of MN going dormant, it acquires no CoA when entering a new > lcoation. > Therefore, PA address is the MN's CoA, registered with the HA. Same as > hierarchical approaches intend to do. In my eyes it is reasonable to allow a > > MN to register a CoA, which is different to one or more addresses assigned > to its local interface (e.g. PA, MAP, ...). Otherwise, what is the alt. CoA > sub > option then for? I don't think you understand the problem correctly. In the case of MAP, a distinct alternate CoA is used by each MN (only the first 64-bit of the blobal IP address for MAP advertised through ND is shared among multiple MNs and the lower 64-bit part is different per MN). In the case of PA, the entire part of the IP address of the PA is used as the alternate CoA and shared among multiple MNs. Regards, Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Feb 15 12:23:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12406 for ; Fri, 15 Feb 2002 12:23:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04119; Fri, 15 Feb 2002 12:13:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04088 for ; Fri, 15 Feb 2002 12:13:22 -0500 (EST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12058 for ; Fri, 15 Feb 2002 12:13:20 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1FHCp729380 for ; Fri, 15 Feb 2002 11:12:51 -0600 (CST) Message-ID: <3C6D4189.5060807@alcatel.com> Date: Fri, 15 Feb 2002 11:12:41 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dear all, I consider this thread bogus, are you talking about home agent based paging? DMA is an entity to be used in a MIP independent paging protocol. PA is commonly used to conduct the paging and as such it exists in both MIP-based (draft-sarikaya and several earlier drafts have it) and MIP-independent protocols. How can you fuse the two? Yoshihiro Ohba wrote: >Marco, > >On Fri, Feb 15, 2002 at 12:29:27PM +0100, Marco Liebsch wrote: > >>Jim, >> >>James Kempf wrote: >> behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Feb 16 22:11:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21122 for ; Sat, 16 Feb 2002 22:11:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00960; Sat, 16 Feb 2002 21:58:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00931 for ; Sat, 16 Feb 2002 21:58:22 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20998 for ; Sat, 16 Feb 2002 21:58:17 -0500 (EST) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1H2v9e15586; Sat, 16 Feb 2002 18:57:09 -0800 (PST) Message-ID: <003501c1b75e$91c218b0$746015ac@T23KEMPF> From: "James Kempf" To: "Marco Liebsch" , "Yoshihiro Ohba" Cc: References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Sat, 16 Feb 2002 18:55:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Yoshi, > > In case of MN going dormant, it acquires no CoA when entering a new > > lcoation. > > Therefore, PA address is the MN's CoA, registered with the HA. Same as > > hierarchical approaches intend to do. In my eyes it is reasonable to allow a > > > > MN to register a CoA, which is different to one or more addresses assigned > > to its local interface (e.g. PA, MAP, ...). Otherwise, what is the alt. CoA > > sub > > option then for? > > I don't think you understand the problem correctly. In the case of > MAP, a distinct alternate CoA is used by each MN (only the first > 64-bit of the blobal IP address for MAP advertised through ND is > shared among multiple MNs and the lower 64-bit part is different per > MN). In the case of PA, the entire part of the IP address of the PA > is used as the alternate CoA and shared among multiple MNs. > I think another problem is that Section 10.9 of the MIPv6 draft isn't clear. What does "in use" mean? In MIPv4, a Care-of Address is "in use" when it is assigned to an active network interface on the Foreign Agent. The Foreign Agent isn't the mobile node. Is this also OK in IPv6? Given that IPv6 uses CoCoA, it would seem not, but the specification doesn't say that. Just because HMIPv6 uses Alternate CoA in one way, doesn't mean that is the only way it can be used. The MIPv6 spec should either state explicitly that the address is required to be assigned to an active network interface on the mobile node, or it should say that the mobile node can delegate the address to another entity which is receiving the mobile node's traffic on its behalf. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Feb 17 14:13:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10099 for ; Sun, 17 Feb 2002 14:13:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22323; Sun, 17 Feb 2002 13:59:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22294 for ; Sun, 17 Feb 2002 13:59:02 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09867 for ; Sun, 17 Feb 2002 13:58:58 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1HIwUL07247 for ; Sun, 17 Feb 2002 12:58:30 -0600 (CST) Message-ID: <3C6FFD43.2030007@alcatel.com> Date: Sun, 17 Feb 2002 12:58:11 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging References: <3C64337B.20201@alcatel.com> <053e01c1b334$f69a1950$7e6015ac@T23KEMPF> <3C684D25.90803@alcatel.com> <010c01c1b4cb$923a0040$7e6015ac@T23KEMPF> <3C6AD7FD.5050705@alcatel.com> <01bb01c1b4d8$d0d10760$7e6015ac@T23KEMPF> <3C6AE6E3.1050303@alcatel.com> <02a201c1b4fd$4b8c0e40$7e6015ac@T23KEMPF> <20020214162601.GB819@catfish> <3C6BF240.1B459AB0@ccrle.nec.de> <20020214195349.GA1140@catfish> <3C6C5476.5080802@alcatel.com> <006301c1b5ce$ae5b3d30$956015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------020307040000030303040708" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------020307040000030303040708 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Jim, Well this is interesting! So we can consider Kempf as coauthor to draft-renker and draft-ohba? If yes this will clarify many things. Maybe now it may appear acceptable to you my previous suggestion for way out: design team with you as player. The main point is that you can not be a judge and a player at the same time. Regards, James Kempf wrote: >Behcet, > >>I appreciate your solutions but can you please bundle them in a draft, >>like draft-kempf so that we can judge in its entirety? >> >> > >As Yoshi pointed out, I didn't propose anything that draft-ohba and >draft-renker didn't. What we are trying to sort out now is the >mechanism. >The proposal in draft-ohba isn't complete, and the proposal in >draft-renker >has some problems. > >Technical discussion of this sort is, after all, the intent of this >mailing list. > > jak > -- Behcet --------------020307040000030303040708 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Jim,
  Well this is interesting!
So we can consider Kempf as coauthor to draft-renker and draft-ohba? If yes this will clarify many things.
  Maybe now it may appear acceptable to you my previous suggestion for way out: design team with you as player.
  The main point is that you can not be a judge and a player at the same time.

Regards,

James Kempf wrote:
Behcet,

I appreciate your solutions but can you please bundle them in a draft,
like draft-kempf so that we can judge in its entirety?



As Yoshi pointed out, I didn't propose anything that draft-ohba and
draft-renker didn't. What we are trying to sort out now is the
mechanism.
The proposal in draft-ohba isn't complete, and the proposal in
draft-renker
has some problems.

Technical discussion of this sort is, after all, the intent of this
mailing list.

            jak


-- 
Behcet

--------------020307040000030303040708-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Feb 17 14:39:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10461 for ; Sun, 17 Feb 2002 14:39:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23994; Sun, 17 Feb 2002 14:28:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23964 for ; Sun, 17 Feb 2002 14:28:28 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10301 for ; Sun, 17 Feb 2002 14:28:25 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1HJRuL08359 for ; Sun, 17 Feb 2002 13:27:56 -0600 (CST) Message-ID: <3C700429.5030303@alcatel.com> Date: Sun, 17 Feb 2002 13:27:37 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: Content-Type: multipart/alternative; boundary="------------040005010900070209070904" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------040005010900070209070904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pat, Sorry to say but you should do more homework, such as where IP paging stands and what basic sometimes unwritten but implied rules apply to the protocol standards, etc. in the hopes of being able to give good guidance to the WG. This way maybe we can have a better judgement from the cochairs because it seems that the other one is basically becoming a player. Regards, Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > As an FYI, I've always found that telling folks that they are full of > hot air doesn't really lead to good team collaboration. Of course, I > can't tell you how to act in a mailing list, but I just thought I'd > provide you with my thoughts. > > PatC > > > Dear all, > > I consider this thread bogus, > > are you talking about home agent based paging? > > ... > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > > > iQA/AwUBPG/lpDN1fXKoxmisEQIvhwCg0PdRhz0YEU6k2GuB/JmRRKU7UGcAnA8W > JEdUf+RKgbxOgVVyLJTThbwv > =ao+j > -----END PGP SIGNATURE----- > -- Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S 026 1000 Coit Road PB7 Plano, TX 75075 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 477 2794 Fax: (972) 519 2460 --------------040005010900070209070904 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Pat,
  Sorry to say but you should do more homework, such as where IP paging stands and what basic sometimes unwritten but implied  rules apply to the protocol standards, etc. in the hopes of being able to give good guidance to the WG. This way maybe we can have a better judgement from the cochairs because it seems that the other one is basically becoming a player.

Regards,
 

Pat R. Calhoun wrote:
RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As an FYI, I've always found that telling folks that they are full of
hot air doesn't really lead to good team collaboration. Of course, I
can't tell you how to act in a mailing list, but I just thought I'd
provide you with my thoughts.

PatC

> Dear all,
> I consider this thread bogus,
> are you talking about home agent based paging?
> ...

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com >

iQA/AwUBPG/lpDN1fXKoxmisEQIvhwCg0PdRhz0YEU6k2GuB/JmRRKU7UGcAnA8W
JEdUf+RKgbxOgVVyLJTThbwv
=ao+j
-----END PGP SIGNATURE-----


-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460


--------------040005010900070209070904-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Feb 17 15:10:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10791 for ; Sun, 17 Feb 2002 15:10:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24949; Sun, 17 Feb 2002 14:54:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24920 for ; Sun, 17 Feb 2002 14:54:06 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10652 for ; Sun, 17 Feb 2002 14:54:02 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1HJrYL09272 for ; Sun, 17 Feb 2002 13:53:34 -0600 (CST) Message-ID: <3C700A2B.7030708@alcatel.com> Date: Sun, 17 Feb 2002 13:53:15 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Glad to see you are working hard even on Sundays. It seems that there is some heat factor somewhere on some people. Not (hopefully) on me, I was the one who made reasonable suggestions not certainly the one making decisions and strange ones to keep creating procedural concerns, some times going to the bottom of what IETF is all about. Again sorry to say but it is regrettable that WG cochair does not know where IP paging stands in the layering and leaves everything to someone with a lot of bias, someone who divides people. I made my comments on the assessment draft, I would like to see them incorporated, I would like to receive a satisfactory reply to the concerns I raised on the satisfiability of the requirements 4.7 and 4.8 in one protocol. So I am a cooperating member, maybe the heat is on you. Regards, Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Feb 17 20:39:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14274 for ; Sun, 17 Feb 2002 20:39:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09555; Sun, 17 Feb 2002 20:26:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09528 for ; Sun, 17 Feb 2002 20:26:40 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14079 for ; Sun, 17 Feb 2002 20:26:36 -0500 (EST) Received: from T23KEMPF (dhcp169.docomolabs-usa.com [172.21.96.169]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1I1Q5e08550; Sun, 17 Feb 2002 17:26:05 -0800 (PST) Message-ID: <002401c1b81b$03b70b80$a96015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" Cc: Date: Sun, 17 Feb 2002 17:24:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Notice of Possible Administrative Action: Behcet Sarikaya Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Mr. Behcet Sarikaya, This is to warn you that your continual posting of provocative and baiting email about the working group chairs' motives and about working group process administered by the working group chairs to the Seamoby list should cease immediately. You were privately warned about this in early January by the Transport Directorate, but you have continued to make such postings. Furthermore, your posting of private email without the permission of the original sender is in gross violation of IETF and Internet email ethics. This is your second warning, you will not get a third. Should you respond to this email at all (publicly or privately), continue to post email with such content, or continue to post private email without the permission of the original sender, you will be removed immediately from the Seamoby list. IETF lists are for discussion of technical topics, and your email has been inconsistent with this purpose. James Kempf Pat Calhoun Seamoby Working Group Chairs _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Feb 18 06:44:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00550 for ; Mon, 18 Feb 2002 06:44:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14997; Mon, 18 Feb 2002 06:31:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14960 for ; Mon, 18 Feb 2002 06:31:05 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00409 for ; Mon, 18 Feb 2002 06:31:00 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1IBUmg08063; Mon, 18 Feb 2002 12:30:48 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA07467; Mon, 18 Feb 2002 12:30:26 +0100 Message-ID: <3C70E5D0.590A56F7@ccrle.nec.de> Date: Mon, 18 Feb 2002 12:30:24 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshihiro Ohba CC: James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Yoshi, I see. This should be clarified what MIP allows. Actually, PA could also generate a different alternate CoA for each registered MN. This would make use of same mechansim as you described. The idea was as follows: To explicitly address the DMA FE in the PA in order to reduce performance desgradation due to tracking all packets coming by and checking whether or not it is a paging trigger packet for a registered idle MN. This addresses requirement 4.8, which is to 'make use of existing registration support'. In general: MIP approaches belong to the re-addressing based mobility management protocols, others, like CIP, are routing-based approaches. For the first class of protocols, explicit addressing of a PA might be a good choice for the reasons mentioned above. For routing-based approaches, maybe a distributed set of DMAs might be a direction to go. These DMAs could be located on or nearby border routers, checking the packets coming by for registered MNs identifiers. What do you think? Greetings, Marco Yoshihiro Ohba wrote: > Marco, > > On Fri, Feb 15, 2002 at 12:29:27PM +0100, Marco Liebsch wrote: > > Jim, > > > > James Kempf wrote: > > > > > I'm separating out the thread about how to get packets from the HA to > > > the dormant mode mobile so I can follow the issues. > > > > > > So my understanding of the primary issues are: > > > > > > 1) The alternate CoA won't work because the PA address doesn't belong to > > > the MN. > > > > > > > In case of MN going dormant, it acquires no CoA when entering a new > > lcoation. > > Therefore, PA address is the MN's CoA, registered with the HA. Same as > > hierarchical approaches intend to do. In my eyes it is reasonable to allow a > > > > MN to register a CoA, which is different to one or more addresses assigned > > to its local interface (e.g. PA, MAP, ...). Otherwise, what is the alt. CoA > > sub > > option then for? > > I don't think you understand the problem correctly. In the case of > MAP, a distinct alternate CoA is used by each MN (only the first > 64-bit of the blobal IP address for MAP advertised through ND is > shared among multiple MNs and the lower 64-bit part is different per > MN). In the case of PA, the entire part of the IP address of the PA > is used as the alternate CoA and shared among multiple MNs. > > Regards, > Yoshihiro Ohba > > _______________________________________________ > 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 Feb 18 16:54:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19917 for ; Mon, 18 Feb 2002 16:54:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13003; Mon, 18 Feb 2002 16:21:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12974 for ; Mon, 18 Feb 2002 16:21:09 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18990 for ; Mon, 18 Feb 2002 16:21:05 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1ILKYjP012196; Mon, 18 Feb 2002 16:20:34 -0500 (EST) Received: from localhost (tari.research.telcordia.com [207.3.232.66]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id QAA14282; Mon, 18 Feb 2002 16:20:27 -0500 (EST) Date: Mon, 18 Feb 2002 16:20:31 -0500 To: Marco Liebsch , James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020218212031.GB1244@catfish> Mail-Followup-To: Marco Liebsch , James Kempf , seamoby@ietf.org References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <20020215165336.GA593@catfish> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 47 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Fri, Feb 15, 2002 at 11:53:36AM -0500, Yoshihiro Ohba wrote: > Marco, > > On Fri, Feb 15, 2002 at 12:29:27PM +0100, Marco Liebsch wrote: > > Jim, > > > > James Kempf wrote: > > > > > I'm separating out the thread about how to get packets from the HA to > > > the dormant mode mobile so I can follow the issues. > > > > > > So my understanding of the primary issues are: > > > > > > 1) The alternate CoA won't work because the PA address doesn't belong to > > > the MN. > > > > > > > In case of MN going dormant, it acquires no CoA when entering a new > > lcoation. > > Therefore, PA address is the MN's CoA, registered with the HA. Same as > > hierarchical approaches intend to do. In my eyes it is reasonable to allow a > > > > MN to register a CoA, which is different to one or more addresses assigned > > to its local interface (e.g. PA, MAP, ...). Otherwise, what is the alt. CoA > > sub > > option then for? > > I don't think you understand the problem correctly. In the case of > MAP, a distinct alternate CoA is used by each MN (only the first > 64-bit of the blobal IP address for MAP advertised through ND is > shared among multiple MNs and the lower 64-bit part is different per > MN). In the case of PA, the entire part of the IP address of the PA > is used as the alternate CoA and shared among multiple MNs. After reading the recent discussion on the mobile-ip mailing list, I've realized that the above MAP usage is only for basic mode of HMIPv6. If HMIPv6 operates in another mode (extended mode), the alternate CoA (i.e., RCoA) is an address assigned to the MAP. However, the extended mode is not possible without modifying the way of intercepting and tunneling packets at HA (i.e., in extended mode, HA adds a Routing Header to each tunneled packet so that MAP can deliver the packet to the MN without looking the inner header containing the global Home Address of the MN). Although I'm not sure whether the this kind of modification is acceptable or not, I think that draft-renker would also require similar modification to the HA operation. Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Feb 18 19:50:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25174 for ; Mon, 18 Feb 2002 19:50:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22015; Mon, 18 Feb 2002 19:18:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21984 for ; Mon, 18 Feb 2002 19:18:19 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24407 for ; Mon, 18 Feb 2002 19:18:15 -0500 (EST) Received: from T23KEMPF (dhcp142.docomolabs-usa.com [172.21.96.142]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1J0H7e03661; Mon, 18 Feb 2002 16:17:08 -0800 (PST) Message-ID: <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> From: "James Kempf" To: "Marco Liebsch" , "Yoshihiro Ohba" Cc: References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Mon, 18 Feb 2002 16:15:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Marco and Yoshi, I sent email to the MIP list about this and asked Charlie Perkins. I did not get much of a response on the MIP list, but one person repiled, I think from the Australian group that implemented HMIPv6. The general opinion was that the alt-CoA did not necessarily have to be associated with a configured interface on the MN. There are a variety of applications where this might be useful, for example, handing over from a cell phone to a workstation when you entered an office. Paging is another. The particular technical twist on paging that makes this more difficult is that one would like the DMA to perform handover to a new DMA in a new paging area for the MN when the MN moves in dormant mode, rather than have the MN wake up, configure its interface, perform the binding update to the HA with the new DMA's CoA, then go back to sleep. One would rather like the L2 paging support response to the L2 IP paging area beacon (if available) or a lightweight IP response (if no L2 support) be able to cause the DMA to perform the handover. There is a security issue here. One could imagine the MN sending an IP AH header secured BU over the paging channel without having to bring up an interface, but this is pretty unlikely to be universally useful. So it seems like there may be some need for setting up a trust relationship between the HA and DMA initially, then being able to transfer that trust relationship to allow the DMAs in the foreign network to perform the update. Am I missing something? jak ----- Original Message ----- From: "Marco Liebsch" To: "Yoshihiro Ohba" Cc: "James Kempf" ; Sent: Monday, February 18, 2002 3:30 AM Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues > Yoshi, > I see. This should be clarified what MIP allows. Actually, PA could also generate > a different alternate CoA for each registered MN. This would make use of same > mechansim as you described. The idea was as follows: To explicitly address the DMA > FE in the PA in order to reduce performance desgradation due to tracking all > packets coming by and checking whether or not it is a paging trigger packet for a > registered idle MN. This addresses requirement 4.8, which is to 'make use of > existing registration support'. > > In general: MIP approaches belong to the re-addressing based mobility management > protocols, others, like CIP, are routing-based approaches. For the first class of > protocols, explicit addressing of a PA might be a good choice for the reasons > mentioned above. For routing-based approaches, maybe a distributed set of DMAs > might be a direction to go. These DMAs could be located on or nearby border > routers, checking the packets coming by for registered MNs identifiers. > > What do you think? > > Greetings, > > Marco > > Yoshihiro Ohba wrote: > > > Marco, > > > > On Fri, Feb 15, 2002 at 12:29:27PM +0100, Marco Liebsch wrote: > > > Jim, > > > > > > James Kempf wrote: > > > > > > > I'm separating out the thread about how to get packets from the HA to > > > > the dormant mode mobile so I can follow the issues. > > > > > > > > So my understanding of the primary issues are: > > > > > > > > 1) The alternate CoA won't work because the PA address doesn't belong to > > > > the MN. > > > > > > > > > > In case of MN going dormant, it acquires no CoA when entering a new > > > lcoation. > > > Therefore, PA address is the MN's CoA, registered with the HA. Same as > > > hierarchical approaches intend to do. In my eyes it is reasonable to allow a > > > > > > MN to register a CoA, which is different to one or more addresses assigned > > > to its local interface (e.g. PA, MAP, ...). Otherwise, what is the alt. CoA > > > sub > > > option then for? > > > > I don't think you understand the problem correctly. In the case of > > MAP, a distinct alternate CoA is used by each MN (only the first > > 64-bit of the blobal IP address for MAP advertised through ND is > > shared among multiple MNs and the lower 64-bit part is different per > > MN). In the case of PA, the entire part of the IP address of the PA > > is used as the alternate CoA and shared among multiple MNs. > > > > Regards, > > Yoshihiro Ohba > > > > _______________________________________________ > > 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 Feb 18 20:02:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25371 for ; Mon, 18 Feb 2002 20:02:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22676; Mon, 18 Feb 2002 19:30:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22645 for ; Mon, 18 Feb 2002 19:30:49 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24772 for ; Mon, 18 Feb 2002 19:30:45 -0500 (EST) Received: from T23KEMPF (dhcp142.docomolabs-usa.com [172.21.96.142]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1J0UGe03899 for ; Mon, 18 Feb 2002 16:30:17 -0800 (PST) Message-ID: <005801c1b8dc$62278e80$8e6015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 18 Feb 2002 16:28:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Progress on WG Last Call for draft-ietf-paging-protocol-assessment-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Folks, We are midway through the WG last call period on the paging assessment draft. We have received one suggestion from a WG member that draft-guri replace draft-renker as the choice for the base paging draft, but no one else in the WG has so far agreed with this suggestion We have also received a suggestion from the same WG member that there be one paging draft for MIPv4 and one paging draft for MIPv6. Another member responded that other IETF protocols have support for IPv4 and IPv6 within the same protocol without having to split, and it is not clear why paging should not also. AnotherWG member expressed the opinion that it would be useful to be able to use particular features of IPv4 or IPv6. The WG chairs believe that it is premature at this time to split the draft since the technical issues are not yet clear, but we would like to hear any further opinions on the matter in there are any. So far, we do not see any concensus on splitting the draft. Other than that, there were no further issues. WG last call ends on Mon. next week (Feb. 25, 2002). At that time, as editor of the draft, I will be inserting those changes that have working group concensus. The intent of the assessment draft is to express WG concensus to the IESG about what draft should be the starting point for the paging protocol design. If you have any suggestions for changes or reasons why the decision made in the assessment draft, as it now stands, should be changed, please express them within the next week. Thanx. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Feb 18 21:09:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26802 for ; Mon, 18 Feb 2002 21:09:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25379; Mon, 18 Feb 2002 20:31:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25350 for ; Mon, 18 Feb 2002 20:31:55 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26057 for ; Mon, 18 Feb 2002 20:31:50 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1J1VNL04886 for ; Mon, 18 Feb 2002 19:31:23 -0600 (CST) Message-ID: <3C71AAEA.50200@alcatel.com> Date: Mon, 18 Feb 2002 19:31:22 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Progress on WG Last Call for draft-ietf-paging-protocol-assessment-01.txt References: <005801c1b8dc$62278e80$8e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James Kempf wrote: >Folks, > >We are midway through the WG last call period on the paging assessment >draft. > >We have received one suggestion from a WG member that draft-guri replace >draft-renker as the choice for the base paging draft, but no one else in >the WG has so far agreed with this suggestion > draft-ohba was also proposed to be the base draft. > >We have also received a suggestion from the same WG member that there be >one paging draft for MIPv4 and one paging draft for MIPv6. Another >member responded that other IETF protocols have support for IPv4 and >IPv6 within the same protocol without having to split, and it is not >clear why paging should not also. > I missed this member's comment, can you please repost it. >AnotherWG member expressed the opinion >that it would be useful to be able to use particular features of IPv4 or >IPv6. > Again I missed this one. >The WG chairs believe that it is premature at this time to split >the draft since the technical issues are not yet clear, but we would >like to hear any further opinions on the matter in there are any. So >far, we do not see any concensus on splitting the draft. > The point raised is not to split "the" draft. The point is IETF protocol standards define a single protocol so that interoperability tests can be made on the implementations. It could have some text on the implications on a different protocol but this text can only be considered informational. No interoperability on it. -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Feb 19 09:01:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18695 for ; Tue, 19 Feb 2002 09:01:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05356; Tue, 19 Feb 2002 08:40:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05325 for ; Tue, 19 Feb 2002 08:40:05 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17926 for ; Tue, 19 Feb 2002 08:40:02 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1JDdX324981 for ; Tue, 19 Feb 2002 15:39:33 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Feb 2002 15:40:01 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Feb 2002 15:40:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Progress on WG Last Call for draft-ietf-paging-protocol-assessment-01.txt Date: Tue, 19 Feb 2002 15:40:01 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6493E@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Progress on WG Last Call for draft-ietf-paging-protocol-assessment-01.txt Thread-Index: AcG43LaOz24VJfgdTOya1LFOfKk9LgAbcrtQ To: , X-OriginalArrivalTime: 19 Feb 2002 13:40:01.0686 (UTC) FILETIME=[EE1FBB60:01C1B94A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA05326 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James One general comment on the draft. Section 4 might stand from some improvement. I think just trying to create some subsections, such as 4.0 4.1 Intro 4.2 Resolution 4.3 Comments on proposed protocols 4.4 Next Steps Most of the text is there. Does this make any sense? I could try editing the text if need be. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Feb 19 09:08:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19258 for ; Tue, 19 Feb 2002 09:08:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05605; Tue, 19 Feb 2002 08:49:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05575 for ; Tue, 19 Feb 2002 08:49:35 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18221 for ; Tue, 19 Feb 2002 08:49:32 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1JDoAg50256; Tue, 19 Feb 2002 14:50:10 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA21514; Tue, 19 Feb 2002 14:48:59 +0100 Message-ID: <3C7257CB.39937220@ccrle.nec.de> Date: Tue, 19 Feb 2002 14:48:59 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Yoshihiro Ohba , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James, James Kempf wrote: > Marco and Yoshi, > > I sent email to the MIP list about this and asked Charlie Perkins. I did > not get much of a response on the MIP list, but one person repiled, I > think from the Australian group that implemented HMIPv6. > > The general opinion was that the alt-CoA did not necessarily have to be > associated with a configured interface on the MN. There are a variety of > applications where this might be useful, for example, handing over from > a cell phone to a workstation when you entered an office. Paging is > another. > As you got from feedback on the MIP list, HMIPv6 makes use of the basic and extended mode. In my understanding Extended mode works exactly like it is described for the paging agent, which is addressing the PA from HA (means paging trigger packets are 'received' at DMA-FE of PA, not 'intercepted'). PA address has been registered with the altern. CoA option at HA. No modification to MIPv6 is required so far. The only requirement for the HA is to make use of an additional Routing Header 'in case of having a site-local home address' registered instead of a global one. Processing at the PA is exactly as natural or unnatural as it is described for the MAP in extended mode (assuming a global home address is registered). Assuming global home addresses, the paging concept makes use of registration mechansism provided by MIPv6 without any modifications (requirement 4.8). They propose some HMIP extensions, like a flag in the BU that allows to indicate that the source address of the IP packet carrying the BU is a 'global CoA'. This allows avoidance of altern. CoA suboptions, but is specific. > > The particular technical twist on paging that makes this more difficult > is that one would like the DMA to perform handover to a new DMA in a new > paging area for the MN when the MN moves in dormant mode, rather than > have the MN wake up, configure its interface, perform the binding update > to the HA with the new DMA's CoA, then go back to sleep. One would > rather like the L2 paging support response to the L2 IP paging area > beacon (if available) or a lightweight IP response (if no L2 support) be > able to cause the DMA to perform the handover. > If the scope of a PA's capability to manage paging areas would be increased rather to restrict an individual PA to manage one paging area only, a MN could move through many different paging areas without sending any binding update to the HA, since DMA stays the same! Only paging area update notification to the PA would be necessary. This can be done by signaling originated from MN or from AR on behalf of he MN, triggered by means of L2. > > There is a security issue here. One could imagine the MN sending an IP > AH header secured BU over the paging channel without having to bring up > an interface, but this is pretty unlikely to be universally useful. So > it seems like there may be some need for setting up a trust relationship > between the HA and DMA initially, then being able to transfer that trust > relationship to allow the DMAs in the foreign network to perform the > update. > A SA between DMA and mobility agent is reasonable for DMA initiated registration update (instead of MN initiated), as you described. Same as above, having one DMA for 'multiple' paging areas could avoid updating each time the MN enters a new paging area. Then updating DMA at mobility agent could be restricted to be dependent on binding lifetime. What do you think? Marco > > Am I missing something? > > jak > > ----- Original Message ----- > From: "Marco Liebsch" > To: "Yoshihiro Ohba" > Cc: "James Kempf" ; > Sent: Monday, February 18, 2002 3:30 AM > Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility > Protocol Issues > > > Yoshi, > > I see. This should be clarified what MIP allows. Actually, PA could > also generate > > a different alternate CoA for each registered MN. This would make use > of same > > mechansim as you described. The idea was as follows: To explicitly > address the DMA > > FE in the PA in order to reduce performance desgradation due to > tracking all > > packets coming by and checking whether or not it is a paging trigger > packet for a > > registered idle MN. This addresses requirement 4.8, which is to 'make > use of > > existing registration support'. > > > > In general: MIP approaches belong to the re-addressing based mobility > management > > protocols, others, like CIP, are routing-based approaches. For the > first class of > > protocols, explicit addressing of a PA might be a good choice for the > reasons > > mentioned above. For routing-based approaches, maybe a distributed set > of DMAs > > might be a direction to go. These DMAs could be located on or nearby > border > > routers, checking the packets coming by for registered MNs > identifiers. > > > > What do you think? > > > > Greetings, > > > > Marco > > > > Yoshihiro Ohba wrote: > > > > > Marco, > > > > > > On Fri, Feb 15, 2002 at 12:29:27PM +0100, Marco Liebsch wrote: > > > > Jim, > > > > > > > > James Kempf wrote: > > > > > > > > > I'm separating out the thread about how to get packets from the > HA to > > > > > the dormant mode mobile so I can follow the issues. > > > > > > > > > > So my understanding of the primary issues are: > > > > > > > > > > 1) The alternate CoA won't work because the PA address doesn't > belong to > > > > > the MN. > > > > > > > > > > > > > In case of MN going dormant, it acquires no CoA when entering a > new > > > > lcoation. > > > > Therefore, PA address is the MN's CoA, registered with the HA. > Same as > > > > hierarchical approaches intend to do. In my eyes it is reasonable > to allow a > > > > > > > > MN to register a CoA, which is different to one or more addresses > assigned > > > > to its local interface (e.g. PA, MAP, ...). Otherwise, what is the > alt. CoA > > > > sub > > > > option then for? > > > > > > I don't think you understand the problem correctly. In the case of > > > MAP, a distinct alternate CoA is used by each MN (only the first > > > 64-bit of the blobal IP address for MAP advertised through ND is > > > shared among multiple MNs and the lower 64-bit part is different per > > > MN). In the case of PA, the entire part of the IP address of the PA > > > is used as the alternate CoA and shared among multiple MNs. > > > > > > Regards, > > > Yoshihiro Ohba > > > > > > _______________________________________________ > > > 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 Tue Feb 19 11:33:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26432 for ; Tue, 19 Feb 2002 11:33:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14277; Tue, 19 Feb 2002 10:57:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14251 for ; Tue, 19 Feb 2002 10:57:42 -0500 (EST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25054 for ; Tue, 19 Feb 2002 10:57:40 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1JFv8708593 for ; Tue, 19 Feb 2002 09:57:08 -0600 (CST) Message-ID: <3C7275D1.8030208@alcatel.com> Date: Tue, 19 Feb 2002 09:57:05 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Progress on WG for paging protocol assessment References: <005801c1b8dc$62278e80$8e6015ac@T23KEMPF> <3C71AAEA.50200@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Folks, Sometime back Pat asked the question of which draft to take as the base. I think that this question should be revisited based on the requirements 4.7 and 4.8. Contrary to the ordinary belief, I think (of course I may be wrong) that there is no single IP Paging protocol, requirements 4.7 and 4.8 are pointing to 4 different IP Paging protocols. If we may change Pat's question to which drafts to take as the base then there are natural solutions: - I hereby suggest draft-ohba as the base draft for mip indepedent IPv4 based solution.THis draft is mainly based on IPv4 and it does not attempt to integrate with MIPv4. There are some problems in its architecture but these can be addressed in the next version. - I hereby suggest draft-guri as the base for mip independent IPv6 based solution. This draft is based on IPv6 and no integration with MIPv6 is attempted. However its architecture must be modified and streamlined with modified draft-ohba. For MIPv4 and MIPv6 based solutions, I have trouble in suggesting the base drafts but the natural solution seems to suggest that - draft-renker may be modified towards a MIPv4 based solution (please consider LMM not home agent based architecture). -draft-sarikaya and draft-koodli may take a MIPv6 based solution, there are already some similarities and taking in close consideration of :LMM requirements and any follow up developments. Regards, -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Feb 19 12:01:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27567 for ; Tue, 19 Feb 2002 12:01:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16300; Tue, 19 Feb 2002 11:29:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16276 for ; Tue, 19 Feb 2002 11:29:02 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26298 for ; Tue, 19 Feb 2002 11:29:00 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1JGSKe21811; Tue, 19 Feb 2002 08:28:20 -0800 (PST) Message-ID: <002f01c1b962$386f0ce0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , References: <005801c1b8dc$62278e80$8e6015ac@T23KEMPF> <3C71AAEA.50200@alcatel.com> Subject: Re: [Seamoby] Progress on WG Last Call for draft-ietf-paging-protocol-assessment-01.txt Date: Tue, 19 Feb 2002 08:26:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Behcet, > >We are midway through the WG last call period on the paging assessment > >draft. > > > >We have received one suggestion from a WG member that draft-guri replace > >draft-renker as the choice for the base paging draft, but no one else in > >the WG has so far agreed with this suggestion > > > draft-ohba was also proposed to be the base draft. > I do not recall having see this proposal during the current last call period, which started on Feb. 11. However, I will take this email as a proposal from you that the draft-ohba be used. So now we have two proposals for a different base draft, draft-ohba and draft-guri. Any other comment from WG members on these suggestions? > > > >We have also received a suggestion from the same WG member that there be > >one paging draft for MIPv4 and one paging draft for MIPv6. Another > >member responded that other IETF protocols have support for IPv4 and > >IPv6 within the same protocol without having to split, and it is not > >clear why paging should not also. > > > I missed this member's comment, can you please repost it. > > >AnotherWG member expressed the opinion > >that it would be useful to be able to use particular features of IPv4 or > >IPv6. > > > Again I missed this one. > The archives for Seamoby are at ftp://ftp.ietf.org/ietf-mail-archive/seamoby/ . You can find the references there. > >The WG chairs believe that it is premature at this time to split > >the draft since the technical issues are not yet clear, but we would > >like to hear any further opinions on the matter in there are any. So > >far, we do not see any concensus on splitting the draft. > > > The point raised is not to split "the" draft. The point is IETF protocol > standards define a single protocol so that interoperability tests can > be made on the implementations. It could have some text on the > implications on a different protocol but this text can only be > considered informational. No interoperability on it. > > Any other comment on this proposal from other working group members? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Feb 19 12:36:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28571 for ; Tue, 19 Feb 2002 12:36:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21608; Tue, 19 Feb 2002 12:20:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21584 for ; Tue, 19 Feb 2002 12:20:35 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28151 for ; Tue, 19 Feb 2002 12:20:32 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1JHJIjP029419; Tue, 19 Feb 2002 12:19:18 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id MAA16046; Tue, 19 Feb 2002 12:19:10 -0500 (EST) Date: Tue, 19 Feb 2002 12:19:14 -0500 To: Marco Liebsch Cc: James Kempf , Yoshihiro Ohba , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020219171914.GA716@catfish> Mail-Followup-To: Marco Liebsch , James Kempf , Yoshihiro Ohba , seamoby@ietf.org References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3C7257CB.39937220@ccrle.nec.de> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Marco and Jim, On Tue, Feb 19, 2002 at 02:48:59PM +0100, Marco Liebsch wrote: > James, > > James Kempf wrote: > > > Marco and Yoshi, > > > > I sent email to the MIP list about this and asked Charlie Perkins. I did > > not get much of a response on the MIP list, but one person repiled, I > > think from the Australian group that implemented HMIPv6. > > > > The general opinion was that the alt-CoA did not necessarily have to be > > associated with a configured interface on the MN. There are a variety of > > applications where this might be useful, for example, handing over from > > a cell phone to a workstation when you entered an office. Paging is > > another. > > > > As you got from feedback on the MIP list, HMIPv6 makes use of the basic and > extended mode. In my understanding Extended mode works exactly like it is > described for the paging agent, which is addressing the PA from HA (means > paging trigger packets are 'received' at DMA-FE of PA, not 'intercepted'). > PA address has been registered with the altern. CoA option at HA. No > modification to MIPv6 is required so far. The only requirement for the HA is > to make use of an additional Routing Header 'in case of having a site-local > home address' registered instead of a global one. Processing at the PA is > exactly as natural or unnatural as it is described for the MAP in extended > mode (assuming a global home address is registered). Assuming global home > addresses, the paging concept makes use of registration mechansism provided > by MIPv6 without any modifications (requirement 4.8). They propose some HMIP > extensions, like a flag in the BU that allows to indicate that the source > address of the IP packet carrying the BU is a 'global CoA'. This allows > avoidance of altern. CoA suboptions, but is specific. Then, it seems to me that: draft-renker = HMIPv6 extended mode + DMHA functionality, where the part of HMIPv6 extended mode is the hook to MIPv6. In other words, it actually depends on HMIPv6. If DMA is put at last hop subnets as described in draft-ohba, then the hook becomes independent of HMIPv6, since all packets can be captured at last hop subnets without a special mechanism. Moreover, if we consider time-slotted dormant mode support at L3, some agent would be needed at last hop subnets to provide better synchronization between a host and network, so putting DMA at each last hop subnet would not be unrealistic to me. > > > > > The particular technical twist on paging that makes this more difficult > > is that one would like the DMA to perform handover to a new DMA in a new > > paging area for the MN when the MN moves in dormant mode, rather than > > have the MN wake up, configure its interface, perform the binding update > > to the HA with the new DMA's CoA, then go back to sleep. One would > > rather like the L2 paging support response to the L2 IP paging area > > beacon (if available) or a lightweight IP response (if no L2 support) be > > able to cause the DMA to perform the handover. > > > > If the scope of a PA's capability to manage paging areas would be increased > rather to restrict an individual PA to manage one paging area only, a MN > could move through many different paging areas without sending any binding > update to the HA, since DMA stays the same! Only paging area update > notification to the PA would be necessary. This can be done by signaling > originated from MN or from AR on behalf of he MN, triggered by means of L2. Yes (and draft-ohba takes this approach). > > > > > > There is a security issue here. One could imagine the MN sending an IP > > AH header secured BU over the paging channel without having to bring up > > an interface, but this is pretty unlikely to be universally useful. So > > it seems like there may be some need for setting up a trust relationship > > between the HA and DMA initially, then being able to transfer that trust > > relationship to allow the DMAs in the foreign network to perform the > > update. > > > > A SA between DMA and mobility agent is reasonable for DMA initiated > registration update (instead of MN initiated), as you described. Same as > above, having one DMA for 'multiple' paging areas could avoid updating each > time the MN enters a new paging area. Then updating DMA at mobility agent > could be restricted to be dependent on binding lifetime. What do you think? Yes (and draft-ohba takes this approach). Yoshihiro Ohba > > Marco > > > > > > Am I missing something? > > > > jak > > > > ----- Original Message ----- > > From: "Marco Liebsch" > > To: "Yoshihiro Ohba" > > Cc: "James Kempf" ; > > Sent: Monday, February 18, 2002 3:30 AM > > Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility > > Protocol Issues > > > > > Yoshi, > > > I see. This should be clarified what MIP allows. Actually, PA could > > also generate > > > a different alternate CoA for each registered MN. This would make use > > of same > > > mechansim as you described. The idea was as follows: To explicitly > > address the DMA > > > FE in the PA in order to reduce performance desgradation due to > > tracking all > > > packets coming by and checking whether or not it is a paging trigger > > packet for a > > > registered idle MN. This addresses requirement 4.8, which is to 'make > > use of > > > existing registration support'. > > > > > > In general: MIP approaches belong to the re-addressing based mobility > > management > > > protocols, others, like CIP, are routing-based approaches. For the > > first class of > > > protocols, explicit addressing of a PA might be a good choice for the > > reasons > > > mentioned above. For routing-based approaches, maybe a distributed set > > of DMAs > > > might be a direction to go. These DMAs could be located on or nearby > > border > > > routers, checking the packets coming by for registered MNs > > identifiers. > > > > > > What do you think? > > > > > > Greetings, > > > > > > Marco > > > > > > Yoshihiro Ohba wrote: > > > > > > > Marco, > > > > > > > > On Fri, Feb 15, 2002 at 12:29:27PM +0100, Marco Liebsch wrote: > > > > > Jim, > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > I'm separating out the thread about how to get packets from the > > HA to > > > > > > the dormant mode mobile so I can follow the issues. > > > > > > > > > > > > So my understanding of the primary issues are: > > > > > > > > > > > > 1) The alternate CoA won't work because the PA address doesn't > > belong to > > > > > > the MN. > > > > > > > > > > > > > > > > In case of MN going dormant, it acquires no CoA when entering a > > new > > > > > lcoation. > > > > > Therefore, PA address is the MN's CoA, registered with the HA. > > Same as > > > > > hierarchical approaches intend to do. In my eyes it is reasonable > > to allow a > > > > > > > > > > MN to register a CoA, which is different to one or more addresses > > assigned > > > > > to its local interface (e.g. PA, MAP, ...). Otherwise, what is the > > alt. CoA > > > > > sub > > > > > option then for? > > > > > > > > I don't think you understand the problem correctly. In the case of > > > > MAP, a distinct alternate CoA is used by each MN (only the first > > > > 64-bit of the blobal IP address for MAP advertised through ND is > > > > shared among multiple MNs and the lower 64-bit part is different per > > > > MN). In the case of PA, the entire part of the IP address of the PA > > > > is used as the alternate CoA and shared among multiple MNs. > > > > > > > > Regards, > > > > Yoshihiro Ohba > > > > > > > > _______________________________________________ > > > > 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 Tue Feb 19 13:04:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29606 for ; Tue, 19 Feb 2002 13:04:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22569; Tue, 19 Feb 2002 12:32:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22543 for ; Tue, 19 Feb 2002 12:32:35 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28497 for ; Tue, 19 Feb 2002 12:32:32 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1JHXHg64135; Tue, 19 Feb 2002 18:33:17 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA24280; Tue, 19 Feb 2002 18:32:03 +0100 Message-ID: <3C728C13.C1D05E10@ccrle.nec.de> Date: Tue, 19 Feb 2002 18:32:03 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshihiro Ohba CC: James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Yoshi, Yoshihiro Ohba wrote: > Marco and Jim, > > On Tue, Feb 19, 2002 at 02:48:59PM +0100, Marco Liebsch wrote: > > James, > > > > James Kempf wrote: > > > > > Marco and Yoshi, > > > > > > I sent email to the MIP list about this and asked Charlie Perkins. I did > > > not get much of a response on the MIP list, but one person repiled, I > > > think from the Australian group that implemented HMIPv6. > > > > > > The general opinion was that the alt-CoA did not necessarily have to be > > > associated with a configured interface on the MN. There are a variety of > > > applications where this might be useful, for example, handing over from > > > a cell phone to a workstation when you entered an office. Paging is > > > another. > > > > > > > As you got from feedback on the MIP list, HMIPv6 makes use of the basic and > > extended mode. In my understanding Extended mode works exactly like it is > > described for the paging agent, which is addressing the PA from HA (means > > paging trigger packets are 'received' at DMA-FE of PA, not 'intercepted'). > > PA address has been registered with the altern. CoA option at HA. No > > modification to MIPv6 is required so far. The only requirement for the HA is > > to make use of an additional Routing Header 'in case of having a site-local > > home address' registered instead of a global one. Processing at the PA is > > exactly as natural or unnatural as it is described for the MAP in extended > > mode (assuming a global home address is registered). Assuming global home > > addresses, the paging concept makes use of registration mechansism provided > > by MIPv6 without any modifications (requirement 4.8). They propose some HMIP > > extensions, like a flag in the BU that allows to indicate that the source > > address of the IP packet carrying the BU is a 'global CoA'. This allows > > avoidance of altern. CoA suboptions, but is specific. > > Then, it seems to me that: > > draft-renker = HMIPv6 extended mode + DMHA functionality, > > where the part of HMIPv6 extended mode is the hook to MIPv6. > > In other words, it actually depends on HMIPv6. > What the mail tries to clarify is that draft-renker makes use of available registration mechanism, which is a requirement in RFC 3154, since draft-renker took a MIPv6 platform 'as an example' in order to explain how to integrate the system modularly. The discussion intended to clarify, that there is no 'magic' behind the reception of the paging trigger packet and no 'unnatural' processing of paging trigger packets within the DMA-FE of the PA. Regards, Marco > > If DMA is put at last hop subnets as described in draft-ohba, then the > hook becomes independent of HMIPv6, since all packets can be captured > at last hop subnets without a special mechanism. Moreover, if we > consider time-slotted dormant mode support at L3, some agent would be > needed at last hop subnets to provide better synchronization between a > host and network, so putting DMA at each last hop subnet would not be > unrealistic to me. > > > > > > > > > The particular technical twist on paging that makes this more difficult > > > is that one would like the DMA to perform handover to a new DMA in a new > > > paging area for the MN when the MN moves in dormant mode, rather than > > > have the MN wake up, configure its interface, perform the binding update > > > to the HA with the new DMA's CoA, then go back to sleep. One would > > > rather like the L2 paging support response to the L2 IP paging area > > > beacon (if available) or a lightweight IP response (if no L2 support) be > > > able to cause the DMA to perform the handover. > > > > > > > If the scope of a PA's capability to manage paging areas would be increased > > rather to restrict an individual PA to manage one paging area only, a MN > > could move through many different paging areas without sending any binding > > update to the HA, since DMA stays the same! Only paging area update > > notification to the PA would be necessary. This can be done by signaling > > originated from MN or from AR on behalf of he MN, triggered by means of L2. > > Yes (and draft-ohba takes this approach). > > > > > > > > > > > There is a security issue here. One could imagine the MN sending an IP > > > AH header secured BU over the paging channel without having to bring up > > > an interface, but this is pretty unlikely to be universally useful. So > > > it seems like there may be some need for setting up a trust relationship > > > between the HA and DMA initially, then being able to transfer that trust > > > relationship to allow the DMAs in the foreign network to perform the > > > update. > > > > > > > A SA between DMA and mobility agent is reasonable for DMA initiated > > registration update (instead of MN initiated), as you described. Same as > > above, having one DMA for 'multiple' paging areas could avoid updating each > > time the MN enters a new paging area. Then updating DMA at mobility agent > > could be restricted to be dependent on binding lifetime. What do you think? > > Yes (and draft-ohba takes this approach). > > Yoshihiro Ohba > > > > > Marco > > > > > > > > > > Am I missing something? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Marco Liebsch" > > > To: "Yoshihiro Ohba" > > > Cc: "James Kempf" ; > > > Sent: Monday, February 18, 2002 3:30 AM > > > Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility > > > Protocol Issues > > > > > > > Yoshi, > > > > I see. This should be clarified what MIP allows. Actually, PA could > > > also generate > > > > a different alternate CoA for each registered MN. This would make use > > > of same > > > > mechansim as you described. The idea was as follows: To explicitly > > > address the DMA > > > > FE in the PA in order to reduce performance desgradation due to > > > tracking all > > > > packets coming by and checking whether or not it is a paging trigger > > > packet for a > > > > registered idle MN. This addresses requirement 4.8, which is to 'make > > > use of > > > > existing registration support'. > > > > > > > > In general: MIP approaches belong to the re-addressing based mobility > > > management > > > > protocols, others, like CIP, are routing-based approaches. For the > > > first class of > > > > protocols, explicit addressing of a PA might be a good choice for the > > > reasons > > > > mentioned above. For routing-based approaches, maybe a distributed set > > > of DMAs > > > > might be a direction to go. These DMAs could be located on or nearby > > > border > > > > routers, checking the packets coming by for registered MNs > > > identifiers. > > > > > > > > What do you think? > > > > > > > > Greetings, > > > > > > > > Marco > > > > > > > > Yoshihiro Ohba wrote: > > > > > > > > > Marco, > > > > > > > > > > On Fri, Feb 15, 2002 at 12:29:27PM +0100, Marco Liebsch wrote: > > > > > > Jim, > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > I'm separating out the thread about how to get packets from the > > > HA to > > > > > > > the dormant mode mobile so I can follow the issues. > > > > > > > > > > > > > > So my understanding of the primary issues are: > > > > > > > > > > > > > > 1) The alternate CoA won't work because the PA address doesn't > > > belong to > > > > > > > the MN. > > > > > > > > > > > > > > > > > > > In case of MN going dormant, it acquires no CoA when entering a > > > new > > > > > > lcoation. > > > > > > Therefore, PA address is the MN's CoA, registered with the HA. > > > Same as > > > > > > hierarchical approaches intend to do. In my eyes it is reasonable > > > to allow a > > > > > > > > > > > > MN to register a CoA, which is different to one or more addresses > > > assigned > > > > > > to its local interface (e.g. PA, MAP, ...). Otherwise, what is the > > > alt. CoA > > > > > > sub > > > > > > option then for? > > > > > > > > > > I don't think you understand the problem correctly. In the case of > > > > > MAP, a distinct alternate CoA is used by each MN (only the first > > > > > 64-bit of the blobal IP address for MAP advertised through ND is > > > > > shared among multiple MNs and the lower 64-bit part is different per > > > > > MN). In the case of PA, the entire part of the IP address of the PA > > > > > is used as the alternate CoA and shared among multiple MNs. > > > > > > > > > > Regards, > > > > > Yoshihiro Ohba > > > > > > > > > > _______________________________________________ > > > > > 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 Tue Feb 19 13:16:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00090 for ; Tue, 19 Feb 2002 13:16:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23280; Tue, 19 Feb 2002 12:44:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23253 for ; Tue, 19 Feb 2002 12:44:25 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28817 for ; Tue, 19 Feb 2002 12:44:24 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1JHhCe23737; Tue, 19 Feb 2002 09:43:12 -0800 (PST) Message-ID: <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> From: "James Kempf" To: "Marco Liebsch" , "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Tue, 19 Feb 2002 09:41:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Yoshi, > Then, it seems to me that: > > draft-renker = HMIPv6 extended mode + DMHA functionality, > > where the part of HMIPv6 extended mode is the hook to MIPv6. > > In other words, it actually depends on HMIPv6. > Telnet uses TCP, and so does HTTP. Does that mean that HTTP depends on Telnet? What this is pointing up is that both HMIPv6 and the IPv6 hooks for paging in draft-renker are using the same mechanism from MIPv6. As I mentioned in my email to the MIP list, I could imagine another application in which a handoff is done from a cell phone to a workstation when the cell phone is switched off. What this is pointing out is that MIPv6 actually has a sufficiently generalized mechanism for our purposes, a good thing. > If DMA is put at last hop subnets as described in draft-ohba, then the > hook becomes independent of HMIPv6, since all packets can be captured > at last hop subnets without a special mechanism. Moreover, if we > consider time-slotted dormant mode support at L3, some agent would be > needed at last hop subnets to provide better synchronization between a > host and network, so putting DMA at each last hop subnet would not be > unrealistic to me. > So explain to me how DMA can be put at the last hop without having a one-to-one mapping between the paging area and the subnet? That was never clearly articulated in draft-ohba, IMHO. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Feb 19 13:38:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00819 for ; Tue, 19 Feb 2002 13:38:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24531; Tue, 19 Feb 2002 13:06:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24502 for ; Tue, 19 Feb 2002 13:06:24 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29676 for ; Tue, 19 Feb 2002 13:06:23 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1JI5Ae24537; Tue, 19 Feb 2002 10:05:10 -0800 (PST) Message-ID: <014701c1b96f$bf172cc0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Marco Liebsch" , "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Tue, 19 Feb 2002 10:03:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit So it seems like we have some deeper technical understanding of how it might be possible to separate location tracking from paging in MIPv6 and have location tracking handled by the mobility protocol. There are still plenty of details to fill out, but in principle, it seems as if the same technique as is used in HMIPv6 extended mode would work here as well. Now, how about MIPv4? Here's a tentative suggestion. If the FA detected that the MN went to sleep or if the MN signaled the FA that it was about to go to sleep, the FA could issue a registration to the HA with the DMA as the CoA. This would require a FA/HA "security association" (actually not really an IPSec SA but a trust relationship established by AAA). And also a DMA/HA "security association"? The FA on the subnet handles dormant mode movement by conveying the MN's response to the L2 or L3 paging area beacon to the HA. This is similar to Yoshi's last hop suggestion, however, it is actually not the DMA that is at the last hop but rather the TA, along the lines of my original suggestion that the TA be made mobility protocol dependent. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Feb 19 14:44:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02944 for ; Tue, 19 Feb 2002 14:44:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27820; Tue, 19 Feb 2002 14:12:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27791 for ; Tue, 19 Feb 2002 14:12:05 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01803 for ; Tue, 19 Feb 2002 14:12:03 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1JJAxjP009760; Tue, 19 Feb 2002 14:11:00 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA16285; Tue, 19 Feb 2002 14:10:52 -0500 (EST) Date: Tue, 19 Feb 2002 14:10:57 -0500 To: James Kempf Cc: Marco Liebsch , Yoshihiro Ohba , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020219191057.GB716@catfish> Mail-Followup-To: James Kempf , Marco Liebsch , Yoshihiro Ohba , seamoby@ietf.org References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 92 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Tue, Feb 19, 2002 at 09:41:36AM -0800, James Kempf wrote: > Yoshi, > > > Then, it seems to me that: > > > > draft-renker = HMIPv6 extended mode + DMHA functionality, > > > > where the part of HMIPv6 extended mode is the hook to MIPv6. > > > > In other words, it actually depends on HMIPv6. > > > > Telnet uses TCP, and so does HTTP. Does that mean that HTTP depends on > Telnet? TCP is mandatory for both telnet and HTTP. On the other hand, HMIPv6 or equivalent mechanism seems to be mandatory for draft-renker while HMIPv6 is optional for MIPv6. So the situation is not exactly analogous to the case of telnet and http. > > What this is pointing up is that both HMIPv6 and the IPv6 hooks for > paging in draft-renker are using the same mechanism from MIPv6. As I > mentioned in my email to the MIP list, I could imagine another > application in which a handoff is done from a cell phone to a > workstation when the cell phone is switched off. What this is pointing > out is that MIPv6 actually has a sufficiently generalized mechanism for > our purposes, a good thing. I agree that the part of sending BU from MH to HA with alternate-CoA would be a good thing. But I don't think that the other part in which PA has to maintain the binding between CoA and the global home address (whose prefix part is an on-link prefix of HA, not an on-link prefix on PA) of a MN. > > > If DMA is put at last hop subnets as described in draft-ohba, then the > > hook becomes independent of HMIPv6, since all packets can be captured > > at last hop subnets without a special mechanism. Moreover, if we > > consider time-slotted dormant mode support at L3, some agent would be > > needed at last hop subnets to provide better synchronization between a > > host and network, so putting DMA at each last hop subnet would not be > > unrealistic to me. > > > > So explain to me how DMA can be put at the last hop without having a > one-to-one mapping between the paging area and the subnet? That was > never clearly articulated in draft-ohba, IMHO. This would not be the main topic of this thread, but this would be a good chance to explain. In draft-ohba, DMAs are put on last-hop subnets. A DMA is a separated entity from Paging Agent and Tracking Agent, and does not have a knowledge about what is the paging area. So the DMA sends a Paging message to Tracking Agent to page the MN. A Tracking Agent maintains the mapping between MN's terminal identifier and MN's paging area. It also maintains a list of Paging Agents per paging area so that it can forward a Paging message received from a DMA to the Paging Agent(s) corresponding to the paging area. The location of Tracking Agent is arbitrary. A Paging Agent maintains the mapping between paging area and IP subnets. The mapping between paging area and subnet is arbitrary, i.e., a paging area could contain multiple IP subnets, or an IP subnet could contain multiple paging areas. To support the arbitrary mapping between paging area and IP subnets, the location of Paging Agent is also arbitrary, e.g., it could be co-located on AR, it could be put behind ARs, or it could be put on APs. If a Paging Agent is put far behind ARs, a list of Access Routers per paging area is maintained at the Paging Agent and the list is used for advertising paging areas and for wide-casting Paging messages. There may be multiple Paging Agents in a single paging area and this would be useful when a paging area covers multiple IP subnets or multiple APs while Paging Agents are co-located with ARs or APs. Any of two agents or all agents can be co-located in a single node, depending on various requirements such as scalability, robustness, complexity. For example, a DMA and a Paging Agent can be put together in an AR. Or a Tracking Agent and a Paging Agent can be put together in a single node behind ARs. Or all three types of agents are put together in a single AR. And if co-located, external message exchange is not necessary between different agents. > > jak > > Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Feb 19 20:43:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10083 for ; Tue, 19 Feb 2002 20:43:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13686; Tue, 19 Feb 2002 20:26:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13611 for ; Tue, 19 Feb 2002 20:26:31 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09817 for ; Tue, 19 Feb 2002 20:26:29 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1K1Q0L24778 for ; Tue, 19 Feb 2002 19:26:00 -0600 (CST) Message-ID: <3C72FB24.9020107@alcatel.com> Date: Tue, 19 Feb 2002 19:25:56 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues-some quotes References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish <014701c1b96f$bf172cc0$7e6015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------070205040608090300080507" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------070205040608090300080507 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hello Jim, Regarding HMIPv6 extended mode discussion, I am quoting from your mail sent on Dec. 17,2001: (full email is at the archives) Seamoby group could possibly accept a protocol proposal based on a protocol that has yet to even complete the requirements phase in another working group, to say nothing of the dependence on Mobile IPv6, which is something the Seamoby working group has tried to avoid. The HMIPv6-based paging proposal not only didn't satisfy the requirements, but it set up a dependence that could ultimately hamper taking the Seamoby protocol to proposed standard, if the Mobile IP group rejected HMIPv6 in favor of another LMM protocol. James Kempf wrote: >So it seems like we have some deeper technical understanding of how it >might be possible to separate location tracking from paging in MIPv6 and >have location tracking handled by the mobility protocol. There are still >plenty of details to fill out, but in principle, it seems as if the same >technique as is used in HMIPv6 extended mode would work here as well. > As for draft-ohba, oh yes you are right, I thought Yoshi proposed draft-ohba in one his emails, it seems that he did not. >> >>I do not recall having see this proposal during the current last call >>period, which started on Feb. 11. However, I will take this email as a >>proposal from you that the draft-ohba be used. So now we have two >>proposals for a different base draft, draft-ohba and draft-guri. >> Here is another quote from email dated Dec 21 on HA based paging: > >Then there is a scalability issue in mapping the DMA to the HA or MAP. > >There is also an issue in initiating a page from the HA. The HA might >be far across the Internet from the paging area where the MN is >located. There may be security and other (like latency) concerns >associated with having the DMA in another domain. > Have fun. -- Behcet --------------070205040608090300080507 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit 
Hello Jim,

Regarding HMIPv6 extended mode discussion, I am quoting from your mail sent on Dec.
17,2001: (full email is at the archives)
Seamoby group could possibly accept a protocol proposal based on
a protocol that has yet to even complete the requirements phase in
another
working group, to say nothing of the dependence on Mobile IPv6, which
is something the Seamoby working group has tried to avoid. The
HMIPv6-based
paging proposal not only didn't satisfy the requirements, but it set up
a dependence
that could ultimately hamper taking the Seamoby protocol to proposed
standard, if
the Mobile IP group rejected HMIPv6 in favor of another LMM protocol.


James Kempf wrote:
So it seems like we have some deeper technical understanding of how it
might be possible to separate location tracking from paging in MIPv6 and
have location tracking handled by the mobility protocol. There are still
plenty of details to fill out, but in principle, it seems as if the same
technique as is used in HMIPv6 extended mode would work here as well.
As for draft-ohba, oh yes you are right, I thought Yoshi proposed draft-ohba in one his emails, it seems that he did not. 

I do not recall having see this proposal during the current last call
period, which started on Feb. 11. However, I will take this email as a
proposal from you that the draft-ohba be used. So now we have two
proposals for a different base draft, draft-ohba and draft-guri.
Here is another quote from email dated Dec 21 on HA based paging:



Then there is a scalability issue in mapping the DMA to the HA or MAP.

There is also an issue in initiating a page from the HA. The HA might
be far across the Internet from the paging area where the MN is
located. There may be security and other (like latency) concerns
associated with having the DMA in another domain.


Have fun.
-- 
Behcet

--------------070205040608090300080507-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 20 00:47:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15522 for ; Wed, 20 Feb 2002 00:47:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA22956; Wed, 20 Feb 2002 00:27:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA22928 for ; Wed, 20 Feb 2002 00:27:33 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15388 for ; Wed, 20 Feb 2002 00:27:29 -0500 (EST) Received: from T23KEMPF (dhcp27.docomolabs-usa.com [172.21.96.27]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1K5QMe14943; Tue, 19 Feb 2002 21:26:22 -0800 (PST) Message-ID: <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> From: "James Kempf" To: "Yoshihiro Ohba" Cc: "Marco Liebsch" , "Yoshihiro Ohba" , References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Tue, 19 Feb 2002 21:24:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Yoshi, >I agree that the part of sending BU from MH to HA with alternate-CoA >would be a good thing. But I don't think that the other part in which >PA has to maintain the binding between CoA and the global home address >(whose prefix part is an on-link prefix of HA, not an on-link prefix >on PA) of a MN. Could you explain this some more? I don't understand what having the DMA mantain a CoA for the home agent has to do with where the prefix of the HoA is. To me, the DMA looks like a kind of FA in MIPv4, but potentially remote from the last hop (though it could be there). As long as the proper trust relationship exists, the MN should be able to allow it to take over. > In draft-ohba, DMAs are put on last-hop subnets. A DMA is a separated > entity from Paging Agent and Tracking Agent, and does not have a > knowledge about what is the paging area. So the DMA sends a Paging > message to Tracking Agent to page the MN. > > A Tracking Agent maintains the mapping between MN's terminal > identifier and MN's paging area. It also maintains a list of Paging > Agents per paging area so that it can forward a Paging message > received from a DMA to the Paging Agent(s) corresponding to the paging > area. The location of Tracking Agent is arbitrary. > Why not have the paging area identifier simply be an anycast (multicast in IPv4) address? And what is a "terminal identifier"? Home address? MAC address? I still don't understand why having the DMA on the last hop is so important. Also, I don't understand how it could work. Suppose an MN goes into dormant mode in subnet X in paging area A. Presumably, the DMA in subnet X now is waiting for packets for the MN. Now, suppose the MN moves to subnet Y, still in paging area A. Does the DMA perform a "handover"? If so, what is the point of having the paging areas? How could it even know? Does the DMA in subnet X continue to handle the MN? If so, what is the point of having the DMA on the last hop? Why not move it back, and have the option of an arbitrary mapping of DMAs to subnets? The other thing I don't like about this is that if the mobility protocol is, say, MIPv6, and the TA is in the HA, then the message flows like this: -> HA ----- (across the Internet) -----> DMA DMA ------------------- (across the Internet) ----------> HA (cum TA) HA ---------------------(across the Internet)----------->PA PA--------------------------------------------------> MN So there's a grand total of three traversals of the Internet in order to page the MN. Not too efficient. Maybe there is some thing I am missing here? > A Paging Agent maintains the mapping between paging area and IP > subnets. The mapping between paging area and subnet is arbitrary, > i.e., a paging area could contain multiple IP subnets, or an IP subnet > could contain multiple paging areas. To support the arbitrary mapping > between paging area and IP subnets, the location of Paging Agent is > also arbitrary, e.g., it could be co-located on AR, it could be put > behind ARs, or it could be put on APs. If a Paging Agent is put far > behind ARs, a list of Access Routers per paging area is maintained at > the Paging Agent and the list is used for advertising paging areas and > for wide-casting Paging messages. There may be multiple Paging Agents > in a single paging area and this would be useful when a paging area > covers multiple IP subnets or multiple APs while Paging Agents are > co-located with ARs or APs. > OK, we seem to be in some agreement here about the Paging Agent. I do see the Paging Agent maintaining a list of Access Routers in its paging area. Also, I see it doing dynamic paging area configuration and failover. > Any of two agents or all agents can be co-located in a single node, > depending on various requirements such as scalability, robustness, > complexity. For example, a DMA and a Paging Agent can be put together > in an AR. Or a Tracking Agent and a Paging Agent can be put together > in a single node behind ARs. Or all three types of agents are put > together in a single AR. And if co-located, external message exchange > is not necessary between different agents. > But you said above that the DMA had to be on the last hop, thus there are constraints. I think the DMA and the PA need to be co-located. They could be on an access router if there is only one subnet per paging area. Or they could be somewhere behind the access router. The DMA hooks for MIPv6 manage the MN's CoA while in dormant mode. It requires some hooks to support the other mobility protocols as well (see my message on MIPv4). jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 20 10:07:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02872 for ; Wed, 20 Feb 2002 10:07:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27441; Wed, 20 Feb 2002 09:55:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27416 for ; Wed, 20 Feb 2002 09:55:35 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02470 for ; Wed, 20 Feb 2002 09:55:31 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1KEsKjP026659; Wed, 20 Feb 2002 09:54:20 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id JAA18069; Wed, 20 Feb 2002 09:54:06 -0500 (EST) Date: Wed, 20 Feb 2002 09:54:11 -0500 To: James Kempf Cc: Yoshihiro Ohba , Marco Liebsch , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020220145411.GB3759@catfish> Mail-Followup-To: James Kempf , Yoshihiro Ohba , Marco Liebsch , seamoby@ietf.org References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 189 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Tue, Feb 19, 2002 at 09:24:46PM -0800, James Kempf wrote: > Yoshi, > > >I agree that the part of sending BU from MH to HA with alternate-CoA > >would be a good thing. But I don't think that the other part in which > >PA has to maintain the binding between CoA and the global home address > >(whose prefix part is an on-link prefix of HA, not an on-link prefix > >on PA) of a MN. > > Could you explain this some more? I don't understand what having the DMA > mantain a CoA for the home agent has to do with where the prefix of the > HoA is. To me, the DMA looks like a kind of FA in MIPv4, but potentially > remote from the last hop (though it could be there). As long as the > proper trust relationship exists, the MN should be able to allow it to > take over. In general, we should be very careful about sending BU since it could easility change the behavior of routing in the Internet. If BU is sent to a CN (MAP is a CN in the case of HMIPv6), then the binding cache created at the CN should be applied only to the packets originated from the CN, not to the packets to be forwarded at the CN. If a MAP(or PA/DMA) maintains a home address (HoA) where the prefix of the HoA does not match one of the on-link prefix of the MAP, then undesired routing behavior could occur, assuming that synchronization between the two binding caches at the MAP and the HA for HoA is impossible. For example, if the lifetime of the binding cache of the MAP is shorter than that of the HA (an attacker can easifly change the lifetime for the BU for the MAP and the BU for the HA), then a routing loop can easily form between the HA and MAP during the period in which the binding cache at the MAP is deleted (due to expiration of the lifetime) while the binding cache at the HA remains active. Otherwise, if a MAP(or PA/DMA) maintains a HoA where the prefix of the HoA matches one of the on-link prefix of the MAP (HMIPv6 basic mode belongs to this case), then no routing loop occur even if the lifetime of the binding cache is not synchronized between MAP and HA (If the MAP does not have a binding cache while HA has, then packets tunneled from the HA will be simply discarded at the MAP). So, I think that a solution relying on the HMIPv6 extended mode is not acceptable. A solution relying on the HMIPv6 basic mode seems to be less problematic, but the technique would be applicable only to IPv6, not to IPv4... BTW, this technical discussion raises one issue as Behcet pointed out: the selection team needs to explain for the fact that they rejected one of the proposals because it depends on HMIPv6 and the fact the selected proposal also turned out to depend on a mechanism which is virtually equivalent to HMIPv6. > > > In draft-ohba, DMAs are put on last-hop subnets. A DMA is a separated > > entity from Paging Agent and Tracking Agent, and does not have a > > knowledge about what is the paging area. So the DMA sends a Paging > > message to Tracking Agent to page the MN. > > > > A Tracking Agent maintains the mapping between MN's terminal > > identifier and MN's paging area. It also maintains a list of Paging > > Agents per paging area so that it can forward a Paging message > > received from a DMA to the Paging Agent(s) corresponding to the paging > > area. The location of Tracking Agent is arbitrary. > > > > Why not have the paging area identifier simply be an anycast (multicast > in IPv4) address? > And what is a "terminal identifier"? Home address? MAC address? Because paging area can be different per MN (personalized paging area). Anycast (or multicast in IPv4) is not defined per host, I think. Regarding terminal identifier, it is described in section 5.1.11 of draft-ohba: If Host supports Mobile IP [MOBILEIP] or Mobile IPv6 [MOBILEIP-V6], the Home Address of the Host MAY be specified in this TLV. Essentially, any stable identifier can be used as the terminal identifier. > > I still don't understand why having the DMA on the last hop is so > important. Also, I don't understand > how it could work. Having the DMA on the last hop is important for (i) working with any mobility management protocol and null mobility management protocol (i.e., stationaly hosts) and (ii) avoiding a single point of failure. > > Suppose an MN goes into dormant mode in subnet X in paging area A. > Presumably, the DMA in subnet X now is waiting for packets for the MN. > Now, suppose the MN moves to subnet Y, still in paging area A. Does the > DMA perform a "handover"? No. The MN can stay dormant without performing handover. When the DMA captures a data packet destined for the CoA, it sends a Paging message to Paging Agent (via TA) and Paging Agent can "page" the MN. Note that since the DMA is on the last hop subnet of the subnet of the CoA, any data packet in which the CoA is specified in the destination address is captured without an exception regardless of what kind of mobility managenet protocol is used, and this is one of the reasons for why DMA is in last hop subnet as I explained above. The DMA does not have to know what is the paging area, because TA and Paging Agent have the knowledge on the paging area. The DMA is used just for capturing a data packet and then triggering paging. > If so, what is the point of having the paging > areas? How could it even know? Does the DMA in subnet X continue to > handle the MN? If so, what is the point of having the DMA on the last > hop? Why not move it back, and have the option of an arbitrary mapping > of DMAs to subnets? > > The other thing I don't like about this is that if the mobility protocol > is, say, MIPv6, and the TA is in the HA, then the message flows like > this: > > -> HA ----- (across the > Internet) -----> DMA > DMA ------------------- (across the Internet) ----------> HA > (cum TA) > HA ---------------------(across the Internet)----------->PA > PA--------------------------------------------------> MN > > So there's a grand total of three traversals of the Internet in order to > page the MN. Not too efficient. In that particular case, why not putting the DMA on the HA? Then it could be much more efficient as: -> HA (=DMA=TA) HA ---------------------(across the Internet)----------->PA PA--------------------------------------------------> MN > > Maybe there is some thing I am missing here? > > > > A Paging Agent maintains the mapping between paging area and IP > > subnets. The mapping between paging area and subnet is arbitrary, > > i.e., a paging area could contain multiple IP subnets, or an IP subnet > > could contain multiple paging areas. To support the arbitrary mapping > > between paging area and IP subnets, the location of Paging Agent is > > also arbitrary, e.g., it could be co-located on AR, it could be put > > behind ARs, or it could be put on APs. If a Paging Agent is put far > > behind ARs, a list of Access Routers per paging area is maintained at > > the Paging Agent and the list is used for advertising paging areas and > > for wide-casting Paging messages. There may be multiple Paging Agents > > in a single paging area and this would be useful when a paging area > > covers multiple IP subnets or multiple APs while Paging Agents are > > co-located with ARs or APs. > > > > OK, we seem to be in some agreement here about the Paging Agent. I do > see the Paging Agent maintaining a list of Access Routers in its paging > area. Also, I see it doing dynamic paging area configuration and > failover. > > > Any of two agents or all agents can be co-located in a single node, > > depending on various requirements such as scalability, robustness, > > complexity. For example, a DMA and a Paging Agent can be put together > > in an AR. Or a Tracking Agent and a Paging Agent can be put together > > in a single node behind ARs. Or all three types of agents are put > > together in a single AR. And if co-located, external message exchange > > is not necessary between different agents. > > > > But you said above that the DMA had to be on the last hop, thus there > are constraints. But less problematic, I believe. > > I think the DMA and the PA need to be co-located. They could be on an > access router if there > is only one subnet per paging area. Or they could be somewhere behind > the access router. > The DMA hooks for MIPv6 manage the MN's CoA while in dormant mode. It > requires some hooks to support the other mobility protocols as well (see > my message on MIPv4). > > jak > > > Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 20 11:00:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04752 for ; Wed, 20 Feb 2002 11:00:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00800; Wed, 20 Feb 2002 10:49:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00774 for ; Wed, 20 Feb 2002 10:49:11 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04398 for ; Wed, 20 Feb 2002 10:49:08 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1KFmfL17913 for ; Wed, 20 Feb 2002 09:48:41 -0600 (CST) Message-ID: <3C73C54B.4070308@alcatel.com> Date: Wed, 20 Feb 2002 09:48:27 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish <20020220145411.GB3759@catfish> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Thanks Yoshi. It is clear that the discussions led to the identification of what is missing in draft-renker which already exists in other drafts, such as DMA (DMA-FE as Marco calls it) is already in draft-guri for IPv6 and in draft-ohba for IPv4 and (P)MAP in draft-sarikaya. Why don't we say to Marco, Marco, sorry but you missed the train and continue our business? Yoshihiro Ohba wrote: > > >BTW, this technical discussion raises one issue as Behcet pointed >out: the selection team needs to explain for the fact that they >rejected one of the proposals because it depends on HMIPv6 and the >fact the selected proposal also turned out to depend on a mechanism >which is virtually equivalent to HMIPv6. > Regards, -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 20 11:23:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05283 for ; Wed, 20 Feb 2002 11:23:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01556; Wed, 20 Feb 2002 11:01:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01522 for ; Wed, 20 Feb 2002 11:01:15 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04778 for ; Wed, 20 Feb 2002 11:01:12 -0500 (EST) Received: from research.telcordia.com (zhang-pc [192.4.12.89]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1KFxhjP003010; Wed, 20 Feb 2002 10:59:43 -0500 (EST) Message-ID: <3C73C7B7.367F6DD4@research.telcordia.com> Date: Wed, 20 Feb 2002 10:58:47 -0500 From: Tao Zhang X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Yoshihiro Ohba , Marco Liebsch , seamoby@ietf.org, tao@research.telcordia.com Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James, In addition to Yoshi's reply to your following question regarding draft-ohba, please see my comments below. James Kempf wrote: > But you said above that the DMA had to be on the last hop, thus there > are constraints. > > I think the DMA and the PA need to be co-located. They could be on an > access router if there > is only one subnet per paging area. Or they could be somewhere behind > the access router. > The DMA hooks for MIPv6 manage the MN's CoA while in dormant mode. It > requires some hooks to support the other mobility protocols as well (see > my message on MIPv4). The DMA does not have to be on the last hop. Placing a DMA on every last-hop subnet is one way of implementing the paging protocol which will enable the paging protocol to be completely independent of mobility protocols. However, if we know what mobility protocol is used and wish to optimizee the paging protocol for that particular mobility protocol, the DMA does not HAVE to be on the last hop. For example, if the mobility protocol is MIPv4, the DMA may be co-located with the FAs or the HA. The jobs of the DMA are to capture packets destined to a dormant host and trigger the paging process. Where to put the DMA in a real network can be determined based on how much dependency or collaboration one wishes the paging protocol to have on/with the mobility protocols. The DMA and the PA MAY be co-located, but do not NEED to be co-located. Regards Tao Zhang _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 20 12:50:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10977 for ; Wed, 20 Feb 2002 12:50:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09716; Wed, 20 Feb 2002 12:39:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09687 for ; Wed, 20 Feb 2002 12:39:22 -0500 (EST) Received: from hotmail.com (f154.law9.hotmail.com [64.4.9.154]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10475 for ; Wed, 20 Feb 2002 12:39:17 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Feb 2002 09:38:51 -0800 Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 20 Feb 2002 17:38:50 GMT X-Originating-IP: [63.78.179.4] From: "Govind Krishnamurthi" To: seamoby@ietf.org Date: Wed, 20 Feb 2002 12:38:50 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Feb 2002 17:38:51.0428 (UTC) FILETIME=[75BA9640:01C1BA35] Subject: [Seamoby] CAR Discovery Requirements ... Call for Comments Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello all, I hope that you have had a chance to read the CAR Discovery Requirements draft. I request you to post any comments that you may have on the document soon, so that I would have the time to incorporate them in the document if we have WG consensus. Regards, Govind. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 20 13:35:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15230 for ; Wed, 20 Feb 2002 13:35:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12179; Wed, 20 Feb 2002 13:25:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12154 for ; Wed, 20 Feb 2002 13:25:01 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13020 for ; Wed, 20 Feb 2002 13:24:58 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1KIOQjP018219; Wed, 20 Feb 2002 13:24:26 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id NAA18628; Wed, 20 Feb 2002 13:24:20 -0500 (EST) Date: Wed, 20 Feb 2002 13:24:24 -0500 To: Behcet Sarikaya Cc: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020220182424.GE3759@catfish> Mail-Followup-To: Behcet Sarikaya , seamoby@ietf.org References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020220145411.GB3759@catfish> <3C73C54B.4070308@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3C73C54B.4070308@alcatel.com> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 19 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Wed, Feb 20, 2002 at 09:48:27AM -0600, Behcet Sarikaya wrote: > Thanks Yoshi. > It is clear that the discussions led to the identification of what is > missing in draft-renker which already exists in other drafts, such as > DMA (DMA-FE as Marco calls it) is already in draft-guri for IPv6 and in > draft-ohba for IPv4 and (P)MAP in draft-sarikaya. > Why don't we say to Marco, Marco, sorry but you missed the train > and continue our business? > Note that draft-ohba is for both IPv4 and IPv6. And I don't much care about whatever protocol is selected as a starting point, as I mentioned earlier. But I do care about what the final WG product will be. Thanks, Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 20 22:47:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29185 for ; Wed, 20 Feb 2002 22:47:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09716; Wed, 20 Feb 2002 22:34:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09690 for ; Wed, 20 Feb 2002 22:34:36 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28869 for ; Wed, 20 Feb 2002 22:34:31 -0500 (EST) Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1L3XKe17863; Wed, 20 Feb 2002 19:33:20 -0800 (PST) Message-ID: <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> From: "James Kempf" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Marco Liebsch" , References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Wed, 20 Feb 2002 19:31:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Yoshi, > In general, we should be very careful about sending BU since it could > easility change the behavior of routing in the Internet. If BU is > sent to a CN (MAP is a CN in the case of HMIPv6), then the binding > cache created at the CN should be applied only to the packets > originated from the CN, not to the packets to be forwarded at the CN. > > If a MAP(or PA/DMA) maintains a home address (HoA) where the prefix of > the HoA does not match one of the on-link prefix of the MAP, then > undesired routing behavior could occur, assuming that synchronization > between the two binding caches at the MAP and the HA for HoA is > impossible. For example, if the lifetime of the binding cache of the > MAP is shorter than that of the HA (an attacker can easifly change the > lifetime for the BU for the MAP and the BU for the HA), then a routing > loop can easily form between the HA and MAP during the period in which > the binding cache at the MAP is deleted (due to expiration of the > lifetime) while the binding cache at the HA remains active. > I guess I don't see how this follows. If the binding cache entry at the MAP times out, it simply drops the packet when the HA forwards it. How does the loop form? (I'm assuming we are talking straight HMIPv6 here, and not paging.) > Otherwise, if a MAP(or PA/DMA) maintains a HoA where the prefix of the > HoA matches one of the on-link prefix of the MAP (HMIPv6 basic mode > belongs to this case), then no routing loop occur even if the lifetime > of the binding cache is not synchronized between MAP and HA (If the > MAP does not have a binding cache while HA has, then packets tunneled > from the HA will be simply discarded at the MAP). > > So, I think that a solution relying on the HMIPv6 extended mode is not > acceptable. A solution relying on the HMIPv6 basic mode seems to be > less problematic, but the technique would be applicable only to IPv6, > not to IPv4... > Still not clear to me. But you do bring up a good point here. In order to have the DMA relay the MN's paging area movement to the MN, it would have to keep around the MN's HoA, which is a piece of MN location state. It would be good to avoid this, but I don't see how short of requiring the MN to come out of dormant mode and issue the BU when it changes paging area. > BTW, this technical discussion raises one issue as Behcet pointed > out: the selection team needs to explain for the fact that they > rejected one of the proposals because it depends on HMIPv6 and the > fact the selected proposal also turned out to depend on a mechanism > which is virtually equivalent to HMIPv6. > This is a category error. As I said before, draft-renker depends on a particular way of using MIPv6. HMIPv6 depends on a particular way of using MIPv6. This does not make draft-renker equivalent to HMIPv6. To see the error, suppose draft-renker would have been published before HMIPv6. Would that make HMIPv6 "virtually equivalent" to draft-renker? > > Why not have the paging area identifier simply be an anycast (multicast > > in IPv4) address? > > And what is a "terminal identifier"? Home address? MAC address? > > Because paging area can be different per MN (personalized paging area). > Anycast (or multicast in IPv4) is not defined per host, I think. > But the MN doesn't have to have a personalized paging area, that is a policy option. Anyway, the point is, it can be an IP address. > Regarding terminal identifier, it is described in section 5.1.11 of > draft-ohba: > > If Host supports Mobile IP [MOBILEIP] or Mobile IPv6 [MOBILEIP-V6], > the Home Address of the Host MAY be specified in this TLV. > > Essentially, any stable identifier can be used as the terminal > identifier. > OK. > > > > I still don't understand why having the DMA on the last hop is so > > important. Also, I don't understand > > how it could work. > > Having the DMA on the last hop is important for (i) working with any > mobility management protocol and null mobility management protocol > (i.e., stationaly hosts) and This isn't clear (but I see you explain it better below). > (ii) avoiding a single point of failure. > But you could have multiple DMAs behind the last hop. And, as I have mentioned in previous notes (and I believe you even specified in draft-ohba) the DMAs can exchange periodic messages. If a message falls out, others reconfigure to take over. The router solution. > > > > Suppose an MN goes into dormant mode in subnet X in paging area A. > > Presumably, the DMA in subnet X now is waiting for packets for the MN. > > Now, suppose the MN moves to subnet Y, still in paging area A. Does the > > DMA perform a "handover"? > > No. The MN can stay dormant without performing handover. When the > DMA captures a data packet destined for the CoA, it sends a Paging > message to Paging Agent (via TA) and Paging Agent can "page" the MN. > Note that since the DMA is on the last hop subnet of the subnet of the > CoA, any data packet in which the CoA is specified in the destination What does the CoA have to do with it? The MN is in dormant mode, roaming across multiple subnets. It no longer has a fixed CoA. Or, are you proposing that the CoA stay the same as when the MN went to sleep? That's the point I was trying to make about the extreme message legs across large chunks of the Internet. > address is captured without an exception regardless of what kind of > mobility managenet protocol is used, and this is one of the reasons > for why DMA is in last hop subnet as I explained above. The DMA does > not have to know what is the paging area, because TA and Paging Agent > have the knowledge on the paging area. > > The DMA is used just for capturing a data packet and then triggering > paging. > It seems like what you are saying is that, in essence, the Access Router in the last hop must maintain the state for any dormant nodes that have gone to sleep, presuming we map the DMA to the Access Router. But I thought we wanted to offload this state from the Access Router. > > If so, what is the point of having the paging > > areas? How could it even know? Does the DMA in subnet X continue to > > handle the MN? If so, what is the point of having the DMA on the last > > hop? Why not move it back, and have the option of an arbitrary mapping > > of DMAs to subnets? > > > > The other thing I don't like about this is that if the mobility protocol > > is, say, MIPv6, and the TA is in the HA, then the message flows like > > this: > > > > -> HA ----- (across the > > Internet) -----> DMA > > DMA ------------------- (across the Internet) ----------> HA > > (cum TA) > > HA ---------------------(across the Internet)----------->PA > > PA--------------------------------------------------> MN > > > > So there's a grand total of three traversals of the Internet in order to > > page the MN. Not too efficient. > > In that particular case, why not putting the DMA on the HA? > Then it could be much more efficient as: > > -> HA (=DMA=TA) > HA ---------------------(across the Internet)----------->PA > PA--------------------------------------------------> MN > Well, then the DMA *certainly* isn't on the last hop, is it? :-) Also, I think we want some way that we can avoid having the MN come out of dormant mode to do a MIPv6 BU when it changes paging area. I'd like somebody in the network to be able to do it for the MN. It is much more efficient powerwise, and it allows using an efficient (and existing) L2 paging protocol without requiring that protocol to carry IP. But perhaps this isn't possible to do (securely). jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 20 23:33:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00272 for ; Wed, 20 Feb 2002 23:33:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12125; Wed, 20 Feb 2002 23:22:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12096 for ; Wed, 20 Feb 2002 23:22:13 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29734 for ; Wed, 20 Feb 2002 23:22:08 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1L4Mdi10212 for ; Thu, 21 Feb 2002 06:22:39 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Feb 2002 06:22:10 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 21 Feb 2002 06:22:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Thu, 21 Feb 2002 06:22:10 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64993@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Thread-Index: AcG6jszmAc56BwgZTc6U8JsLODHemgAACumw To: , Cc: , , X-OriginalArrivalTime: 21 Feb 2002 04:22:10.0710 (UTC) FILETIME=[54B19B60:01C1BA8F] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi all, > > BTW, this technical discussion raises one issue as Behcet pointed > > out: the selection team needs to explain for the fact that they > > rejected one of the proposals because it depends on HMIPv6 and the > > fact the selected proposal also turned out to depend on a mechanism > > which is virtually equivalent to HMIPv6. > > > > This is a category error. > > As I said before, draft-renker depends on a particular way of using > MIPv6. > HMIPv6 depends on a particular way of using MIPv6. This does not make > draft-renker equivalent to HMIPv6. Just sticking my nose into this. If draft-renker would be dependent on HMIP, then this might be a problem. (i.e. - a normative reference) Currently, HMIPv6 is not progressing until MIPv6 completes. Additionally, MIP WG is undergoing a review of LMM (Local Mobility Management) solutions, and the result of this may make changes to HMIPv6. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 20 23:34:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00308 for ; Wed, 20 Feb 2002 23:34:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12216; Wed, 20 Feb 2002 23:23:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12191 for ; Wed, 20 Feb 2002 23:23:29 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29769 for ; Wed, 20 Feb 2002 23:23:24 -0500 (EST) Received: from T23KEMPF (dhcp142.docomolabs-usa.com [172.21.96.142]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1L4M2e18960; Wed, 20 Feb 2002 20:22:10 -0800 (PST) Message-ID: <018001c1ba8f$1b7b2730$2c6015ac@T23KEMPF> From: "James Kempf" To: "Tao Zhang" Cc: "Yoshihiro Ohba" , "Marco Liebsch" , , References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <3C73C7B7.367F6DD4@research.telcordia.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Wed, 20 Feb 2002 20:20:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Tao, > The DMA does not have to be on the last hop. Placing a DMA on every last-hop > subnet is one way of implementing the paging protocol which will enable the > paging protocol to be completely independent of mobility protocols. However, > if we know what mobility protocol is used and wish to optimizee the paging > protocol for that particular mobility protocol, the DMA does not HAVE to be > on the last hop. For example, if the mobility protocol is MIPv4, the DMA may > be co-located with the FAs or the HA. The jobs of the DMA are to capture > packets destined to a dormant host and trigger the paging process. Where to > put the DMA in a real network can be determined based on how much dependency > or collaboration one wishes the paging protocol to have on/with the mobility > protocols. > > The DMA and the PA MAY be co-located, but do not NEED to be co-located. > OK, now this is starting to make a little sense to me. If the DMA doesn't need to be at the last hop, then I think we could arrange to optimize as you say, and consider that as part of adding something to the mobility protocol for paging and not changing it fundamentally. I think that would be better than specifying it at the last hop and then incurring the messaging overhead. Since I think we now seem to agree on this point, then maybe we can move the focus to what I think is a more important design question. Is there any way to arrange the DMA and TA in MIPv6 so that a) the foreign network is not maintaining any location state for the mobile node, including not maintaining the home agent address, and b) that the MN doesn't have to come out of dormant mode to do a BU and can use an existing, lightweight L2 paging protocol or lightweight IP protocol to somehow get that done by the network, modulo the security question. I think these goals may not be reconcilable, but I hope I am mistaken. For MIPv4, the problem seems much easier to solve because the FA can change the registration for the MN when the MN changes paging area (provided the right security association exists). jak PS: In Hawaii paging, I think the DMA and TA will be in the foreign network, because mobilitiy management is localized, unlike MIP. They won't be on the last hop though, at least, not according to Ram's Mobicomm paper of last year. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Feb 20 23:38:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00353 for ; Wed, 20 Feb 2002 23:38:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12388; Wed, 20 Feb 2002 23:28:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12361 for ; Wed, 20 Feb 2002 23:28:13 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29835 for ; Wed, 20 Feb 2002 23:28:08 -0500 (EST) Received: from T23KEMPF (dhcp142.docomolabs-usa.com [172.21.96.142]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1L4Qve19082; Wed, 20 Feb 2002 20:26:57 -0800 (PST) Message-ID: <018e01c1ba8f$c68ddc80$2c6015ac@T23KEMPF> From: "James Kempf" To: , Cc: , , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64993@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Wed, 20 Feb 2002 20:25:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit John, > > > BTW, this technical discussion raises one issue as Behcet pointed > > > out: the selection team needs to explain for the fact that they > > > rejected one of the proposals because it depends on HMIPv6 and the > > > fact the selected proposal also turned out to depend on a mechanism > > > which is virtually equivalent to HMIPv6. > > > > > > > This is a category error. > > > > As I said before, draft-renker depends on a particular way of using > > MIPv6. > > HMIPv6 depends on a particular way of using MIPv6. This does not make > > draft-renker equivalent to HMIPv6. > > Just sticking my nose into this. If draft-renker would be dependent on HMIP, > then this might be a problem. (i.e. - a normative reference) Currently, HMIPv6 > is not progressing until MIPv6 completes. Additionally, MIP WG is undergoing > a review of LMM (Local Mobility Management) solutions, and the result > of this may make changes to HMIPv6. > As perhaps you might have been able to determine from the technical discussion, we are a long way from worrying about questions like this. We still have to figure out how, fundamentally, paging will work. Fortunately, nobody has plans to do an IP paging product any time soon. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 06:18:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13225 for ; Thu, 21 Feb 2002 06:18:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13101; Thu, 21 Feb 2002 06:05:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13070 for ; Thu, 21 Feb 2002 06:05:46 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13106 for ; Thu, 21 Feb 2002 06:05:42 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1LB7fg08415; Thu, 21 Feb 2002 12:07:41 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA14833; Thu, 21 Feb 2002 12:05:10 +0100 Message-ID: <3C74D466.9018A0BD@ccrle.nec.de> Date: Thu, 21 Feb 2002 12:05:10 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshihiro Ohba CC: James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Yoshi, Yoshihiro Ohba wrote: > On Tue, Feb 19, 2002 at 09:41:36AM -0800, James Kempf wrote: > > Yoshi, > > > > > Then, it seems to me that: > > > > > > draft-renker = HMIPv6 extended mode + DMHA functionality, > > > > > > where the part of HMIPv6 extended mode is the hook to MIPv6. > > > > > > In other words, it actually depends on HMIPv6. > > > > > > > Telnet uses TCP, and so does HTTP. Does that mean that HTTP depends on > > Telnet? > > TCP is mandatory for both telnet and HTTP. On the other hand, HMIPv6 > or equivalent mechanism seems to be mandatory for draft-renker while > HMIPv6 is optional for MIPv6. So the situation is not exactly > analogous to the case of telnet and http. > > > > > What this is pointing up is that both HMIPv6 and the IPv6 hooks for > > paging in draft-renker are using the same mechanism from MIPv6. As I > > mentioned in my email to the MIP list, I could imagine another > > application in which a handoff is done from a cell phone to a > > workstation when the cell phone is switched off. What this is pointing > > out is that MIPv6 actually has a sufficiently generalized mechanism for > > our purposes, a good thing. > > I agree that the part of sending BU from MH to HA with alternate-CoA > would be a good thing. But I don't think that the other part in which > PA has to maintain the binding between CoA and the global home address > (whose prefix part is an on-link prefix of HA, not an on-link prefix > on PA) of a MN. > > > > > > If DMA is put at last hop subnets as described in draft-ohba, then the > > > hook becomes independent of HMIPv6, since all packets can be captured > > > at last hop subnets without a special mechanism. Moreover, if we > > > consider time-slotted dormant mode support at L3, some agent would be > > > needed at last hop subnets to provide better synchronization between a > > > host and network, so putting DMA at each last hop subnet would not be > > > unrealistic to me. > > > > > > > So explain to me how DMA can be put at the last hop without having a > > one-to-one mapping between the paging area and the subnet? That was > > never clearly articulated in draft-ohba, IMHO. > > This would not be the main topic of this thread, but this would be a > good chance to explain. > > In draft-ohba, DMAs are put on last-hop subnets. A DMA is a separated > entity from Paging Agent and Tracking Agent, and does not have a > knowledge about what is the paging area. So the DMA sends a Paging > message to Tracking Agent to page the MN. > As already described, putting the DMA on routers in a distributed manner, is a good approach which is probably required for e.g. routing based mobility management approaches, since paging trigger packets do not address the DMA directly. This is described for the concept in draft renker, which allows to take away DMA functional entity from PA and locate it on e.g. border routers. I'm not sure if placing the DMA on the last hop is the right approach. Your proposal 'last-hop DMHA' proposes a rather distributed architecture, having a lot of communication and protocol message exchange between the entities. I am not sure if this complexity is really necessary in order to design a scalable and flexible system. In draft-renker, taking the DMA functional entity away from PA and placing them on or close to border routers, is an option. But for the described example mobility management platform MIPv6, the PA makes use of available registration mechansims and allows addressing the DMA function. Again, in order to avoid replying emails w.r.t the latter sentence: This does NOT mean, that the concept is dependent on MIPv6. And also not on HMIPv6. This should be clear. Separating the DMA is a minor issue and only a small fraction in the entire paging issue, addressing 'how deoes the IP paging architecture gets paging trigger packets'. What should be considered is the entire architecture described, which keeps flexibility without introducing unnecessary complexity.. Marco > > A Tracking Agent maintains the mapping between MN's terminal > identifier and MN's paging area. It also maintains a list of Paging > Agents per paging area so that it can forward a Paging message > received from a DMA to the Paging Agent(s) corresponding to the paging > area. The location of Tracking Agent is arbitrary. > > A Paging Agent maintains the mapping between paging area and IP > subnets. The mapping between paging area and subnet is arbitrary, > i.e., a paging area could contain multiple IP subnets, or an IP subnet > could contain multiple paging areas. To support the arbitrary mapping > between paging area and IP subnets, the location of Paging Agent is > also arbitrary, e.g., it could be co-located on AR, it could be put > behind ARs, or it could be put on APs. If a Paging Agent is put far > behind ARs, a list of Access Routers per paging area is maintained at > the Paging Agent and the list is used for advertising paging areas and > for wide-casting Paging messages. There may be multiple Paging Agents > in a single paging area and this would be useful when a paging area > covers multiple IP subnets or multiple APs while Paging Agents are > co-located with ARs or APs. > > Any of two agents or all agents can be co-located in a single node, > depending on various requirements such as scalability, robustness, > complexity. For example, a DMA and a Paging Agent can be put together > in an AR. Or a Tracking Agent and a Paging Agent can be put together > in a single node behind ARs. Or all three types of agents are put > together in a single AR. And if co-located, external message exchange > is not necessary between different agents. > > > > > jak > > > > > > Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 08:02:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15756 for ; Thu, 21 Feb 2002 08:02:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18059; Thu, 21 Feb 2002 07:47:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17988 for ; Thu, 21 Feb 2002 07:47:28 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15318 for ; Thu, 21 Feb 2002 07:47:25 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1LCnQg11667; Thu, 21 Feb 2002 13:49:26 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA16247; Thu, 21 Feb 2002 13:46:51 +0100 Message-ID: <3C74EC3B.5CDFDEA7@ccrle.nec.de> Date: Thu, 21 Feb 2002 13:46:51 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshihiro Ohba CC: James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi Yoshi and James, I do not understand why the discussion is now on MAPs and HMIPv6 ??? Original issue was 'how are paging trigger packets received/intercepted at the DMA'. Isn't it? 1st issue: DMA receives or intercepts paging trigger packet 2nd issue: DMA makes use of the MN identifiers in the paging trigger packet in order to request other functional antities to resolve paging area and to acquire exact routing information for the MN registered as idle. draft-renker describes an architecture, where the DMA functional entity can be integrated with the PA function and considers distributed functional entity, e.g. on border routers. For a MIPv6 managed system, the concept proposes the explained registration mechanism (meeting the requirement 4.8). It considers to extract the DMA fucntional entity. The entire concept ( PA, AR attendants and integrated or separated DMA ) intends to design a flexible architecture without introduction of unneeded complexity. draft-ohba describes an entirely distributed architecture with a lot of protocol interaction between entities, also considering distributed DMA (as described, its on the last hop).. DMA location is obviously different for individual platforms and scenarios. But not only DMA, but entire architecture advantages and disadvantages should be taken into account. Marco Yoshihiro Ohba wrote: > On Tue, Feb 19, 2002 at 09:24:46PM -0800, James Kempf wrote: > > Yoshi, > > > > >I agree that the part of sending BU from MH to HA with alternate-CoA > > >would be a good thing. But I don't think that the other part in which > > >PA has to maintain the binding between CoA and the global home address > > >(whose prefix part is an on-link prefix of HA, not an on-link prefix > > >on PA) of a MN. > > > > Could you explain this some more? I don't understand what having the DMA > > mantain a CoA for the home agent has to do with where the prefix of the > > HoA is. To me, the DMA looks like a kind of FA in MIPv4, but potentially > > remote from the last hop (though it could be there). As long as the > > proper trust relationship exists, the MN should be able to allow it to > > take over. > > In general, we should be very careful about sending BU since it could > easility change the behavior of routing in the Internet. If BU is > sent to a CN (MAP is a CN in the case of HMIPv6), then the binding > cache created at the CN should be applied only to the packets > originated from the CN, not to the packets to be forwarded at the CN. > > If a MAP(or PA/DMA) maintains a home address (HoA) where the prefix of > the HoA does not match one of the on-link prefix of the MAP, then > undesired routing behavior could occur, assuming that synchronization > between the two binding caches at the MAP and the HA for HoA is > impossible. For example, if the lifetime of the binding cache of the > MAP is shorter than that of the HA (an attacker can easifly change the > lifetime for the BU for the MAP and the BU for the HA), then a routing > loop can easily form between the HA and MAP during the period in which > the binding cache at the MAP is deleted (due to expiration of the > lifetime) while the binding cache at the HA remains active. > > Otherwise, if a MAP(or PA/DMA) maintains a HoA where the prefix of the > HoA matches one of the on-link prefix of the MAP (HMIPv6 basic mode > belongs to this case), then no routing loop occur even if the lifetime > of the binding cache is not synchronized between MAP and HA (If the > MAP does not have a binding cache while HA has, then packets tunneled > from the HA will be simply discarded at the MAP). > > So, I think that a solution relying on the HMIPv6 extended mode is not > acceptable. A solution relying on the HMIPv6 basic mode seems to be > less problematic, but the technique would be applicable only to IPv6, > not to IPv4... > > BTW, this technical discussion raises one issue as Behcet pointed > out: the selection team needs to explain for the fact that they > rejected one of the proposals because it depends on HMIPv6 and the > fact the selected proposal also turned out to depend on a mechanism > which is virtually equivalent to HMIPv6. > > > > > > In draft-ohba, DMAs are put on last-hop subnets. A DMA is a separated > > > entity from Paging Agent and Tracking Agent, and does not have a > > > knowledge about what is the paging area. So the DMA sends a Paging > > > message to Tracking Agent to page the MN. > > > > > > A Tracking Agent maintains the mapping between MN's terminal > > > identifier and MN's paging area. It also maintains a list of Paging > > > Agents per paging area so that it can forward a Paging message > > > received from a DMA to the Paging Agent(s) corresponding to the paging > > > area. The location of Tracking Agent is arbitrary. > > > > > > > Why not have the paging area identifier simply be an anycast (multicast > > in IPv4) address? > > And what is a "terminal identifier"? Home address? MAC address? > > Because paging area can be different per MN (personalized paging area). > Anycast (or multicast in IPv4) is not defined per host, I think. > > Regarding terminal identifier, it is described in section 5.1.11 of > draft-ohba: > > If Host supports Mobile IP [MOBILEIP] or Mobile IPv6 [MOBILEIP-V6], > the Home Address of the Host MAY be specified in this TLV. > > Essentially, any stable identifier can be used as the terminal > identifier. > > > > > I still don't understand why having the DMA on the last hop is so > > important. Also, I don't understand > > how it could work. > > Having the DMA on the last hop is important for (i) working with any > mobility management protocol and null mobility management protocol > (i.e., stationaly hosts) and (ii) avoiding a single point of failure. > > > > > Suppose an MN goes into dormant mode in subnet X in paging area A. > > Presumably, the DMA in subnet X now is waiting for packets for the MN. > > Now, suppose the MN moves to subnet Y, still in paging area A. Does the > > DMA perform a "handover"? > > No. The MN can stay dormant without performing handover. When the > DMA captures a data packet destined for the CoA, it sends a Paging > message to Paging Agent (via TA) and Paging Agent can "page" the MN. > Note that since the DMA is on the last hop subnet of the subnet of the > CoA, any data packet in which the CoA is specified in the destination > address is captured without an exception regardless of what kind of > mobility managenet protocol is used, and this is one of the reasons > for why DMA is in last hop subnet as I explained above. The DMA does > not have to know what is the paging area, because TA and Paging Agent > have the knowledge on the paging area. > > The DMA is used just for capturing a data packet and then triggering > paging. > > > If so, what is the point of having the paging > > areas? How could it even know? Does the DMA in subnet X continue to > > handle the MN? If so, what is the point of having the DMA on the last > > hop? Why not move it back, and have the option of an arbitrary mapping > > of DMAs to subnets? > > > > The other thing I don't like about this is that if the mobility protocol > > is, say, MIPv6, and the TA is in the HA, then the message flows like > > this: > > > > -> HA ----- (across the > > Internet) -----> DMA > > DMA ------------------- (across the Internet) ----------> HA > > (cum TA) > > HA ---------------------(across the Internet)----------->PA > > PA--------------------------------------------------> MN > > > > So there's a grand total of three traversals of the Internet in order to > > page the MN. Not too efficient. > > In that particular case, why not putting the DMA on the HA? > Then it could be much more efficient as: > > -> HA (=DMA=TA) > HA ---------------------(across the Internet)----------->PA > PA--------------------------------------------------> MN > > > > > Maybe there is some thing I am missing here? > > > > > > > A Paging Agent maintains the mapping between paging area and IP > > > subnets. The mapping between paging area and subnet is arbitrary, > > > i.e., a paging area could contain multiple IP subnets, or an IP subnet > > > could contain multiple paging areas. To support the arbitrary mapping > > > between paging area and IP subnets, the location of Paging Agent is > > > also arbitrary, e.g., it could be co-located on AR, it could be put > > > behind ARs, or it could be put on APs. If a Paging Agent is put far > > > behind ARs, a list of Access Routers per paging area is maintained at > > > the Paging Agent and the list is used for advertising paging areas and > > > for wide-casting Paging messages. There may be multiple Paging Agents > > > in a single paging area and this would be useful when a paging area > > > covers multiple IP subnets or multiple APs while Paging Agents are > > > co-located with ARs or APs. > > > > > > > OK, we seem to be in some agreement here about the Paging Agent. I do > > see the Paging Agent maintaining a list of Access Routers in its paging > > area. Also, I see it doing dynamic paging area configuration and > > failover. > > > > > Any of two agents or all agents can be co-located in a single node, > > > depending on various requirements such as scalability, robustness, > > > complexity. For example, a DMA and a Paging Agent can be put together > > > in an AR. Or a Tracking Agent and a Paging Agent can be put together > > > in a single node behind ARs. Or all three types of agents are put > > > together in a single AR. And if co-located, external message exchange > > > is not necessary between different agents. > > > > > > > But you said above that the DMA had to be on the last hop, thus there > > are constraints. > > But less problematic, I believe. > > > > > I think the DMA and the PA need to be co-located. They could be on an > > access router if there > > is only one subnet per paging area. Or they could be somewhere behind > > the access router. > > The DMA hooks for MIPv6 manage the MN's CoA while in dormant mode. It > > requires some hooks to support the other mobility protocols as well (see > > my message on MIPv4). > > > > jak > > > > > > > > Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 08:33:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16513 for ; Thu, 21 Feb 2002 08:33:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19860; Thu, 21 Feb 2002 08:21:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19829 for ; Thu, 21 Feb 2002 08:21:35 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16194 for ; Thu, 21 Feb 2002 08:21:31 -0500 (EST) Received: from T23KEMPF (dhcp27.docomolabs-usa.com [172.21.96.27]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1LDKOe29507; Thu, 21 Feb 2002 05:20:24 -0800 (PST) Message-ID: <001901c1bada$4c32f790$1b6015ac@T23KEMPF> From: "James Kempf" To: "Marco Liebsch" , "Yoshihiro Ohba" Cc: References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <3C74D466.9018A0BD@ccrle.nec.de> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Thu, 21 Feb 2002 05:18:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Marco, >Separating the DMA is a minor issue and only a small fraction > in the entire paging issue, addressing 'how deoes the IP paging architecture > gets paging trigger packets'. What should be considered is the entire > architecture described, which keeps flexibility without introducing > unnecessary complexity.. > Actually, I think getting the DMA part right is one of the critical questions. It is where paging impacts routing, and if we don't do it right, we could end up with a design that compromises routing in critical ways, or introduces yet another "agent" that can compromise robustness. That's why I'm happy we are spending so much time on it. We should try to have a discussion about this in Minneapolis. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 08:38:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16647 for ; Thu, 21 Feb 2002 08:38:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20185; Thu, 21 Feb 2002 08:26:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20156 for ; Thu, 21 Feb 2002 08:26:56 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16291 for ; Thu, 21 Feb 2002 08:26:52 -0500 (EST) Received: from T23KEMPF (dhcp27.docomolabs-usa.com [172.21.96.27]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1LDPje29593; Thu, 21 Feb 2002 05:25:45 -0800 (PST) Message-ID: <003701c1badb$0b529450$1b6015ac@T23KEMPF> From: "James Kempf" To: "Marco Liebsch" , "Yoshihiro Ohba" Cc: References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <3C74EC3B.5CDFDEA7@ccrle.nec.de> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Thu, 21 Feb 2002 05:24:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Marco, I agree. Perhaps we can take the discussion on HMIPv6 to the MIP list. jak ----- Original Message ----- From: "Marco Liebsch" To: "Yoshihiro Ohba" Cc: "James Kempf" ; Sent: Thursday, February 21, 2002 4:46 AM Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues > Hi Yoshi and James, > > I do not understand why the discussion is now on MAPs and HMIPv6 ??? Original > issue was 'how are paging trigger packets received/intercepted at the DMA'. > Isn't it? > 1st issue: DMA receives or intercepts paging trigger packet > 2nd issue: DMA makes use of the MN identifiers in the paging trigger packet in > order to request other functional antities to resolve paging area and to > acquire exact routing information for the MN registered as idle. > > draft-renker describes an architecture, where the DMA functional entity can be > integrated with the PA function and considers distributed functional entity, > e.g. on border routers. For a MIPv6 managed system, the concept proposes the > explained registration mechanism (meeting the requirement 4.8). It considers > to extract the DMA fucntional entity. The entire concept ( PA, AR attendants > and integrated or separated DMA ) intends to design a flexible architecture > without introduction of unneeded complexity. > > draft-ohba describes an entirely distributed architecture with a lot of > protocol interaction between entities, also considering distributed DMA (as > described, its on the last hop).. > > DMA location is obviously different for individual platforms and scenarios. > But not only DMA, but entire architecture advantages and disadvantages should > be taken into account. > > Marco > > > Yoshihiro Ohba wrote: > > > On Tue, Feb 19, 2002 at 09:24:46PM -0800, James Kempf wrote: > > > Yoshi, > > > > > > >I agree that the part of sending BU from MH to HA with alternate-CoA > > > >would be a good thing. But I don't think that the other part in which > > > >PA has to maintain the binding between CoA and the global home address > > > >(whose prefix part is an on-link prefix of HA, not an on-link prefix > > > >on PA) of a MN. > > > > > > Could you explain this some more? I don't understand what having the DMA > > > mantain a CoA for the home agent has to do with where the prefix of the > > > HoA is. To me, the DMA looks like a kind of FA in MIPv4, but potentially > > > remote from the last hop (though it could be there). As long as the > > > proper trust relationship exists, the MN should be able to allow it to > > > take over. > > > > In general, we should be very careful about sending BU since it could > > easility change the behavior of routing in the Internet. If BU is > > sent to a CN (MAP is a CN in the case of HMIPv6), then the binding > > cache created at the CN should be applied only to the packets > > originated from the CN, not to the packets to be forwarded at the CN. > > > > If a MAP(or PA/DMA) maintains a home address (HoA) where the prefix of > > the HoA does not match one of the on-link prefix of the MAP, then > > undesired routing behavior could occur, assuming that synchronization > > between the two binding caches at the MAP and the HA for HoA is > > impossible. For example, if the lifetime of the binding cache of the > > MAP is shorter than that of the HA (an attacker can easifly change the > > lifetime for the BU for the MAP and the BU for the HA), then a routing > > loop can easily form between the HA and MAP during the period in which > > the binding cache at the MAP is deleted (due to expiration of the > > lifetime) while the binding cache at the HA remains active. > > > > Otherwise, if a MAP(or PA/DMA) maintains a HoA where the prefix of the > > HoA matches one of the on-link prefix of the MAP (HMIPv6 basic mode > > belongs to this case), then no routing loop occur even if the lifetime > > of the binding cache is not synchronized between MAP and HA (If the > > MAP does not have a binding cache while HA has, then packets tunneled > > from the HA will be simply discarded at the MAP). > > > > So, I think that a solution relying on the HMIPv6 extended mode is not > > acceptable. A solution relying on the HMIPv6 basic mode seems to be > > less problematic, but the technique would be applicable only to IPv6, > > not to IPv4... > > > > BTW, this technical discussion raises one issue as Behcet pointed > > out: the selection team needs to explain for the fact that they > > rejected one of the proposals because it depends on HMIPv6 and the > > fact the selected proposal also turned out to depend on a mechanism > > which is virtually equivalent to HMIPv6. > > > > > > > > > In draft-ohba, DMAs are put on last-hop subnets. A DMA is a separated > > > > entity from Paging Agent and Tracking Agent, and does not have a > > > > knowledge about what is the paging area. So the DMA sends a Paging > > > > message to Tracking Agent to page the MN. > > > > > > > > A Tracking Agent maintains the mapping between MN's terminal > > > > identifier and MN's paging area. It also maintains a list of Paging > > > > Agents per paging area so that it can forward a Paging message > > > > received from a DMA to the Paging Agent(s) corresponding to the paging > > > > area. The location of Tracking Agent is arbitrary. > > > > > > > > > > Why not have the paging area identifier simply be an anycast (multicast > > > in IPv4) address? > > > And what is a "terminal identifier"? Home address? MAC address? > > > > Because paging area can be different per MN (personalized paging area). > > Anycast (or multicast in IPv4) is not defined per host, I think. > > > > Regarding terminal identifier, it is described in section 5.1.11 of > > draft-ohba: > > > > If Host supports Mobile IP [MOBILEIP] or Mobile IPv6 [MOBILEIP-V6], > > the Home Address of the Host MAY be specified in this TLV. > > > > Essentially, any stable identifier can be used as the terminal > > identifier. > > > > > > > > I still don't understand why having the DMA on the last hop is so > > > important. Also, I don't understand > > > how it could work. > > > > Having the DMA on the last hop is important for (i) working with any > > mobility management protocol and null mobility management protocol > > (i.e., stationaly hosts) and (ii) avoiding a single point of failure. > > > > > > > > Suppose an MN goes into dormant mode in subnet X in paging area A. > > > Presumably, the DMA in subnet X now is waiting for packets for the MN. > > > Now, suppose the MN moves to subnet Y, still in paging area A. Does the > > > DMA perform a "handover"? > > > > No. The MN can stay dormant without performing handover. When the > > DMA captures a data packet destined for the CoA, it sends a Paging > > message to Paging Agent (via TA) and Paging Agent can "page" the MN. > > Note that since the DMA is on the last hop subnet of the subnet of the > > CoA, any data packet in which the CoA is specified in the destination > > address is captured without an exception regardless of what kind of > > mobility managenet protocol is used, and this is one of the reasons > > for why DMA is in last hop subnet as I explained above. The DMA does > > not have to know what is the paging area, because TA and Paging Agent > > have the knowledge on the paging area. > > > > The DMA is used just for capturing a data packet and then triggering > > paging. > > > > > If so, what is the point of having the paging > > > areas? How could it even know? Does the DMA in subnet X continue to > > > handle the MN? If so, what is the point of having the DMA on the last > > > hop? Why not move it back, and have the option of an arbitrary mapping > > > of DMAs to subnets? > > > > > > The other thing I don't like about this is that if the mobility protocol > > > is, say, MIPv6, and the TA is in the HA, then the message flows like > > > this: > > > > > > -> HA ----- (across the > > > Internet) -----> DMA > > > DMA ------------------- (across the Internet) ----------> HA > > > (cum TA) > > > HA ---------------------(across the Internet)----------->PA > > > PA--------------------------------------------------> MN > > > > > > So there's a grand total of three traversals of the Internet in order to > > > page the MN. Not too efficient. > > > > In that particular case, why not putting the DMA on the HA? > > Then it could be much more efficient as: > > > > -> HA (=DMA=TA) > > HA ---------------------(across the Internet)----------->PA > > PA--------------------------------------------------> MN > > > > > > > > Maybe there is some thing I am missing here? > > > > > > > > > > A Paging Agent maintains the mapping between paging area and IP > > > > subnets. The mapping between paging area and subnet is arbitrary, > > > > i.e., a paging area could contain multiple IP subnets, or an IP subnet > > > > could contain multiple paging areas. To support the arbitrary mapping > > > > between paging area and IP subnets, the location of Paging Agent is > > > > also arbitrary, e.g., it could be co-located on AR, it could be put > > > > behind ARs, or it could be put on APs. If a Paging Agent is put far > > > > behind ARs, a list of Access Routers per paging area is maintained at > > > > the Paging Agent and the list is used for advertising paging areas and > > > > for wide-casting Paging messages. There may be multiple Paging Agents > > > > in a single paging area and this would be useful when a paging area > > > > covers multiple IP subnets or multiple APs while Paging Agents are > > > > co-located with ARs or APs. > > > > > > > > > > OK, we seem to be in some agreement here about the Paging Agent. I do > > > see the Paging Agent maintaining a list of Access Routers in its paging > > > area. Also, I see it doing dynamic paging area configuration and > > > failover. > > > > > > > Any of two agents or all agents can be co-located in a single node, > > > > depending on various requirements such as scalability, robustness, > > > > complexity. For example, a DMA and a Paging Agent can be put together > > > > in an AR. Or a Tracking Agent and a Paging Agent can be put together > > > > in a single node behind ARs. Or all three types of agents are put > > > > together in a single AR. And if co-located, external message exchange > > > > is not necessary between different agents. > > > > > > > > > > But you said above that the DMA had to be on the last hop, thus there > > > are constraints. > > > > But less problematic, I believe. > > > > > > > > I think the DMA and the PA need to be co-located. They could be on an > > > access router if there > > > is only one subnet per paging area. Or they could be somewhere behind > > > the access router. > > > The DMA hooks for MIPv6 manage the MN's CoA while in dormant mode. It > > > requires some hooks to support the other mobility protocols as well (see > > > my message on MIPv4). > > > > > > jak > > > > > > > > > > > > > Yoshihiro Ohba > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 08:50:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16996 for ; Thu, 21 Feb 2002 08:50:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21016; Thu, 21 Feb 2002 08:39:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20980 for ; Thu, 21 Feb 2002 08:39:00 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16638 for ; Thu, 21 Feb 2002 08:38:56 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1LDexg13484; Thu, 21 Feb 2002 14:40:59 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA16885; Thu, 21 Feb 2002 14:38:23 +0100 Message-ID: <3C74F84F.E56AB72B@ccrle.nec.de> Date: Thu, 21 Feb 2002 14:38:23 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Yoshihiro Ohba , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James Kempf wrote: > Yoshi, > > > In general, we should be very careful about sending BU since it could > > easility change the behavior of routing in the Internet. If BU is > > sent to a CN (MAP is a CN in the case of HMIPv6), then the binding > > cache created at the CN should be applied only to the packets > > originated from the CN, not to the packets to be forwarded at the CN. > > > > If a MAP(or PA/DMA) maintains a home address (HoA) where the prefix of > > the HoA does not match one of the on-link prefix of the MAP, then > > undesired routing behavior could occur, assuming that synchronization > > between the two binding caches at the MAP and the HA for HoA is > > impossible. For example, if the lifetime of the binding cache of the > > MAP is shorter than that of the HA (an attacker can easifly change the > > lifetime for the BU for the MAP and the BU for the HA), then a routing > > loop can easily form between the HA and MAP during the period in which > > the binding cache at the MAP is deleted (due to expiration of the > > lifetime) while the binding cache at the HA remains active. > > > > I guess I don't see how this follows. If the binding cache entry at the > MAP > times out, it simply drops the packet when the HA forwards it. How does > the loop form? > (I'm assuming we are talking straight HMIPv6 here, and not paging.) > Since the Paging Agent is not a MAP (!), paging related information is to be maintained in an individual and synchronized way in order to avoid compelling a MN to wake-up in order to maintain paging related registrations even though mobility related registration is still valid. draft-renker discusses some of these issues, which is e.g. (in case of MIPv6) preferring a longer lifetime at HA for PA registration as alternate CoA. Since it is not desirable to modify the mobility management system when integrating paging, the paging system has to cope with re-registration. This is the same for a PA registration at a HA (as draft-renker describes as an example) as well as for a MN's CoA registration (as proposed for an interception based, distributed DMA architecture). When having appropriate security associations established, respective entities of the paging system could do re-registration on behalf of the mobile node. > > Otherwise, if a MAP(or PA/DMA) maintains a HoA where the prefix of the > > HoA matches one of the on-link prefix of the MAP (HMIPv6 basic mode > > belongs to this case), then no routing loop occur even if the lifetime > > of the binding cache is not synchronized between MAP and HA (If the > > MAP does not have a binding cache while HA has, then packets tunneled > > from the HA will be simply discarded at the MAP). > > > > So, I think that a solution relying on the HMIPv6 extended mode is not > > acceptable. A solution relying on the HMIPv6 basic mode seems to be > > less problematic, but the technique would be applicable only to IPv6, > > not to IPv4... > > > > Still not clear to me. > > But you do bring up a good point here. > > In order to have the DMA relay the MN's paging area movement to the MN, > it would have to keep around the MN's HoA, which is a piece of MN > location > state. It would be good to avoid this, but I don't see how short of > requiring > the MN to come out of dormant mode and issue the BU when it changes > paging area. > Again, in case of keeping a DMA as long as possible for an individual node, no handover is required and no BU is to be sent to the mobility agent. When entering a new paging area, Tracking Agent functional entity is to be notified, requested by the same DMA to initiate paging in case of incoming paging trigger packets. That's what draft-renker describes. As far as I understood, Yoshi mentioned that this is what draft-ohba allows as well. > > > BTW, this technical discussion raises one issue as Behcet pointed > > out: the selection team needs to explain for the fact that they > > rejected one of the proposals because it depends on HMIPv6 and the > > fact the selected proposal also turned out to depend on a mechanism > > which is virtually equivalent to HMIPv6. > > > > This is a category error. > > As I said before, draft-renker depends on a particular way of using > MIPv6. > HMIPv6 depends on a particular way of using MIPv6. This does not make > draft-renker equivalent to HMIPv6. > > To see the error, suppose draft-renker would have been published before > HMIPv6. Would that make HMIPv6 "virtually equivalent" to draft-renker? > Right, but I do not like the expression 'depends' on a particular way of using MIPv6. It's a generic concept. In order to meet the requirement 4.8 we described a way, the architecture deploys the registration mechanisms provided by the mobilty protocol. This does not make it dependent. A distributed DMA function is also possible. > > > > Why not have the paging area identifier simply be an anycast > (multicast > > > in IPv4) address? > > > And what is a "terminal identifier"? Home address? MAC address? > > > > Because paging area can be different per MN (personalized paging > area). > > Anycast (or multicast in IPv4) is not defined per host, I think. > > > > But the MN doesn't have to have a personalized paging area, that is > a policy option. Anyway, the point is, it can be an IP address. > Right, personalized paging areas is an option, but an important one. This is discussed and allowed in draft-renker. It is not clear to me how individual paging areas could be managed with a static assignment of a paging agent functional entity to a paging area. For the terminal identifier, the paging system has to cope with the identifier a paging trigger packet carries. This can be the home address in case of MIPv6, as Yoshi explained, which leads to the same thread again discussing processing paging trigger packets in the draft-renker concept (which was said to be unnatural). Marco > > > Regarding terminal identifier, it is described in section 5.1.11 of > > draft-ohba: > > > > If Host supports Mobile IP [MOBILEIP] or Mobile IPv6 [MOBILEIP-V6], > > the Home Address of the Host MAY be specified in this TLV. > > > > Essentially, any stable identifier can be used as the terminal > > identifier. > > > > OK. > > > > > > > I still don't understand why having the DMA on the last hop is so > > > important. Also, I don't understand > > > how it could work. > > > > Having the DMA on the last hop is important for (i) working with any > > mobility management protocol and null mobility management protocol > > (i.e., stationaly hosts) and > > This isn't clear (but I see you explain it better below). > > > (ii) avoiding a single point of failure. > > > > But you could have multiple DMAs behind the last hop. And, as I have > mentioned in previous notes (and I believe you even specified in > draft-ohba) the DMAs can exchange periodic messages. If a message falls > out, others reconfigure to take over. The router solution. > > > > > > > Suppose an MN goes into dormant mode in subnet X in paging area A. > > > Presumably, the DMA in subnet X now is waiting for packets for the > MN. > > > Now, suppose the MN moves to subnet Y, still in paging area A. Does > the > > > DMA perform a "handover"? > > > > No. The MN can stay dormant without performing handover. When the > > DMA captures a data packet destined for the CoA, it sends a Paging > > message to Paging Agent (via TA) and Paging Agent can "page" the MN. > > Note that since the DMA is on the last hop subnet of the subnet of the > > CoA, any data packet in which the CoA is specified in the destination > > What does the CoA have to do with it? The MN is in dormant mode, roaming > across multiple > subnets. It no longer has a fixed CoA. Or, are you proposing that the > CoA stay the > same as when the MN went to sleep? That's the point I was trying to make > about > the extreme message legs across large chunks of the Internet. > > > address is captured without an exception regardless of what kind of > > mobility managenet protocol is used, and this is one of the reasons > > for why DMA is in last hop subnet as I explained above. The DMA does > > not have to know what is the paging area, because TA and Paging Agent > > have the knowledge on the paging area. > > > > The DMA is used just for capturing a data packet and then triggering > > paging. > > > > It seems like what you are saying is that, in essence, the Access Router > in the last hop must maintain the state for any dormant nodes that have > gone to sleep, presuming we map the DMA to the Access Router. > But I thought we wanted to offload this state from the Access Router. > > > > If so, what is the point of having the paging > > > areas? How could it even know? Does the DMA in subnet X continue to > > > handle the MN? If so, what is the point of having the DMA on the > last > > > hop? Why not move it back, and have the option of an arbitrary > mapping > > > of DMAs to subnets? > > > > > > The other thing I don't like about this is that if the mobility > protocol > > > is, say, MIPv6, and the TA is in the HA, then the message flows like > > > this: > > > > > > -> HA ----- (across the > > > Internet) -----> DMA > > > DMA ------------------- (across the Internet) ----------> > HA > > > (cum TA) > > > HA ---------------------(across the Internet)----------->PA > > > PA--------------------------------------------------> MN > > > > > > So there's a grand total of three traversals of the Internet in > order to > > > page the MN. Not too efficient. > > > > In that particular case, why not putting the DMA on the HA? > > Then it could be much more efficient as: > > > > -> HA (=DMA=TA) > > HA ---------------------(across the Internet)----------->PA > > PA--------------------------------------------------> MN > > > > Well, then the DMA *certainly* isn't on the last hop, is it? :-) > > Also, I think we want some way that we can avoid having the MN come out > of > dormant mode to do a MIPv6 BU when it changes paging area. I'd like > somebody in the network > to be able to do it for the MN. It is much more efficient powerwise, and > it allows using an efficient (and existing) L2 paging protocol without > requiring that protocol to carry IP. > > But perhaps this isn't possible to do (securely). > > jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 09:04:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17551 for ; Thu, 21 Feb 2002 09:04:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21794; Thu, 21 Feb 2002 08:52:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21763 for ; Thu, 21 Feb 2002 08:52:19 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17058 for ; Thu, 21 Feb 2002 08:52:15 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1LDsJg14387; Thu, 21 Feb 2002 14:54:19 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA17110; Thu, 21 Feb 2002 14:51:42 +0100 Message-ID: <3C74FB6E.3A1DAED3@ccrle.nec.de> Date: Thu, 21 Feb 2002 14:51:42 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Behcet Sarikaya CC: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish <20020220145411.GB3759@catfish> <3C73C54B.4070308@alcatel.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Behcet Sarikaya wrote: > .... > Why don't we say to Marco, Marco, sorry but you missed the train > and continue our business? > .... Behcet, I am looking to your statements for quite a long time, which are actually not technically beneficial, but only destructive. Is this the way standardization work in IETF should be driven? If yes, then this is very unfortunate. Marco > > Yoshihiro Ohba wrote: > > > > > > >BTW, this technical discussion raises one issue as Behcet pointed > >out: the selection team needs to explain for the fact that they > >rejected one of the proposals because it depends on HMIPv6 and the > >fact the selected proposal also turned out to depend on a mechanism > >which is virtually equivalent to HMIPv6. > > > Regards, > > -- > Behcet > > _______________________________________________ > 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 Thu Feb 21 09:12:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17875 for ; Thu, 21 Feb 2002 09:12:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22548; Thu, 21 Feb 2002 08:59:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22508 for ; Thu, 21 Feb 2002 08:59:34 -0500 (EST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17435 for ; Thu, 21 Feb 2002 08:59:30 -0500 (EST) Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g1LDwad09354 for ; Thu, 21 Feb 2002 14:58:37 +0100 (MET) Message-ID: <3C74FDD0.55D37BB4@inrialpes.fr> Date: Thu, 21 Feb 2002 15:01:52 +0100 From: Pars MUTAF X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> <3C74F84F.E56AB72B@ccrle.nec.de> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello all, A terminology question: Should we use the term "mobile node", "mobile host" or just "host"? > Right, personalized paging areas is an option, but an important one. This is > discussed and allowed in draft-renker. It is not clear to me how individual > paging areas could be managed with a static assignment of a paging agent > functional entity to a paging area. It would be good to have some flexibility on that issue... Regards, pars _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 10:43:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21108 for ; Thu, 21 Feb 2002 10:43:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28563; Thu, 21 Feb 2002 10:28:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28530 for ; Thu, 21 Feb 2002 10:28:49 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20387 for ; Thu, 21 Feb 2002 10:28:44 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1LFUpg19834; Thu, 21 Feb 2002 16:30:51 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA18547; Thu, 21 Feb 2002 16:28:07 +0100 Message-ID: <3C751207.70337D5E@ccrle.nec.de> Date: Thu, 21 Feb 2002 16:28:07 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Yoshihiro Ohba , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <3C74D466.9018A0BD@ccrle.nec.de> <001901c1bada$4c32f790$1b6015ac@T23KEMPF> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James, of course it is definitely a big issue. I only wanted to express that quality of a concept should not only be dependent on where the DMA functional entity is described to be located for an individual example. The entire architecture should be looked at w.r.t complexity, flexibility and reliability. Again, the DMA issue an important one to be studied thoroughly. Marco James Kempf wrote: > Marco, > > >Separating the DMA is a minor issue and only a small fraction > > in the entire paging issue, addressing 'how deoes the IP paging > architecture > > gets paging trigger packets'. What should be considered is the entire > > architecture described, which keeps flexibility without introducing > > unnecessary complexity.. > > > > Actually, I think getting the DMA part right is one of the critical > questions. > It is where paging impacts routing, and if we don't do it right, we > could end up with a design that compromises routing in critical > ways, or introduces yet another "agent" that can compromise > robustness. That's why I'm happy we are spending so much > time on it. > > We should try to have a discussion about this in Minneapolis. > > jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 11:34:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23269 for ; Thu, 21 Feb 2002 11:34:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02258; Thu, 21 Feb 2002 11:17:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02189 for ; Thu, 21 Feb 2002 11:17:43 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22697 for ; Thu, 21 Feb 2002 11:17:40 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1LGHCL04543 for ; Thu, 21 Feb 2002 10:17:12 -0600 (CST) Message-ID: <3C751D75.40907@alcatel.com> Date: Thu, 21 Feb 2002 10:16:53 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020220145411.GB3759@catfis <20020220182424.GE3759@catfish> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Yoshi, draft-ohba 00 was on IPv4, I think. Refering to your section 5 on message formats, I thought you mainly addressed v4 formats. Yes it is true that in previous text you try to accomodate IPv4, IPv6, Mobile IPv4 and Mobile IPv6. I have been indicating all along that this is a mistake. Hope you come to agree it. Yoshihiro Ohba wrote: > > >And I don't much care about whatever protocol is selected as a >starting point, as I mentioned earlier. But I do care about what the >final WG product will be. > Are you throwing the towel? -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 11:35:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23374 for ; Thu, 21 Feb 2002 11:35:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02415; Thu, 21 Feb 2002 11:21:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02384 for ; Thu, 21 Feb 2002 11:21:02 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22799 for ; Thu, 21 Feb 2002 11:20:58 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7R9Y1>; Thu, 21 Feb 2002 08:20:31 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Marco Liebsch'" , Behcet Sarikaya Cc: seamoby@ietf.org Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Thu, 21 Feb 2002 08:20:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BAF3.AAFEF760" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org 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_01C1BAF3.AAFEF760 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> .... >> Why don't we say to Marco, Marco, sorry but you missed the train >> and continue our business? .... > > Behcet, > > I am looking to your statements for quite a long time, which are > actually not technically beneficial, but only destructive. Is this > the way standardization work in IETF should be driven? If yes, > then this is very unfortunate. It certainly is NOT the way the IETF WG typically work... Unfortunately, there is always a few that believe that they must put some folks down in order to elevate themselves (and let me tell you that the net effect is *inversed* to what the flamer wishes). I would also like to remind folks that because someone is an editor doesn't mean that his/her point of views automatically get inserted into a WG document. But as with any other person on the list, the editor has a right to express his/her opinion. The end result is that the WG document only includes text that has rough WG concensus. I will again ask that folks try to remain constructive... Only by fostering a spirit of cooperation can we meet our milestones. PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPHUeSTN1fXKoxmisEQJg/gCeIJW6MqRS39QSd1hyFLtHwXNAHU8AmgNj WTjssmcocLcBhhB5FHGpmOa/ =1wPe -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1BAF3.AAFEF760 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Dormant Mode Location Tracking by Mobility = Protocol Issues

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> ....
>> Why don't we say to Marco, Marco, sorry but = you missed the train
>> and  continue our business? = ....
>
> Behcet,
>
> I am looking to your statements for quite a = long time, which are
> actually not  technically beneficial, but = only destructive. Is this
> the way standardization work in  IETF = should be driven? If yes,
> then this is very unfortunate.

It certainly is NOT the way the IETF WG typically = work...
Unfortunately, there is always a few that believe = that they must put
some folks down in order to elevate themselves (and = let me tell you
that the net effect is *inversed* to what the flamer = wishes). I would
also like to remind folks that because someone is an = editor doesn't
mean that his/her point of views automatically get = inserted into a WG
document. But as with any other person on the list, = the editor has a
right to express his/her opinion.

The end result is that the WG document only includes = text that has
rough WG concensus.

I will again ask that folks try to remain = constructive... Only by
fostering a spirit of cooperation can we meet our = milestones.

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPHUeSTN1fXKoxmisEQJg/gCeIJW6MqRS39QSd1hyFLtHwXNAHU8AmgN= j
WTjssmcocLcBhhB5FHGpmOa/
=3D1wPe
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BAF3.AAFEF760-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 11:52:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24075 for ; Thu, 21 Feb 2002 11:52:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03600; Thu, 21 Feb 2002 11:33:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03569 for ; Thu, 21 Feb 2002 11:33:33 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23255 for ; Thu, 21 Feb 2002 11:33:29 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1LGX2L09637 for ; Thu, 21 Feb 2002 10:33:02 -0600 (CST) Message-ID: <3C752129.1090603@alcatel.com> Date: Thu, 21 Feb 2002 10:32:41 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: Content-Type: multipart/alternative; boundary="------------030804010103060902030509" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------030804010103060902030509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pat, This is what you called heat factor in your mail last Sunday. I have contributed (together with my coworkers) two drafts out of a total of 5. Those drafts have enough technical content to warrant me as a member in this WG. However if you think otherwise I am ready to step down. Regards, Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> .... > >> Why don't we say to Marco, Marco, sorry but you missed the train > >> and continue our business? .... > > > > Behcet, > > > > I am looking to your statements for quite a long time, which are > > actually not technically beneficial, but only destructive. Is this > > the way standardization work in IETF should be driven? If yes, > > then this is very unfortunate. > > It certainly is NOT the way the IETF WG typically work... > Unfortunately, there is always a few that believe that they must put > some folks down in order to elevate themselves (and let me tell you > that the net effect is *inversed* to what the flamer wishes). I would > also like to remind folks that because someone is an editor doesn't > mean that his/her point of views automatically get inserted into a WG > document. But as with any other person on the list, the editor has a > right to express his/her opinion. > > The end result is that the WG document only includes text that has > rough WG concensus. > > I will again ask that folks try to remain constructive... Only by > fostering a spirit of cooperation can we meet our milestones. > > PatC > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com > > > iQA/AwUBPHUeSTN1fXKoxmisEQJg/gCeIJW6MqRS39QSd1hyFLtHwXNAHU8AmgNj > WTjssmcocLcBhhB5FHGpmOa/ > =1wPe > -----END PGP SIGNATURE----- > -- Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S 026 1000 Coit Road PB7 Plano, TX 75075 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 477 2794 Fax: (972) 519 2460 --------------030804010103060902030509 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Pat,
  This is what you called heat factor in your mail last Sunday.
I have contributed (together with my coworkers) two drafts out of a total of 5. Those drafts have enough  technical content to warrant me as a member in this WG. However if you think otherwise I am ready to step down.

Regards,

Pat R. Calhoun wrote:
RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> ....
>> Why don't we say to Marco, Marco, sorry but you missed the train
>> and  continue our business? ....
>
> Behcet,
>
> I am looking to your statements for quite a long time, which are
> actually not  technically beneficial, but only destructive. Is this
> the way standardization work in  IETF should be driven? If yes,
> then this is very unfortunate.

It certainly is NOT the way the IETF WG typically work...
Unfortunately, there is always a few that believe that they must put
some folks down in order to elevate themselves (and let me tell you
that the net effect is *inversed* to what the flamer wishes). I would
also like to remind folks that because someone is an editor doesn't
mean that his/her point of views automatically get inserted into a WG
document. But as with any other person on the list, the editor has a
right to express his/her opinion.

The end result is that the WG document only includes text that has
rough WG concensus.

I will again ask that folks try to remain constructive... Only by
fostering a spirit of cooperation can we meet our milestones.

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com >

iQA/AwUBPHUeSTN1fXKoxmisEQJg/gCeIJW6MqRS39QSd1hyFLtHwXNAHU8AmgNj
WTjssmcocLcBhhB5FHGpmOa/
=1wPe
-----END PGP SIGNATURE-----


-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460

--------------030804010103060902030509-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 11:57:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24264 for ; Thu, 21 Feb 2002 11:57:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04272; Thu, 21 Feb 2002 11:46:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04244 for ; Thu, 21 Feb 2002 11:46:03 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23823 for ; Thu, 21 Feb 2002 11:45:59 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1LGjVs04838 for ; Thu, 21 Feb 2002 10:45:31 -0600 (CST) Message-ID: <3C752418.5000002@alcatel.com> Date: Thu, 21 Feb 2002 10:45:12 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org CC: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64993@esebe004.NOE.Nokia.com> <018e01c1ba8f$c68ddc80$2c6015ac@T23KEMPF> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Jim, James Kempf wrote: > >As perhaps you might have been able to determine from the technical >discussion, >we are a long way from worrying about questions like this. > >We still have to figure out how, fundamentally, paging will work. >Fortunately, nobody >has plans to do an IP paging product any time soon. > > jak > This is contrary the latest assessment draft. Can you please clarify? > > Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 11:58:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24311 for ; Thu, 21 Feb 2002 11:58:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04216; Thu, 21 Feb 2002 11:45:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04176 for ; Thu, 21 Feb 2002 11:45:53 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23820 for ; Thu, 21 Feb 2002 11:45:49 -0500 (EST) Received: from research.telcordia.com (zhang-pc [192.4.12.89]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1LGihjP020598; Thu, 21 Feb 2002 11:44:43 -0500 (EST) Message-ID: <3C7523BE.88A5DC04@research.telcordia.com> Date: Thu, 21 Feb 2002 11:43:42 -0500 From: Tao Zhang X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Yoshihiro Ohba , Marco Liebsch , seamoby@ietf.org, tao@research.telcordia.com Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <3C73C7B7.367F6DD4@research.telcordia.com> <018001c1ba8f$1b7b2730$2c6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James, > Tao, > > > The DMA does not have to be on the last hop. Placing a DMA on every > last-hop > > subnet is one way of implementing the paging protocol which will > enable the > > paging protocol to be completely independent of mobility protocols. > However, > > if we know what mobility protocol is used and wish to optimizee the > paging > > protocol for that particular mobility protocol, the DMA does not HAVE > to be > > on the last hop. For example, if the mobility protocol is MIPv4, the > DMA may > > be co-located with the FAs or the HA. The jobs of the DMA are to > capture > > packets destined to a dormant host and trigger the paging process. > Where to > > put the DMA in a real network can be determined based on how much > dependency > > or collaboration one wishes the paging protocol to have on/with the > mobility > > protocols. > > > > The DMA and the PA MAY be co-located, but do not NEED to be > co-located. > > > > OK, now this is starting to make a little sense to me. If the DMA > doesn't need to be at the last hop, > then I think we could arrange to optimize as you say, and consider that > as part of adding something > to the mobility protocol for paging and not changing it fundamentally. I > think that would be better than specifying > it at the last hop and then incurring the messaging overhead. > > Since I think we now seem to agree on this point, then maybe we can move > the focus to what I think is > a more important design question. Is there any way to arrange the DMA > and TA in MIPv6 so that a) the foreign network is not maintaining any > location state for the mobile node, including not maintaining the home > agent address, and It will be nice to figure out such a solution and I think it is worth a try. One issue is that if there are multiple paging areas in a foreign network and the location states for dormant hosts are not maintained in the foreign network but rather, say, in the home network, the home netowrk (or any network that needs to maintain the mobility states) will have to understand the paging areas defined in the foreign network. However, each foreign network may have their own ways of defining and representing these paging areas and may not wish to disclose much information regarding their paging area configures to an outside network for competitive reasons. Another issue is that each foreign network may wish to implement its own paging algorithms. Some paging algorithms may need close interactions with location update strategies used to update dormant host locations. If location state is not maintained in the foreign network, it may become difficult for the paging algorithms in the foreign network to interact with the dormant location udpate strategies. For example, one location update strategy is to send not only the current paging area ID but also the last paging area ID so that the paging algorithm can analyze the movement pattern of the mobile and use it to determine the area to page the mobile. This will be difficult to implement if location state for a dormant mobile is only maintained at, say, the home network (i.e., when location update is done with the home network only). > b) that the MN doesn't have to come out of dormant mode to do a BU and > can use an existing, lightweight L2 paging protocol or lightweight IP > protocol to somehow get that done by the network, modulo the security > question. If we do not require every location update to be done with 100% reliability (which seems to be a reasonable assumption), there will be no need for the dormant mobile to obtain a new IP address or perform BU just for the purpose of performing location update in a subnet different from the one in which it entered into dormant mode. It can simply wake up to the level that it can send IP packets, send an location update (or a few to increase the succes probability), and go back to sleep right away. This may not take too much time (it should be much shorter than getting an new IP address and then performing BU). It also reduces the dependency on L2 techniques for dormant host location update. > I think these goals may not be reconcilable, but I hope I am mistaken. > > For MIPv4, the problem seems much easier to solve because the FA can > change the registration for the MN when the MN changes paging area > (provided the right security association exists). > > jak > > PS: In Hawaii paging, I think the DMA and TA will be in the foreign > network, because mobilitiy management is localized, unlike MIP. They > won't be on the last hop though, at least, not according to Ram's > Mobicomm paper of last year. If I understand Ram's 2001 Mobicom paper correctly, there is no separate TA entity in HAWAII paging. The DMA and the PA functions are combined into an entity called a paging initiator. Any base station and router in a HAWAII network will be equipped with the paging initiator functionality. HAWAII uses host-based routing and combines location update with routing. In particular, the network maintains a host-based paging route for each dormant host and the route leads from the DRR to the base station from which the network received the last paging update from the dormant host. When the dormant host updates its location, the host-based paging route for this mobile will also be udpated accordingly (therefore no need for a separate TA). The base station and any router on the latest paging route knows how to send paging messages to the corresponding paging area to which the paging route leads. The base station on the latest paging route for a mobile will be the default paging initiator that pages the mobile upon receiving user packets. Each base station is indeed in the last hop. Any router along the latest paging route could also be a paging intiator (to allow load balancing and increase reliability). Thanks Tao _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 12:15:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25092 for ; Thu, 21 Feb 2002 12:15:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06231; Thu, 21 Feb 2002 12:03:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06202 for ; Thu, 21 Feb 2002 12:03:44 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24681 for ; Thu, 21 Feb 2002 12:03:40 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1LH2cjP022224; Thu, 21 Feb 2002 12:02:38 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id MAA20988; Thu, 21 Feb 2002 12:02:31 -0500 (EST) Date: Thu, 21 Feb 2002 12:02:36 -0500 To: James Kempf Cc: Yoshihiro Ohba , Marco Liebsch , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020221170236.GD2356@catfish> Mail-Followup-To: James Kempf , Yoshihiro Ohba , Marco Liebsch , seamoby@ietf.org References: <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 45 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Jim, On Wed, Feb 20, 2002 at 07:31:43PM -0800, James Kempf wrote: > Yoshi, > > > In general, we should be very careful about sending BU since it could > > easility change the behavior of routing in the Internet. If BU is > > sent to a CN (MAP is a CN in the case of HMIPv6), then the binding > > cache created at the CN should be applied only to the packets > > originated from the CN, not to the packets to be forwarded at the CN. > > > > If a MAP(or PA/DMA) maintains a home address (HoA) where the prefix of > > the HoA does not match one of the on-link prefix of the MAP, then > > undesired routing behavior could occur, assuming that synchronization > > between the two binding caches at the MAP and the HA for HoA is > > impossible. For example, if the lifetime of the binding cache of the > > MAP is shorter than that of the HA (an attacker can easifly change the > > lifetime for the BU for the MAP and the BU for the HA), then a routing > > loop can easily form between the HA and MAP during the period in which > > the binding cache at the MAP is deleted (due to expiration of the > > lifetime) while the binding cache at the HA remains active. > > > > I guess I don't see how this follows. If the binding cache entry at the > MAP > times out, it simply drops the packet when the HA forwards it. How does > the loop form? > (I'm assuming we are talking straight HMIPv6 here, and not paging.) I don't think MAP can simply discard it. What if the MAP is on the path between CN and HA and the MAP receives a packet destined for HoA? Do you change the processing rule depending on whether the HoA is included in an IP-in-IP encapsulated packet or in normal IP packet without IP-in-IP encapsulation (I know that Mobile IPv4 Foreign Agent does a similar thing to avoid routing loop)? Then, what if the MAP is also a tunnel end-point of other protocols and a packet received on that tunnel and also contain the HoA as the destination address? Anyway, HMIPv6 and draft-renker uses the same mechanism that is not used in Mobile IPv6 in order to redirect packets from HA to an agent (MAP or PA) and a DHMA protocol should not mandate the mechanism until HMIPv6 is finalized. Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 13:11:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27347 for ; Thu, 21 Feb 2002 13:11:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15047; Thu, 21 Feb 2002 12:55:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15018 for ; Thu, 21 Feb 2002 12:55:24 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26635 for ; Thu, 21 Feb 2002 12:55:16 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1LHscjP028678; Thu, 21 Feb 2002 12:54:38 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id MAA21127; Thu, 21 Feb 2002 12:54:31 -0500 (EST) Date: Thu, 21 Feb 2002 12:54:37 -0500 To: Behcet Sarikaya Cc: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020221175437.GB2971@catfish> Mail-Followup-To: Behcet Sarikaya , seamoby@ietf.org References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020220182424.GE3759@catfish> <3C751D75.40907@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3C751D75.40907@alcatel.com> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 36 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Thu, Feb 21, 2002 at 10:16:53AM -0600, Behcet Sarikaya wrote: > Hello Yoshi, > draft-ohba 00 was on IPv4, I think. Refering to your section 5 on > message formats, I thought you mainly addressed v4 formats. No. What makes you think in such a way? > Yes it is > true that in previous text you try to accomodate IPv4, IPv6, Mobile IPv4 > and Mobile IPv6. I have been indicating all along that this is a > mistake. Hope you come to agree it. That depends on the layer where the DMHA signaling is supposed to work. If it is supposed to run over L4, then is should be a single document. > > > Yoshihiro Ohba wrote: > > > > > > >And I don't much care about whatever protocol is selected as a > >starting point, as I mentioned earlier. But I do care about what the > >final WG product will be. > > > > Are you throwing the towel? I guess your goal is different from my goal. > > -- > Behcet > Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 14:06:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29827 for ; Thu, 21 Feb 2002 14:06:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19586; Thu, 21 Feb 2002 13:54:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19556 for ; Thu, 21 Feb 2002 13:54:40 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29358 for ; Thu, 21 Feb 2002 13:54:37 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1LIrIjP004326; Thu, 21 Feb 2002 13:53:18 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id NAA21244; Thu, 21 Feb 2002 13:53:09 -0500 (EST) Date: Thu, 21 Feb 2002 13:53:13 -0500 To: James Kempf Cc: Yoshihiro Ohba , Marco Liebsch , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020221185313.GD2971@catfish> Mail-Followup-To: James Kempf , Yoshihiro Ohba , Marco Liebsch , seamoby@ietf.org References: <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 79 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Wed, Feb 20, 2002 at 07:31:43PM -0800, James Kempf wrote: > > OK. > > > > > > > I still don't understand why having the DMA on the last hop is so > > > important. Also, I don't understand > > > how it could work. > > > > Having the DMA on the last hop is important for (i) working with any > > mobility management protocol and null mobility management protocol > > (i.e., stationaly hosts) and > > This isn't clear (but I see you explain it better below). > > > (ii) avoiding a single point of failure. > > > > But you could have multiple DMAs behind the last hop. And, as I have > mentioned in previous notes (and I believe you even specified in > draft-ohba) the DMAs can exchange periodic messages. If a message falls > out, others reconfigure to take over. The router solution. As Tao mentioned, if we can use a stable method (unlike the method used in HMIPv6) for redirecting packets from HA to DMA at arbitrary location, DMAs could be put behind the last hop. > > > > > > > Suppose an MN goes into dormant mode in subnet X in paging area A. > > > Presumably, the DMA in subnet X now is waiting for packets for the > MN. > > > Now, suppose the MN moves to subnet Y, still in paging area A. Does > the > > > DMA perform a "handover"? > > > > No. The MN can stay dormant without performing handover. When the > > DMA captures a data packet destined for the CoA, it sends a Paging > > message to Paging Agent (via TA) and Paging Agent can "page" the MN. > > Note that since the DMA is on the last hop subnet of the subnet of the > > CoA, any data packet in which the CoA is specified in the destination > > What does the CoA have to do with it? The MN is in dormant mode, roaming > across multiple > subnets. It no longer has a fixed CoA. Or, are you proposing that the > CoA stay the > same as when the MN went to sleep? That's the point I was trying to make > about > the extreme message legs across large chunks of the Internet. Sorry, CoA was not a good word. It could be HoA when DMA is co-located with HA. In fact, we have the following description in section 4.15 of draft-ohba: 4.15. Supporting Mobility Management Protocol If a Host is a mobile node, it is able to move around while it is in a dormant mode, with changing L2 attachment points or L3 subnets but without changing its IP address. It is possible for a Dormant Monitoring Agent to be co-located with a Home Agent of Mobile IP so that packets destined for the mobile Host's home address are captured at the Home Agent for triggering paging operation before it is forwarded to the care-of address, instead of having a Dormant Monitoring Agent at each last hop subnet in foreign networks. This is still consistent with the definition of Dormant Monitoring Agent because the mobile's home network is considered to be the last hop subnet in terms of home address. Alternatively, if inter-administrative domain paging is not allowed due to network management policies, a Dormant Monitoring Agent can be co-located with a Foreign Agent of Mobile IP. I think this is one of what you want. [...] Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 14:32:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00971 for ; Thu, 21 Feb 2002 14:32:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21260; Thu, 21 Feb 2002 14:20:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21235 for ; Thu, 21 Feb 2002 14:20:37 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00415 for ; Thu, 21 Feb 2002 14:20:34 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1LJJRjP007320; Thu, 21 Feb 2002 14:19:28 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA21341; Thu, 21 Feb 2002 14:19:20 -0500 (EST) Date: Thu, 21 Feb 2002 14:19:25 -0500 To: Marco Liebsch Cc: James Kempf , Yoshihiro Ohba , seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020221191925.GE2971@catfish> Mail-Followup-To: Marco Liebsch , James Kempf , Yoshihiro Ohba , seamoby@ietf.org References: <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> <3C74F84F.E56AB72B@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3C74F84F.E56AB72B@ccrle.nec.de> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 44 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Thu, Feb 21, 2002 at 02:38:23PM +0100, Marco Liebsch wrote: > > > > > Why not have the paging area identifier simply be an anycast > > (multicast > > > > in IPv4) address? > > > > And what is a "terminal identifier"? Home address? MAC address? > > > > > > Because paging area can be different per MN (personalized paging > > area). > > > Anycast (or multicast in IPv4) is not defined per host, I think. > > > > > > > But the MN doesn't have to have a personalized paging area, that is > > a policy option. Anyway, the point is, it can be an IP address. Yes, that can be an IP address. I guess this is not an essential issue compared with other issues. > > > > Right, personalized paging areas is an option, but an important one. This is > discussed and allowed in draft-renker. It is not clear to me how individual > paging areas could be managed with a static assignment of a paging agent > functional entity to a paging area. This is a good point. Fxine-grained assignment of personal paging area is difficult with a static assignment of a paging agent, unless all paging agents are co-located with base stations. > > For the terminal identifier, the paging system has to cope with the > identifier a paging trigger packet carries. This can be the home address in > case of MIPv6, as Yoshi explained, which leads to the same thread again > discussing processing paging trigger packets in the draft-renker concept > (which was said to be unnatural). Yes, it will lead to the same thread, except for the case DMA is co-located with HA. > > Marco > Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Feb 21 16:00:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03952 for ; Thu, 21 Feb 2002 16:00:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25243; Thu, 21 Feb 2002 15:49:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25213 for ; Thu, 21 Feb 2002 15:49:00 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03551 for ; Thu, 21 Feb 2002 15:48:55 -0500 (EST) From: rene.purnadi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1LKnBQ14801 for ; Thu, 21 Feb 2002 14:49:11 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Feb 2002 14:48:55 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 14:47:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Moving forward with paging Date: Thu, 21 Feb 2002 14:47:58 -0600 Message-ID: <748E8123D183394982E32A511DB3E736C83820@daebe005.NOE.Nokia.com> Thread-Topic: [Seamoby] Moving forward with paging Thread-Index: AcG1lRssJ0Cq6BEtQ9mBKMHL5E83vwFg2f8A To: , Cc: , X-OriginalArrivalTime: 21 Feb 2002 20:47:59.0377 (UTC) FILETIME=[0C0BF010:01C1BB19] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James, In HMIPv6, the MAP does NOT send the BU to the HA. The MN is the one that sends the BU to the HA to update the binding cache, using Regional CoA. Rene Purnadi -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, February 14, 2002 2:17 PM To: Yoshihiro Ohba Cc: Behcet Sarikaya; seamoby@ietf.org Subject: Re: [Seamoby] Moving forward with paging Yoshi, > But I don't think the hooks described in draft-renker really satisfies > the requirements 4.7 and 4.8 even with Explicit Mode (see below). > I wasn't proposing that these be used without any modification. > The scheme described in draft-renker relies on using the PA's address > as the alternate CoA in order to redirect packets for the dormant host > to the PA. However, when a redirected data packet is received by the > PA, the PA must look into the inner IP header (or the final entry of > Routing Header if route opmization is used) in which the MN's Home > Address is contained in the destination IP address field in order to > distinguish the MN, as described in the draft. This is very unnatural > way of dealing with IP-in-IP packet (or Routing Header) at an > intermediary node. What about simply using a Deering-Zill tunnel from the HA? Also, I'm not sure why a Routing Header wouldn't work. Suppose there is a Routing Header with the PA's address in it at some point, and what the PA does when it sees that header is to issue an IP page. Then, when the MN replies, it sends along the packet. It is up to the MN to renew it's mobility binding at the HA. >This is also related to the following comments > from the assessment team: > > 2) There is no description of how the mobility management is > completed after the paging request is received. There must be > some coordination on when the deregistration is sent to PA. > > I think that the coordination is very difficult (especially in terms > of security) as long as the solution relies on the use of the MN's > Home Address at PA. > I agree that security is difficult. It essentially requires constructing a trust relationship between the HA and PA that allows the PA to issue binding updates to the HA when the MN moves in dormant mode, on the mobile's behalf. But this is no different in principle than HMIPv6. The benefit is that there is no state on the mobile's location maintained in the foreign network, it is all with the HA. > In order to avoid this situation, an HMIPv6-like solution based on > Regional CoA would be necessary for draft-renker, but this feature is > not available for MIPv4. This means that the scheme is not really > independent of a mobility management protocol. > The issue I have with this is that the MNs location state gets maintained at a "routing proxy." This is a potential source of failure that needs to be replicated. Replication means expense. I think we want a solution that looks like routing, where nearby routers take over if one fails. I would rather confine an expensive replicated agent to the HA, where it is unavoidable, rather than introduce one into the foreign network. And, when the IRTF Micromobility Task Force comes up with a micromobility routing protocol, there will be no expensive routing proxy at all. W.r.t. MIPv4, I think Regional Registration is now Informational, though doesn't have an RFC number yet, it is like HMIPv6. But I don't think it should be used either. > On the other hand, the degree of "independency of mobility managenent > protocol" specified in draft-ohba is the highest among all the > proposals, and thus there is no problem of this kind with draft-ohba. > I think this is a very important point. > draft-ohba doesn't specify where the tracking agent is, in particular, it doesn't specify that it is handled by the mobility protocol. In addition, the security issue isn't discussed. 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 From seamoby-admin@ietf.org Thu Feb 21 18:54:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07567 for ; Thu, 21 Feb 2002 18:54:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03134; Thu, 21 Feb 2002 18:40:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03104 for ; Thu, 21 Feb 2002 18:40:03 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07381 for ; Thu, 21 Feb 2002 18:39:56 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1LNdTq12445 for ; Thu, 21 Feb 2002 17:39:29 -0600 (CST) Message-ID: <3C75851D.2060706@alcatel.com> Date: Thu, 21 Feb 2002 17:39:09 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020220182424.GE3759@catfish> <3C751D75.40907@alcatel.com> <20020221175437.GB2971@catfish> Content-Type: multipart/alternative; boundary="------------090606040102030106010000" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------090606040102030106010000 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Yoshi, As for the message formats, draft-guri defines them as destination option extension headers. I could not see any such specification in your section 5. I thought that you defined your messages as IPv4 options. MIPv4 (RFC 3220) defines registration messages as UDP messages (e.g. port 434 is defined as destination port) but the tunneling is IP based. No one considers MIPv4 as L4 protocol though. I think that in IPv4 there is no other way, so maybe you should also have defined the paging messages as UDP messages, something to note for the next version? MIPv6 uses IPv6 extension headers to define BU/BAck UDP is not used at all. MIPv6 also is not considered L4 protocol. As for layering, what you said is correct, i.e. if we define as L4 then of course IP Paging is above IP layer so we can define one independent of IP or MIP version as UDP or TCP is. Has anybody (any of the 5 drafts) defined it that way? My answer is no. Because then you have to define source and destination ports on which the L4 protocol will work. This has been very useful, hopefully people will realize the need for multiple drafts. Yoshihiro Ohba wrote: >On Thu, Feb 21, 2002 at 10:16:53AM -0600, Behcet Sarikaya wrote: > >>Hello Yoshi, >>draft-ohba 00 was on IPv4, I think. Refering to your section 5 on >>message formats, I thought you mainly addressed v4 formats. >> > >No. What makes you think in such a way? > >>Yes it is >>true that in previous text you try to accomodate IPv4, IPv6, Mobile IPv4 >>and Mobile IPv6. I have been indicating all along that this is a >>mistake. Hope you come to agree it. >> > >That depends on the layer where the DMHA signaling is supposed to work. >If it is supposed to run over L4, then is should be a single document. > Behcet --------------090606040102030106010000 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Yoshi,
  As for the message formats, draft-guri defines them as destination option extension headers. I could not see any such specification in your section 5. I thought that you defined your messages as IPv4 options.

  MIPv4 (RFC 3220) defines registration messages as UDP messages (e.g. port 434 is defined as destination port) but the tunneling is IP based. No one considers MIPv4 as L4 protocol though. I think that in IPv4 there is no other way, so maybe you should also have defined the paging messages as UDP messages, something to note for the next version?

  MIPv6 uses IPv6 extension headers to define BU/BAck UDP is not used at all. MIPv6 also is not considered L4 protocol.

  As for layering, what you said is correct, i.e. if we define as L4 then of course IP Paging is above IP layer so we can define one independent of IP or MIP version as UDP or TCP is.

  Has anybody (any of the 5 drafts) defined it that way? My answer is no. Because then you have to define source and destination ports on which the L4 protocol will work.

  This has been very useful, hopefully people will realize the need for multiple drafts.



Yoshihiro Ohba wrote:
On Thu, Feb 21, 2002 at 10:16:53AM -0600, Behcet Sarikaya wrote:
Hello Yoshi,
draft-ohba 00 was on IPv4, I think. Refering to your section 5 on
message formats, I thought you mainly addressed v4 formats. 

No.  What makes you think in such a way?

Yes it is
true that in previous text you try to accomodate IPv4, IPv6, Mobile IPv4
and Mobile IPv6. I have been indicating all along that this is a
mistake. Hope you come to agree it.

That depends on the layer where the DMHA signaling is supposed to work.
If it is supposed to run over L4, then is should be a single document.


        

        

        
 
Behcet 


        

        
        

--------------090606040102030106010000--


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


From seamoby-admin@ietf.org  Thu Feb 21 19:19:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07912
	for ; Thu, 21 Feb 2002 19:19:43 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03787;
	Thu, 21 Feb 2002 18:58:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03760
	for ; Thu, 21 Feb 2002 18:58:57 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07608
	for ; Thu, 21 Feb 2002 18:58:53 -0500 (EST)
Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1LNwIe16267;
	Thu, 21 Feb 2002 15:58:18 -0800 (PST)
Message-ID: <001b01c1bb33$69b636c0$746015ac@T23KEMPF>
From: "James Kempf" 
To: "Pars MUTAF" 
Cc: 
References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> <3C74F84F.E56AB72B@ccrle.nec.de> <3C74FDD0.55D37BB4@inrialpes.fr>
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Date: Thu, 21 Feb 2002 15:56:42 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

"host" No reason why a fixed host couldn't use paging. On the other
hand, I don't think a router would, so "node" is too broad.

            jak

----- Original Message -----
From: "Pars MUTAF" 
Cc: 
Sent: Thursday, February 21, 2002 6:01 AM
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues


>
> Hello all,
>
> A terminology question:
>
> Should we use the term "mobile node", "mobile host" or just
> "host"?
>
>
> > Right, personalized paging areas is an option, but an important one.
This is
> > discussed and allowed in draft-renker. It is not clear to me how
individual
> > paging areas could be managed with a static assignment of a paging
agent
> > functional entity to a paging area.
>
> It would be good to have some flexibility on that issue...
>
>
> Regards,
> pars
>
>
> _______________________________________________
> 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  Thu Feb 21 19:22:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07941
	for ; Thu, 21 Feb 2002 19:22:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04558;
	Thu, 21 Feb 2002 19:11:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04529
	for ; Thu, 21 Feb 2002 19:11:53 -0500 (EST)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07829
	for ; Thu, 21 Feb 2002 19:11:50 -0500 (EST)
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1M0BJjP001772;
	Thu, 21 Feb 2002 19:11:19 -0500 (EST)
Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id TAA21923;
	Thu, 21 Feb 2002 19:11:13 -0500 (EST)
Date: Thu, 21 Feb 2002 19:11:18 -0500
To: Behcet Sarikaya 
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Message-ID: <20020222001118.GB3148@catfish>
Mail-Followup-To: Behcet Sarikaya ,
	seamoby@ietf.org
References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020220182424.GE3759@catfish> <3C751D75.40907@alcatel.com> <20020221175437.GB2971@catfish> <3C75851D.2060706@alcatel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: <3C75851D.2060706@alcatel.com>
User-Agent: Mutt/1.3.27i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 33
X-Virus-Scanned: by AMaViS-perl11-milter
 (http://amavis.org/)
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

On Thu, Feb 21, 2002 at 05:39:09PM -0600, Behcet Sarikaya wrote:
> Hi Yoshi,
> As for the message formats, draft-guri defines them as destination
> option extension headers. I could not see any such specification in your
> section 5. I thought that you defined your messages as IPv4 options.
> 
> MIPv4 (RFC 3220) defines registration messages as UDP messages (e.g.
> port 434 is defined as destination port) but the tunneling is IP based.
> No one considers MIPv4 as L4 protocol though. I think that in IPv4 there
> is no other way, so maybe you should also have defined the paging
> messages as UDP messages, something to note for the next version?
> 
> MIPv6 uses IPv6 extension headers to define BU/BAck UDP is not used at
> all. MIPv6 also is not considered L4 protocol.
> 
> As for layering, what you said is correct, i.e. if we define as L4 then
> of course IP Paging is above IP layer so we can define one independent
> of IP or MIP version as UDP or TCP is.
> 
> Has anybody (any of the 5 drafts) defined it that way? My answer is no.
> Because then you have to define source and destination ports on which
> the L4 protocol will work.

Yes, draft-ohba is defined it that way. i.e., using UDP as transport
for all signaling messages, and that's why I mentioned: "That depends
on the layer where the DMHA signaling is supposed to work."

> 
> This has been very useful, hopefully people will realize the need for
> multiple drafts.
> 

Yoshihiro Ohba

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


From seamoby-admin@ietf.org  Fri Feb 22 07:00:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28500
	for ; Fri, 22 Feb 2002 07:00:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15920;
	Fri, 22 Feb 2002 06:43:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15853
	for ; Fri, 22 Feb 2002 06:43:09 -0500 (EST)
Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27988
	for ; Fri, 22 Feb 2002 06:43:06 -0500 (EST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1MBjiQ39322;
	Fri, 22 Feb 2002 12:45:44 +0100 (CET)
	(envelope-from Marco.Liebsch@ccrle.nec.de)
Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA28184;
	Fri, 22 Feb 2002 12:42:33 +0100
Message-ID: <3C762EA9.67FC60EA@ccrle.nec.de>
Date: Fri, 22 Feb 2002 12:42:33 +0100
From: Marco Liebsch 
Organization: NEC Europe Ltd.
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yoshihiro Ohba 
CC: James Kempf , seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References: <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> <20020221185313.GD2971@catfish>
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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Yoshi,

Yoshihiro Ohba wrote:

> On Wed, Feb 20, 2002 at 07:31:43PM -0800, James Kempf wrote:
> >
> > OK.
> >
> > > >
> > > > I still don't understand why having the DMA on the last hop is so
> > > > important. Also, I don't understand
> > > > how it could work.
> > >
> > > Having the DMA on the last hop is important for (i) working with any
> > > mobility management protocol and null mobility management protocol
> > > (i.e., stationaly hosts) and
> >
> > This isn't clear (but I see you explain it better below).
> >
> > > (ii) avoiding a single point of failure.
> > >
> >
> > But you could have multiple DMAs behind the last hop. And, as I have
> > mentioned in previous notes (and I believe you even specified in
> > draft-ohba) the DMAs can exchange periodic messages. If a message falls
> > out, others reconfigure to take over. The router solution.
>
> As Tao mentioned, if we can use a stable method (unlike the method
> used in HMIPv6) for redirecting packets from HA to DMA at arbitrary
> location, DMAs could be put behind the last hop.
>
> >
> > > >
> > > > Suppose an MN goes into dormant mode  in subnet X in paging area A.
> > > > Presumably, the DMA in subnet X now is waiting for packets for the
> > MN.
> > > > Now, suppose the MN moves to subnet Y, still in paging area A. Does
> > the
> > > > DMA perform a "handover"?
> > >
> > > No.  The MN can stay dormant without performing handover.  When the
> > > DMA captures a data packet destined for the CoA, it sends a Paging
> > > message to Paging Agent (via TA) and Paging Agent can "page" the MN.
> > > Note that since the DMA is on the last hop subnet of the subnet of the
> > > CoA, any data packet in which the CoA is specified in the destination
> >
> > What does the CoA have to do with it? The MN is in dormant mode, roaming
> > across multiple
> > subnets. It no longer has a fixed CoA. Or, are you proposing that the
> > CoA stay the
> > same as when the MN went to sleep? That's the point I was trying to make
> > about
> > the extreme message legs across large chunks of the Internet.
>
> Sorry, CoA was not a good word.  It could be HoA when DMA is co-located
> with HA.  In fact, we have the following description in section 4.15 of
> draft-ohba:
>
> 4.15.  Supporting Mobility Management Protocol
>
>    If a Host is a mobile node, it is able to move around while it is in
>    a dormant mode, with changing L2 attachment points or L3 subnets but
>    without changing its IP address.
>
>    It is possible for a Dormant Monitoring Agent to be co-located with a
>    Home Agent of Mobile IP so that packets destined for the mobile
>    Host's home address are captured at the Home Agent for triggering
>    paging operation before it is forwarded to the care-of address,
>    instead of having a Dormant Monitoring Agent at each last hop subnet
>    in foreign networks.

this would require pre-establishment of a security association between DMA and
TA/PA located in foreign network. Anyway, this is what we discussed in our
proposal, to allow paging areas beyond the scope of an admin. domain, which is
allowed to be managed at the paging agent node, but addressing the additional
security issue where a pre-establishment of a SA netween PA and PA-attendants
in ARs is to be taken into account.

> This is still consistent with the definition of
>    Dormant Monitoring Agent because the mobile's home network is
>    considered to be the last hop subnet in terms of home address.
>    Alternatively, if inter-administrative domain paging is not allowed
>    due to network management policies, a Dormant Monitoring Agent can be
>    co-located with a Foreign Agent of Mobile IP.
>

Is there any difference between the latter approach in your description and
what the Paging Agent node-DMA combination for Mobile IPv6 provides w.r.t
routing issues addressed in this thread?



>
> I think this is one of what you want.
>
> [...]
>
> Yoshihiro Ohba




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


From seamoby-admin@ietf.org  Fri Feb 22 07:19:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29148
	for ; Fri, 22 Feb 2002 07:19:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17349;
	Fri, 22 Feb 2002 07:07:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17324
	for ; Fri, 22 Feb 2002 07:07:23 -0500 (EST)
Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28741
	for ; Fri, 22 Feb 2002 07:07:19 -0500 (EST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1MCA1Q40287;
	Fri, 22 Feb 2002 13:10:01 +0100 (CET)
	(envelope-from Marco.Liebsch@ccrle.nec.de)
Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA28510;
	Fri, 22 Feb 2002 13:06:50 +0100
Message-ID: <3C76345A.42688D4C@ccrle.nec.de>
Date: Fri, 22 Feb 2002 13:06:50 +0100
From: Marco Liebsch 
Organization: NEC Europe Ltd.
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yoshihiro Ohba 
CC: James Kempf , seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References: <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> <3C74F84F.E56AB72B@ccrle.nec.de> <20020221191925.GE2971@catfish>
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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Yoshi,

Yoshihiro Ohba wrote:

> On Thu, Feb 21, 2002 at 02:38:23PM +0100, Marco Liebsch wrote:
> >
> > > > > Why not have the paging area identifier simply be an anycast
> > > (multicast
> > > > > in IPv4) address?
> > > > > And what is a "terminal identifier"? Home address? MAC address?
> > > >
> > > > Because paging area can be different per MN (personalized paging
> > > area).
> > > > Anycast (or multicast in IPv4) is not defined per host, I think.
> > > >
> > >
> > > But the MN doesn't have to have a personalized paging area, that is
> > > a policy option. Anyway, the point is, it can be an IP address.
>
> Yes, that can be an IP address.  I guess this is not an essential
> issue compared with other issues.
>
> > >
> >
> > Right, personalized paging areas is an option, but an important one. This is
> > discussed and allowed in draft-renker. It is not clear to me how individual
> > paging areas could be managed with a static assignment of a paging agent
> > functional entity to a paging area.
>
> This is a good point.  Fxine-grained assignment of personal paging
> area is difficult with a static assignment of a paging agent, unless
> all paging agents are co-located with base stations.
>

I am not sure, but I think this is exactly written in the requirements (maybe I
misinterpreted)

'...each paging area is served by a unique paging agent...'. I think what we did
in our proposal loosens this requirement a bit, since we allowed a paging agent to
support multiple paging areas, which could be individual (personal) ones. Anyway,
I think this is still in relation to what the requirement sais, having a unique
paging agent per paging area (which could be a static one or an individual one).

Marco





>
> >
> > For the terminal identifier, the paging system has to cope with the
> > identifier a paging trigger packet carries. This can be the home address in
> > case of MIPv6, as Yoshi explained, which leads to the same thread again
> > discussing processing paging trigger packets in the draft-renker concept
> > (which was said to be unnatural).
>
> Yes, it will lead to the same thread, except for the case DMA is
> co-located with HA.
>
> >
> > Marco
> >
>
> Yoshihiro Ohba


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


From seamoby-admin@ietf.org  Fri Feb 22 10:17:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05336
	for ; Fri, 22 Feb 2002 10:17:20 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28020;
	Fri, 22 Feb 2002 10:05:07 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27979
	for ; Fri, 22 Feb 2002 10:05:03 -0500 (EST)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04871
	for ; Fri, 22 Feb 2002 10:04:58 -0500 (EST)
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 HAA01841;
	Fri, 22 Feb 2002 07:04:30 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1MF4U724117;
	Fri, 22 Feb 2002 07:04:30 -0800
X-mProtect:  Fri, 22 Feb 2002 07:04:30 -0800 Nokia Silicon Valley Messaging Protection
Received: from maxdialin21.iprg.nokia.com (205.226.20.251, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdl0pJZL; Fri, 22 Feb 2002 07:04:27 PST
Message-ID: <3C765D9A.A1306D09@iprg.nokia.com>
Date: Fri, 22 Feb 2002 07:02:50 -0800
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish
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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit


Hello folks,

I think we should allow for routers to use paging.

For instance, I may have a wide-area wireless router
that forwards packets to other short-range wireless
devices attached to my belt.  That router still needs
to be able to make use of paging as a way to conserve
battery power.

Regards,
Charlie P.


James Kempf wrote:

> "host" No reason why a fixed host couldn't use paging. On the other
> hand, I don't think a router would, so "node" is too broad.
>
>             jak
>
> ----- Original Message -----
> From: "Pars MUTAF" 
> Cc: 
> Sent: Thursday, February 21, 2002 6:01 AM
> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
> Protocol Issues
>
> >
> > Hello all,
> >
> > A terminology question:
> >
> > Should we use the term "mobile node", "mobile host" or just
> > "host"?
> >
> >
> > > Right, personalized paging areas is an option, but an important one.
> This is
> > > discussed and allowed in draft-renker. It is not clear to me how
> individual
> > > paging areas could be managed with a static assignment of a paging
> agent
> > > functional entity to a paging area.
> >
> > It would be good to have some flexibility on that issue...
> >
> >
> > Regards,
> > pars
> >
> >
> > _______________________________________________
> > 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  Fri Feb 22 10:49:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06877
	for ; Fri, 22 Feb 2002 10:49:53 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29616;
	Fri, 22 Feb 2002 10:34:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29588
	for ; Fri, 22 Feb 2002 10:34:31 -0500 (EST)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06102
	for ; Fri, 22 Feb 2002 10:34:29 -0500 (EST)
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1MFXM3v026404;
	Fri, 22 Feb 2002 10:33:23 -0500 (EST)
Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id KAA23056;
	Fri, 22 Feb 2002 10:33:09 -0500 (EST)
Date: Fri, 22 Feb 2002 10:33:14 -0500
To: Marco Liebsch 
Cc: Yoshihiro Ohba ,
        James Kempf , seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Message-ID: <20020222153314.GB792@catfish>
Mail-Followup-To: Marco Liebsch ,
	Yoshihiro Ohba ,
	James Kempf , seamoby@ietf.org
References: <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> <20020221185313.GD2971@catfish> <3C762EA9.67FC60EA@ccrle.nec.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: <3C762EA9.67FC60EA@ccrle.nec.de>
User-Agent: Mutt/1.3.27i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 49
X-Virus-Scanned: by AMaViS-perl11-milter
 (http://amavis.org/)
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

On Fri, Feb 22, 2002 at 12:42:33PM +0100, Marco Liebsch wrote:
> > 4.15.  Supporting Mobility Management Protocol
> >
> >    If a Host is a mobile node, it is able to move around while it is in
> >    a dormant mode, with changing L2 attachment points or L3 subnets but
> >    without changing its IP address.
> >
> >    It is possible for a Dormant Monitoring Agent to be co-located with a
> >    Home Agent of Mobile IP so that packets destined for the mobile
> >    Host's home address are captured at the Home Agent for triggering
> >    paging operation before it is forwarded to the care-of address,
> >    instead of having a Dormant Monitoring Agent at each last hop subnet
> >    in foreign networks.
> 
> this would require pre-establishment of a security association between DMA and
> TA/PA located in foreign network. Anyway, this is what we discussed in our
> proposal, to allow paging areas beyond the scope of an admin. domain, which is
> allowed to be managed at the paging agent node, but addressing the additional
> security issue where a pre-establishment of a SA netween PA and PA-attendants
> in ARs is to be taken into account.
> 
> > This is still consistent with the definition of
> >    Dormant Monitoring Agent because the mobile's home network is
> >    considered to be the last hop subnet in terms of home address.
> >    Alternatively, if inter-administrative domain paging is not allowed
> >    due to network management policies, a Dormant Monitoring Agent can be
> >    co-located with a Foreign Agent of Mobile IP.
> >
> 
> Is there any difference between the latter approach in your description and
> what the Paging Agent node-DMA combination for Mobile IPv6 provides w.r.t
> routing issues addressed in this thread?

Good question.

When Mobile IPv4 Foreign Agent operates in co-located Care-of Address
mode (I think RFC3220 supports this), the Mobile IPv4 registration is
forced via the FA but the the IP-in-IP tunnel is terminated on the MN,
not on the FA.  This case does not raise the routing issue I
mentioned.

On the other hand, when Mobile IPv4 Foreign Agent operates in Foreign
Agent Care-of Address mode, the IP-in-IP tunnel is terminated on the
FA.  This case raises the routing issue I mentioned.  But this is the
problem of vanilla Mobile IPv4 and out of the control of DMHA, I
think.

Yoshihiro Ohba


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


From seamoby-admin@ietf.org  Fri Feb 22 10:55:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07186
	for ; Fri, 22 Feb 2002 10:55:54 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00334;
	Fri, 22 Feb 2002 10:43:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00302
	for ; Fri, 22 Feb 2002 10:43:29 -0500 (EST)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06531
	for ; Fri, 22 Feb 2002 10:43:26 -0500 (EST)
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1MFgO3v027207;
	Fri, 22 Feb 2002 10:42:24 -0500 (EST)
Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id KAA23082;
	Fri, 22 Feb 2002 10:42:18 -0500 (EST)
Date: Fri, 22 Feb 2002 10:42:22 -0500
To: Marco Liebsch 
Cc: Yoshihiro Ohba ,
        James Kempf , seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Message-ID: <20020222154222.GC792@catfish>
Mail-Followup-To: Marco Liebsch ,
	Yoshihiro Ohba ,
	James Kempf , seamoby@ietf.org
References: <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> <3C74F84F.E56AB72B@ccrle.nec.de> <20020221191925.GE2971@catfish> <3C76345A.42688D4C@ccrle.nec.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: <3C76345A.42688D4C@ccrle.nec.de>
User-Agent: Mutt/1.3.27i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 22
X-Virus-Scanned: by AMaViS-perl11-milter
 (http://amavis.org/)
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

Marco,

RFC3154 talks about functional elements.
A single PA-FE could be realized by multiple protocol entities 
of the same name 'PA'.  So I don't think we loosen the requirement.

Yoshihiro Ohba


On Fri, Feb 22, 2002 at 01:06:50PM +0100, Marco Liebsch wrote:
> I am not sure, but I think this is exactly written in the requirements (maybe I
> misinterpreted)
> 
> '...each paging area is served by a unique paging agent...'. I think what we did
> in our proposal loosens this requirement a bit, since we allowed a paging agent to
> support multiple paging areas, which could be individual (personal) ones. Anyway,
> I think this is still in relation to what the requirement sais, having a unique
> paging agent per paging area (which could be a static one or an individual one).
> 
> Marco
> 
> 

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


From seamoby-admin@ietf.org  Fri Feb 22 13:29:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15194
	for ; Fri, 22 Feb 2002 13:29:04 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11920;
	Fri, 22 Feb 2002 13:18:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11893
	for ; Fri, 22 Feb 2002 13:18:16 -0500 (EST)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14722
	for ; Fri, 22 Feb 2002 13:18:13 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1MIHiq28268
	for ; Fri, 22 Feb 2002 12:17:44 -0600 (CST)
Message-ID: <3C768B32.1080605@alcatel.com>
Date: Fri, 22 Feb 2002 12:17:22 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References: <000001c1b5cb$36514990$956015ac@T23KEMPF> <3C6CF117.2A2CCA2C@ccrle.nec.de> <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020220182424.GE3759@catfish> <3C751D75.40907@alcatel.com> <20020221175437.GB2971@catfish> <3C75851D.2060706@alcatel.com> <20020222001118.GB3148@catfish>
Content-Type: multipart/alternative;
 boundary="------------080501020504080801040308"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------080501020504080801040308
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Hi Yoshi,
It is one thing to say the signaling messages sent over UDP, it is
another thing to say LA-DMHA is an application layer protocol which runs
over UDP.
On page 5 of draft-ohba, the first sentence states LA-DMHA is an
application layer protocol which runs over UDP.
Of course in MIPv6 they could have defined BU/BAck as UDP messages, I
think that they wanted to have the whole operation including signaling
to be independent of higher layers.
Main paging functionalities such as packet capturing (not only for one
specific application but any application running at the host) and paging
operations are IP version specific.
For example paging areas and related interactions utilize multicasting
which is different in IPv4 and in IPv6.
For example packet capturing and forwarding are also version dependent.

So just because we can define the signaling using UDP does not render
the protocol an application layer protocol. IP Paging with its
functionalities so basic to all applications running on a host can not
simply be application layer protocol.

IP paging can not also be defined as a transport layer protocol because
it is not a new transport mechanism. L4 protocols such as UDP, TCP and
SCTP define specific transport mechanisms. That's why they are transport
layer protocols.

Hope you agree with the above.


Yoshihiro Ohba wrote:

>On Thu, Feb 21, 2002 at 05:39:09PM -0600, Behcet Sarikaya wrote:
>
>>
>
>Yes, draft-ohba is defined it that way. i.e., using UDP as transport
>for all signaling messages, and that's why I mentioned: "That depends
>on the layer where the DMHA signaling is supposed to work."
>
--behcet

>

--------------080501020504080801040308
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit





Hi Yoshi,

  It is one thing to say the signaling messages sent over UDP, it is another
thing to say LA-DMHA is an application layer protocol which runs over UDP.

On page 5 of draft-ohba, the first sentence states LA-DMHA is an application
layer protocol which runs over UDP.

  Of course in MIPv6 they could have defined BU/BAck as UDP messages, I think
that they wanted to have the whole operation including signaling to be independent
of higher layers.

  Main paging functionalities such as packet capturing (not only for one
specific application but any application running at the host) and paging
operations are IP version specific. 

   For example paging areas and related interactions utilize multicasting
which is different in IPv4 and in IPv6.

   For example packet capturing and forwarding are also version dependent.



  So just because we can define the signaling using UDP does not render the
protocol an application layer protocol. IP Paging with its functionalities
so basic to all applications running on a host can not simply be application
layer protocol.

  

  IP paging can not also be defined as a transport layer protocol because
it is not a new transport mechanism. L4 protocols such as UDP, TCP and SCTP
define specific transport mechanisms. That's why they are transport layer
protocols.



  Hope you agree with the above.

  



Yoshihiro Ohba wrote:



  
On Thu, Feb 21, 2002 at 05:39:09PM -0600, Behcet Sarikaya wrote:

  

    


    

    

Yes, draft-ohba is defined it that way. i.e., using UDP as transport
for all signaling messages, and that's why I mentioned: "That depends
on the layer where the DMHA signaling is supposed to work."

    

--behcet

    

      


      

      
      

--------------080501020504080801040308--


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


From seamoby-admin@ietf.org  Fri Feb 22 13:42:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15922
	for ; Fri, 22 Feb 2002 13:42:01 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13337;
	Fri, 22 Feb 2002 13:31:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13308
	for ; Fri, 22 Feb 2002 13:31:09 -0500 (EST)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15348
	for ; Fri, 22 Feb 2002 13:31:06 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1MIUbX27049
	for ; Fri, 22 Feb 2002 12:30:37 -0600 (CST)
Message-ID: <3C768E37.7030902@alcatel.com>
Date: Fri, 22 Feb 2002 12:30:15 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References: <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> <3C74F84F.E56AB72B@ccrle.nec.de> <20020221191925.GE2971@catfish> <3C76345A.42688D4C@ccrle.nec.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Hi Marco,
  RFC 3154 has this on page 10 in section 5.1:
 Each paging area is served by a unique Paging Agent.
I think that in some drafts this was interreted as  we need to have a 
paging agent for each paging area.
Certainly this statement is not saying that. But it is allowing a 
one-to-one mapping as well.

Marco Liebsch wrote:

>
>'...each paging area is served by a unique paging agent...'. I think what we did
>in our proposal loosens this requirement a bit, since we allowed a paging agent to
>support multiple paging areas, which could be individual (personal) ones. Anyway,
>I think this is still in relation to what the requirement sais, having a unique
>paging agent per paging area (which could be a static one or an individual one).
>
>Marco
>
>
>
>
>

-- 
Behcet 




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


From seamoby-admin@ietf.org  Fri Feb 22 15:11:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20362
	for ; Fri, 22 Feb 2002 15:11:17 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21646;
	Fri, 22 Feb 2002 14:59:27 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21614
	for ; Fri, 22 Feb 2002 14:59:25 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19670
	for ; Fri, 22 Feb 2002 14:59:22 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1MJwre14289
	for ; Fri, 22 Feb 2002 11:58:53 -0800 (PST)
Message-ID: <00de01c1bbdb$217ff370$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Date: Fri, 22 Feb 2002 11:57:17 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Folks,

The deadline for WG Last Call on the paging assessment,
draft-ietf-seamoby-paging-protocol-assessment-01.txt, is Monday 4 PM
Pacific Time. Please send in any comments by then. At the conclusion of
WG Last Call, we will be submitting the paging assessment draft to the
IESG after making any changes that have WG concensus.

Since my last email on this topic, we have had two additional
suggestions from the WG.

An editorial suggestion was made to divide Section 4 into separate
subsections. I'll take a look at the document next week and see if this
makes sense. At first glance, the proposed subsections do look as if
they would improve readability.

A suggestion was made by another WG member that, instead of selecting a
single draft as a starting point, the WG should select all drafts and
have each draft focus on a different part of the paging problem. So far,
there has been no further comment from the WG on this proposal and so it
does not look like there is concensus for it at this time. If you are
interested in commenting on this proposal, please review the email
describing it at the Seamoby archives and post your comment.


                        jak


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


From seamoby-admin@ietf.org  Fri Feb 22 15:30:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22148
	for ; Fri, 22 Feb 2002 15:30:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23221;
	Fri, 22 Feb 2002 15:18:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23190
	for ; Fri, 22 Feb 2002 15:18:36 -0500 (EST)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21573
	for ; Fri, 22 Feb 2002 15:18:33 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1MKI4q06068
	for ; Fri, 22 Feb 2002 14:18:04 -0600 (CST)
Message-ID: <3C76A766.4000408@alcatel.com>
Date: Fri, 22 Feb 2002 14:17:42 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
References: <00de01c1bbdb$217ff370$7e6015ac@T23KEMPF>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Hello all,
  I think that this is the email I had posted before that is mentioned 
in the 3rd paragraph of James' email below, I just am reposting it 
(please note that after the discussions it became clearer that  
draft-ohba is mainly based on IPv4 was not correct):

  Contrary to the ordinary belief, I think (of course I may be wrong)
that there is no single IP Paging protocol, requirements 4.7 and 4.8 are
pointing to 4 different IP Paging protocols.

  If we may change Pat's question to which drafts to take as the base
then there are natural solutions:

- I hereby suggest draft-ohba as the base draft for mip independent IPv4
based solution.THis draft is mainly based on IPv4 and it does not
attempt to integrate with MIPv4. There are some problems in its
architecture but these can be addressed in the next version.

- I hereby suggest draft-guri as the base for mip independent IPv6 based
solution. This draft is based on IPv6 and no integration with MIPv6 is
attempted. However its architecture must be modified and streamlined
with modified draft-ohba.

For MIPv4 and MIPv6 based solutions, I have trouble in suggesting the
base drafts but the natural solution seems to suggest that

- draft-renker may be modified towards a MIPv4 based solution (please
consider LMM not home agent  based architecture).

-draft-sarikaya and draft-koodli may take a MIPv6 based solution, there
are already some similarities and taking in close consideration of :LMM
requirements and any follow up developments.

James Kempf wrote:

>Folks,
>
>The deadline for WG Last Call on the paging assessment,
>draft-ietf-seamoby-paging-protocol-assessment-01.txt, is Monday 4 PM
>Pacific Time. Please send in any comments by then. At the conclusion of
>WG Last Call, we will be submitting the paging assessment draft to the
>IESG after making any changes that have WG concensus.
>
>Since my last email on this topic, we have had two additional
>suggestions from the WG.
>
>An editorial suggestion was made to divide Section 4 into separate
>subsections. I'll take a look at the document next week and see if this
>makes sense. At first glance, the proposed subsections do look as if
>they would improve readability.
>
>A suggestion was made by another WG member that, instead of selecting a
>single draft as a starting point, the WG should select all drafts and
>have each draft focus on a different part of the paging problem. So far,
>there has been no further comment from the WG on this proposal and so it
>does not look like there is concensus for it at this time. If you are
>interested in commenting on this proposal, please review the email
>describing it at the Seamoby archives and post your comment.
>
>
>                        jak
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>

-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460




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


From seamoby-admin@ietf.org  Fri Feb 22 17:53:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29925
	for ; Fri, 22 Feb 2002 17:53:48 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02274;
	Fri, 22 Feb 2002 17:42:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02245
	for ; Fri, 22 Feb 2002 17:42:23 -0500 (EST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29557
	for ; Fri, 22 Feb 2002 17:42:13 -0500 (EST)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA07788 for ; Fri, 22 Feb 2002 15:42:16 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA27488 for ; Fri, 22 Feb 2002 15:42:15 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52)
	id ; Fri, 22 Feb 2002 16:42:15 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF3E@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'Govind Krishnamurthi'" , seamoby@ietf.org
Cc: Nakhjiri Madjid-MNAKHJI1 
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments
Date: Fri, 22 Feb 2002 16:42:13 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

Govind, 

not sure if I making the deadline or not. Sorry if I bring up
things that have been discussed on the list, I only go based
on what I see in the draft:

Don't know if inter-domain is included in the discussion,
but I am guessing since you mentioned multiple access technologies
and multiple mobility management mechanism, I am guessing that
multi-admin domain is in scope: in that case, you would have several 
issues

1-I didn't see any security requirements, it depends on how
much of the policy and capability information can be shared
with the MN, one example is the location and info of all the 
network management units behind the ARs, another is the network
topology information.

2-since CAR is carrying capability information (I am guessing
this would also mean availibility of resources) then signaling
of network policies might be an issue. I did not see any info
on policy.


Regards,

Madjid


-----Original Message-----
From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
Sent: Wednesday, February 20, 2002 11:39 AM
To: seamoby@ietf.org
Subject: [Seamoby] CAR Discovery Requirements ... Call for Comments


Hello all,
I hope that you have had a chance to read the CAR Discovery Requirements 
draft. I request you to post any comments that you may have on the document 
soon, so that I would have the time to incorporate them in the document if 
we have WG consensus.

Regards,
Govind.

_________________________________________________________________
Join the world's largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


_______________________________________________
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  Fri Feb 22 18:17:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00744
	for ; Fri, 22 Feb 2002 18:17:48 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04067;
	Fri, 22 Feb 2002 18:06:54 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04038
	for ; Fri, 22 Feb 2002 18:06:52 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00429
	for ; Fri, 22 Feb 2002 18:06:49 -0500 (EST)
From: Srinivas.Sreemanthula@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1MN8qQ17948
	for ; Fri, 22 Feb 2002 17:08:52 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 22 Feb 2002 17:06:52 -0600
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 22 Feb 2002 17:06:52 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
Date: Fri, 22 Feb 2002 17:06:51 -0600
Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF66D@daebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
Thread-Index: AcG75FmOsoV6XkP+Q3OWsZGErTo2wwADBe2A
To: , 
X-OriginalArrivalTime: 22 Feb 2002 23:06:52.0459 (UTC) FILETIME=[9D5D17B0:01C1BBF5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA04039
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 8bit


Actually, Behcet has a point with respect to the the analysis of the requirements (4.7 and 4.8).  Also, from the solutions presented so far, we did not see an integrated protocol solution that satisfies both the simple IP (non-mobility)  and mobility-aware. Renker, the current base draft,  provides two modes but not as a single solution.  
 
An important question I would ask is if there is any interest in practical deployment of DMHA as an independent protocol (without mobility)?  

To me, DMHA is more applicable to mobile handheld terminals with limited battery life.  Dormancy will avoid frequent mobility (update) procedures to save the battery and also makes efficient radio spectrum usage. From all the existing proposals, it is very clear that when DMHA is used with a mobility protocol, DMHA extensions must be incorporated within mobility protocol. The point is, it would make sense to emphasize on the 4.8 (mobility aware) requirement.

From this point of view, I would nominate proposals that have base mobility support without any particular references to LMM. The approach would be to merge all good aspects of different mobility based proposals(MIP & MIPv6) from renker, sarikaya and koodli drafts (without the concept of a base draft).
 
Thanks,
Srini

-----Original Message-----
From: ext Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: 22 February, 2002 2:18 PM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


Hello all,
  I think that this is the email I had posted before that is mentioned 
in the 3rd paragraph of James' email below, I just am reposting it 
(please note that after the discussions it became clearer that  
draft-ohba is mainly based on IPv4 was not correct):

  Contrary to the ordinary belief, I think (of course I may be wrong)
that there is no single IP Paging protocol, requirements 4.7 and 4.8 are
pointing to 4 different IP Paging protocols.

  If we may change Pat's question to which drafts to take as the base
then there are natural solutions:

- I hereby suggest draft-ohba as the base draft for mip independent IPv4
based solution.THis draft is mainly based on IPv4 and it does not
attempt to integrate with MIPv4. There are some problems in its
architecture but these can be addressed in the next version.

- I hereby suggest draft-guri as the base for mip independent IPv6 based
solution. This draft is based on IPv6 and no integration with MIPv6 is
attempted. However its architecture must be modified and streamlined
with modified draft-ohba.

For MIPv4 and MIPv6 based solutions, I have trouble in suggesting the
base drafts but the natural solution seems to suggest that

- draft-renker may be modified towards a MIPv4 based solution (please
consider LMM not home agent  based architecture).

-draft-sarikaya and draft-koodli may take a MIPv6 based solution, there
are already some similarities and taking in close consideration of :LMM
requirements and any follow up developments.

James Kempf wrote:

>Folks,
>
>The deadline for WG Last Call on the paging assessment,
>draft-ietf-seamoby-paging-protocol-assessment-01.txt, is Monday 4 PM
>Pacific Time. Please send in any comments by then. At the conclusion of
>WG Last Call, we will be submitting the paging assessment draft to the
>IESG after making any changes that have WG concensus.
>
>Since my last email on this topic, we have had two additional
>suggestions from the WG.
>
>An editorial suggestion was made to divide Section 4 into separate
>subsections. I'll take a look at the document next week and see if this
>makes sense. At first glance, the proposed subsections do look as if
>they would improve readability.
>
>A suggestion was made by another WG member that, instead of selecting a
>single draft as a starting point, the WG should select all drafts and
>have each draft focus on a different part of the paging problem. So far,
>there has been no further comment from the WG on this proposal and so it
>does not look like there is concensus for it at this time. If you are
>interested in commenting on this proposal, please review the email
>describing it at the Seamoby archives and post your comment.
>
>
>                        jak
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>

-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460




_______________________________________________
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  Fri Feb 22 18:39:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01155
	for ; Fri, 22 Feb 2002 18:39:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04578;
	Fri, 22 Feb 2002 18:26:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04548
	for ; Fri, 22 Feb 2002 18:26:34 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00952
	for ; Fri, 22 Feb 2002 18:26:30 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id <1QP7SA35>; Fri, 22 Feb 2002 15:26:04 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Srinivas.Sreemanthula@nokia.com'" ,
        behcet.sarikaya@alcatel.com, seamoby@ietf.org
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging Asses
	sment Draft
Date: Fri, 22 Feb 2002 15:25:59 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BBF8.48E18FB0"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

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_01C1BBF8.48E18FB0
Content-Type: text/plain

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> From this point of view, I would nominate proposals that have base
> mobility support  without any particular references to LMM. The
> approach would be to merge all good  aspects of different mobility
> based proposals(MIP & MIPv6) from renker, sarikaya and  koodli
> drafts (without the concept of a base draft).

Trying to understand your proposal here. 

Are you stating that we shouldn't start with any particular starting
point, but rather starting pulling text from all directions into a
single document?

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use 

iQA/AwUBPHbThjN1fXKoxmisEQJo9QCgt4ft2730DyHcrk/Yku/HBPtcPLgAn1mL
6zYyVgW9f6jFo37AqI/Yzj2H
=lUu4
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BBF8.48E18FB0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Deadline Approaching: WG Last Call for Paging =
Assessment Draft




 

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1




> From this point of view, I would nominate =
proposals that have base

> mobility support  without any particular =
references to LMM. The

> approach would be to merge all good  =
aspects of different mobility

> based proposals(MIP & MIPv6) from renker, =
sarikaya and  koodli

> drafts (without the concept of a base =
draft).




Trying to understand your proposal here. 




Are you stating that we shouldn't start with any =
particular starting

point, but rather starting pulling text from all =
directions into a

single document?




PatC




-----BEGIN PGP SIGNATURE-----

Version: PGPfreeware 7.0.3 for non-commercial use =
<http://www.pgp.com>




iQA/AwUBPHbThjN1fXKoxmisEQJo9QCgt4ft2730DyHcrk/Yku/HBPtcPLgAn1m=
L

6zYyVgW9f6jFo37AqI/Yzj2H

=3DlUu4

-----END PGP SIGNATURE-----





------_=_NextPart_001_01C1BBF8.48E18FB0--

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


From seamoby-admin@ietf.org  Fri Feb 22 18:39:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01183
	for ; Fri, 22 Feb 2002 18:39:33 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04689;
	Fri, 22 Feb 2002 18:28:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04658
	for ; Fri, 22 Feb 2002 18:28:30 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00982
	for ; Fri, 22 Feb 2002 18:28:26 -0500 (EST)
From: Srinivas.Sreemanthula@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1MNUSQ19092
	for ; Fri, 22 Feb 2002 17:30:28 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 22 Feb 2002 17:28:28 -0600
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 22 Feb 2002 17:28:17 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BBF8.9AFEB55C"
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
Date: Fri, 22 Feb 2002 17:28:16 -0600
Message-ID: <07EE0E021034014F99A57B032BC9C0E574FF35@daebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
Thread-Index: AcG7+E4oqa/UzchNTk6bzNX5H2yhGAAAHcYg
To: , ,
        
X-OriginalArrivalTime: 22 Feb 2002 23:28:17.0332 (UTC) FILETIME=[9B352740:01C1BBF8]
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C1BBF8.9AFEB55C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

yes. But that in itself will not provide a complete solution, more work =
still needs to be done.
=20
thanks

-----Original Message-----
From: ext Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
Sent: 22 February, 2002 5:26 PM
To: Sreemanthula Srinivas (NRC/Dallas); behcet.sarikaya@alcatel.com; =
seamoby@ietf.org
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging =
Assessment Draft




-----BEGIN PGP SIGNED MESSAGE-----=20
Hash: SHA1=20

> From this point of view, I would nominate proposals that have base=20
> mobility support  without any particular references to LMM. The=20
> approach would be to merge all good  aspects of different mobility=20
> based proposals(MIP & MIPv6) from renker, sarikaya and  koodli=20
> drafts (without the concept of a base draft).=20

Trying to understand your proposal here.=20

Are you stating that we shouldn't start with any particular starting=20
point, but rather starting pulling text from all directions into a=20
single document?=20

PatC=20

-----BEGIN PGP SIGNATURE-----=20
Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com>=20

iQA/AwUBPHbThjN1fXKoxmisEQJo9QCgt4ft2730DyHcrk/Yku/HBPtcPLgAn1mL=20
6zYyVgW9f6jFo37AqI/Yzj2H=20
=3DlUu4=20
-----END PGP SIGNATURE-----=20


------_=_NextPart_001_01C1BBF8.9AFEB55C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




RE: [Seamoby] Deadline Approaching: WG Last Call for Paging =
Assessment Draft




yes.=20
But that in itself will not provide a complete solution, more work=20
still needs to be done.


 


thanks



  
-----Original Message-----
From: ext Pat R. Calhoun =

  [mailto:pcalhoun@bstormnetworks.com]
Sent: 22 February, 2002 =
5:26=20
  PM
To: Sreemanthula Srinivas (NRC/Dallas);=20
  behcet.sarikaya@alcatel.com; seamoby@ietf.org
Subject: RE: =
[Seamoby]=20
  Deadline Approaching: WG Last Call for Paging Assessment=20
  Draft


  
 
-----BEGIN PGP SIGNED=20
  MESSAGE----- 
Hash: SHA1 

  
> From this point of view, I would nominate =
proposals that=20
  have base 
> mobility support  =
without any=20
  particular references to LMM. The 
> =
approach would=20
  be to merge all good  aspects of different mobility =

> based proposals(MIP & MIPv6) from renker, sarikaya =
and =20
  koodli 
> drafts (without the concept of a =
base=20
  draft). 

  
Trying to understand your proposal here. 

  
Are you stating that we shouldn't start with any =
particular=20
  starting 
point, but rather starting pulling =
text from=20
  all directions into a 
single =
document? 

  
PatC 

  
-----BEGIN PGP SIGNATURE----- 
Version:=20
  PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> 

  
iQA/AwUBPHbThjN1fXKoxmisEQJo9QCgt4ft2730DyHcrk/Yku/HBPtcPLgAn1mL=
=20
  
6zYyVgW9f6jFo37AqI/Yzj2H 
=3DlUu4=20
  
-----END PGP SIGNATURE-----=20



------_=_NextPart_001_01C1BBF8.9AFEB55C--

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


From seamoby-admin@ietf.org  Fri Feb 22 19:44:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02540
	for ; Fri, 22 Feb 2002 19:44:22 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07555;
	Fri, 22 Feb 2002 19:32:41 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07524
	for ; Fri, 22 Feb 2002 19:32:39 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02382
	for ; Fri, 22 Feb 2002 19:32:36 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1N0VXe25120;
	Fri, 22 Feb 2002 16:31:33 -0800 (PST)
Message-ID: <020301c1bc01$3aa18e60$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: , ,
        , 
References: <07EE0E021034014F99A57B032BC9C0E574FF35@daebe001.NOE.Nokia.com>
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
Date: Fri, 22 Feb 2002 16:29:56 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit


> yes. But that in itself will not provide a complete solution, more
work still needs to be done.

So I have some difficulty seeing how that differs from taking a base
document and pulling in pieces from other documents where working group
concensus is established to change something.

As I believe has been demonstrated many times over the last couple
weeks, having a base document makes it easier to criticize something.
And you still need an editor to do the document composition and keep
track of issues, regardless of how you go about it.

            jak



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


From seamoby-admin@ietf.org  Fri Feb 22 20:32:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03423
	for ; Fri, 22 Feb 2002 20:32:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09323;
	Fri, 22 Feb 2002 20:21:29 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09256
	for ; Fri, 22 Feb 2002 20:21:25 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03243
	for ; Fri, 22 Feb 2002 20:21:23 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id <1QP7SARH>; Fri, 22 Feb 2002 17:20:55 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'James Kempf'" ,
        Srinivas.Sreemanthula@nokia.com, behcet.sarikaya@alcatel.com,
        seamoby@ietf.org
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging Asses
	sment Draft
Date: Fri, 22 Feb 2002 17:20:49 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BC08.53ECC270"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

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_01C1BC08.53ECC270
Content-Type: text/plain

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> yes. But that in itself will not provide a complete solution, more
>> work still needs to be done.

>So I have some difficulty seeing how that differs from taking a base
>document and pulling >in pieces from other documents where working
>group concensus is established to change  something.
>
>As I believe has been demonstrated many times over the last couple
>weeks, having a base  document makes it easier to criticize
>something. And you still need an editor to do the  document
>composition and keep track of issues, regardless of how you go about
>it.  

My thoughts exactly

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use 

iQA/AwUBPHbucjN1fXKoxmisEQIoIwCg9vfwJk2uy4n1LzmfPNsO3kJIN0YAnR/q
cN+1wgrBzncIgWOhvyx64EIp
=oAJZ
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BC08.53ECC270
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Deadline Approaching: WG Last Call for Paging =
Assessment Draft




 

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1




>> yes. But that in itself will not provide a =
complete solution, more

>> work still needs to be done.




>So I have some difficulty seeing how that differs =
from taking a base

>document and pulling >in pieces from other =
documents where working

>group concensus is established to change  =
something.

>

>As I believe has been demonstrated many times =
over the last couple

>weeks, having a base  document makes it =
easier to criticize

>something. And you still need an editor to do =
the  document

>composition and keep track of issues, regardless =
of how you go about

>it.  




My thoughts exactly




PatC




-----BEGIN PGP SIGNATURE-----

Version: PGPfreeware 7.0.3 for non-commercial use =
<http://www.pgp.com>




iQA/AwUBPHbucjN1fXKoxmisEQIoIwCg9vfwJk2uy4n1LzmfPNsO3kJIN0YAnR/=
q

cN+1wgrBzncIgWOhvyx64EIp

=3DoAJZ

-----END PGP SIGNATURE-----





------_=_NextPart_001_01C1BC08.53ECC270--

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


From seamoby-admin@ietf.org  Fri Feb 22 21:48:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05115
	for ; Fri, 22 Feb 2002 21:48:04 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11925;
	Fri, 22 Feb 2002 21:36:07 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11900
	for ; Fri, 22 Feb 2002 21:36:05 -0500 (EST)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04869
	for ; Fri, 22 Feb 2002 21:36:01 -0500 (EST)
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1N2ZTov019468;
	Fri, 22 Feb 2002 21:35:30 -0500 (EST)
Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id VAA24397;
	Fri, 22 Feb 2002 21:35:19 -0500 (EST)
Date: Fri, 22 Feb 2002 21:35:23 -0500
To: Behcet Sarikaya 
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Message-ID: <20020223023523.GD3543@catfish>
Mail-Followup-To: Behcet Sarikaya ,
	seamoby@ietf.org
References: <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020220182424.GE3759@catfish> <3C751D75.40907@alcatel.com> <20020221175437.GB2971@catfish> <3C75851D.2060706@alcatel.com> <20020222001118.GB3148@catfish> <3C768B32.1080605@alcatel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: <3C768B32.1080605@alcatel.com>
User-Agent: Mutt/1.3.27i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 35
X-Virus-Scanned: by AMaViS-perl11-milter
 (http://amavis.org/)
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

On Fri, Feb 22, 2002 at 12:17:22PM -0600, Behcet Sarikaya wrote:
> Hi Yoshi,
> It is one thing to say the signaling messages sent over UDP, it is
> another thing to say LA-DMHA is an application layer protocol which runs
> over UDP.
> On page 5 of draft-ohba, the first sentence states LA-DMHA is an
> application layer protocol which runs over UDP.
> Of course in MIPv6 they could have defined BU/BAck as UDP messages, I
> think that they wanted to have the whole operation including signaling
> to be independent of higher layers.
> Main paging functionalities such as packet capturing (not only for one
> specific application but any application running at the host) and paging
> operations are IP version specific.
> For example paging areas and related interactions utilize multicasting
> which is different in IPv4 and in IPv6.
> For example packet capturing and forwarding are also version dependent.
> 
> So just because we can define the signaling using UDP does not render
> the protocol an application layer protocol. IP Paging with its
> functionalities so basic to all applications running on a host can not
> simply be application layer protocol.
> 
> IP paging can not also be defined as a transport layer protocol because
> it is not a new transport mechanism. L4 protocols such as UDP, TCP and
> SCTP define specific transport mechanisms. That's why they are transport
> layer protocols.
> 
> Hope you agree with the above.

Not yet.  I have a counter example.  Realm-Specific IP (RFC3103),
which is a NAT technology, defines an application layer protocol for
controlling a NAT box, while actual data packet transfer through the
NAT box is version dependent.

Yoshihiro Ohba

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


From seamoby-admin@ietf.org  Fri Feb 22 21:58:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05174
	for ; Fri, 22 Feb 2002 21:58:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12247;
	Fri, 22 Feb 2002 21:47:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12216
	for ; Fri, 22 Feb 2002 21:47:17 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05107
	for ; Fri, 22 Feb 2002 21:47:13 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id <1QP7SAS6>; Fri, 22 Feb 2002 18:46:45 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Yoshihiro Ohba'" ,
        Behcet Sarikaya
	 
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol
	 Issues
Date: Fri, 22 Feb 2002 18:46:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BC14.549F2C10"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

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_01C1BC14.549F2C10
Content-Type: text/plain

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> Hope you agree with the above.
>
>Not yet.  I have a counter example.  Realm-Specific IP (RFC3103),
>which is a NAT technology, defines  an application layer protocol
>for controlling a NAT box, while actual data packet transfer through
>the  NAT box is version dependent.

RFC 3103 is an experimental protocol. Whether or not it sees the
light of day is unknown. Further, why are we worried about supporting
NAT?

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use 

iQA/AwUBPHcCkzN1fXKoxmisEQL7LACgnUrBt4amoj9+xkm5pBtP3opVFT0AoOob
Y9ZVkCIWwXX2X3qk0AsnWq19
=3AiD
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BC14.549F2C10
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Dormant Mode Location Tracking by Mobility =
Protocol Issues




 

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1




>> Hope you agree with the above.

>

>Not yet.  I have a counter example.  =
Realm-Specific IP (RFC3103),

>which is a NAT technology, defines  an =
application layer protocol

>for controlling a NAT box, while actual data =
packet transfer through

>the  NAT box is version dependent.




RFC 3103 is an experimental protocol. Whether or not =
it sees the

light of day is unknown. Further, why are we worried =
about supporting

NAT?




PatC




-----BEGIN PGP SIGNATURE-----

Version: PGPfreeware 7.0.3 for non-commercial use =
<http://www.pgp.com>




iQA/AwUBPHcCkzN1fXKoxmisEQL7LACgnUrBt4amoj9+xkm5pBtP3opVFT0AoOo=
b

Y9ZVkCIWwXX2X3qk0AsnWq19

=3D3AiD

-----END PGP SIGNATURE-----





------_=_NextPart_001_01C1BC14.549F2C10--

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


From seamoby-admin@ietf.org  Fri Feb 22 22:30:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05666
	for ; Fri, 22 Feb 2002 22:30:37 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13372;
	Fri, 22 Feb 2002 22:19:47 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13344
	for ; Fri, 22 Feb 2002 22:19:45 -0500 (EST)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05293
	for ; Fri, 22 Feb 2002 22:19:41 -0500 (EST)
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1N3Ibov021148;
	Fri, 22 Feb 2002 22:18:37 -0500 (EST)
Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id WAA24468;
	Fri, 22 Feb 2002 22:18:31 -0500 (EST)
Date: Fri, 22 Feb 2002 22:18:36 -0500
To: "Pat R. Calhoun" 
Cc: "'Yoshihiro Ohba'" ,
        Behcet Sarikaya , seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Message-ID: <20020223031836.GA4571@catfish>
Mail-Followup-To: "Pat R. Calhoun" ,
	'Yoshihiro Ohba' ,
	Behcet Sarikaya , seamoby@ietf.org
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.3.27i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 32
X-Virus-Scanned: by AMaViS-perl11-milter
 (http://amavis.org/)
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

This is just for showing an example of a protocol that does not 
have separate specficications for IPv4 and IPv6.  
There is no other intention.  

Yoshihiro Ohba


On Fri, Feb 22, 2002 at 06:46:44PM -0800, Pat R. Calhoun wrote:
>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> >> Hope you agree with the above.
> >
> >Not yet.  I have a counter example.  Realm-Specific IP (RFC3103),
> >which is a NAT technology, defines  an application layer protocol
> >for controlling a NAT box, while actual data packet transfer through
> >the  NAT box is version dependent.
> 
> RFC 3103 is an experimental protocol. Whether or not it sees the
> light of day is unknown. Further, why are we worried about supporting
> NAT?
> 
> PatC
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use 
> 
> iQA/AwUBPHcCkzN1fXKoxmisEQL7LACgnUrBt4amoj9+xkm5pBtP3opVFT0AoOob
> Y9ZVkCIWwXX2X3qk0AsnWq19
> =3AiD
> -----END PGP SIGNATURE-----

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


From seamoby-admin@ietf.org  Fri Feb 22 23:17:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07088
	for ; Fri, 22 Feb 2002 23:17:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15407;
	Fri, 22 Feb 2002 23:04:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15380
	for ; Fri, 22 Feb 2002 23:04:10 -0500 (EST)
Received: from hotmail.com (f203.law9.hotmail.com [64.4.9.203])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06961
	for ; Fri, 22 Feb 2002 23:04:05 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 22 Feb 2002 20:03:38 -0800
Received: from 63.214.111.92 by lw9fd.law9.hotmail.msn.com with HTTP;
	Sat, 23 Feb 2002 04:03:34 GMT
X-Originating-IP: [63.214.111.92]
From: "Govind Krishnamurthi" 
To: Madjid.Nakhjiri@motorola.com, seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments
Date: Fri, 22 Feb 2002 23:03:34 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 23 Feb 2002 04:03:38.0443 (UTC) FILETIME=[128EA1B0:01C1BC1F]
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

Madjid,
Thanks for your comments. My responses are embedded.
Regards,
-Govind.

>Don't know if inter-domain is included in the discussion,
>but I am guessing since you mentioned multiple access technologies
>and multiple mobility management mechanism, I am guessing that
>multi-admin domain is in scope: in that case, you would have several
>issues
>

------> Yes, we do include inter-domain in the requirements.
Requirement 3.6, talks about this. As for  now support for
inter-domain CAR discovery is a SHOULD and not a MUST.
Do you feel that support for inter-technology as a MUST might imply
this requirement to be a MUST too?


>1-I didn't see any security requirements, it depends on how
>much of the policy and capability information can be shared
>with the MN, one example is the location and info of all the
>network management units behind the ARs, another is the network
>topology information.
>

-----> Requirement 3.4 states that capabilities MUST be transferred in a
secure fashion. If I understood you right, are there  special security 
requirements for CAR discovery w.r.t to different domains except the ones we 
have to deal with establishing an SA between two ARs in different domains. 
If you feel any particular security requirements text needs to be added, 
please post it.


>2-since CAR is carrying capability information (I am guessing
>this would also mean availibility of resources) then signaling
>of network policies might be an issue. I did not see any info
>on policy.

-----> You are right that policy information may be a capability that needs 
to be transferred. The requirements draft does not define the capabilities
or their formats (yet). It has been left as TBD. But there hasn't much 
discussion done on this topic. Do you feel that you would need special 
signalling for network policies as capabilities? Or for that matter
any other capability?




_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


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


From seamoby-admin@ietf.org  Sat Feb 23 11:33:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21466
	for ; Sat, 23 Feb 2002 11:33:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19327;
	Sat, 23 Feb 2002 11:19:20 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19296
	for ; Sat, 23 Feb 2002 11:19:18 -0500 (EST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21351
	for ; Sat, 23 Feb 2002 11:19:15 -0500 (EST)
Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114])
	by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g1NGIJd17546
	for ; Sat, 23 Feb 2002 17:18:19 +0100 (MET)
Message-ID: <3C77C195.97CC5F3C@inrialpes.fr>
Date: Sat, 23 Feb 2002 17:21:41 +0100
From: Pars MUTAF 
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: seamoby@ietf.org
References: <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020219171914.GA716@catfish> <012101c1b96c$ad8bc770$7e6015ac@T23KEMPF> <20020219191057.GB716@catfish> <002a01c1b9ce$e977f940$1b6015ac@T23KEMPF> <20020220145411.GB3759@catfish> <014301c1ba88$48f021e0$2c6015ac@T23KEMPF> <20020221185313.GD2971@catfish> <3C762EA9.67FC60EA@ccrle.nec.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] draft on paging threats
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit


Hello,

We (myself and Claude Castelluccia) have submitted a detailed
threat analysis of using paging in the Internet. The abstract is
below.

Interested people can see that document by clicking on the
following link:

http://www.inrialpes.fr/planete/people/mutaf/draft-mutaf-paging-threats-00.txt

If you have time, we are especially looking for your precious
comments on the "malicious paging signaling" attack
which exploits legitimate dormant hosts (Section 4.1).
This is serious, because "paging" which is intended for
optimizing bandwidth use, may become a bandwidth threat.
IP layer solutions may be necessary. This is, perhaps, one more
motivation for IP paging.

The questionable issues were whether the attack is feasible and
the DoS gain of paging in the Internet. This is what we tried to
analyze.

Thank you in advance.

Best regards,

Pars Mutaf



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

                                 IP Paging Threat Analysis

Abstract

   This document is an analysis of threats that arise from using
   link layer paging technologies or IP paging in the Internet
   where denial-of-service attacks are common and easy. These
   problems fall in the scope of IP paging, since link layer paging
   technologies do not have provisions for repelling such threats
   and the source of an attack may be anywhere in the Internet. In
   addition, vulnerabilities that may be added by IP paging are
   also discussed.




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


From seamoby-admin@ietf.org  Mon Feb 25 08:50:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10011
	for ; Mon, 25 Feb 2002 08:50:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20001;
	Mon, 25 Feb 2002 08:36:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19972
	for ; Mon, 25 Feb 2002 08:36:54 -0500 (EST)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09488
	for ; Mon, 25 Feb 2002 08:36:50 -0500 (EST)
From: Dirk.Trossen@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PDawZ05961
	for ; Mon, 25 Feb 2002 15:36:58 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 25 Feb 2002 15:36:48 +0200
Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 25 Feb 2002 15:36:48 +0200
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 25 Feb 2002 07:36:46 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments
Date: Mon, 25 Feb 2002 08:36:45 -0500
Message-ID: 
Thread-Topic: [Seamoby] CAR Discovery Requirements ... Call for Comments
Thread-Index: AcG79WzuW0Pmz/O1Ty+fw1MRhErz+ACCuEtQ
To: 
Cc: 
X-OriginalArrivalTime: 25 Feb 2002 13:36:46.0276 (UTC) FILETIME=[78210840:01C1BE01]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA19973
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 8bit

Hi Madjid,

Thanks for your comments, see my comments inline.

> 1-I didn't see any security requirements, it depends on how
> much of the policy and capability information can be shared
> with the MN, one example is the location and info of all the 
> network management units behind the ARs, another is the network
> topology information.

I don't quite understand what you're exactly after. The cap. information 
as such is to be tranfered in a secure manner which is included in the 
requirements. The question whether it makes sense to share said information 
with an MN is a different discussion. It is up to the AR (as a member
of a particular domain) to share information. If the AR is revealing 
such sensitive information, it is not the problem of CAR discovery,
apart from the mere transfer aspect.

> 
> 2-since CAR is carrying capability information (I am guessing
> this would also mean availibility of resources) then signaling
> of network policies might be an issue. I did not see any info
> on policy.

CAR discovery is supposed to cover capability information exchange.
However, it is not within the scope of CAR WHICH information eventually
will be transfered. But in the problem statement, exchange of policy
information is mentioned as an example what could be exchanged in such
capability transfer. I don't think that we have to put this again in
the requirements draft.

Best Regards,



Dirk

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


From seamoby-admin@ietf.org  Mon Feb 25 10:46:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14439
	for ; Mon, 25 Feb 2002 10:46:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26857;
	Mon, 25 Feb 2002 10:33:20 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26829
	for ; Mon, 25 Feb 2002 10:33:17 -0500 (EST)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13974
	for ; Mon, 25 Feb 2002 10:33:11 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1PFWiq27214
	for ; Mon, 25 Feb 2002 09:32:44 -0600 (CST)
Message-ID: <3C7A58FE.3060604@alcatel.com>
Date: Mon, 25 Feb 2002 09:32:14 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF66D@daebe001.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Dear all,
  Several mails have been sent over the weekend I'll try to give my 
views in one mail.
Regarding Srinivas' email, my understanding is that he is against 
Alternative 1 (one size fits all solution) and he is for the Alternative 
2. In that he is suggesting that we concentrate on Requirement 4.8 
rather than 4.7. As for the drafts, he seems to be inclined to home 
agent based architectures which is demonstrated in draft-renker. This is 
an architectural choice, I think that his choice of alternatives is clear.
  Besides, I think that the chairs would like to choose draft/drafts as 
soon as possible and ask people to submit their 01 drafts by March 1st 
and move on. We do not have a lot of time for doing this.

Regarding Yoshi's email, I am quoting the abstract of RFC 3103:

> This document presents a protocol with which to implement Realm
>    Specific IP (RSIP).  The protocol defined herein allows negotiation
>    of resources between an RSIP host and gateway, so that the host can
>    lease some of the gateway's addressing parameters in order to
>    establish a global network presence.  This protocol is designed to
>    operate on the application layer and to use its own TCP or UDP port.
>    In particular, the protocol allows a gateway to allocate addressing
>    and control parameters to a host such that a flow policy can be
>    enforced at the gateway.

Yoshi, I think that the functionalities summarized above of RSIP have 
nothing to do with IP Paging. Can we define a port specific to  IP 
Paging , if yes then how does IP Paging capture all packets to the 
dormant hosts?

Added to this, please see Pars' email,

>This is serious, because "paging" which is intended for
>optimizing bandwidth use, may become a bandwidth threat.
>IP layer solutions may be necessary. This is, perhaps, one more motivation for IP paging.
>

Let us get motivated for IP Paging.

Regards,



Srinivas.Sreemanthula@nokia.com wrote:


-- 
Behcet 




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


From seamoby-admin@ietf.org  Mon Feb 25 11:59:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18553
	for ; Mon, 25 Feb 2002 11:59:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01303;
	Mon, 25 Feb 2002 11:41:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01272
	for ; Mon, 25 Feb 2002 11:41:55 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17331
	for ; Mon, 25 Feb 2002 11:41:50 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1PGeUe11661;
	Mon, 25 Feb 2002 08:40:30 -0800 (PST)
Message-ID: <004b01c1be1a$f31d10c0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Pat R. Calhoun" ,
        "'Yoshihiro Ohba'" ,
        "Behcet Sarikaya" 
Cc: 
References: 
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Date: Mon, 25 Feb 2002 08:38:54 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Pat,

> >Not yet.  I have a counter example.  Realm-Specific IP (RFC3103),
> >which is a NAT technology, defines  an application layer protocol
> >for controlling a NAT box, while actual data packet transfer through
> >the  NAT box is version dependent.
>
> RFC 3103 is an experimental protocol. Whether or not it sees the
> light of day is unknown. Further, why are we worried about supporting
> NAT?
>

I believe that Yoshi was saying that RSIP is an example of a protocol
where the same protocol can run over both IPv4 and IPv6. If paging
could do this too, we would not need two version of the paging protocol.
I don't believe he was advocating supporting NAT.

W.r.t the point that came up in the original note about MIPv6 using
IP headers for BU/BAck, it is worthwhile investigating, but there
are some fairly severe implementation difficulties with using header
options.
For example, the HUT Linux implementation of MIPv6 does not
give application programs access to the BU/BAck information,
it is only accessable to the kernel. Erik Nordmark wrote a draft
a while back advocating getting rid of header options in MIPv6
for the Home Address Option and BU/BAck and instead using
Deering-Zill tunnels. Due to the maturity of MIPv6 implementations,
this is not possible, but his technical arguments were good, so
I think we should probably have equal or better technical arguments
if we want to use header options for paging.

            jak


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


From seamoby-admin@ietf.org  Mon Feb 25 13:06:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22271
	for ; Mon, 25 Feb 2002 13:06:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06707;
	Mon, 25 Feb 2002 12:52:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06678
	for ; Mon, 25 Feb 2002 12:52:10 -0500 (EST)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21785
	for ; Mon, 25 Feb 2002 12:52:07 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1PHpcX08079
	for ; Mon, 25 Feb 2002 11:51:38 -0600 (CST)
Message-ID: <3C7A798D.6030403@alcatel.com>
Date: Mon, 25 Feb 2002 11:51:09 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References:  <004b01c1be1a$f31d10c0$7e6015ac@T23KEMPF>
Content-Type: multipart/alternative;
 boundary="------------010908010906040105020602"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------010908010906040105020602
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Jim,
  An IP level IP Paging protocol must be implemented as a kernel mode 
program like HUT Mipv6 implementation (I think now it is called MIPL). 
Sometimes user level implementations are also tried.
  In fact about a year ago we had tried to prototype an earlier version 
of draft-sarikaya extending MIPL. The (undergraduate) students had 
failed because MIPL at that time was not allowing sub-options to be 
defined with binding updates.
  MIPv4/v6 based IP Paging can easily be implemented extending present 
implementations, this was the conclusion of our project. In fact there 
are other prototyping efforts documented in literature.

  Hope this helps,

James Kempf wrote:

>Pat,
>
>>>Not yet.  I have a counter example.  Realm-Specific IP (RFC3103),
>>>which is a NAT technology, defines  an application layer protocol
>>>for controlling a NAT box, while actual data packet transfer through
>>>the  NAT box is version dependent.
>>>
>>RFC 3103 is an experimental protocol. Whether or not it sees the
>>light of day is unknown. Further, why are we worried about supporting
>>NAT?
>>
>
>I believe that Yoshi was saying that RSIP is an example of a protocol
>where the same protocol can run over both IPv4 and IPv6. If paging
>could do this too, we would not need two version of the paging protocol.
>I don't believe he was advocating supporting NAT.
>
>W.r.t the point that came up in the original note about MIPv6 using
>IP headers for BU/BAck, it is worthwhile investigating, but there
>are some fairly severe implementation difficulties with using header
>options.
>For example, the HUT Linux implementation of MIPv6 does not
>give application programs access to the BU/BAck information,
>it is only accessable to the kernel. Erik Nordmark wrote a draft
>a while back advocating getting rid of header options in MIPv6
>for the Home Address Option and BU/BAck and instead using
>Deering-Zill tunnels. Due to the maturity of MIPv6 implementations,
>this is not possible, but his technical arguments were good, so
>I think we should probably have equal or better technical arguments
>if we want to use header options for paging.
>
>            jak
>
behcet

>
>

--------------010908010906040105020602
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Jim,

  An IP level IP Paging protocol must be implemented as a kernel mode program
like HUT Mipv6 implementation (I think now it is called MIPL). Sometimes
user level implementations are also tried.

  In fact about a year ago we had tried to prototype an earlier version of
draft-sarikaya extending MIPL. The (undergraduate) students had failed because
MIPL at that time was not allowing sub-options to be defined with binding
updates. 

  MIPv4/v6 based IP Paging can easily be implemented extending present implementations,
this was the conclusion of our project. In fact there are other prototyping
efforts documented in literature.



  Hope this helps,



James Kempf wrote:



  
Pat,


  

    

      
Not yet.  I have a counter example.  Realm-Specific IP (RFC3103),
which is a NAT technology, defines  an application layer protocol
for controlling a NAT box, while actual data packet transfer through
the  NAT box is version dependent.

      

      
RFC 3103 is an experimental protocol. Whether or not it sees the
light of day is unknown. Further, why are we worried about supporting
NAT?


      

      

I believe that Yoshi was saying that RSIP is an example of a protocol
where the same protocol can run over both IPv4 and IPv6. If paging
could do this too, we would not need two version of the paging protocol.
I don't believe he was advocating supporting NAT.

W.r.t the point that came up in the original note about MIPv6 using
IP headers for BU/BAck, it is worthwhile investigating, but there
are some fairly severe implementation difficulties with using header
options.
For example, the HUT Linux implementation of MIPv6 does not
give application programs access to the BU/BAck information,
it is only accessable to the kernel. Erik Nordmark wrote a draft
a while back advocating getting rid of header options in MIPv6
for the Home Address Option and BU/BAck and instead using
Deering-Zill tunnels. Due to the maturity of MIPv6 implementations,
this is not possible, but his technical arguments were good, so
I think we should probably have equal or better technical arguments
if we want to use header options for paging.

            jak


      

behcet

      

        


        

        

          


          

          
          

--------------010908010906040105020602--


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


From seamoby-admin@ietf.org  Mon Feb 25 13:33:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23721
	for ; Mon, 25 Feb 2002 13:33:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08494;
	Mon, 25 Feb 2002 13:22:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08465
	for ; Mon, 25 Feb 2002 13:22:06 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23047
	for ; Mon, 25 Feb 2002 13:22:03 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id <1QP7SBG0>; Mon, 25 Feb 2002 10:21:35 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol
	 Issues
Date: Mon, 25 Feb 2002 10:21:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BE29.4128E420"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

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_01C1BE29.4128E420
Content-Type: text/plain

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Perhaps this is pure ignorance, but I fail to see why this must be
handled in the kernel. Is there an assumption that kernel code may be
run when in power saving mode, or is there some other assumption here
that I missed?

PatC
- -----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] 
Sent: Monday, February 25, 2002 9:51 AM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues


Jim,
  An IP level IP Paging protocol must be implemented as a kernel mode
program like HUT Mipv6 implementation (I think now it is called
MIPL). Sometimes user level implementations are also tried.
  In fact about a year ago we had tried to prototype an earlier
version of draft-sarikaya extending MIPL. The (undergraduate)
students had failed because MIPL at that time was not allowing
sub-options to be defined with binding updates. 
  MIPv4/v6 based IP Paging can easily be implemented extending
present implementations, this was the conclusion of our project. In
fact there are other prototyping efforts documented in literature.

  Hope this helps,

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use 

iQA/AwUBPHqArjN1fXKoxmisEQKAHQCfbPHwIxIFhYx5cviMWo6IZIVuZEsAoKfC
g7nltZhFvku4lNWQ+YNYQ5+b
=N20v
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BE29.4128E420
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Dormant Mode Location Tracking by Mobility =
Protocol Issues




 

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1




Perhaps this is pure ignorance, but I fail to see why =
this must be

handled in the kernel. Is there an assumption that =
kernel code may be

run when in power saving mode, or is there some =
other assumption here

that I missed?




PatC

- -----Original Message-----

From: Behcet Sarikaya [mailto:behcet.sarikaya@alcat=
el.com] 

Sent: Monday, February 25, 2002 9:51 AM

To: seamoby@ietf.org

Subject: Re: [Seamoby] Dormant Mode Location =
Tracking by Mobility

Protocol Issues






Jim,

  An IP level IP Paging protocol must be =
implemented as a kernel mode

program like HUT Mipv6 implementation (I think now =
it is called

MIPL). Sometimes user level implementations are also =
tried.

  In fact about a year ago we had tried to =
prototype an earlier

version of draft-sarikaya extending MIPL. The =
(undergraduate)

students had failed because MIPL at that time was =
not allowing

sub-options to be defined with binding updates. =


  MIPv4/v6 based IP Paging can easily be =
implemented extending

present implementations, this was the conclusion of =
our project. In

fact there are other prototyping efforts documented =
in literature.




  Hope this helps,




-----BEGIN PGP SIGNATURE-----

Version: PGPfreeware 7.0.3 for non-commercial use =
<http://www.pgp.com>




iQA/AwUBPHqArjN1fXKoxmisEQKAHQCfbPHwIxIFhYx5cviMWo6IZIVuZEsAoKf=
C

g7nltZhFvku4lNWQ+YNYQ5+b

=3DN20v

-----END PGP SIGNATURE-----





------_=_NextPart_001_01C1BE29.4128E420--

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


From seamoby-admin@ietf.org  Mon Feb 25 15:05:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27777
	for ; Mon, 25 Feb 2002 15:05:30 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14130;
	Mon, 25 Feb 2002 14:53:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14093
	for ; Mon, 25 Feb 2002 14:53:35 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27256
	for ; Mon, 25 Feb 2002 14:53:30 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1PJr1e19546;
	Mon, 25 Feb 2002 11:53:01 -0800 (PST)
Message-ID: <017c01c1be35$cec69730$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Pat R. Calhoun" ,
        "'Behcet Sarikaya'" , 
References: 
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Date: Mon, 25 Feb 2002 11:51:25 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Behcet,

>   An IP level IP Paging protocol must be implemented as a kernel mode
> program like HUT Mipv6 implementation (I think now it is called
> MIPL). Sometimes user level implementations are also tried.
>   In fact about a year ago we had tried to prototype an earlier
> version of draft-sarikaya extending MIPL. The (undergraduate)
> students had failed because MIPL at that time was not allowing
> sub-options to be defined with binding updates. 
>   MIPv4/v6 based IP Paging can easily be implemented extending
> present implementations, this was the conclusion of our project. In
> fact there are other prototyping efforts documented in literature.
> 

Right, I can see where you might want to keep the implementation
in the kernel if the last hop paging message is an IP message instead
of a L2 paging message. If you don't have a specialized L2 paging
channel, you have to use multicast to send out the paging message
since the MN doesn't have valid routing at that point. Probably
in IPv6 it would be done on a link local address. To minimize
battery consumption for messages that aren't for this particular
mobile node, you would want to filter out messages that aren't
to that MN before coming out of the kernel. A context switch
would be more expensive in terms of power. If there is
L2 paging support, however, this would be done in the driver
and IP would not even see it.

I think there are other parts of paging that would
be easier to do at user level, like paging area registration
and perhaps even dormant mode registration. So I think
that there is a fairly limited, narrow set of functions that
would make sense to implement in the kernel.

I'm still not convinced that header options are the right way to
go, however. It could just as well be an ICMP message.

But these are implementation details. We are a long way away
from this. We still need to figure out what the right architecture
is.

            jak



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


From seamoby-admin@ietf.org  Mon Feb 25 15:59:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29780
	for ; Mon, 25 Feb 2002 15:59:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17364;
	Mon, 25 Feb 2002 15:47:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17334
	for ; Mon, 25 Feb 2002 15:47:09 -0500 (EST)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29338
	for ; Mon, 25 Feb 2002 15:47:07 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1PKkdX21040
	for ; Mon, 25 Feb 2002 14:46:39 -0600 (CST)
Message-ID: <3C7AA291.8090800@alcatel.com>
Date: Mon, 25 Feb 2002 14:46:09 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol	 Issues
References: 
Content-Type: multipart/alternative;
 boundary="------------060707040707090306080903"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------060707040707090306080903
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Pat,
  I was referring to public domain implementations of MIPv4/v6.
Only kernel code can be executed in  power saving mode could as well be 
correct, but it is out of my reach to make such a statement.

  If paging is defined as an extension to MIPv4/v6 and its LMM 
extensions, another advantage is to inherit the packet forwarding 
mechanisms rather than defining new mechanisms.
 
  Regards,

Pat R. Calhoun wrote:

>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Perhaps this is pure ignorance, but I fail to see why this must be
> handled in the kernel. Is there an assumption that kernel code may be
> run when in power saving mode, or is there some other assumption here
> that I missed?
>
> PatC
> - -----Original Message-----
> From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ]
> Sent: Monday, February 25, 2002 9:51 AM
> To: seamoby@ietf.org
> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
> Protocol Issues
>
>
> Jim,
>   An IP level IP Paging protocol must be implemented as a kernel mode
> program like HUT Mipv6 implementation (I think now it is called
> MIPL). Sometimes user level implementations are also tried.
>   In fact about a year ago we had tried to prototype an earlier
> version of draft-sarikaya extending MIPL. The (undergraduate)
> students had failed because MIPL at that time was not allowing
> sub-options to be defined with binding updates.
>   MIPv4/v6 based IP Paging can easily be implemented extending
> present implementations, this was the conclusion of our project. In
> fact there are other prototyping efforts documented in literature.
>
>   Hope this helps,
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com >
>
> iQA/AwUBPHqArjN1fXKoxmisEQKAHQCfbPHwIxIFhYx5cviMWo6IZIVuZEsAoKfC
> g7nltZhFvku4lNWQ+YNYQ5+b
> =N20v
> -----END PGP SIGNATURE-----
>

-- 
Behcet



--------------060707040707090306080903
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Hi Pat,

  I was referring to public domain implementations of MIPv4/v6.

Only kernel code can be executed in  power saving mode could as well be correct,
but it is out of my reach to make such a statement.



  If paging is defined as an extension to MIPv4/v6 and its LMM extensions,
another advantage is to inherit the packet forwarding mechanisms rather than
defining new mechanisms. 

 

  Regards,



Pat R. Calhoun wrote:



  
  RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol
Issues
  
 

  -----BEGIN PGP SIGNED MESSAGE-----

  Hash: SHA1

  
Perhaps this is pure ignorance, but I fail to see why
this must be

  handled in the kernel. Is there an assumption that kernel
code may be

  run when in power saving mode, or is there some other assumption
here

  that I missed?

  
PatC

  - -----Original Message-----

  From: Behcet Sarikaya [
mailto:behcet.sarikaya@alcatel.com
] 

  Sent: Monday, February 25, 2002 9:51 AM

  To: seamoby@ietf.org

  Subject: Re: [Seamoby] Dormant Mode Location Tracking by
Mobility

  Protocol Issues

  

  
Jim,

    An IP level IP Paging protocol must be implemented as
a kernel mode

  program like HUT Mipv6 implementation (I think now it is
called

  MIPL). Sometimes user level implementations are also tried.

    In fact about a year ago we had tried to prototype an
earlier

  version of draft-sarikaya extending MIPL. The (undergraduate)

  students had failed because MIPL at that time was not allowing

  sub-options to be defined with binding updates. 

    MIPv4/v6 based IP Paging can easily be implemented extending

  present implementations, this was the conclusion of our
project. In

  fact there are other prototyping efforts documented in literature.

  
  Hope this helps,

  
-----BEGIN PGP SIGNATURE-----

  Version: PGPfreeware 7.0.3 for non-commercial use <
http://www.pgp.com
>

  
iQA/AwUBPHqArjN1fXKoxmisEQKAHQCfbPHwIxIFhYx5cviMWo6IZIVuZEsAoKfC

  g7nltZhFvku4lNWQ+YNYQ5+b

  =N20v

  -----END PGP SIGNATURE-----

  

  

  
-- 
Behcet


  

  
  

--------------060707040707090306080903--


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


From seamoby-admin@ietf.org  Mon Feb 25 17:38:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02521
	for ; Mon, 25 Feb 2002 17:38:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21836;
	Mon, 25 Feb 2002 17:22:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21806
	for ; Mon, 25 Feb 2002 17:22:48 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02044
	for ; Mon, 25 Feb 2002 17:22:44 -0500 (EST)
From: Srinivas.Sreemanthula@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PMOox02040
	for ; Mon, 25 Feb 2002 16:24:51 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 25 Feb 2002 16:22:46 -0600
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 25 Feb 2002 16:21:43 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BE4A.CDEB0252"
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 25 Feb 2002 16:21:43 -0600
Message-ID: <07EE0E021034014F99A57B032BC9C0E574FF3B@daebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
Thread-Index: AcG8CHUb740wU5FgRSSuTFzKt2tz+wCHscxQ
To: , ,
        , 
X-OriginalArrivalTime: 25 Feb 2002 22:21:43.0784 (UTC) FILETIME=[CE1B5680:01C1BE4A]
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C1BE4A.CDEB0252
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My point is not so much process related whether to combine or take one =
and add others. My intention is to put empahasis on mobility based =
solutions. From the description on why Renker was chosen, it seems 4.7 =
was given more preference.  I think WG would agree that Renker =
particularly does not have any strengths in the mobility based =
"Implicit" (Mipv6) case.  Hence the suggestion to combine them all. =20
=20
I am not hooked that combining is the only way, it is more important to =
make progress one way or another identifying the right issues.
=20
=20
=20
-----Original Message-----
From: ext Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
Sent: 22 February, 2002 7:21 PM
To: 'James Kempf'; Sreemanthula Srinivas (NRC/Dallas); =
behcet.sarikaya@alcatel.com; seamoby@ietf.org
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging =
Assessment Draft




-----BEGIN PGP SIGNED MESSAGE-----=20
Hash: SHA1=20

>> yes. But that in itself will not provide a complete solution, more=20
>> work still needs to be done.=20

>So I have some difficulty seeing how that differs from taking a base=20
>document and pulling >in pieces from other documents where working=20
>group concensus is established to change  something.=20
>=20
>As I believe has been demonstrated many times over the last couple=20
>weeks, having a base  document makes it easier to criticize=20
>something. And you still need an editor to do the  document=20
>composition and keep track of issues, regardless of how you go about=20
>it. =20

My thoughts exactly=20

PatC=20

-----BEGIN PGP SIGNATURE-----=20
Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com>=20

iQA/AwUBPHbucjN1fXKoxmisEQIoIwCg9vfwJk2uy4n1LzmfPNsO3kJIN0YAnR/q=20
cN+1wgrBzncIgWOhvyx64EIp=20
=3DoAJZ=20
-----END PGP SIGNATURE-----=20


------_=_NextPart_001_01C1BE4A.CDEB0252
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




RE: [Seamoby] Deadline Approaching: WG Last Call for Paging =
Assessment Draft




My=20
point is not so much process related whether to combine or take one and =
add=20
others. My intention is to put empahasis on mobility based solutions. =
From the=20
description on why Renker was chosen, it seems 4.7 was given more=20
preference.  I think WG would agree that Renker particularly does =
not have=20
any strengths in the mobility based "Implicit" (Mipv6) case.  Hence =
the=20
suggestion to combine them all.  


 


I am=20
not hooked that combining is the only way, it is more important to make =
progress=20
one way or another identifying the right issues.


 


 


 


-----Original Message-----
From: ext Pat R. Calhoun=20
[mailto:pcalhoun@bstormnetworks.com]
Sent: 22 February, 2002 =
7:21=20
PM
To: 'James Kempf'; Sreemanthula Srinivas (NRC/Dallas);=20
behcet.sarikaya@alcatel.com; seamoby@ietf.org
Subject: RE: =
[Seamoby]=20
Deadline Approaching: WG Last Call for Paging Assessment=20
Draft




  

-----BEGIN PGP SIGNED=20
  MESSAGE----- 
Hash: SHA1 

  
>> yes. But that in itself will not provide a =
complete=20
  solution, more 
>> work still needs to =
be=20
  done. 

  
>So I have some difficulty seeing how that =
differs from=20
  taking a base 
>document and pulling =
>in pieces=20
  from other documents where working 
>group =
concensus=20
  is established to change  something. 
>=20
  
>As I believe has been demonstrated many times =
over the=20
  last couple 
>weeks, having a base  =
document=20
  makes it easier to criticize 
>something. =
And you=20
  still need an editor to do the  document 
>composition and keep track of issues, regardless of how =
you go=20
  about 
>it.  

  
My thoughts exactly 

  
PatC 

  
-----BEGIN PGP SIGNATURE----- 
Version:=20
  PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> 

  
iQA/AwUBPHbucjN1fXKoxmisEQIoIwCg9vfwJk2uy4n1LzmfPNsO3kJIN0YAnR/q=
=20
  
cN+1wgrBzncIgWOhvyx64EIp 
=3DoAJZ=20
  
-----END PGP SIGNATURE-----=20



------_=_NextPart_001_01C1BE4A.CDEB0252--

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


From seamoby-admin@ietf.org  Mon Feb 25 17:59:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03190
	for ; Mon, 25 Feb 2002 17:59:17 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22874;
	Mon, 25 Feb 2002 17:47:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22806
	for ; Mon, 25 Feb 2002 17:47:46 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02759
	for ; Mon, 25 Feb 2002 17:47:08 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1PMkel20637;
	Mon, 25 Feb 2002 16:46:40 -0600 (CST)
Message-ID: <3C7ACD92.4040502@alcatel.com>
Date: Mon, 25 Feb 2002 17:49:38 -0600
From: Vinod Kumar Choyi 
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: James Kempf , seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF>
Content-Type: multipart/alternative;
 boundary="------------090509040300000508020702"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------090509040300000508020702
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi James,

Sorry for the delay. I went throught draft-renker...., and realized that 
in case of MIP, the HA keeps track of the PA. Each time the MN moves to 
a different paging area, it registers the PA@ with the HA. When 
local-mobility management protocols/intra-domain protocols (RegReg6 or 
HMIP or...) are implemented at the foreign network, and if there are 
multiple PAs present within a foreign domain (which is likely to be the 
case) then changing a PA would cause the sending of binding update 
messages to the HA. Intra-domain protocols were developed (even though 
not standardized yet) one of the reasons being to reduce the binding 
messages sent by the MN (apart from from other advantages). Depending 
upon the size of the PAs (if small), then the advantage of using 
HMIP/RegReg6 is reduced remarkably.
IMO, having paging information known to HA, when MN is in a foreign 
network is not such a good idea, it should be dealt with locally and the 
HA should be agnostic to paging.
The other thing about the draft is that eventhough it does talk about 
various scenarios and possible solutions it ends up looking more like 
the requirements draft with little more specifications.
I am not in favor of this draft being adopted as the base draft.

regards
vinod

James Kempf wrote:

>Behcet,
>
>>  An IP level IP Paging protocol must be implemented as a kernel mode
>>program like HUT Mipv6 implementation (I think now it is called
>>MIPL). Sometimes user level implementations are also tried.
>>  In fact about a year ago we had tried to prototype an earlier
>>version of draft-sarikaya extending MIPL. The (undergraduate)
>>students had failed because MIPL at that time was not allowing
>>sub-options to be defined with binding updates. 
>>  MIPv4/v6 based IP Paging can easily be implemented extending
>>present implementations, this was the conclusion of our project. In
>>fact there are other prototyping efforts documented in literature.
>>
>
>Right, I can see where you might want to keep the implementation
>in the kernel if the last hop paging message is an IP message instead
>of a L2 paging message. If you don't have a specialized L2 paging
>channel, you have to use multicast to send out the paging message
>since the MN doesn't have valid routing at that point. Probably
>in IPv6 it would be done on a link local address. To minimize
>battery consumption for messages that aren't for this particular
>mobile node, you would want to filter out messages that aren't
>to that MN before coming out of the kernel. A context switch
>would be more expensive in terms of power. If there is
>L2 paging support, however, this would be done in the driver
>and IP would not even see it.
>
>I think there are other parts of paging that would
>be easier to do at user level, like paging area registration
>and perhaps even dormant mode registration. So I think
>that there is a fairly limited, narrow set of functions that
>would make sense to implement in the kernel.
>
>I'm still not convinced that header options are the right way to
>go, however. It could just as well be an ICMP message.
>
>But these are implementation details. We are a long way away
>from this. We still need to figure out what the right architecture
>is.
>
>            jak
>
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>


--------------090509040300000508020702
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Hi James,



Sorry for the delay. I went throught draft-renker...., and realized that
in case of MIP, the HA keeps track of the PA. Each time the MN moves to a
different paging area, it registers the PA@ with the HA. When local-mobility
management protocols/intra-domain protocols (RegReg6 or HMIP or...) are implemented
at the foreign network, and if there are multiple PAs present within a foreign
domain (which is likely to be the case) then changing a PA would cause the
sending of binding update messages to the HA. Intra-domain protocols were
developed (even though not standardized yet) one of the reasons being to
reduce the binding messages sent by the MN (apart from from other advantages).
Depending upon the size of the PAs (if small), then the advantage of using
HMIP/RegReg6 is reduced remarkably.

IMO, having paging information known to HA, when MN is in a foreign network
is not such a good idea, it should be dealt with locally and the HA should
be agnostic to paging.

The other thing about the draft is that eventhough it does talk about various
scenarios and possible solutions it ends up looking more like the requirements
draft with little more specifications.

I am not in favor of this draft being adopted as the base draft.



regards

vinod



James Kempf wrote:



  
Behcet,


  

    
  An IP level IP Paging protocol must be implemented as a kernel mode
program like HUT Mipv6 implementation (I think now it is called
MIPL). Sometimes user level implementations are also tried.
  In fact about a year ago we had tried to prototype an earlier
version of draft-sarikaya extending MIPL. The (undergraduate)
students had failed because MIPL at that time was not allowing
sub-options to be defined with binding updates. 
  MIPv4/v6 based IP Paging can easily be implemented extending
present implementations, this was the conclusion of our project. In
fact there are other prototyping efforts documented in literature.


    

    

Right, I can see where you might want to keep the implementation
in the kernel if the last hop paging message is an IP message instead
of a L2 paging message. If you don't have a specialized L2 paging
channel, you have to use multicast to send out the paging message
since the MN doesn't have valid routing at that point. Probably
in IPv6 it would be done on a link local address. To minimize
battery consumption for messages that aren't for this particular
mobile node, you would want to filter out messages that aren't
to that MN before coming out of the kernel. A context switch
would be more expensive in terms of power. If there is
L2 paging support, however, this would be done in the driver
and IP would not even see it.

I think there are other parts of paging that would
be easier to do at user level, like paging area registration
and perhaps even dormant mode registration. So I think
that there is a f
airly limited, narrow set of functions that
would make sense to implement in the kernel.

I'm still not convinced that header options are the right way to
go, however. It could just as well be an ICMP message.

But these are implementation details. We are a long way away
from this. We still need to figure out what the right architecture
is.

            jak



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

    

    

    
    

--------------090509040300000508020702--


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


From seamoby-admin@ietf.org  Mon Feb 25 17:59:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03219
	for ; Mon, 25 Feb 2002 17:59:55 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22937;
	Mon, 25 Feb 2002 17:48:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22908
	for ; Mon, 25 Feb 2002 17:48:40 -0500 (EST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02803
	for ; Mon, 25 Feb 2002 17:48:36 -0500 (EST)
From: Srinivas.Sreemanthula@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PMmtG12129
	for ; Mon, 25 Feb 2002 16:48:55 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 25 Feb 2002 16:48:38 -0600
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 25 Feb 2002 16:47:30 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 25 Feb 2002 16:47:30 -0600
Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF670@daebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
Thread-Index: AcG+EdBHzRhIVjQESLS7t5q8KUTNpQAOQKOA
To: , 
X-OriginalArrivalTime: 25 Feb 2002 22:47:30.0879 (UTC) FILETIME=[683F4CF0:01C1BE4E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA22909
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 8bit

Bechet,
You are stretching your interpretation of my mail and presenting as my views.

1. There may be a solution that fits all. I am not against it. But who wants to use simple-ip? "Independence to mobility protocol" was a key point in decision making, as indicated in the paging-assessment draft.  Paging protocol is most likely will always be used with mobile devices, hence the successful and wide acceptance of paging protocol depends on a solution that takes more of mobility into consideration. Sacrificing this point may well make the final paging protocol not so useful, at best.

2. I am not particularly inclined for HA based solutions. My point is, while defining a mobility based paging protocol we should not take a particular LMM method (for e.g. HMIPv6) as  solution, like draft-sarikaya. But instead a generalised LMM approach. HA based solution will also be needed for non-LMM cases.

Srini

-----Original Message-----
From: ext Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: 25 February, 2002 9:32 AM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


Dear all,
  Several mails have been sent over the weekend I'll try to give my 
views in one mail.
Regarding Srinivas' email, my understanding is that he is against 
Alternative 1 (one size fits all solution) and he is for the Alternative 
2. In that he is suggesting that we concentrate on Requirement 4.8 
rather than 4.7. As for the drafts, he seems to be inclined to home 
agent based architectures which is demonstrated in draft-renker. This is 
an architectural choice, I think that his choice of alternatives is clear.
  Besides, I think that the chairs would like to choose draft/drafts as 
soon as possible and ask people to submit their 01 drafts by March 1st 
and move on. We do not have a lot of time for doing this.

Regarding Yoshi's email, I am quoting the abstract of RFC 3103:

> This document presents a protocol with which to implement Realm
>    Specific IP (RSIP).  The protocol defined herein allows negotiation
>    of resources between an RSIP host and gateway, so that the host can
>    lease some of the gateway's addressing parameters in order to
>    establish a global network presence.  This protocol is designed to
>    operate on the application layer and to use its own TCP or UDP port.
>    In particular, the protocol allows a gateway to allocate addressing
>    and control parameters to a host such that a flow policy can be
>    enforced at the gateway.

Yoshi, I think that the functionalities summarized above of RSIP have 
nothing to do with IP Paging. Can we define a port specific to  IP 
Paging , if yes then how does IP Paging capture all packets to the 
dormant hosts?

Added to this, please see Pars' email,

>This is serious, because "paging" which is intended for
>optimizing bandwidth use, may become a bandwidth threat.
>IP layer solutions may be necessary. This is, perhaps, one more motivation for IP paging.
>

Let us get motivated for IP Paging.

Regards,



Srinivas.Sreemanthula@nokia.com wrote:


-- 
Behcet 




_______________________________________________
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 Feb 25 18:21:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03730
	for ; Mon, 25 Feb 2002 18:21:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23978;
	Mon, 25 Feb 2002 18:08:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23950
	for ; Mon, 25 Feb 2002 18:08:44 -0500 (EST)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03387
	for ; Mon, 25 Feb 2002 18:08:39 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1PN8Bq00756;
	Mon, 25 Feb 2002 17:08:11 -0600 (CST)
Message-ID: <3C7AC3BD.6050308@alcatel.com>
Date: Mon, 25 Feb 2002 17:07:41 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Srinivas.Sreemanthula@nokia.com
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF670@daebe001.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Hi Srinivas,
  My comments in line.
Srinivas.Sreemanthula@nokia.com wrote:

>Bechet,
>You are stretching your interpretation of my mail and presenting as my views.
>
Apologies if so.

>
>1. There may be a solution that fits all. I am not against it. But who wants to use simple-ip? "Independence to mobility protocol" was a key point in decision making, as indicated in the paging-assessment draft.  Paging protocol is most likely will always be used with mobile devices, hence the successful and wide acceptance of paging protocol depends on a solution that takes more of mobility into consideration. Sacrificing this point may well make the final paging protocol not so useful, at best.
>
Agreed. As a matter of fact this was what I argued during requirements 
draft development phase, I was against Requirement 4.7. I am sure Jim, 
Yoshi and other colleagues will remember this. By having both 4.7 and 
4.8 as requirements confused people in thinking that one size fits all 
solutions can be developed.

>
>2. I am not particularly inclined for HA based solutions. My point is, while defining a mobility based paging protocol we should not take a particular LMM method (for e.g. HMIPv6) as  solution, like draft-sarikaya. But instead a generalised LMM approach. HA based solution will also be needed for non-LMM cases.
>
May I disagree on this? LMM is not Seamoby protocol. Alternative 2 is 
stating clearly that we follow the developments in Mobile IP WG and 
align Seamoby paging protocol with the LMM of choice in MIP WG. This 
creates a dependency. We already have a dependency by using MIP. What is 
wrong with another one?

>
>Srini
>
Regards,

--bechet




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


From seamoby-admin@ietf.org  Mon Feb 25 18:23:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03796
	for ; Mon, 25 Feb 2002 18:23:01 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24093;
	Mon, 25 Feb 2002 18:11:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24066
	for ; Mon, 25 Feb 2002 18:11:36 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03442
	for ; Mon, 25 Feb 2002 18:11:32 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1PNB4l26695;
	Mon, 25 Feb 2002 17:11:04 -0600 (CST)
Message-ID: <3C7AD346.2070200@alcatel.com>
Date: Mon, 25 Feb 2002 18:13:58 -0600
From: Vinod Kumar Choyi 
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Srinivas.Sreemanthula@nokia.com
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF670@daebe001.NOE.Nokia.com>
Content-Type: multipart/alternative;
 boundary="------------050102050007040404050003"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------050102050007040404050003
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Srinivas,

Mobile devices  (that do not have any home or do not use MIP)could also 
use just Simple IP, but I agree with you that the emphasis should be 
more on mobility.

regards
vinod

Srinivas.Sreemanthula@nokia.com wrote:

>Bechet,
>You are stretching your interpretation of my mail and presenting as my views.
>
>1. There may be a solution that fits all. I am not against it. But who wants to use simple-ip? "Independence to mobility protocol" was a key point in decision making, as indicated in the paging-assessment draft.  Paging protocol is most likely will always be used with mobile devices, hence the successful and wide acceptance of paging protocol depends on a solution that takes more of mobility into consideration. Sacrificing this point may well make the final paging protocol not so useful, at best.
>
>2. I am not particularly inclined for HA based solutions. My point is, while defining a mobility based paging protocol we should not take a particular LMM method (for e.g. HMIPv6) as  solution, like draft-sarikaya. But instead a generalised LMM approach. HA based solution will also be needed for non-LMM cases.
>
>Srini
>
>-----Original Message-----
>From: ext Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
>Sent: 25 February, 2002 9:32 AM
>To: seamoby@ietf.org
>Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
>Assessment Draft
>
>
>Dear all,
>  Several mails have been sent over the weekend I'll try to give my 
>views in one mail.
>Regarding Srinivas' email, my understanding is that he is against 
>Alternative 1 (one size fits all solution) and he is for the Alternative 
>2. In that he is suggesting that we concentrate on Requirement 4.8 
>rather than 4.7. As for the drafts, he seems to be inclined to home 
>agent based architectures which is demonstrated in draft-renker. This is 
>an architectural choice, I think that his choice of alternatives is clear.
>  Besides, I think that the chairs would like to choose draft/drafts as 
>soon as possible and ask people to submit their 01 drafts by March 1st 
>and move on. We do not have a lot of time for doing this.
>
>Regarding Yoshi's email, I am quoting the abstract of RFC 3103:
>
>>This document presents a protocol with which to implement Realm
>>   Specific IP (RSIP).  The protocol defined herein allows negotiation
>>   of resources between an RSIP host and gateway, so that the host can
>>   lease some of the gateway's addressing parameters in order to
>>   establish a global network presence.  This protocol is designed to
>>   operate on the application layer and to use its own TCP or UDP port.
>>   In particular, the protocol allows a gateway to allocate addressing
>>   and control parameters to a host such that a flow policy can be
>>   enforced at the gateway.
>>
>
>Yoshi, I think that the functionalities summarized above of RSIP have 
>nothing to do with IP Paging. Can we define a port specific to  IP 
>Paging , if yes then how does IP Paging capture all packets to the 
>dormant hosts?
>
>Added to this, please see Pars' email,
>
>>This is serious, because "paging" which is intended for
>>optimizing bandwidth use, may become a bandwidth threat.
>>IP layer solutions may be necessary. This is, perhaps, one more motivation for IP paging.
>>
>
>Let us get motivated for IP Paging.
>
>Regards,
>
>
>
>Srinivas.Sreemanthula@nokia.com wrote:
>
>


--------------050102050007040404050003
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Srinivas,



Mobile devices  (that do not have any home or do not use MIP)could also use
just Simple IP, but I agree with you that the emphasis should be more on
mobility.



regards

vinod



Srinivas.Sreemanthula@nokia.com wrote:



  
Bechet,
You are stretching your interpretation of my mail and presenting as my views.

1. There may be a solution that fits all. I am not against it. But who wants to use simple-ip? "Independence to mobility protocol" was a key point in decision making, as indicated in the paging-assessment draft.  Paging protocol is most likely will always be used with mobile devices, hence the successful and wide acceptance of paging protocol depends on a solution that takes more of mobility into consideration. Sacrificing this point may well make the final paging protocol not so useful, at best.

2. I am not particularly inclined for HA based solutions. My point is, while defining a mobility based paging protocol we should not take a particular LMM method (for e.g. HMIPv6) as  solution, like draft-sarikaya. But instead a generalised LMM approach. HA based solution will also be needed for non-LMM cases.

Srini

-----Original Message-----
From: e
xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: 25 February, 2002 9:32 AM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


Dear all,
  Several mails have been sent over the weekend I'll try to give my 
views in one mail.
Regarding Srinivas' email, my understanding is that he is against 
Alternative 1 (one size fits all solution) and he is for the Alternative 
2. In that he is suggesting that we concentrate on Requirement 4.8 
rather than 4.7. As for the drafts, he seems to be inclined to home 
agent based architectures which is demonstrated in draft-renker. This is 
an architectural choice, I think that his choice of alternatives is clear.
  Besides, I think that the chairs would like to choose draft/drafts a
s 
soon as possible and ask people to submit their 01 drafts by March 1st 
and move on. We do not have a lot of time for doing this.

Regarding Yoshi's email, I am quoting the abstract of RFC 3103:


  

    
This document presents a protocol with which to implement Realm
   Specific IP (RSIP).  The protocol defined herein allows negotiation
   of resources between an RSIP host and gateway, so that the host can
   lease some of the gateway's addressing parameters in order to
   establish a global network presence.  This protocol is designed to
   operate on the application layer and to use its own TCP or UDP port.
   In particular, the protocol allows a gateway to allocate addressing
   and control parameters to a host such that a flow policy can be
   enforced at the gateway.

    

    

Yoshi, I think that the functionalities summarized above of RSIP have 
nothing to do with IP Paging. Can we define a port specific to  IP 
Paging , if yes then how does IP Paging capture all packets to the 
dormant hosts?

Added to this, please see Pars' email,


    

      
This is serious, because "paging" which is intended for
optimizing bandwidth use, may become a bandwidth threat.
IP layer solutions may be necessary. This is, perhaps, one more motivation for IP paging.


      

      

Let us get motivated for IP Paging.

Regards,



Srinivas.Sreemanthula@nokia.com wrote:



      

      

      
      

--------------050102050007040404050003--


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


From seamoby-admin@ietf.org  Mon Feb 25 18:30:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03996
	for ; Mon, 25 Feb 2002 18:30:36 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24332;
	Mon, 25 Feb 2002 18:19:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24300
	for ; Mon, 25 Feb 2002 18:19:09 -0500 (EST)
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03627
	for ; Mon, 25 Feb 2002 18:19:04 -0500 (EST)
From: Srinivas.Sreemanthula@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PNJei21060
	for ; Tue, 26 Feb 2002 01:19:40 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 26 Feb 2002 01:19:06 +0200
Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 26 Feb 2002 01:19:06 +0200
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 25 Feb 2002 17:18:32 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 25 Feb 2002 17:18:31 -0600
Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF672@daebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
Thread-Index: AcG+UU7Pzhdf04i1TzqYwgfc4uLMEgAACP9A
To: 
Cc: 
X-OriginalArrivalTime: 25 Feb 2002 23:18:32.0484 (UTC) FILETIME=[BDD9AE40:01C1BE52]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA24301
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 8bit


>May I disagree on this? LMM is not Seamoby protocol. Alternative 2 is 
>stating clearly that we follow the developments in Mobile IP WG and 
>align Seamoby paging protocol with the LMM of choice in MIP WG. This 
>creates a dependency. We already have a dependency by using MIP. What is 
>wrong with another one?

I disagree. The fate of the paging protocol usability must not depend on whether (or when) a particular LMM is accepted in MIP WG or not. Instead, let's accept the dependency on mobility and limit it right there, without extending it to a particular LMM (or trying to align it to that of MIP WG). Let's develop a common solution - non-LMM based and a generalised LMM based or one that fits both.




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


From seamoby-admin@ietf.org  Mon Feb 25 18:30:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04007
	for ; Mon, 25 Feb 2002 18:30:45 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24378;
	Mon, 25 Feb 2002 18:19:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24352
	for ; Mon, 25 Feb 2002 18:19:25 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03630
	for ; Mon, 25 Feb 2002 18:19:20 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1PNIre27876;
	Mon, 25 Feb 2002 15:18:53 -0800 (PST)
Message-ID: <028001c1be52$90f07d00$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Vinod Kumar Choyi" , 
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com>
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Date: Mon, 25 Feb 2002 15:17:17 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Vinod,

> Sorry for the delay. I went throught draft-renker...., and realized
that
> in case of MIP, the HA keeps track of the PA. Each time the MN moves
to
> a different paging area, it registers the PA@ with the HA. When
> local-mobility management protocols/intra-domain protocols (RegReg6 or
> HMIP or...) are implemented at the foreign network, and if there are
> multiple PAs present within a foreign domain (which is likely to be
the
> case) then changing a PA would cause the sending of binding update
> messages to the HA.

I think this was already identified as an issue. Main issue is the
expense
of requiring the MN to come out of dormant mode, bring up its MIPv6
stack, send the BU, then go back into dormant mode. This is considerably
expensive in terms of power than what typically is the case with mobile
devices that use paging today.

So the architectural question is whether it is possible to architect the
system
such that the MN can avoid having to come completely out of dormant mode
if L2 paging support is available (of course, if there is no L2 paging
support,
then it is impossible) while at the same time requiring the mobility
protocol
(in this case MIPv6) to maintain location information even while the MN
is in dormant mode? The reason for the latter is so that there is one
protocol
whereby the MN's location state is maintained, rather than 2.

> Intra-domain protocols were developed (even though
> not standardized yet) one of the reasons being to reduce the binding
> messages sent by the MN (apart from from other advantages). Depending
> upon the size of the PAs (if small), then the advantage of using
> HMIP/RegReg6 is reduced remarkably.

HMIP/RegReg were developed for a different purpose, to minimize
signaling
during handover. If the MN is asleep, then what does it care how long
the signaling takes? I would not imagine HMIP/RegReg being involved
in dormant mode signaling.

> IMO, having paging information known to HA, when MN is in a foreign
> network is not such a good idea, it should be dealt with locally and
the
> HA should be agnostic to paging.

Why is it any different than having the HA know the CoA?

> The other thing about the draft is that eventhough it does talk about
> various scenarios and possible solutions it ends up looking more like
> the requirements draft with little more specifications.
> I am not in favor of this draft being adopted as the base draft.
>

Noted.

            jak


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


From seamoby-admin@ietf.org  Mon Feb 25 18:51:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04389
	for ; Mon, 25 Feb 2002 18:51:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25324;
	Mon, 25 Feb 2002 18:39:07 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25295
	for ; Mon, 25 Feb 2002 18:39:05 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04147
	for ; Mon, 25 Feb 2002 18:39:01 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1PNcYl01543;
	Mon, 25 Feb 2002 17:38:34 -0600 (CST)
Message-ID: <3C7AD9B6.1000504@alcatel.com>
Date: Mon, 25 Feb 2002 18:41:26 -0600
From: Vinod Kumar Choyi 
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: James Kempf 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF>
Content-Type: multipart/alternative;
 boundary="------------010906030101030802060402"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------010906030101030802060402
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

James,

I don't think you understood what I mentioned, changing of paging area 
would cause sending of BUs to HA even when MN is within the same domain. 
So if you have smaller paging areas within a domain, MN sends a BU to HA 
each time it changes an area and HMIP/RegReg were developed to reduce 
the signaling. , I am not talking about HMIP/RegReg signalling. Kindly 
read my message again.
regards
vinod

James Kempf wrote:

>Vinod,
>
>>Sorry for the delay. I went throught draft-renker...., and realized
>>
>that
>
>>in case of MIP, the HA keeps track of the PA. Each time the MN moves
>>
>to
>
>>a different paging area, it registers the PA@ with the HA. When
>>local-mobility management protocols/intra-domain protocols (RegReg6 or
>>HMIP or...) are implemented at the foreign network, and if there are
>>multiple PAs present within a foreign domain (which is likely to be
>>
>the
>
>>case) then changing a PA would cause the sending of binding update
>>messages to the HA.
>>
>
>I think this was already identified as an issue. Main issue is the
>expense
>of requiring the MN to come out of dormant mode, bring up its MIPv6
>stack, send the BU, then go back into dormant mode. This is considerably
>expensive in terms of power than what typically is the case with mobile
>devices that use paging today.
>
>So the architectural question is whether it is possible to architect the
>system
>such that the MN can avoid having to come completely out of dormant mode
>if L2 paging support is available (of course, if there is no L2 paging
>support,
>then it is impossible) while at the same time requiring the mobility
>protocol
>(in this case MIPv6) to maintain location information even while the MN
>is in dormant mode? The reason for the latter is so that there is one
>protocol
>whereby the MN's location state is maintained, rather than 2.
>
>>Intra-domain protocols were developed (even though
>>not standardized yet) one of the reasons being to reduce the binding
>>messages sent by the MN (apart from from other advantages). Depending
>>upon the size of the PAs (if small), then the advantage of using
>>HMIP/RegReg6 is reduced remarkably.
>>
>
>HMIP/RegReg were developed for a different purpose, to minimize
>signaling
>during handover. If the MN is asleep, then what does it care how long
>the signaling takes? I would not imagine HMIP/RegReg being involved
>in dormant mode signaling.
>
>>IMO, having paging information known to HA, when MN is in a foreign
>>network is not such a good idea, it should be dealt with locally and
>>
>the
>
>>HA should be agnostic to paging.
>>
>
>Why is it any different than having the HA know the CoA?
>
>>The other thing about the draft is that eventhough it does talk about
>>various scenarios and possible solutions it ends up looking more like
>>the requirements draft with little more specifications.
>>I am not in favor of this draft being adopted as the base draft.
>>
>
>Noted.
>
>            jak
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>


--------------010906030101030802060402
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





James,



I don't think you understood what I mentioned, changing of paging area would
cause sending of BUs to HA even when MN is within the same domain. So if
you have smaller paging areas within a domain, MN sends a BU to HA each time
it changes an area and HMIP/RegReg were developed to reduce the signaling.
, I am not talking about HMIP/RegReg signalling. Kindly read my message again.

regards

vinod



James Kempf wrote:



  
Vinod,


  

    
Sorry for the delay. I went throught draft-renker...., and realized

    

    
that

    

      
in case of MIP, the HA keeps track of the PA. Each time the MN moves

      

      
to

      

        
a different paging area, it registers the PA@ with the HA. When
local-mobility management protocols/intra-domain protocols (RegReg6 or
HMIP or...) are implemented at the foreign network, and if there are
multiple PAs present within a foreign domain (which is likely to be

        

        
the

        

          
case) then changing a PA would cause the sending of binding update
messages to the HA.

          

          

I think this was already identified as an issue. Main issue is the
expense
of requiring the MN to come out of dormant mode, bring up its MIPv6
stack, send the BU, then go back into dormant mode. This is considerably
expensive in terms of power than what typically is the case with mobile
devices that use paging today.

So the architectural question is whether it is possible to architect the
system
such that the MN can avoid having to come completely out of dormant mode
if L2 paging support is available (of course, if there is no L2 paging
support,
then it is impossible) while at the same time requiring the mobility
protocol
(in this case MIPv6) to maintain location information even while the MN
is in dormant mode? The reason for the latter is so that there is one
protocol
whereby the MN's location state is maintained, rather than 2.


          

            
Intra-domain protocols were developed (even though
not standardized yet) one of the reasons being to reduce the binding
messages sent by the MN (apart from from other advantages). Depending
upon the size of the PAs (if small), then the advantage of using
HMIP/RegReg6 is reduced remarkably.

            

            

HMIP/RegReg were developed for a different purpose, to minimize
signaling
during handover. If the MN is asleep, then what does it care how long
the signaling takes? I would not imagine HMIP/RegReg being involved
in dormant mode signaling.


            

              
IMO, having paging information known to HA, when MN is in a foreign
network is not such a good idea, it should be dealt with locally and

              

              
the

              

                
HA should be agnostic to paging.

                

                

Why is it any different than having the HA know the CoA?


                

                  
The other thing about the draft is that eventhough it does talk about
various scenarios and possible solutions it ends up looking more like
the requirements draft with little more specifications.
I am not in favor of this draft being adopted as the base draft.


                  

                  

Noted.

            jak


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

                  

                  

                  
                  

--------------010906030101030802060402--


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


From seamoby-admin@ietf.org  Mon Feb 25 19:03:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04589
	for ; Mon, 25 Feb 2002 19:03:38 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25694;
	Mon, 25 Feb 2002 18:52:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25625
	for ; Mon, 25 Feb 2002 18:52:12 -0500 (EST)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04401
	for ; Mon, 25 Feb 2002 18:52:07 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1PNpdq07967;
	Mon, 25 Feb 2002 17:51:39 -0600 (CST)
Message-ID: <3C7ACE0B.4040104@alcatel.com>
Date: Mon, 25 Feb 2002 17:51:39 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Srinivas.Sreemanthula@nokia.com
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF672@daebe001.NOE.Nokia.com>
Content-Type: multipart/alternative;
 boundary="------------010900040701060305070400"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------010900040701060305070400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

A solution with no LMM means HA based paging, HA based paging is not 
scalable and it is inefficient. As you admit it has to be used only when 
no LMM agents available.

   LMM for Mipv4 seems to be done-deal, the only problem is right now at 
MIP WG is LMM for Mipv6 and I am sure it will be resolved very 
fast..There is no point and I do not think MIP WG would allow trying to 
develop an alternative.
 
  Alternative 2 is a win-win for all. If agreed, it enables both MIP 
based and Simple IP based solutions to be developed. Alternative 2 
requires harmonization within each and with MIP WG. This is the right 
approach, I think.

Srinivas.Sreemanthula@nokia.com wrote:

>>May I disagree on this? LMM is not Seamoby protocol. Alternative 2 is 
>>stating clearly that we follow the developments in Mobile IP WG and 
>>align Seamoby paging protocol with the LMM of choice in MIP WG. This 
>>creates a dependency. We already have a dependency by using MIP. What is 
>>wrong with another one?
>>
>
>I disagree. The fate of the paging protocol usability must not depend on whether (or when) a particular LMM is accepted in MIP WG or not. Instead, let's accept the dependency on mobility and limit it right there, without extending it to a particular LMM (or trying to align it to that of MIP WG). Let's develop a common solution - non-LMM based and a generalised LMM based or one that fits both.
>
>
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>

-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460



--------------010900040701060305070400
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





A solution with no LMM means HA based paging, HA based paging is not scalable
and it is inefficient. As you admit it has to be used only when no LMM agents
available.



   LMM for Mipv4 seems to be done-deal, the only problem is right now at
MIP WG is LMM for Mipv6 and I am sure it will be resolved very fast..There
is no point and I do not think MIP WG would allow trying to develop an alternative.

  

  Alternative 2 is a win-win for all. If agreed, it enables both MIP based
and Simple IP based solutions to be developed. Alternative 2 requires harmonization
within each and with MIP WG. This is the right approach, I think.



Srinivas.Sreemanthula@nokia.com wrote:



  

    
May I disagree on this? LMM is not Seamoby protocol. Alternative 2 is 
stating clearly that we follow the developments in Mobile IP WG and 
align Seamoby paging protocol with the LMM of choice in MIP WG. This 
creates a dependency. We already have a dependency by using MIP. What is 
wrong with another one?

    

    

I disagree. The fate of the paging protocol usability must not depend on whether (or when) a particular LMM is accepted in MIP WG or not. Instead, let's accept the dependency on mobility and limit it right there, without extending it to a particular LMM (or trying to align it to that of MIP WG). Let's develop a common solution - non-LMM based and a generalised LMM based or one that fits both.




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

    

    

    
-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460


    

    
    

--------------010900040701060305070400--


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


From seamoby-admin@ietf.org  Mon Feb 25 19:10:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04762
	for ; Mon, 25 Feb 2002 19:10:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25912;
	Mon, 25 Feb 2002 18:58:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25881
	for ; Mon, 25 Feb 2002 18:58:56 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04516
	for ; Mon, 25 Feb 2002 18:58:51 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1PNwMe29639;
	Mon, 25 Feb 2002 15:58:22 -0800 (PST)
Message-ID: <02b501c1be58$14d271a0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" ,
        
Cc: 
References: <07EE0E021034014F99A57B032BC9C0E50FF670@daebe001.NOE.Nokia.com> <3C7AC3BD.6050308@alcatel.com>
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
Date: Mon, 25 Feb 2002 15:56:45 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Srini/Behcet,

This sounds like a rehash of the requirements discussion. We have the
requirements, and we have a couple of possible approachs to meet them.
Let's move on...

            jak

----- Original Message -----
From: "Behcet Sarikaya" 
To: 
Cc: 
Sent: Monday, February 25, 2002 3:07 PM
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


> Hi Srinivas,
>   My comments in line.
> Srinivas.Sreemanthula@nokia.com wrote:
>
> >Bechet,
> >You are stretching your interpretation of my mail and presenting as
my views.
> >
> Apologies if so.
>
> >
> >1. There may be a solution that fits all. I am not against it. But
who wants to use simple-ip? "Independence to mobility protocol" was a
key point in decision making, as indicated in the paging-assessment
draft.  Paging protocol is most likely will always be used with mobile
devices, hence the successful and wide acceptance of paging protocol
depends on a solution that takes more of mobility into consideration.
Sacrificing this point may well make the final paging protocol not so
useful, at best.
> >
> Agreed. As a matter of fact this was what I argued during requirements
> draft development phase, I was against Requirement 4.7. I am sure Jim,
> Yoshi and other colleagues will remember this. By having both 4.7 and
> 4.8 as requirements confused people in thinking that one size fits all
> solutions can be developed.
>
> >
> >2. I am not particularly inclined for HA based solutions. My point
is, while defining a mobility based paging protocol we should not take a
particular LMM method (for e.g. HMIPv6) as  solution, like
draft-sarikaya. But instead a generalised LMM approach. HA based
solution will also be needed for non-LMM cases.
> >
> May I disagree on this? LMM is not Seamoby protocol. Alternative 2 is
> stating clearly that we follow the developments in Mobile IP WG and
> align Seamoby paging protocol with the LMM of choice in MIP WG. This
> creates a dependency. We already have a dependency by using MIP. What
is
> wrong with another one?
>
> >
> >Srini
> >
> Regards,
>
> --bechet
>
>
>
>
> _______________________________________________
> 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 Feb 25 19:26:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04912
	for ; Mon, 25 Feb 2002 19:26:05 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26805;
	Mon, 25 Feb 2002 19:14:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26776
	for ; Mon, 25 Feb 2002 19:14:42 -0500 (EST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04822
	for ; Mon, 25 Feb 2002 19:14:39 -0500 (EST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id RAA22477 for ; Mon, 25 Feb 2002 17:14:41 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id RAA14560 for ; Mon, 25 Feb 2002 17:14:41 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52)
	id <1LKFC6LQ>; Mon, 25 Feb 2002 18:14:41 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF59@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'Govind Krishnamurthi'" , seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments
Date: Mon, 25 Feb 2002 18:14:37 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

Govind,
Thank you for my email. I guess I was a bit sloppy in my reading. 
I guess I wanted to leave early that Friday (blame it on the Olympics :) )
 I appologize for that, comments below,

BR,
Madjid

-----Original Message-----
From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
Sent: Friday, February 22, 2002 10:04 PM
To: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments


Madjid,
Thanks for your comments. My responses are embedded.
Regards,
-Govind.

>Don't know if inter-domain is included in the discussion,
>but I am guessing since you mentioned multiple access technologies
>and multiple mobility management mechanism, I am guessing that
>multi-admin domain is in scope: in that case, you would have several
>issues
>

------> Yes, we do include inter-domain in the requirements.
Requirement 3.6, talks about this. As for  now support for
inter-domain CAR discovery is a SHOULD and not a MUST.
Do you feel that support for inter-technology as a MUST might imply
this requirement to be a MUST too?

MN>> Thank you for pointing it out. I missed that sentence. 
The implication of intertechnology on inter-domain is scenario
independent. I have a feeling, you would have a variety of cases,
both when various access radios are owned by same operator/admin
authority, and when they are not. So that is tough call, but
a SHOULD is a good interim goal to keep everybody happy:)

>1-I didn't see any security requirements, it depends on how
>much of the policy and capability information can be shared
>with the MN, one example is the location and info of all the
>network management units behind the ARs, another is the network
>topology information.
>

-----> Requirement 3.4 states that capabilities MUST be transferred in a
secure fashion. If I understood you right, are there  special security 
requirements for CAR discovery w.r.t to different domains except the ones we 
have to deal with establishing an SA between two ARs in different domains. 
If you feel any particular security requirements text needs to be added, 
please post it.

MN>> Boy, I missed that last sentence too :( 
However, in your dynamic CAR case (If I remember correctly)
 MN is handling the selection process. This means it is getting
information from ARs that it might not already have SAs with, correct?
If that is correct, especially if this information is more than
just signal strength and include sensitive network management information,
then there is a security issue, since the MN is not a trusted node
for those networks, and the MN can't have SAs with all the ARs that it
might come across? am I missing some point?



>2-since CAR is carrying capability information (I am guessing
>this would also mean availibility of resources) then signaling
>of network policies might be an issue. I did not see any info
>on policy.

-----> You are right that policy information may be a capability that needs 
to be transferred. The requirements draft does not define the capabilities
or their formats (yet). It has been left as TBD. But there hasn't much 
discussion done on this topic. Do you feel that you would need special 
signalling for network policies as capabilities? Or for that matter
any other capability?

MN>> Yes, I would think policy info is important type of 
"capability information" for QoS management, admission control
 are related, right? and admission control is an important part
of a successful handover, so possibility of a need for policy
signaling exist. We might not have to do design the signaling
here, but CAR signaling can be used as a vehicle.
UNLESS, capability is transferred by context transfer, we did have
that discussion at some point, so this might be a scope issue.

Madjid




_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

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


From seamoby-admin@ietf.org  Mon Feb 25 19:35:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05052
	for ; Mon, 25 Feb 2002 19:35:05 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27022;
	Mon, 25 Feb 2002 19:23:23 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26991
	for ; Mon, 25 Feb 2002 19:23:21 -0500 (EST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04881
	for ; Mon, 25 Feb 2002 19:23:18 -0500 (EST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id RAA14199 for ; Mon, 25 Feb 2002 17:23:20 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA22523 for ; Mon, 25 Feb 2002 17:23:20 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52)
	id ; Mon, 25 Feb 2002 18:23:20 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF5A@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'Dirk.Trossen@nokia.com'" ,
        Nakhjiri Madjid-MNAKHJI1 
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments
Date: Mon, 25 Feb 2002 18:23:19 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

Dirk,

Thanks for your email, see below.

BR,
Madjid

-----Original Message-----
From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
Sent: Monday, February 25, 2002 7:37 AM
To: Madjid Nakhjiri
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments


Hi Madjid,

Thanks for your comments, see my comments inline.

> 1-I didn't see any security requirements, it depends on how
> much of the policy and capability information can be shared
> with the MN, one example is the location and info of all the 
> network management units behind the ARs, another is the network
> topology information.

I don't quite understand what you're exactly after. The cap. information 
as such is to be tranfered in a secure manner which is included in the 
requirements. The question whether it makes sense to share said information 
with an MN is a different discussion. It is up to the AR (as a member
of a particular domain) to share information. If the AR is revealing 
such sensitive information, it is not the problem of CAR discovery,
apart from the mere transfer aspect.

Madjid>> I responded to Govind on this issue. However, to respond
to the above, my issue is, say the MN needs some information before
the handover, that the AR thinks it is too sensitive to be shared, then
the whole thing would fall apart in an inter-domain scenario??

> 
> 2-since CAR is carrying capability information (I am guessing
> this would also mean availibility of resources) then signaling
> of network policies might be an issue. I did not see any info
> on policy.

CAR discovery is supposed to cover capability information exchange.
However, it is not within the scope of CAR WHICH information eventually
will be transfered. But in the problem statement, exchange of policy
information is mentioned as an example what could be exchanged in such
capability transfer. I don't think that we have to put this again in
the requirements draft.

Madjid>> Sounds fair. However, If you need an AR-AR signaling,
you can extend Context transfer to handle capability (this
was discussed a lot last year). if you need
AR-MN signaling  you would still have the issue of AR-MN trust.  

Just a thought,

BR,

Madjid

Best Regards,



Dirk

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


From seamoby-admin@ietf.org  Mon Feb 25 19:43:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05109
	for ; Mon, 25 Feb 2002 19:43:18 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27653;
	Mon, 25 Feb 2002 19:31:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27628
	for ; Mon, 25 Feb 2002 19:31:42 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05017
	for ; Mon, 25 Feb 2002 19:31:38 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1Q0VAe01305;
	Mon, 25 Feb 2002 16:31:10 -0800 (PST)
Message-ID: <02d001c1be5c$a98970b0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Vinod Kumar Choyi" 
Cc: 
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF> <3C7AD9B6.1000504@alcatel.com>
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Date: Mon, 25 Feb 2002 16:29:33 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

I understood what you said. What I was saying is that the delay of
signaling isn't a problem when the MN is in dormant mode because there
is no user traffic waiting on the signaling to complete. I think most
proposals for LMM are to control the delay involved in handing over an
active MN, so that the MN doesn't have to wait on the rtt of a BU to the
HA and various CNs.

As for the amount of signaling, of course, the size of the paging areas
needs to be regulated so that a BU isn't getting sent every time a
dormant mode MN moves from one subnet to another. Otherwise, yes, it
would be expensive.

It sounds to me that you are in favor of a VLR-like solution, in which
paging information is maintained in the foreign network. Is that so?

            jak

----- Original Message -----
From: "Vinod Kumar Choyi" 
To: "James Kempf" 
Cc: 
Sent: Monday, February 25, 2002 4:41 PM
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues


> James,
>
> I don't think you understood what I mentioned, changing of paging area
> would cause sending of BUs to HA even when MN is within the same
domain.
> So if you have smaller paging areas within a domain, MN sends a BU to
HA
> each time it changes an area and HMIP/RegReg were developed to reduce
> the signaling. , I am not talking about HMIP/RegReg signalling. Kindly
> read my message again.
> regards
> vinod
>
> James Kempf wrote:
>
> >Vinod,
> >
> >>Sorry for the delay. I went throught draft-renker...., and realized
> >>
> >that
> >
> >>in case of MIP, the HA keeps track of the PA. Each time the MN moves
> >>
> >to
> >
> >>a different paging area, it registers the PA@ with the HA. When
> >>local-mobility management protocols/intra-domain protocols (RegReg6
or
> >>HMIP or...) are implemented at the foreign network, and if there are
> >>multiple PAs present within a foreign domain (which is likely to be
> >>
> >the
> >
> >>case) then changing a PA would cause the sending of binding update
> >>messages to the HA.
> >>
> >
> >I think this was already identified as an issue. Main issue is the
> >expense
> >of requiring the MN to come out of dormant mode, bring up its MIPv6
> >stack, send the BU, then go back into dormant mode. This is
considerably
> >expensive in terms of power than what typically is the case with
mobile
> >devices that use paging today.
> >
> >So the architectural question is whether it is possible to architect
the
> >system
> >such that the MN can avoid having to come completely out of dormant
mode
> >if L2 paging support is available (of course, if there is no L2
paging
> >support,
> >then it is impossible) while at the same time requiring the mobility
> >protocol
> >(in this case MIPv6) to maintain location information even while the
MN
> >is in dormant mode? The reason for the latter is so that there is one
> >protocol
> >whereby the MN's location state is maintained, rather than 2.
> >
> >>Intra-domain protocols were developed (even though
> >>not standardized yet) one of the reasons being to reduce the binding
> >>messages sent by the MN (apart from from other advantages).
Depending
> >>upon the size of the PAs (if small), then the advantage of using
> >>HMIP/RegReg6 is reduced remarkably.
> >>
> >
> >HMIP/RegReg were developed for a different purpose, to minimize
> >signaling
> >during handover. If the MN is asleep, then what does it care how long
> >the signaling takes? I would not imagine HMIP/RegReg being involved
> >in dormant mode signaling.
> >
> >>IMO, having paging information known to HA, when MN is in a foreign
> >>network is not such a good idea, it should be dealt with locally and
> >>
> >the
> >
> >>HA should be agnostic to paging.
> >>
> >
> >Why is it any different than having the HA know the CoA?
> >
> >>The other thing about the draft is that eventhough it does talk
about
> >>various scenarios and possible solutions it ends up looking more
like
> >>the requirements draft with little more specifications.
> >>I am not in favor of this draft being adopted as the base draft.
> >>
> >
> >Noted.
> >
> >            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


From seamoby-admin@ietf.org  Mon Feb 25 19:44:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05131
	for ; Mon, 25 Feb 2002 19:44:54 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27739;
	Mon, 25 Feb 2002 19:34:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27710
	for ; Mon, 25 Feb 2002 19:34:42 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05045
	for ; Mon, 25 Feb 2002 19:34:39 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1Q0Y8e01445;
	Mon, 25 Feb 2002 16:34:09 -0800 (PST)
Message-ID: <02fa01c1be5d$143bbda0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" ,
        
Cc: 
References: <07EE0E021034014F99A57B032BC9C0E50FF672@daebe001.NOE.Nokia.com> <3C7ACE0B.4040104@alcatel.com>
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft
Date: Mon, 25 Feb 2002 16:32:32 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit


> A solution with no LMM means HA based paging, HA based paging is not
> scalable and it is inefficient. As you admit it has to be used only
when
> no LMM agents available.
>

Why is sending a packet that initiates paging (not the paging itself) to
an
address in the foreign network from the HA more inefficient than sending
packets
to an active MN at a foreign network CoA from the HA?

                jak


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


From seamoby-admin@ietf.org  Tue Feb 26 00:07:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10609
	for ; Tue, 26 Feb 2002 00:07:37 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08436;
	Mon, 25 Feb 2002 23:56:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08406
	for ; Mon, 25 Feb 2002 23:55:59 -0500 (EST)
Received: from hotmail.com (f262.law9.hotmail.com [64.4.8.137])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10527
	for ; Mon, 25 Feb 2002 23:55:55 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 25 Feb 2002 20:55:29 -0800
Received: from 63.214.82.147 by lw9fd.law9.hotmail.msn.com with HTTP;
	Tue, 26 Feb 2002 04:55:28 GMT
X-Originating-IP: [63.214.82.147]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments
Date: Mon, 25 Feb 2002 23:55:28 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 26 Feb 2002 04:55:29.0533 (UTC) FILETIME=[D0268AD0:01C1BE81]
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

Madjid,
My comments inline. Thanks for your comments again.
Regards,
Govind.


>MN>> Thank you for pointing it out. I missed that sentence.
>The implication of intertechnology on inter-domain is scenario
>independent. I have a feeling, you would have a variety of cases,
>both when various access radios are owned by same operator/admin
>authority, and when they are not. So that is tough call, but
>a SHOULD is a good interim goal to keep everybody happy:)

------> It is a SHOULD right now.. so that settles this issue then.


>

>MN>> Boy, I missed that last sentence too :(
>However, in your dynamic CAR case (If I remember correctly)
>  MN is handling the selection process. This means it is getting
>information from ARs that it might not already have SAs with, correct?
>If that is correct, especially if this information is more than
>just signal strength and include sensitive network management information,
>then there is a security issue, since the MN is not a trusted node
>for those networks, and the MN can't have SAs with all the ARs that it
>might come across? am I missing some point?
>
>


-----> There was some confusion about what dynamic discovery means.
It was later  (in version 02.txt) defined as being done on the fly during 
the handover process(any network node/MN can do it) and anticipated implies 
that the discovery is done prior to the handover (again any network node/MN 
can do it). So I guess thatIf the MN has a security association with the 
current AR and the current AR has a
SA with the new AR then we are through, is it not? Do you see any other
problem?

>MN>> Yes, I would think policy info is important type of
>"capability information" for QoS management, admission control
>  are related, right? and admission control is an important part
>of a successful handover, so possibility of a need for policy
>signaling exist. We might not have to do design the signaling
>here, but CAR signaling can be used as a vehicle.
>UNLESS, capability is transferred by context transfer, we did have
>that discussion at some point, so this might be a scope issue.

-----> CAR discovery, I believe, occurs prior to context transfer. So it 
cannot be associated with that.


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


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


From seamoby-admin@ietf.org  Tue Feb 26 04:28:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21471
	for ; Tue, 26 Feb 2002 04:28:22 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28891;
	Tue, 26 Feb 2002 04:04:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28862
	for ; Tue, 26 Feb 2002 04:04:35 -0500 (EST)
Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21090
	for ; Tue, 26 Feb 2002 04:04:31 -0500 (EST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1Q947Q21686;
	Tue, 26 Feb 2002 10:04:07 +0100 (CET)
	(envelope-from Marco.Liebsch@ccrle.nec.de)
Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA02554;
	Tue, 26 Feb 2002 10:04:03 +0100
Message-ID: <3C7B4F83.20AE63C7@ccrle.nec.de>
Date: Tue, 26 Feb 2002 10:04:03 +0100
From: Marco Liebsch 
Organization: NEC Europe Ltd.
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Srinivas.Sreemanthula@nokia.com
CC: pcalhoun@bstormnetworks.com, kempf@docomolabs-usa.com,
        behcet.sarikaya@alcatel.com, seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment 
 Draft
References: <07EE0E021034014F99A57B032BC9C0E574FF3B@daebe001.NOE.Nokia.com>
Content-Type: multipart/alternative;
 boundary="------------04E78DF47AD470350C571326"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------04E78DF47AD470350C571326
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Srinivas,

I think this was said already, but I do not see any difference to what
has been proposed several times already. My understanding of 'combining'
in a reasonable way is to take a flexible framework and ascertain where
to integrate specific parts of the other proposals. In my opinion, this
is easier taking a concept like the renker-draft, which tries to avoid
possibly unnecessary complexity w.r.t. architecture components but
allows to extend individual functions, than starting with a very
specific and complex base. What do you think?

Marco

Srinivas.Sreemanthula@nokia.com wrote:

>  My point is not so much process related whether to combine or take
> one and add others. My intention is to put empahasis on mobility based
> solutions. >From the description on why Renker was chosen, it seems
> 4.7 was given more preference.  I think WG would agree that Renker
> particularly does not have any strengths in the mobility based
> "Implicit" (Mipv6) case.  Hence the suggestion to combine them all. I
> am not hooked that combining is the only way, it is more important to
> make progress one way or another identifying the right
> issues.-----Original Message-----
> From: ext Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
> Sent: 22 February, 2002 7:21 PM
> To: 'James Kempf'; Sreemanthula Srinivas (NRC/Dallas);
> behcet.sarikaya@alcatel.com; seamoby@ietf.org
> Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging
> Assessment Draft
>
>
>
>      -----BEGIN PGP SIGNED MESSAGE-----
>      Hash: SHA1
>
>      >> yes. But that in itself will not provide a complete
>      solution, more
>      >> work still needs to be done.
>
>      >So I have some difficulty seeing how that differs from
>      taking a base
>      >document and pulling >in pieces from other documents where
>      working
>      >group concensus is established to change  something.
>      >
>      >As I believe has been demonstrated many times over the last
>      couple
>      >weeks, having a base  document makes it easier to criticize
>
>      >something. And you still need an editor to do the  document
>
>      >composition and keep track of issues, regardless of how you
>      go about
>      >it.
>
>      My thoughts exactly
>
>      PatC
>
>      -----BEGIN PGP SIGNATURE-----
>      Version: PGPfreeware 7.0.3 for non-commercial use
>      
>
>
>      QA/AwUBPHbucjN1fXKoxmisEQIoIwCg9vfwJk2uy4n1LzmfPNsO3kJIN0YAnR/q
>
>      cN+1wgrBzncIgWOhvyx64EIp
>      =oAJZ
>      -----END PGP SIGNATURE-----
>



--------------04E78DF47AD470350C571326
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi Srinivas,

I think this was said already, but I do not see any difference to what
has been proposed several times already. My understanding of 'combining'
in a reasonable way is to take a flexible framework and ascertain where
to integrate specific parts of the other proposals. In my opinion, this
is easier taking a concept like the renker-draft, which tries to avoid
possibly unnecessary complexity w.r.t. architecture components but allows
to extend individual functions, than starting with a very specific and
complex base. What do you think?

Marco 

Srinivas.Sreemanthula@nokia.com wrote:

 My
point is not so much process related whether to combine or take one and
add others. My intention is to put empahasis on mobility based solutions.
>From the description on why Renker was chosen, it seems 4.7 was given
more preference.  I think WG would agree that Renker particularly
does not have any strengths in the mobility based "Implicit" (Mipv6) case. 
Hence the suggestion to combine them all. I
am not hooked that combining is the only way, it is more important to make
progress one way or another identifying the right issues.-----Original
Message-----

From: ext Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]

Sent: 22 February, 2002 7:21
PM

To: 'James Kempf'; Sreemanthula
Srinivas (NRC/Dallas); behcet.sarikaya@alcatel.com; seamoby@ietf.org

Subject: RE: [Seamoby] Deadline
Approaching: WG Last Call for Paging Assessment Draft

 

 

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

>> yes. But that in itself will not provide a complete
solution, more

>> work still needs to be done.

>So I have some difficulty seeing how that differs from
taking a base

>document and pulling >in pieces from other documents
where working

>group concensus is established to change  something.

>

>As I believe has been demonstrated many times over the
last couple

>weeks, having a base  document makes it easier
to criticize

>something. And you still need an editor to do the 
document

>composition and keep track of issues, regardless of
how you go about

>it.

My thoughts exactly

PatC

-----BEGIN PGP SIGNATURE-----

Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPHbucjN1fXKoxmisEQIoIwCg9vfwJk2uy4n1LzmfPNsO3kJIN0YAnR/q

cN+1wgrBzncIgWOhvyx64EIp

=oAJZ

-----END PGP SIGNATURE-----





 

--------------04E78DF47AD470350C571326--


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


From seamoby-admin@ietf.org  Tue Feb 26 04:55:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22024
	for ; Tue, 26 Feb 2002 04:55:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01047;
	Tue, 26 Feb 2002 04:42:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00977
	for ; Tue, 26 Feb 2002 04:42:22 -0500 (EST)
Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21779
	for ; Tue, 26 Feb 2002 04:42:18 -0500 (EST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1Q9fqQ23389;
	Tue, 26 Feb 2002 10:41:52 +0100 (CET)
	(envelope-from Marco.Liebsch@ccrle.nec.de)
Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA02958;
	Tue, 26 Feb 2002 10:41:48 +0100
Message-ID: <3C7B585C.8D2FEA20@ccrle.nec.de>
Date: Tue, 26 Feb 2002 10:41:48 +0100
From: Marco Liebsch 
Organization: NEC Europe Ltd.
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Vinod Kumar Choyi 
CC: James Kempf , seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com>
Content-Type: multipart/alternative;
 boundary="------------B3AB16C3C1F7B6C16184A2AD"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------B3AB16C3C1F7B6C16184A2AD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I just want to clarify what has been not understood and addressed
misleadingly more than once.

The concept described in draft-renker does 'not' push tracking function
to the HA! Again: The Paging Agent node implements a TA functionality,
taking care of paging areas the mobile terminal is roaming in. The
mobile terminal (or PA assistant functional entities in ARs) keeps the
TA updated when entering a new paging area. This does 'not' include
registration update at a mobility agent (which is the HA in case of
MIPv6). A respective Paging Agent node (there are multiple in an admin.
domain, for load sharing as well as to introduce redundancy for failover
handling) is repsonsible for more than one paging area. The registration
at the HA addresses requirement 4.8 and allows reception of paging
trigger packets at the DMA functional entity for a registered idle
mobile terminal. How should the following requirement 4.8 be interpreted
in a different way as described in draft-renker:

'... The IP paging protocol should make use of existing registration
support...'

For other mobility platforms (e.g. routing based ones), packet capturing
at distributed DMAs (which could be located close to border routers)
might be necessary, since explicit registration of a respective DMA
might be not possible.

Regards,

Marco


Vinod Kumar Choyi wrote:

> Hi James,
>
> Sorry for the delay. I went throught draft-renker...., and realized
> that in case of MIP, the HA keeps track of the PA. Each time the MN
> moves to a different paging area, it registers the PA@ with the HA.
> When local-mobility management protocols/intra-domain protocols
> (RegReg6 or HMIP or...) are implemented at the foreign network, and if
> there are multiple PAs present within a foreign domain (which is
> likely to be the case) then changing a PA would cause the sending of
> binding update messages to the HA. Intra-domain protocols were
> developed (even though not standardized yet) one of the reasons being
> to reduce the binding messages sent by the MN (apart from from other
> advantages). Depending upon the size of the PAs (if small), then the
> advantage of using HMIP/RegReg6 is reduced remarkably.
> IMO, having paging information known to HA, when MN is in a foreign
> network is not such a good idea, it should be dealt with locally and
> the HA should be agnostic to paging.
> The other thing about the draft is that eventhough it does talk about
> various scenarios and possible solutions it ends up looking more like
> the requirements draft with little more specifications.
> I am not in favor of this draft being adopted as the base draft.
>
> regards
> vinod
>
> James Kempf wrote:
>
>> Behcet,
>>
>>
>> >   An IP level IP Paging protocol must be implemented as a kernel
>> > mode
>> > program like HUT Mipv6 implementation (I think now it is called
>> > MIPL). Sometimes user level implementations are also tried.
>> >   In fact about a year ago we had tried to prototype an earlier
>> > version of draft-sarikaya extending MIPL. The (undergraduate)
>> > students had failed because MIPL at that time was not allowing
>> > sub-options to be defined with binding updates.
>> >   MIPv4/v6 based IP Paging can easily be implemented extending
>> > present implementations, this was the conclusion of our project. In
>> > fact there are other prototyping efforts documented in literature.
>> >
>> >
>> Right, I can see where you might want to keep the implementation
>> in the kernel if the last hop paging message is an IP message
>> instead
>> of a L2 paging message. If you don't have a specialized L2 paging
>> channel, you have to use multicast to send out the paging message
>> since the MN doesn't have valid routing at that point. Probably
>> in IPv6 it would be done on a link local address. To minimize
>> battery consumption for messages that aren't for this particular
>> mobile node, you would want to filter out messages that aren't
>> to that MN before coming out of the kernel. A context switch
>> would be more expensive in terms of power. If there is
>> L2 paging support, however, this would be done in the driver
>> and IP would not even see it.
>>
>> I think there are other parts of paging that would
>> be easier to do at user level, like paging area registration
>> and perhaps even dormant mode registration. So I think
>> that there is a f
>> airly limited, narrow set of functions that
>> would make sense to implement in the kernel.
>>
>> I'm still not convinced that header options are the right way to
>> go, however. It could just as well be an ICMP message.
>>
>> But these are implementation details. We are a long way away
>> from this. We still need to figure out what the right architecture
>> is.
>>
>>             jak
>>
>>
>>
>> _______________________________________________
>> Seamoby mailing list
>> Seamoby@ietf.org
>> https://www1.ietf.org/mailman/listinfo/seamoby
>>

--------------B3AB16C3C1F7B6C16184A2AD
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi,

I just want to clarify what has been not understood and addressed misleadingly
more than once.

The concept described in draft-renker does 'not' push tracking function
to the HA! Again: The Paging Agent node implements a TA functionality,
taking care of paging areas the mobile terminal is roaming in. The mobile
terminal (or PA assistant functional entities in ARs) keeps the TA updated
when entering a new paging area. This does 'not' include registration update
at a mobility agent (which is the HA in case of MIPv6). A respective Paging
Agent node (there are multiple in an admin. domain, for load sharing as
well as to introduce redundancy for failover handling) is repsonsible for
more than one paging area. The registration at the HA addresses requirement
4.8 and allows reception of paging trigger packets at the DMA functional
entity for a registered idle mobile terminal. How should the following
requirement 4.8 be interpreted in a different way as described in draft-renker:

'... The IP paging protocol should make use of existing registration
support...'

For other mobility platforms (e.g. routing based ones), packet capturing
at distributed DMAs (which could be located close to border routers) might
be necessary, since explicit registration of a respective DMA might be
not possible.

Regards,

Marco

 

Vinod Kumar Choyi wrote:

Hi James,

Sorry for the delay. I went throught draft-renker...., and realized
that in case of MIP, the HA keeps track of the PA. Each time the MN moves
to a different paging area, it registers the PA@ with the HA. When local-mobility
management protocols/intra-domain protocols (RegReg6 or HMIP or...) are
implemented at the foreign network, and if there are multiple PAs present
within a foreign domain (which is likely to be the case) then changing
a PA would cause the sending of binding update messages to the HA. Intra-domain
protocols were developed (even though not standardized yet) one of the
reasons being to reduce the binding messages sent by the MN (apart from
from other advantages). Depending upon the size of the PAs (if small),
then the advantage of using HMIP/RegReg6 is reduced remarkably.

IMO, having paging information known to HA, when MN is in a foreign
network is not such a good idea, it should be dealt with locally and the
HA should be agnostic to paging.

The other thing about the draft is that eventhough it does talk about
various scenarios and possible solutions it ends up looking more like the
requirements draft with little more specifications.

I am not in favor of this draft being adopted as the base draft.

regards

vinod

James Kempf wrote:



Behcet,







  An IP level IP Paging protocol must be implemented as a kernel mode
program like HUT Mipv6 implementation (I think now it is called
MIPL). Sometimes user level implementations are also tried.
  In fact about a year ago we had tried to prototype an earlier
version of draft-sarikaya extending MIPL. The (undergraduate)
students had failed because MIPL at that time was not allowing
sub-options to be defined with binding updates. 
  MIPv4/v6 based IP Paging can easily be implemented extending
present implementations, this was the conclusion of our project. In
fact there are other prototyping efforts documented in literature.








Right, I can see where you might want to keep the implementation
in the kernel if the last hop paging message is an IP message instead
of a L2 paging message. If you don't have a specialized L2 paging
channel, you have to use multicast to send out the paging message
since the MN doesn't have valid routing at that point. Probably
in IPv6 it would be done on a link local address. To minimize
battery consumption for messages that aren't for this particular
mobile node, you would want to filter out messages that aren't
to that MN before coming out of the kernel. A context switch
would be more expensive in terms of power. If there is
L2 paging support, however, this would be done in the driver
and IP would not even see it.

I think there are other parts of paging that would
be easier to do at user level, like paging area registration
and perhaps even dormant mode registration. So I think
that there is a f
airly limited, narrow set of functions that
would make sense to implement in the kernel.

I'm still not convinced that header options are the right way to
go, however. It could just as well be an ICMP message.

But these are implementation details. We are a long way away
from this. We still need to figure out what the right architecture
is.

            jak



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







--------------B3AB16C3C1F7B6C16184A2AD--


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


From seamoby-admin@ietf.org  Tue Feb 26 05:13:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22240
	for ; Tue, 26 Feb 2002 05:13:30 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01683;
	Tue, 26 Feb 2002 04:59:41 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01652
	for ; Tue, 26 Feb 2002 04:59:39 -0500 (EST)
Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22060
	for ; Tue, 26 Feb 2002 04:59:35 -0500 (EST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1Q9xCQ24108;
	Tue, 26 Feb 2002 10:59:12 +0100 (CET)
	(envelope-from Marco.Liebsch@ccrle.nec.de)
Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA03137;
	Tue, 26 Feb 2002 10:59:07 +0100
Message-ID: <3C7B5C6B.56B0357E@ccrle.nec.de>
Date: Tue, 26 Feb 2002 10:59:07 +0100
From: Marco Liebsch 
Organization: NEC Europe Ltd.
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Vinod Kumar Choyi 
CC: James Kempf , seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF> <3C7AD9B6.1000504@alcatel.com>
Content-Type: multipart/alternative;
 boundary="------------0212FB1F5ED26B5F8EBC2A54"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------0212FB1F5ED26B5F8EBC2A54
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi again, Vinod,

Vinod Kumar Choyi wrote:

> James,
>
> I don't think you understood what I mentioned, changing of paging area
> would cause sending of BUs to HA even when MN is within the same
> domain.

sorry, but I think you did not understand what's written in the draft.
Please be referred to my previous reply to your concern on the concept.
again: In case of MIPv6, HA is only involved in forwarding paging
trigger packets to a DMA. This registration might be long-term and is
indpendent of paging areas, which are managed by TA functional entity.
By the way, DMA does not change when entering a new paging area.

Marco


> So if you have smaller paging areas within a domain, MN sends a BU to
> HA each time it changes an area and HMIP/RegReg were developed to
> reduce the signaling. , I am not talking about HMIP/RegReg signalling.
> Kindly read my message again.
> regards
> vinod
>
> James Kempf wrote:
>
>> Vinod,
>>
>>
>> > Sorry for the delay. I went throught draft-renker...., and realized
>> >
>> that
>>
>> > in case of MIP, the HA keeps track of the PA. Each time the MN
>> > moves
>> >
>> to
>>
>> > a different paging area, it registers the PA@ with the HA. When
>> > local-mobility management protocols/intra-domain protocols (RegReg6
>> > or
>> > HMIP or...) are implemented at the foreign network, and if there
>> > are
>> > multiple PAs present within a foreign domain (which is likely to be
>> >
>> the
>>
>> > case) then changing a PA would cause the sending of binding update
>> > messages to the HA.
>> >
>> I think this was already identified as an issue. Main issue is the
>> expense
>> of requiring the MN to come out of dormant mode, bring up its MIPv6
>> stack, send the BU, then go back into dormant mode. This is
>> considerably
>> expensive in terms of power than what typically is the case with
>> mobile
>> devices that use paging today.
>>
>> So the architectural question is whether it is possible to architect
>> the
>> system
>> such that the MN can avoid having to come completely out of dormant
>> mode
>> if L2 paging support is available (of course, if there is no L2
>> paging
>> support,
>> then it is impossible) while at the same time requiring the mobility
>> protocol
>> (in this case MIPv6) to maintain location information even while the
>> MN
>> is in dormant mode? The reason for the latter is so that there is
>> one
>> protocol
>> whereby the MN's location state is maintained, rather than 2.
>>
>>
>> > Intra-domain protocols were developed (even though
>> > not standardized yet) one of the reasons being to reduce the
>> > binding
>> > messages sent by the MN (apart from from other advantages).
>> > Depending
>> > upon the size of the PAs (if small), then the advantage of using
>> > HMIP/RegReg6 is reduced remarkably.
>> >
>> HMIP/RegReg were developed for a different purpose, to minimize
>> signaling
>> during handover. If the MN is asleep, then what does it care how
>> long
>> the signaling takes? I would not imagine HMIP/RegReg being involved
>> in dormant mode signaling.
>>
>>
>> > IMO, having paging information known to HA, when MN is in a foreign
>> > network is not such a good idea, it should be dealt with locally
>> > and
>> >
>> the
>>
>> > HA should be agnostic to paging.
>> >
>> Why is it any different than having the HA know the CoA?
>>
>>
>> > The other thing about the draft is that eventhough it does talk
>> > about
>> > various scenarios and possible solutions it ends up looking more
>> > like
>> > the requirements draft with little more specifications.
>> > I am not in favor of this draft being adopted as the base draft.
>> >
>> >
>> Noted.
>>
>>             jak
>>
>>
>> _______________________________________________
>> Seamoby mailing list
>> Seamoby@ietf.org
>> https://www1.ietf.org/mailman/listinfo/seamoby
>>

--------------0212FB1F5ED26B5F8EBC2A54
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi again, Vinod,

Vinod Kumar Choyi wrote:

James,

I don't think you understood what I mentioned, changing of paging area
would cause sending of BUs to HA even when MN is within the same domain.

sorry, but I think you did not understand what's written in the draft.

Please be referred to my previous reply to your concern on the concept.

again: In case of MIPv6, HA is only involved in forwarding paging trigger
packets to a DMA. This registration might be long-term and is indpendent
of paging areas, which are managed by TA functional entity. By the way,
DMA does not change when entering a new paging area.

Marco

 

So if you have smaller paging areas within a domain,
MN sends a BU to HA each time it changes an area and HMIP/RegReg were developed
to reduce the signaling. , I am not talking about HMIP/RegReg signalling.
Kindly read my message again.

regards

vinod

James Kempf wrote:



Vinod,







Sorry for the delay. I went throught draft-renker...., and realized





that





in case of MIP, the HA keeps track of the PA. Each time the MN moves





to





a different paging area, it registers the PA@ with the HA. When
local-mobility management protocols/intra-domain protocols (RegReg6 or
HMIP or...) are implemented at the foreign network, and if there are
multiple PAs present within a foreign domain (which is likely to be





the





case) then changing a PA would cause the sending of binding update
messages to the HA.






I think this was already identified as an issue. Main issue is the
expense
of requiring the MN to come out of dormant mode, bring up its MIPv6
stack, send the BU, then go back into dormant mode. This is considerably
expensive in terms of power than what typically is the case with mobile
devices that use paging today.

So the architectural question is whether it is possible to architect the
system
such that the MN can avoid having to come completely out of dormant mode
if L2 paging support is available (of course, if there is no L2 paging
support,
then it is impossible) while at the same time requiring the mobility
protocol
(in this case MIPv6) to maintain location information even while the MN
is in dormant mode? The reason for the latter is so that there is one
protocol
whereby the MN's location state is maintained, rather than 2.







Intra-domain protocols were developed (even though
not standardized yet) one of the reasons being to reduce the binding
messages sent by the MN (apart from from other advantages). Depending
upon the size of the PAs (if small), then the advantage of using
HMIP/RegReg6 is reduced remarkably.






HMIP/RegReg were developed for a different purpose, to minimize
signaling
during handover. If the MN is asleep, then what does it care how long
the signaling takes? I would not imagine HMIP/RegReg being involved
in dormant mode signaling.







IMO, having paging information known to HA, when MN is in a foreign
network is not such a good idea, it should be dealt with locally and





the





HA should be agnostic to paging.






Why is it any different than having the HA know the CoA?







The other thing about the draft is that eventhough it does talk about
various scenarios and possible solutions it ends up looking more like
the requirements draft with little more specifications.
I am not in favor of this draft being adopted as the base draft.








Noted.

            jak


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







--------------0212FB1F5ED26B5F8EBC2A54--


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


From seamoby-admin@ietf.org  Tue Feb 26 11:04:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05097
	for ; Tue, 26 Feb 2002 11:04:05 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18777;
	Tue, 26 Feb 2002 10:40:32 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18752
	for ; Tue, 26 Feb 2002 10:40:30 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04101
	for ; Tue, 26 Feb 2002 10:40:27 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1QFdwl28116;
	Tue, 26 Feb 2002 09:39:59 -0600 (CST)
Message-ID: <3C7BBAE1.7070003@alcatel.com>
Date: Tue, 26 Feb 2002 10:42:09 -0600
From: Vinod Kumar Choyi 
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: James Kempf , seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF> <3C7AD9B6.1000504@alcatel.com> <02d001c1be5c$a98970b0$7e6015ac@T23KEMPF>
Content-Type: multipart/alternative;
 boundary="------------050209040608030707050609"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------050209040608030707050609
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

James,

Yes, I am in favour of paging info maintained in the foreign network.

regards
vinod

James Kempf wrote:

>I understood what you said. What I was saying is that the delay of
>signaling isn't a problem when the MN is in dormant mode because there
>is no user traffic waiting on the signaling to complete. I think most
>proposals for LMM are to control the delay involved in handing over an
>active MN, so that the MN doesn't have to wait on the rtt of a BU to the
>HA and various CNs.
>
>As for the amount of signaling, of course, the size of the paging areas
>needs to be regulated so that a BU isn't getting sent every time a
>dormant mode MN moves from one subnet to another. Otherwise, yes, it
>would be expensive.
>
>It sounds to me that you are in favor of a VLR-like solution, in which
>paging information is maintained in the foreign network. Is that so?
>
>            jak
>
>----- Original Message -----
>From: "Vinod Kumar Choyi" 
>To: "James Kempf" 
>Cc: 
>Sent: Monday, February 25, 2002 4:41 PM
>Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
>Protocol Issues
>
>
>>James,
>>
>>I don't think you understood what I mentioned, changing of paging area
>>would cause sending of BUs to HA even when MN is within the same
>>
>domain.
>
>>So if you have smaller paging areas within a domain, MN sends a BU to
>>
>HA
>
>>each time it changes an area and HMIP/RegReg were developed to reduce
>>the signaling. , I am not talking about HMIP/RegReg signalling. Kindly
>>read my message again.
>>regards
>>vinod
>>
>>James Kempf wrote:
>>
>>>Vinod,
>>>
>>>>Sorry for the delay. I went throught draft-renker...., and realized
>>>>
>>>that
>>>
>>>>in case of MIP, the HA keeps track of the PA. Each time the MN moves
>>>>
>>>to
>>>
>>>>a different paging area, it registers the PA@ with the HA. When
>>>>local-mobility management protocols/intra-domain protocols (RegReg6
>>>>
>or
>
>>>>HMIP or...) are implemented at the foreign network, and if there are
>>>>multiple PAs present within a foreign domain (which is likely to be
>>>>
>>>the
>>>
>>>>case) then changing a PA would cause the sending of binding update
>>>>messages to the HA.
>>>>
>>>I think this was already identified as an issue. Main issue is the
>>>expense
>>>of requiring the MN to come out of dormant mode, bring up its MIPv6
>>>stack, send the BU, then go back into dormant mode. This is
>>>
>considerably
>
>>>expensive in terms of power than what typically is the case with
>>>
>mobile
>
>>>devices that use paging today.
>>>
>>>So the architectural question is whether it is possible to architect
>>>
>the
>
>>>system
>>>such that the MN can avoid having to come completely out of dormant
>>>
>mode
>
>>>if L2 paging support is available (of course, if there is no L2
>>>
>paging
>
>>>support,
>>>then it is impossible) while at the same time requiring the mobility
>>>protocol
>>>(in this case MIPv6) to maintain location information even while the
>>>
>MN
>
>>>is in dormant mode? The reason for the latter is so that there is one
>>>protocol
>>>whereby the MN's location state is maintained, rather than 2.
>>>
>>>>Intra-domain protocols were developed (even though
>>>>not standardized yet) one of the reasons being to reduce the binding
>>>>messages sent by the MN (apart from from other advantages).
>>>>
>Depending
>
>>>>upon the size of the PAs (if small), then the advantage of using
>>>>HMIP/RegReg6 is reduced remarkably.
>>>>
>>>HMIP/RegReg were developed for a different purpose, to minimize
>>>signaling
>>>during handover. If the MN is asleep, then what does it care how long
>>>the signaling takes? I would not imagine HMIP/RegReg being involved
>>>in dormant mode signaling.
>>>
>>>>IMO, having paging information known to HA, when MN is in a foreign
>>>>network is not such a good idea, it should be dealt with locally and
>>>>
>>>the
>>>
>>>>HA should be agnostic to paging.
>>>>
>>>Why is it any different than having the HA know the CoA?
>>>
>>>>The other thing about the draft is that eventhough it does talk
>>>>
>about
>
>>>>various scenarios and possible solutions it ends up looking more
>>>>
>like
>
>>>>the requirements draft with little more specifications.
>>>>I am not in favor of this draft being adopted as the base draft.
>>>>
>>>Noted.
>>>
>>>           jak
>>>
>>>
>>>_______________________________________________
>>>Seamoby mailing list
>>>Seamoby@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/seamoby
>>>
>>
>


--------------050209040608030707050609
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





James,



Yes, I am in favour of paging info maintained in the foreign network.



regards

vinod



James Kempf wrote:



  
I understood what you said. What I was saying is that the delay of
signaling isn't a problem when the MN is in dormant mode because there
is no user traffic waiting on the signaling to complete. I think most
proposals for LMM are to control the delay involved in handing over an
active MN, so that the MN doesn't have to wait on the rtt of a BU to the
HA and various CNs.

As for the amount of signaling, of course, the size of the paging areas
needs to be regulated so that a BU isn't getting sent every time a
dormant mode MN moves from one subnet to another. Otherwise, yes, it
would be expensive.

It sounds to me that you are in favor of a VLR-like solution, in which
paging information is maintained in the foreign network. Is that so?

            jak

----- Original Message -----
From: "Vinod Kumar Choyi" <vinod.choyi@alcatel.com>
To: "James Kempf" <kempf@docomolabs-usa.com>
Cc: <seamoby@ietf.org>
Sent: Monday, February 25, 2002 4:41 PM
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues



  

    
James,

I don't think you understood what I mentioned, changing of paging area
would cause sending of BUs to HA even when MN is within the same

    

    
domain.

    

      
So if you have smaller paging areas within a domain, MN sends a BU to

      

      
HA

      

        
each time it changes an area and HMIP/RegReg were developed to reduce
the signaling. , I am not talking about HMIP/RegReg signalling. Kindly
read my message again.
regards
vinod

James Kempf wrote:


        

          
Vinod,


          

            
Sorry for the delay. I went throught draft-renker...., and realized


            

            
that


            

              
in case of MIP, the HA keeps track of the PA. Each time the MN moves


              

              
to


              

                
a different paging area, it registers the PA@ with the HA. When
local-mobility management protocols/intra-domain protocols (RegReg6

                

                

                

                
or

                

                  

                    

                      
HMIP or...) are implemented at the foreign network, and if there are
multiple PAs present within a foreign domain (which is likely to be


                      

                      
the


                      

                        
case) then changing a PA would cause the sending of binding update
messages to the HA.


                        

                        
I think this was already identified as an issue. Main issue is the
expense
of requiring the MN to come out of dormant mode, bring up its MIPv6
stack, send the BU, then go back into dormant mode. This is

                        

                        

                        
considerably

                        

                          

                            
expensive in terms of power than what typically is the case with

                            

                            

                            
mobile

                            

                              

                                
devices that use paging today.

So the architectural question is whether it is possible to architect

                                

                                

                                
the

                                

                                  

                                    
system
such that the MN can avoid having to come completely out of dormant

                                    

                                    

                                    
mode

                                    

                                      

                                        
if L2 paging support is available (of course, if there is no L2

                                        

                                        

                                        
paging

                                        

                                          

                                            
support,
then it is impossible) while at the same time requiring the mobility
protocol
(in this case MIPv6) to maintain location information even while the

                                            

                                            

                                            
MN

                                            

                                              

                                                
is in dormant mode? The reason for the latter is so that there is one
protocol
whereby the MN's location state is maintained, rather than 2.


                                                

                                                  
Intra-domain protocols were developed (even though
not standardized yet) one of the reasons being to reduce the binding
messages sent by the MN (apart from from other advantages).

                                                  

                                                  

                                                  

                                                  
Depending

                                                  

                                                    

                                                      

                                                        
upon the size of the PAs (if small), then the advantage of using
HMIP/RegReg6 is reduced remarkably.


                                                        

                                                        
HMIP/RegReg were developed for a different purpose, to minimize
signaling
during handover. If the MN is asleep, then what does it care how long
the signaling takes? I would not imagine HMIP/RegReg being involved
in dormant mode signaling.


                                                        

                                                          
IMO, having paging information known to HA, when MN is in a foreign
network is not such a good idea, it should be dealt with locally and


                                                          

                                                          
the


                                                          

                                                            
HA should be agnostic to paging.


                                                            

                                                            
Why is it any different than having the HA know the CoA?


                                                            

                                                              
The other thing about the draft is that eventhough it does talk

                                                              

                                                              

                                                              

                                                              
about

                                                              

                                                                

                                                                  

                                                                    
various scenarios and possible solutions it ends up looking more

                                                                    

                                                                    

                                                                    

                                                                    
like

                                                                    

                                                                      

                                                                        

                                                                          
the requirements draft with little more specifications.
I am not in favor of this draft being adopted as the base draft.


                                                                          

                                                                          
Noted.

           jak


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


                                                                          

                                                                          


                                                                          

                                                                          


                                                                          

                                                                          

                                                                          
                                                                          

--------------050209040608030707050609--


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


From seamoby-admin@ietf.org  Tue Feb 26 11:35:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07869
	for ; Tue, 26 Feb 2002 11:35:55 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21157;
	Tue, 26 Feb 2002 11:23:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21092
	for ; Tue, 26 Feb 2002 11:23:22 -0500 (EST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06092
	for ; Tue, 26 Feb 2002 11:23:14 -0500 (EST)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA18915 for ; Tue, 26 Feb 2002 09:23:18 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA09980 for ; Tue, 26 Feb 2002 09:23:17 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52)
	id ; Tue, 26 Feb 2002 10:23:16 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF5E@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'Govind Krishnamurthi'" , seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments
Date: Tue, 26 Feb 2002 10:23:16 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

Govind,

Please see my comments below.

BR,

Madjid

-----Original Message-----
From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
Sent: Monday, February 25, 2002 10:55 PM
To: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments


Madjid,
My comments inline. Thanks for your comments again.
Regards,
Govind.


>MN>> Thank you for pointing it out. I missed that sentence.
>The implication of intertechnology on inter-domain is scenario
>independent. I have a feeling, you would have a variety of cases,
>both when various access radios are owned by same operator/admin
>authority, and when they are not. So that is tough call, but
>a SHOULD is a good interim goal to keep everybody happy:)

------> It is a SHOULD right now.. so that settles this issue then.

Madjid>OK. However, remember that the original attraction of
CAR as a protocol will be greatly diminished (IMHO) if it can't 
handle inter-domain.

>

>MN>> Boy, I missed that last sentence too :(
>However, in your dynamic CAR case (If I remember correctly)
>  MN is handling the selection process. This means it is getting
>information from ARs that it might not already have SAs with, correct?
>If that is correct, especially if this information is more than
>just signal strength and include sensitive network management information,
>then there is a security issue, since the MN is not a trusted node
>for those networks, and the MN can't have SAs with all the ARs that it
>might come across? am I missing some point?
>
>


-----> There was some confusion about what dynamic discovery means.
It was later  (in version 02.txt) defined as being done on the fly during 
the handover process(any network node/MN can do it) and anticipated implies 
that the discovery is done prior to the handover (again any network node/MN 
can do it). So I guess thatIf the MN has a security association with the 
current AR and the current AR has a
SA with the new AR then we are through, is it not? Do you see any other
problem?

Madjid>> Well, not quite, there are two issues, first
The AR-AR SA is a big IF, in case of inter-domain (I am guessing
you are dealing with more than just one new AR, right). Now, since
inter-domain is a should, I give up on this, lets move to the second
issue, you seem to be assuming that from oldAR-MN and oldAR-NewAR
SA you can deduce newAR-MN SA? How, you said that CAR comes before
Context transfer. 

>MN>> Yes, I would think policy info is important type of
>"capability information" for QoS management, admission control
>  are related, right? and admission control is an important part
>of a successful handover, so possibility of a need for policy
>signaling exist. We might not have to do design the signaling
>here, but CAR signaling can be used as a vehicle.
>UNLESS, capability is transferred by context transfer, we did have
>that discussion at some point, so this might be a scope issue.

-----> CAR discovery, I believe, occurs prior to context transfer. So it 
cannot be associated with that.

Madjid>> Good point on capability issue,
 but see my previous comment on security. BTW, did you agree on
the policy issue, that I mentioned in previous email (above)?

Regards,
Madjid
_________________________________________________________________
Join the world's largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


_______________________________________________
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  Tue Feb 26 13:05:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13554
	for ; Tue, 26 Feb 2002 13:05:05 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07624;
	Tue, 26 Feb 2002 12:53:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07594
	for ; Tue, 26 Feb 2002 12:53:13 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12975
	for ; Tue, 26 Feb 2002 12:53:10 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1QHqfe29509;
	Tue, 26 Feb 2002 09:52:41 -0800 (PST)
Message-ID: <014601c1beee$29e76910$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Vinod Kumar Choyi" , 
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF> <3C7AD9B6.1000504@alcatel.com> <02d001c1be5c$a98970b0$7e6015ac@T23KEMPF> <3C7BBAE1.7070003@alcatel.com>
Subject: Where to put the TA? (was: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues)
Date: Tue, 26 Feb 2002 09:51:05 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Vinod,

> Yes, I am in favour of paging info maintained in the foreign network.
>

So one argument you've made in favor of that architecture is that it
reduces the amount of signaling for smaller sized (like one subnet
sized) paging areas, right?  Any other issues?

Have you seen Andrew Cambell's paper "P-MIP: Paging Extensions for
Mobile IP"? He has some measurements to show that even if you have one
paging area per subnet, paging signaling volume is less (and in some
cases, substantially less) than MIP signaling for a wide range of cells
per subnet. His design (for MIPv4) maintains the mobile node's location
information in the HA. I'm not advocating that we adopt his architecture
(for example, the architecture maintains the one to one mapping between
paging areas and subnets that we are trying to get rid of) but the
measurements seem convincing.

The other issues I have with maintaining the TA in the foreign network
are the following:

1) Duplicate mobile node location information between the mobility
protocol and the paging protocol. This requires explicit
"deregistration" by the MN with the mobility protocol and "registration"
with the paging when  the MN goes into dormant mode, and the opposite
when it comes out of dormant mode. It would be desirable for the MN to
simply be able to time out and go to sleep.

2) Possibility of race conditions between the mobility protocol location
update and the paging protocol update. For example, what happens if a
packet comes in for the MN between the completion of "deregistration"
with the mobility protocol and "registration" with the paging protocol?

3) TA must maintain state associated with the MN. This leads to
expensive, large, stateful nodes that must be designed to be five 9's
reliable, instead of cheap, redundant nodes like routers are for
routing. In short, a telephony style node rather than an IP style node.

There are some issues which I think having the TA in the foreign network
have in common with having it as part of the mobility protocol which
might be easier to solve:

1) Security. If the TA is part of the mobility protocol, it may require
the host to send any paging area updates to the HA for MIPv6 when it
moves paging area. This may increase power use on the host, and may not
maximally utilize L2 support. If the TA is part of the foreign network,
then the MN could set up a trust relationship with the TA initially
which allows the foreign network ARs to perform the paging area updates
so the MN doesn't have to wake up. This could maximize power saving and
increase use of L2 paging support.

There are some issues which I think having the TA in the foreign network
is better:

1) Paging area update signaling can be confined to the network if L2
support w.o. IP information is available, provided the necessary trust
relationships are in place. This is linked to the security problem
above.

And finally, there are some issues that bother me, but I can't quite put
my finger on how they might be a problem:

1) If the TA is in the foreign network and it goes down, then the
location information is lost. I think, using dynamic paging area
reconfiguration, that the MNs could be forced to reregister when this is
detected, but I'm not sure there isn't some other catch here.


Comments?

                    jak







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


From seamoby-admin@ietf.org  Tue Feb 26 13:10:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13858
	for ; Tue, 26 Feb 2002 13:10:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07901;
	Tue, 26 Feb 2002 12:59:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07874
	for ; Tue, 26 Feb 2002 12:59:41 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13219
	for ; Tue, 26 Feb 2002 12:59:38 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1QHxAl12343
	for ; Tue, 26 Feb 2002 11:59:10 -0600 (CST)
Message-ID: <3C7BCCED.8040605@alcatel.com>
Date: Tue, 26 Feb 2002 11:59:09 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF> <3C7AD9B6.1000504@alcatel.com> <3C7B5C6B.56B0357E@ccrle.nec.de>
Content-Type: multipart/alternative;
 boundary="------------010708040003010109060508"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------010708040003010109060508
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Marco,
  DMA in draft-renker is on page 51 only which is Appendix C, not the 
main text which is supposed to provide the solution.
  It is difficult to understand whether what you are saying now was what 
you said or had in your original draft. Maybe this is what you wish to 
have in a future draft. Then we first see the draft and then comment on it.
  Also it is not clear from the figure and the text on Page 51 of 
draft-renker how TA, PA and DMA take their places in a simple IP 
architecture, which takes me back to the fact that Requirements 4.7 and 
4.8 can not be satisfied in a single one size fits all solution.
  Hope you come to agree with this.

Regards,


Marco Liebsch wrote:

> Hi again, Vinod,
>
> Vinod Kumar Choyi wrote:
>
>> James,
>>
>> I don't think you understood what I mentioned, changing of paging 
>> area would cause sending of BUs to HA even when MN is within the same 
>> domain.
>>
> sorry, but I think you did not understand what's written in the draft.
> Please be referred to my previous reply to your concern on the concept.
> again: In case of MIPv6, HA is only involved in forwarding paging 
> trigger packets to a DMA. This registration might be long-term and is 
> indpendent of paging areas, which are managed by TA functional entity. 
> By the way, DMA does not change when entering a new paging area.
>
> Marco
>  
>
>> So if you have smaller paging areas within a domain, MN sends a BU to 
>> HA each time it changes an area and HMIP/RegReg were developed to 
>> reduce the signaling. , I am not talking about HMIP/RegReg 
>> signalling. Kindly read my message again.
>> regards
>> vinod
>>
>> James Kempf wrote:
>>
>>>Vinod,
>>>
>>>>Sorry for the delay. I went throught draft-renker...., and realized
>>>>
>>>that
>>>
>>>>in case of MIP, the HA keeps track of the PA. Each time the MN moves
>>>>
>>>to
>>>
>>>>a different paging area, it registers the PA@ with the HA. When
>>>>local-mobility management protocols/intra-domain protocols (RegReg6 or
>>>>HMIP or...) are implemented at the foreign network, and if there are
>>>>multiple PAs present within a foreign domain (which is likely to be
>>>>
>>>the
>>>
>>>>case) then changing a PA would cause the sending of binding update
>>>>messages to the HA.
>>>>
>>>
>>>I think this was already identified as an issue. Main issue is the
>>>expense
>>>of requiring the MN to come out of dormant mode, bring up its MIPv6
>>>stack, send the BU, then go back into dormant mode. This is considerably
>>>expensive in terms of power than what typically is the case with mobile
>>>devices that use paging today.
>>>
>>>So the architectural question is whether it is possible to architect the
>>>system
>>>such that the MN can avoid having to come completely out of dormant mode
>>>if L2 paging support is available (of course, if there is no L2 paging
>>>support,
>>>then it is impossible) while at the same time requiring the mobility
>>>protocol
>>>(in this case MIPv6) to maintain location information even while the MN
>>>is in dormant mode? The reason for the latter is so that there is one
>>>protocol
>>>whereby the MN's location state is maintained, rather than 2.
>>>
>>>>Intra-domain protocols were developed (even though
>>>>not standardized yet) one of the reasons being to reduce the binding
>>>>messages sent by the MN (apart from from other advantages). Depending
>>>>upon the size of the PAs (if small), then the advantage of using
>>>>HMIP/RegReg6 is reduced remarkably.
>>>>
>>>
>>>HMIP/RegReg were developed for a different purpose, to minimize
>>>signaling
>>>during handover. If the MN is asleep, then what does it care how long
>>>the signaling takes? I would not imagine HMIP/RegReg being involved
>>>in dormant mode signaling.
>>>
>>>>IMO, having paging information known to HA, when MN is in a foreign
>>>>network is not such a good idea, it should be dealt with locally and
>>>>
>>>the
>>>
>>>>HA should be agnostic to paging.
>>>>
>>>
>>>Why is it any different than having the HA know the CoA?
>>>
>>>>The other thing about the draft is that eventhough it does talk about
>>>>various scenarios and possible solutions it ends up looking more like
>>>>the requirements draft with little more specifications.
>>>>I am not in favor of this draft being adopted as the base draft.
>>>>
>>>
>>>Noted.
>>>
>>>            jak
>>>
>>>
>>>_______________________________________________
>>>Seamoby mailing list
>>>Seamoby@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/seamoby
>>>

-- 
Behcet 



--------------010708040003010109060508
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Hi Marco,

  DMA in draft-renker is on page 51 only which is Appendix C, not the main
text which is supposed to provide the solution.

  It is difficult to understand whether what you are saying now was what
you said or had in your original draft. Maybe this is what you wish to have
in a future draft. Then we first see the draft and then comment on it.

  Also it is not clear from the figure and the text on Page 51 of draft-renker
how TA, PA and DMA take their places in a simple IP architecture, which takes
me back to the fact that Requirements 4.7 and 4.8 can not be satisfied in
a single one size fits all solution.

  Hope you come to agree with this.



Regards,





Marco Liebsch wrote:


  Hi again,
Vinod, 
  
Vinod Kumar Choyi wrote: 

  
James, 
    
I don't think you understood what I mentioned, changing of paging
area would cause sending of BUs to HA even when MN is within the same domain.

    

 sorry, but I think you did not understand what's written in the draft. 

Please be referred to my previous reply to your concern on the concept. 

again: In case of MIPv6, HA is only involved in forwarding paging trigger 
packets to a DMA. This registration might be long-term and is indpendent of
paging areas, which are managed by TA functional entity. By the way, DMA
does not change when entering a new paging area. 
    
Marco 

  

    
So if you have smaller paging areas within a
domain, MN sends a BU to HA each time it changes an area and HMIP/RegReg
were developed to reduce the signaling. , I am not talking about HMIP/RegReg
signalling. Kindly read my message again. 

regards 

vinod 
      
James Kempf wrote: 

      

        
Vinod,


        

          
Sorry for the delay. I went throught draft-renker...., and realized

          

          
that

          

            
in case of MIP, the HA keeps track of the PA. Each time the MN moves

            

            
to

            

              
a different paging area, it registers the PA@ with the HA. When
local-mobility management protocols/intra-domain protocols (RegReg6 or
HMIP or...) are implemented at the foreign network, and if there are
multiple PAs present within a foreign domain (which is likely to be

              

              
the

              

                
case) then changing a PA would cause the sending of binding update
messages to the HA.

                

                

I think this was already identified as an issue. Main issue is the
expense
of requiring the MN to come out of dormant mode, bring up its MIPv6
stack, send the BU, then go back into dormant mode. This is considerably
expensive in terms of power than what typically is the case with mobile
devices that use paging today.

So the architectural question is whether it is possible to architect the
system
such that the MN can avoid having to come completely out of dormant mode
if L2 paging support is available (of course, if there is no L2 paging
support,
then it is impossible) while at the same time requiring the mobility
protocol
(in this case MIPv6) to maintain location information even while the MN
is in dormant mode? The reason for the latter is so that there is one
protocol
whereby the MN's location state is maintained, rather than 2.


                

                  
Intra-domain protocols were developed (even though
not standardized yet) one of the reasons being to reduce the binding
messages sent by the MN (apart from from other advantages). Depending
upon the size of the PAs (if small), then the advantage of using
HMIP/RegReg6 is reduced remarkably.

                  

                  

HMIP/RegReg were developed for a different purpose, to minimize
signaling
during handover. If the MN is asleep, then what does it care how long
the signaling takes? I would not imagine HMIP/RegReg being involved
in dormant mode signaling.


                  

                    
IMO, having paging information known to HA, when MN is in a foreign
network is not such a good idea, it should be dealt with locally and

                    

                    
the

                    

                      
HA should be agnostic to paging.

                      

                      

Why is it any different than having the HA know the CoA?


                      

                        
The other thing about the draft is that eventhough it does talk about
various scenarios and possible solutions it ends up looking more like
the requirements draft with little more specifications.
I am not in favor of this draft being adopted as the base draft.


                        

                        

Noted.

            jak


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

                        

                        

                        

                        

                        
-- 
Behcet 


                        

                        
                        

--------------010708040003010109060508--


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


From seamoby-admin@ietf.org  Tue Feb 26 13:52:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15922
	for ; Tue, 26 Feb 2002 13:52:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10839;
	Tue, 26 Feb 2002 13:41:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10812
	for ; Tue, 26 Feb 2002 13:41:08 -0500 (EST)
Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15358
	for ; Tue, 26 Feb 2002 13:41:04 -0500 (EST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1QIebQ48628;
	Tue, 26 Feb 2002 19:40:37 +0100 (CET)
	(envelope-from Marco.Liebsch@ccrle.nec.de)
Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA08193;
	Tue, 26 Feb 2002 19:40:36 +0100
Message-ID: <3C7BD6A4.AA27CAC9@ccrle.nec.de>
Date: Tue, 26 Feb 2002 19:40:36 +0100
From: Marco Liebsch 
Organization: NEC Europe Ltd.
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Behcet Sarikaya 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF> <3C7AD9B6.1000504@alcatel.com> <3C7B5C6B.56B0357E@ccrle.nec.de> <3C7BCCED.8040605@alcatel.com>
Content-Type: multipart/alternative;
 boundary="------------F3D4073C0EFC7FD520A1B542"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------F3D4073C0EFC7FD520A1B542
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Behcet,

Behcet Sarikaya wrote:

> Hi Marco,
>   DMA in draft-renker is on page 51 only which is Appendix C, not the
> main text which is supposed to provide the solution.
>   It is difficult to understand whether what you are saying now was
> what you said or had in your original draft. Maybe this is what you
> wish to have in a future draft. Then we first see the draft and then
> comment on it.
>   Also it is not clear from the figure and the text on Page 51 of
> draft-renker how TA, PA and DMA take their places in a simple IP
> architecture, which takes me back to the fact that Requirements 4.7
> and 4.8 can not be satisfied in a single one size fits all solution.
>   Hope you come to agree with this.
>

Not really. Location of the DMA is described on some pages in the draft.
As we have already discovered in a discussion that for some IP moblity
management systems distributed DMAs with respective capturing support
might be reasonable. For this, the coposite architecture described in
the draft might require separating the DMA functional entity from the
paging agent node. The concept as it is also separates generic IP paging
from access link specifics, allowing attendant paging agent functional
entities on access routers to map a generic IP paging request to
technology specifics. For a MIPv6 system, if you could make use of
available registration support, wouldn't you do it, if you expect a
benefit from this? That's what the draft-renker concept describes from
the 00 draft. Having (and keeping) a DMA while roaming within a paging
area as well as changing the paging area would not require registration
of a different DMA with a mobility agent.

Hope this clarifies a bit.

Regards,

Marco





>
> Regards,
>
>
> Marco Liebsch wrote:
>
>> Hi again, Vinod,
>>
>> Vinod Kumar Choyi wrote:
>>
>> > James,
>> >
>> > I don't think you understood what I mentioned, changing of paging
>> > area would cause sending of BUs to HA even when MN is within the
>> > same domain.
>>
>> sorry, but I think you did not understand what's written in the
>> draft.
>> Please be referred to my previous reply to your concern on the
>> concept.
>> again: In case of MIPv6, HA is only involved in forwarding paging
>> trigger packets to a DMA. This registration might be long-term and
>> is indpendent of paging areas, which are managed by TA functional
>> entity. By the way, DMA does not change when entering a new paging
>> area.
>>
>> Marco
>>
>>
>> > So if you have smaller paging areas within a domain, MN sends a BU
>> > to HA each time it changes an area and HMIP/RegReg were developed
>> > to reduce the signaling. , I am not talking about HMIP/RegReg
>> > signalling. Kindly read my message again.
>> > regards
>> > vinod
>> >
>> > James Kempf wrote:
>> >
>> >>  Vinod,
>> >>
>> >>
>> >> > Sorry for the delay. I went throught draft-renker...., and
>> >> > realized
>> >> >
>> >>  that
>> >>
>> >> > in case of MIP, the HA keeps track of the PA. Each time the MN
>> >> > moves
>> >> >
>> >>  to
>> >>
>> >> > a different paging area, it registers the PA@ with the HA. When
>> >> > local-mobility management protocols/intra-domain protocols
>> >> > (RegReg6 or
>> >> > HMIP or...) are implemented at the foreign network, and if
>> >> > there are
>> >> > multiple PAs present within a foreign domain (which is likely
>> >> > to be
>> >> >
>> >>  the
>> >>
>> >> > case) then changing a PA would cause the sending of binding
>> >> > update
>> >> > messages to the HA.
>> >> >
>> >>  I think this was already identified as an issue. Main issue is
>> >>  the
>> >>  expense
>> >>  of requiring the MN to come out of dormant mode, bring up its
>> >>  MIPv6
>> >>  stack, send the BU, then go back into dormant mode. This is
>> >>  considerably
>> >>  expensive in terms of power than what typically is the case with
>> >>  mobile
>> >>  devices that use paging today.
>> >>
>> >>  So the architectural question is whether it is possible to
>> >>  architect the
>> >>  system
>> >>  such that the MN can avoid having to come completely out of
>> >>  dormant mode
>> >>  if L2 paging support is available (of course, if there is no L2
>> >>  paging
>> >>  support,
>> >>  then it is impossible) while at the same time requiring the
>> >>  mobility
>> >>  protocol
>> >>  (in this case MIPv6) to maintain location information even while
>> >>  the MN
>> >>  is in dormant mode? The reason for the latter is so that there is
>> >>  one
>> >>  protocol
>> >>  whereby the MN's location state is maintained, rather than 2.
>> >>
>> >>
>> >> > Intra-domain protocols were developed (even though
>> >> > not standardized yet) one of the reasons being to reduce the
>> >> > binding
>> >> > messages sent by the MN (apart from from other advantages).
>> >> > Depending
>> >> > upon the size of the PAs (if small), then the advantage of
>> >> > using
>> >> > HMIP/RegReg6 is reduced remarkably.
>> >> >
>> >>  HMIP/RegReg were developed for a different purpose, to minimize
>> >>  signaling
>> >>  during handover. If the MN is asleep, then what does it care how
>> >>  long
>> >>  the signaling takes? I would not imagine HMIP/RegReg being
>> >>  involved
>> >>  in dormant mode signaling.
>> >>
>> >>
>> >> > IMO, having paging information known to HA, when MN is in a
>> >> > foreign
>> >> > network is not such a good idea, it should be dealt with
>> >> > locally and
>> >> >
>> >>  the
>> >>
>> >> > HA should be agnostic to paging.
>> >> >
>> >>  Why is it any different than having the HA know the CoA?
>> >>
>> >>
>> >> > The other thing about the draft is that eventhough it does talk
>> >> > about
>> >> > various scenarios and possible solutions it ends up looking
>> >> > more like
>> >> > the requirements draft with little more specifications.
>> >> > I am not in favor of this draft being adopted as the base
>> >> > draft.
>> >> >
>> >> >
>> >>  Noted.
>> >>
>> >>              jak
>> >>
>> >>
>> >>  _______________________________________________
>> >>  Seamoby mailing list
>> >>  Seamoby@ietf.org
>> >>  https://www1.ietf.org/mailman/listinfo/seamoby
>> >>
> --
> Behcet
>
>



--------------F3D4073C0EFC7FD520A1B542
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi Behcet,

Behcet Sarikaya wrote:

Hi Marco,

  DMA in draft-renker is on page 51 only which is Appendix C,
not the main text which is supposed to provide the solution.

  It is difficult to understand whether what you are saying now
was what you said or had in your original draft. Maybe this is what you
wish to have in a future draft. Then we first see the draft and then comment
on it.

  Also it is not clear from the figure and the text on Page 51
of draft-renker how TA, PA and DMA take their places in a simple IP architecture,
which takes me back to the fact that Requirements 4.7 and 4.8 can not be
satisfied in a single one size fits all solution.

  Hope you come to agree with this.

 

Not really. Location of the DMA is described on some pages in the draft.
As we have already discovered in a discussion that for some IP moblity
management systems distributed DMAs with respective capturing support might
be reasonable. For this, the coposite architecture described in the draft
might require separating the DMA functional entity from the paging agent
node. The concept as it is also separates generic IP paging from access
link specifics, allowing attendant paging agent functional entities on
access routers to map a generic IP paging request to technology specifics.
For a MIPv6 system, if you could make use of available registration support,
wouldn't you do it, if you expect a benefit from this? That's what the
draft-renker concept describes from the 00 draft. Having (and keeping)
a DMA while roaming within a paging area as well as changing the paging
area would not require registration of a different DMA with a mobility
agent.

Hope this clarifies a bit.

Regards,

Marco

 

 

 

 

 

Regards,

 

Marco Liebsch wrote:

Hi again,
Vinod,

Vinod Kumar Choyi wrote:

James,

I don't think you understood what I mentioned, changing of paging area
would cause sending of BUs to HA even when MN is within the same domain.

sorry, but I think you did not understand what's written in the draft.

Please be referred to my previous reply to your concern on the concept.

again: In case of MIPv6, HA is only involved in forwarding paging trigger
packets to a DMA. This registration might be long-term and is indpendent
of paging areas, which are managed by TA functional entity. By the way,
DMA does not change when entering a new paging area.

Marco

 

So if you have smaller paging areas within a domain,
MN sends a BU to HA each time it changes an area and HMIP/RegReg were developed
to reduce the signaling. , I am not talking about HMIP/RegReg signalling.
Kindly read my message again.

regards

vinod

James Kempf wrote:



Vinod,







Sorry for the delay. I went throught draft-renker...., and realized





that





in case of MIP, the HA keeps track of the PA. Each time the MN moves





to





a different paging area, it registers the PA@ with the HA. When
local-mobility management protocols/intra-domain protocols (RegReg6 or
HMIP or...) are implemented at the foreign network, and if there are
multiple PAs present within a foreign domain (which is likely to be





the





case) then changing a PA would cause the sending of binding update
messages to the HA.






I think this was already identified as an issue. Main issue is the
expense
of requiring the MN to come out of dormant mode, bring up its MIPv6
stack, send the BU, then go back into dormant mode. This is considerably
expensive in terms of power than what typically is the case with mobile
devices that use paging today.

So the architectural question is whether it is possible to architect the
system
such that the MN can avoid having to come completely out of dormant mode
if L2 paging support is available (of course, if there is no L2 paging
support,
then it is impossible) while at the same time requiring the mobility
protocol
(in this case MIPv6) to maintain location information even while the MN
is in dormant mode? The reason for the latter is so that there is one
protocol
whereby the MN's location state is maintained, rather than 2.







Intra-domain protocols were developed (even though
not standardized yet) one of the reasons being to reduce the binding
messages sent by the MN (apart from from other advantages). Depending
upon the size of the PAs (if small), then the advantage of using
HMIP/RegReg6 is reduced remarkably.






HMIP/RegReg were developed for a different purpose, to minimize
signaling
during handover. If the MN is asleep, then what does it care how long
the signaling takes? I would not imagine HMIP/RegReg being involved
in dormant mode signaling.







IMO, having paging information known to HA, when MN is in a foreign
network is not such a good idea, it should be dealt with locally and





the





HA should be agnostic to paging.






Why is it any different than having the HA know the CoA?







The other thing about the draft is that eventhough it does talk about
various scenarios and possible solutions it ends up looking more like
the requirements draft with little more specifications.
I am not in favor of this draft being adopted as the base draft.








Noted.

            jak


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









-- 
Behcet

 



 

--------------F3D4073C0EFC7FD520A1B542--


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


From seamoby-admin@ietf.org  Tue Feb 26 15:22:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20211
	for ; Tue, 26 Feb 2002 15:22:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17368;
	Tue, 26 Feb 2002 15:11:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17301
	for ; Tue, 26 Feb 2002 15:11:46 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19880
	for ; Tue, 26 Feb 2002 15:11:41 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1QKBDl15167;
	Tue, 26 Feb 2002 14:11:13 -0600 (CST)
Message-ID: <3C7C0479.3B80637E@alcatel.com>
Date: Tue, 26 Feb 2002 13:56:09 -0800
From: Xiaofeng Xu 
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: Vinod Kumar Choyi , seamoby@ietf.org
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF> <3C7AD9B6.1000504@alcatel.com> <02d001c1be5c$a98970b0$7e6015ac@T23KEMPF> <3C7BBAE1.7070003@alcatel.com> <014601c1beee$29e76910$7e6015ac@T23KEMPF>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Re: Where to put the TA?
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Design of Paging Area size and placement of TA shall consider:
1) balance of registration sigalling load and paging signalling load
2) mobile node's mobility behaviour model
3) mobile node's originated and terminated traffic model
4) visited network distribution and configuration model
5) layer 2 technology characteristics
.....

There have been many studies on similar topic in cellular networks.

Regards,
Xiaofeng



James Kempf wrote:

> Vinod,
>
> > Yes, I am in favour of paging info maintained in the foreign network.
> >
>
> So one argument you've made in favor of that architecture is that it
> reduces the amount of signaling for smaller sized (like one subnet
> sized) paging areas, right?  Any other issues?
>
> Have you seen Andrew Cambell's paper "P-MIP: Paging Extensions for
> Mobile IP"? He has some measurements to show that even if you have one
> paging area per subnet, paging signaling volume is less (and in some
> cases, substantially less) than MIP signaling for a wide range of cells
> per subnet. His design (for MIPv4) maintains the mobile node's location
> information in the HA. I'm not advocating that we adopt his architecture
> (for example, the architecture maintains the one to one mapping between
> paging areas and subnets that we are trying to get rid of) but the
> measurements seem convincing.
>
> The other issues I have with maintaining the TA in the foreign network
> are the following:
>
> 1) Duplicate mobile node location information between the mobility
> protocol and the paging protocol. This requires explicit
> "deregistration" by the MN with the mobility protocol and "registration"
> with the paging when  the MN goes into dormant mode, and the opposite
> when it comes out of dormant mode. It would be desirable for the MN to
> simply be able to time out and go to sleep.
>
> 2) Possibility of race conditions between the mobility protocol location
> update and the paging protocol update. For example, what happens if a
> packet comes in for the MN between the completion of "deregistration"
> with the mobility protocol and "registration" with the paging protocol?
>
> 3) TA must maintain state associated with the MN. This leads to
> expensive, large, stateful nodes that must be designed to be five 9's
> reliable, instead of cheap, redundant nodes like routers are for
> routing. In short, a telephony style node rather than an IP style node.
>
> There are some issues which I think having the TA in the foreign network
> have in common with having it as part of the mobility protocol which
> might be easier to solve:
>
> 1) Security. If the TA is part of the mobility protocol, it may require
> the host to send any paging area updates to the HA for MIPv6 when it
> moves paging area. This may increase power use on the host, and may not
> maximally utilize L2 support. If the TA is part of the foreign network,
> then the MN could set up a trust relationship with the TA initially
> which allows the foreign network ARs to perform the paging area updates
> so the MN doesn't have to wake up. This could maximize power saving and
> increase use of L2 paging support.
>
> There are some issues which I think having the TA in the foreign network
> is better:
>
> 1) Paging area update signaling can be confined to the network if L2
> support w.o. IP information is available, provided the necessary trust
> relationships are in place. This is linked to the security problem
> above.
>
> And finally, there are some issues that bother me, but I can't quite put
> my finger on how they might be a problem:
>
> 1) If the TA is in the foreign network and it goes down, then the
> location information is lost. I think, using dynamic paging area
> reconfiguration, that the MNs could be forced to reregister when this is
> detected, but I'm not sure there isn't some other catch here.
>
> Comments?
>
>                     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


From seamoby-admin@ietf.org  Tue Feb 26 15:33:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20569
	for ; Tue, 26 Feb 2002 15:33:20 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17785;
	Tue, 26 Feb 2002 15:22:28 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17755
	for ; Tue, 26 Feb 2002 15:22:26 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20222
	for ; Tue, 26 Feb 2002 15:22:21 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1QKLsl18019
	for ; Tue, 26 Feb 2002 14:21:54 -0600 (CST)
Message-ID: <3C7BEE61.9000805@alcatel.com>
Date: Tue, 26 Feb 2002 14:21:53 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF> <3C7AD9B6.1000504@alcatel.com> <3C7B5C6B.56B0357E@ccrle.nec.de> <3C7BCCED.8040605@alcatel.com> <3C7BD6A4.AA27CAC9@ccrle.nec.de>
Content-Type: multipart/alternative;
 boundary="------------030406090700060705040707"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------030406090700060705040707
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Marco,
  In case of simple IP,  the entities such as DMA, TA and PA need to be 
deployed along with the host software implemented in Simple IP hosts
in order to have IP Paging support. Again things would be different if 
IPv4 or IPv6 were to be used for transport.
  If on the other hand Mobile IP is deployed  with its entities of HA, 
FA and GFAs for MIPv4 or AR and MAP (or other) entities for MIPv6 and in 
use at the mobile nodes then we would only add PAs with an extension 
software at the mobile nodes
in order to have IP Paging support.
  The way interoperability is tested would be completely different for 
these two (more correctly 4) different deployment scenarios.
 
  Therefore we do need to define every distinct case in distinct drafts.

  How would the scenario you talk about, assuming Simple IP, and then I 
find MIP infrastructure available so let me do the registration using MIP
fit into this? If there is MIP deployed and it supports paging I do not 
need DMAs and TAs.

  One can question the investment in Simple IP architecture which to a 
large extend duplicates Mobile IP entities. This is what Srinivas was 
talking about. I think that it is a valid concern.

  These are my views.

Regards,

 

Marco Liebsch wrote:

> Hi Behcet,
>
> Behcet Sarikaya wrote:
>
>> Hi Marco,
>>   DMA in draft-renker is on page 51 only which is Appendix C, not the 
>> main text which is supposed to provide the solution.
>>   It is difficult to understand whether what you are saying now was 
>> what you said or had in your original draft. Maybe this is what you 
>> wish to have in a future draft. Then we first see the draft and then 
>> comment on it.
>>   Also it is not clear from the figure and the text on Page 51 of 
>> draft-renker how TA, PA and DMA take their places in a simple IP 
>> architecture, which takes me back to the fact that Requirements 4.7 
>> and 4.8 can not be satisfied in a single one size fits all solution.
>>   Hope you come to agree with this.
>>  
>
> Not really. Location of the DMA is described on some pages in the 
> draft. As we have already discovered in a discussion that for some IP 
> moblity management systems distributed DMAs with respective capturing 
> support might be reasonable. For this, the coposite architecture 
> described in the draft might require separating the DMA functional 
> entity from the paging agent node. The concept as it is also separates 
> generic IP paging from access link specifics, allowing attendant 
> paging agent functional entities on access routers to map a generic IP 
> paging request to technology specifics. For a MIPv6 system, if you 
> could make use of available registration support, wouldn't you do it, 
> if you expect a benefit from this? That's what the draft-renker 
> concept describes from the 00 draft. Having (and keeping) a DMA while 
> roaming within a paging area as well as changing the paging area would 
> not require registration of a different DMA with a mobility agent.
>
> Hope this clarifies a bit.
>
> Regards,
>
> Marco
>  
>  
>  
>  
>
>>  
>> Regards,
>>  
>>
>> Marco Liebsch wrote:
>>
>>> Hi again, Vinod,
>>>
>>> Vinod Kumar Choyi wrote:
>>>
>>>> James,
>>>>
>>>> I don't think you understood what I mentioned, changing of paging 
>>>> area would cause sending of BUs to HA even when MN is within the 
>>>> same domain.
>>>>
>>> sorry, but I think you did not understand what's written in the draft.
>>> Please be referred to my previous reply to your concern on the concept.
>>> again: In case of MIPv6, HA is only involved in forwarding paging 
>>> trigger packets to a DMA. This registration might be long-term and 
>>> is indpendent of paging areas, which are managed by TA functional 
>>> entity. By the way, DMA does not change when entering a new paging 
>>> area.
>>>
>>> Marco
>>>  
>>>
>>>> So if you have smaller paging areas within a domain, MN sends a BU 
>>>> to HA each time it changes an area and HMIP/RegReg were developed 
>>>> to reduce the signaling. , I am not talking about HMIP/RegReg 
>>>> signalling. Kindly read my message again.
>>>> regards
>>>> vinod
>>>>
>>>> James Kempf wrote:
>>>>
>>>>>Vinod,
>>>>>
>>>>>>Sorry for the delay. I went throught draft-renker...., and realized
>>>>>>
>>>>>that
>>>>>
>>>>>>in case of MIP, the HA keeps track of the PA. Each time the MN moves
>>>>>>
>>>>>to
>>>>>
>>>>>>a different paging area, it registers the PA@ with the HA. When
>>>>>>local-mobility management protocols/intra-domain protocols (RegReg6 or
>>>>>>HMIP or...) are implemented at the foreign network, and if there are
>>>>>>multiple PAs present within a foreign domain (which is likely to be
>>>>>>
>>>>>the
>>>>>
>>>>>>case) then changing a PA would cause the sending of binding update
>>>>>>messages to the HA.
>>>>>>
>>>>>
>>>>>I think this was already identified as an issue. Main issue is the
>>>>>expense
>>>>>of requiring the MN to come out of dormant mode, bring up its MIPv6
>>>>>stack, send the BU, then go back into dormant mode. This is considerably
>>>>>expensive in terms of power than what typically is the case with mobile
>>>>>devices that use paging today.
>>>>>
>>>>>So the architectural question is whether it is possible to architect the
>>>>>system
>>>>>such that the MN can avoid having to come completely out of dormant mode
>>>>>if L2 paging support is available (of course, if there is no L2 paging
>>>>>support,
>>>>>then it is impossible) while at the same time requiring the mobility
>>>>>protocol
>>>>>(in this case MIPv6) to maintain location information even while the MN
>>>>>is in dormant mode? The reason for the latter is so that there is one
>>>>>protocol
>>>>>whereby the MN's location state is maintained, rather than 2.
>>>>>
>>>>>>Intra-domain protocols were developed (even though
>>>>>>not standardized yet) one of the reasons being to reduce the binding
>>>>>>messages sent by the MN (apart from from other advantages). Depending
>>>>>>upon the size of the PAs (if small), then the advantage of using
>>>>>>HMIP/RegReg6 is reduced remarkably.
>>>>>>
>>>>>
>>>>>HMIP/RegReg were developed for a different purpose, to minimize
>>>>>signaling
>>>>>during handover. If the MN is asleep, then what does it care how long
>>>>>the signaling takes? I would not imagine HMIP/RegReg being involved
>>>>>in dormant mode signaling.
>>>>>
>>>>>>IMO, having paging information known to HA, when MN is in a foreign
>>>>>>network is not such a good idea, it should be dealt with locally and
>>>>>>
>>>>>the
>>>>>
>>>>>>HA should be agnostic to paging.
>>>>>>
>>>>>
>>>>>Why is it any different than having the HA know the CoA?
>>>>>
>>>>>>The other thing about the draft is that eventhough it does talk about
>>>>>>various scenarios and possible solutions it ends up looking more like
>>>>>>the requirements draft with little more specifications.
>>>>>>I am not in favor of this draft being adopted as the base draft.
>>>>>>
>>>>>
>>>>>Noted.
>>>>>
>>>>>            jak
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Seamoby mailing list
>>>>>Seamoby@ietf.org
>>>>>https://www1.ietf.org/mailman/listinfo/seamoby
>>>>>
>>-- 
>>Behcet
>>
>>  
>
>
>  


-- 
Behcet



--------------030406090700060705040707
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Hi Marco,

  In case of simple IP,  the entities such as DMA, TA and PA need to be deployed
along with the host software implemented in Simple IP hosts 

in order to have IP Paging support. Again things would be different if IPv4
or IPv6 were to be used for transport.

  If on the other hand Mobile IP is deployed  with its entities of HA, FA
and GFAs for MIPv4 or AR and MAP (or other) entities for MIPv6 and in use
at the mobile nodes then we would only add PAs with an extension software
at the mobile nodes 

in order to have IP Paging support. 

  The way interoperability is tested would be completely different for these
two (more correctly 4) different deployment scenarios.

  

  Therefore we do need to define every distinct case in distinct drafts.



  How would the scenario you talk about, assuming Simple IP, and then I find
MIP infrastructure available so let me do the registration using MIP 

fit into this? If there is MIP deployed and it supports paging I do not need
DMAs and TAs. 



  One can question the investment in Simple IP architecture which to a large
extend duplicates Mobile IP entities. This is what Srinivas was talking about.
I think that it is a valid concern.



  These are my views. 



Regards,



  



Marco Liebsch wrote:


  Hi Behcet, 
  
Behcet Sarikaya wrote: 

  
Hi Marco, 

  DMA in draft-renker is on page 51 only which is Appendix C, not the main
text which is supposed to provide the solution. 

  It is difficult to understand whether what you are saying now was what
you said or had in your original draft. Maybe this is what you wish to have
in a future draft. Then we first see the draft and then comment on it. 

  Also it is not clear from the figure and the text on Page 51 of draft-renker
how TA, PA and DMA take their places in a simple IP architecture, which takes
me back to the fact that Requirements 4.7 and 4.8 can not be satisfied in
a single one size fits all solution. 

  Hope you come to agree with this. 

 

 Not really. Location of the DMA is described on some pages in the draft. 
As we have already discovered in a discussion that for some IP moblity management
systems distributed DMAs with respective capturing support might be reasonable.
For this, the coposite architecture described in the draft might require
separating the DMA functional entity from the paging agent node. The concept
as it is also separates generic IP paging from access link specifics, allowing
attendant paging agent functional entities on access routers to map a generic
IP paging request to technology specifics. For a MIPv6 system, if you could
make use of available registration support, wouldn't you do it, if you expect
a benefit from this? That's what the draft-renker concept describes from
the 00 draft. Having (and keeping) a DMA while roaming within a paging area
as well as changing the paging area would not require registration of a different
DMA with a mobility agent. 
    
Hope this clarifies a bit. 

    
Regards, 

    
Marco 

  

  

  

  

    
  

Regards, 

  
      
Marco Liebsch wrote: 

      
Hi
again, Vinod, 
        
Vinod Kumar Choyi wrote: 

        
James, 
          
I don't think you understood what I mentioned, changing of paging
area would cause sending of BUs to HA even when MN is within the same domain.

          

 sorry, but I think you did not understand what's written in the draft. 

Please be referred to my previous reply to your concern on the concept. 

again: In case of MIPv6, HA is only involved in forwarding paging trigger 
packets to a DMA. This registration might be long-term and is indpendent of
paging areas, which are managed by TA functional entity. By the way, DMA
does not change when entering a new paging area. 
          
Marco 

  

          
So if you have smaller paging areas within
a domain, MN sends a BU to HA each time it changes an area and HMIP/RegReg
were developed to reduce the signaling. , I am not talking about HMIP/RegReg
signalling. Kindly read my message again. 

regards 

vinod 
            
James Kempf wrote: 

            

              
Vinod,


              

                
Sorry for the delay. I went throught draft-renker...., and realized

                

                
that

                

                  
in case of MIP, the HA keeps track of the PA. Each time the MN moves

                  

                  
to

                  

                    
a different paging area, it registers the PA@ with the HA. When
local-mobility management protocols/intra-domain protocols (RegReg6 or
HMIP or...) are implemented at the foreign network, and if there are
multiple PAs present within a foreign domain (which is likely to be

                    

                    
the

                    

                      
case) then changing a PA would cause the sending of binding update
messages to the HA.

                      

                      

I think this was already identified as an issue. Main issue is the
expense
of requiring the MN to come out of dormant mode, bring up its MIPv6
stack, send the BU, then go back into dormant mode. This is considerably
expensive in terms of power than what typically is the case with mobile
devices that use paging today.

So the architectural question is whether it is possible to architect the
system
such that the MN can avoid having to come completely out of dormant mode
if L2 paging support is available (of course, if there is no L2 paging
support,
then it is impossible) while at the same time requiring the mobility
protocol
(in this case MIPv6) to maintain location information even while the MN
is in dormant mode? The reason for the latter is so that there is one
protocol
whereby the MN's location state is maintained, rather than 2.


                      

                        
Intra-domain protocols were developed (even though
not standardized yet) one of the reasons being to reduce the binding
messages sent by the MN (apart from from other advantages). Depending
upon the size of the PAs (if small), then the advantage of using
HMIP/RegReg6 is reduced remarkably.

                        

                        

HMIP/RegReg were developed for a different purpose, to minimize
signaling
during handover. If the MN is asleep, then what does it care how long
the signaling takes? I would not imagine HMIP/RegReg being involved
in dormant mode signaling.


                        

                          
IMO, having paging information known to HA, when MN is in a foreign
network is not such a good idea, it should be dealt with locally and

                          

                          
the

                          

                            
HA should be agnostic to paging.

                            

                            

Why is it any different than having the HA know the CoA?


                            

                              
The other thing about the draft is that eventhough it does talk about
various scenarios and possible solutions it ends up looking more like
the requirements draft with little more specifications.
I am not in favor of this draft being adopted as the base draft.


                              

                              

Noted.

            jak


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

                              

                              

                              

                              
-- 
Behcet

  

                              

 

                              

                              
-- 
Behcet

                              

                              
                              

--------------030406090700060705040707--


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


From seamoby-admin@ietf.org  Tue Feb 26 17:52:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24036
	for ; Tue, 26 Feb 2002 17:52:25 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26053;
	Tue, 26 Feb 2002 17:40:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26028
	for ; Tue, 26 Feb 2002 17:40:56 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23811
	for ; Tue, 26 Feb 2002 17:40:52 -0500 (EST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id ; Tue, 26 Feb 2002 22:40:49 +0000
Message-ID: <3C7C0EF2.CD828B31@cs.ucl.ac.uk>
Date: Tue, 26 Feb 2002 22:40:50 +0000
From: Theo Pagtzis 
Reply-To: t.pagtzis@cs.ucl.ac.uk
Organization: UCL/Mobile Systems Group
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: Vinod Kumar Choyi 
CC: Srinivas.Sreemanthula@nokia.com, seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment 
         Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF670@daebe001.NOE.Nokia.com> <3C7AD346.2070200@alcatel.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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Hello all,

May I suggest that I would find personally unfair to go ahead with a
selection of a single solution since _none_ was satisfying in absolute
terms specific marks required for a weighted consideration as an WG
item. I personally stated the following in the evaluation team which I
would just reiterate: at this stage no protocol must be selected amongst
all. Having read all drafts I feel that none is fittest than another. I
am also talking as an evaluator that has no interest in any of them in
terms of selection. Right now the authors of the drafts needed to go
back on their drawing board and consider the comments that the
evaluation team gave (hence the output draft). The authors must rework
their solutions in the light of these comments.

A last round of evaluation must then be carried out by the same team
since it already has the initial view of the problem. A final decision
must be taken past the last changes and amendments of the DHMA protocol
solutions, which must not be disputed by anybody under objective
criteria and no arguments against the evaluators that they missed this
or did not see that. 

The results from the review would then come up as a revised draft and in
public scrutiny to the interested individuals that must be considered
objectively (no company hats) if we ever want to see something moving
forward. If the results from the criteria pass a last call from the
community then the chair will announce the protocol that dominates
overall in marks. Then we proceed and take it further.

Alternatively the authors of the draft get together and they build a
single protocol by unifying the concepts that the evaluation team found
to stand out from each proposal. The authors converge and bring their
elements together in a single solution that is decided if to be
independent of any mobility protocol or not.

The chair declares a concensus on the matter, a single protocol is
defined and considered an WG item. 

We can then proceed in peace and evolution of the DHMA solution.

Please consider..


regards

Theo
UCL/Mobile Systems

Vinod Kumar Choyi wrote:
> 
> Srinivas,
> 
> Mobile devices  (that do not have any home or do not use MIP)could
> also use just Simple IP, but I agree with you that the emphasis should
> be more on mobility.
> 
> regards
> vinod
> 
> Srinivas.Sreemanthula@nokia.com wrote:
> 
> > Bechet,
> > You are stretching your interpretation of my mail and presenting as
> > my views.
> > 1. There may be a solution that fits all. I am not against it. But
> > who wants to use simple-ip? "Independence to mobility protocol" was
> > a key point in decision making, as indicated in the
> > paging-assessment draft.  Paging protocol is most likely will always
> > be used with mobile devices, hence the successful and wide
> > acceptance of paging protocol depends on a solution that takes more
> > of mobility into consideration. Sacrificing this point may well make
> > the final paging protocol not so useful, at best.
> > 2. I am not particularly inclined for HA based solutions. My point
> > is, while defining a mobility based paging protocol we should not
> > take a particular LMM method (for e.g. HMIPv6) as  solution, like
> > draft-sarikaya. But instead a generalised LMM approach. HA based
> > solution will also be needed for non-LMM cases.
> > Srini
> > -----Original Message-----
> > From: e
> > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > Sent: 25 February, 2002 9:32 AM
> > To: seamoby@ietf.org
> > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > Assessment Draft
> > Dear all,
> >   Several mails have been sent over the weekend I'll try to give my
> > views in one mail.
> > Regarding Srinivas' email, my understanding is that he is against
> > Alternative 1 (one size fits all solution) and he is for the
> > Alternative
> > 2. In that he is suggesting that we concentrate on Requirement 4.8
> > rather than 4.7. As for the drafts, he seems to be inclined to home
> > agent based architectures which is demonstrated in draft-renker.
> > This is
> > an architectural choice, I think that his choice of alternatives is
> > clear.
> >   Besides, I think that the chairs would like to choose draft/drafts
> > a
> > s
> > soon as possible and ask people to submit their 01 drafts by March
> > 1st
> > and move on. We do not have a lot of time for doing this.
> > Regarding Yoshi's email, I am quoting the abstract of RFC 3103:
> >
> >> This document presents a protocol with which to implement Realm
> >>    Specific IP (RSIP).  The protocol defined herein allows
> >> negotiation
> >>    of resources between an RSIP host and gateway, so that the host
> >> can
> >>    lease some of the gateway's addressing parameters in order to
> >>    establish a global network presence.  This protocol is designed
> >> to
> >>    operate on the application layer and to use its own TCP or UDP
> >> port.
> >>    In particular, the protocol allows a gateway to allocate
> >> addressing
> >>    and control parameters to a host such that a flow policy can be
> >>    enforced at the gateway.
> >>
> > Yoshi, I think that the functionalities summarized above of RSIP
> > have
> > nothing to do with IP Paging. Can we define a port specific to  IP
> > Paging , if yes then how does IP Paging capture all packets to the
> > dormant hosts?
> > Added to this, please see Pars' email,
> >
> >> This is serious, because "paging" which is intended for
> >> optimizing bandwidth use, may become a bandwidth threat.
> >> IP layer solutions may be necessary. This is, perhaps, one more
> >> motivation for IP paging.
> >>
> > Let us get motivated for IP Paging.
> > Regards,
> > Srinivas.Sreemanthula@nokia.com wrote:
> >

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


From seamoby-admin@ietf.org  Tue Feb 26 18:17:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24667
	for ; Tue, 26 Feb 2002 18:17:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27213;
	Tue, 26 Feb 2002 18:06:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27182
	for ; Tue, 26 Feb 2002 18:06:24 -0500 (EST)
Received: from hotmail.com (f62.law9.hotmail.com [64.4.9.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24401
	for ; Tue, 26 Feb 2002 18:06:20 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 26 Feb 2002 15:05:54 -0800
Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP;
	Tue, 26 Feb 2002 23:05:54 GMT
X-Originating-IP: [63.78.179.4]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments
Date: Tue, 26 Feb 2002 18:05:54 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 26 Feb 2002 23:05:54.0590 (UTC) FILETIME=[2485FBE0:01C1BF1A]
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org




Madjis,
My comments are inline.
Regards,
Govind.

>------> It is a SHOULD right now.. so that settles this issue then.
>
>Madjid>OK. However, remember that the original attraction of
>CAR as a protocol will be greatly diminished (IMHO) if it can't
>handle inter-domain.
>

----> Thats why we  have to decide whether it is a SHOULD or a MUST.


[snip]
>
>Madjid>> Well, not quite, there are two issues, first
>The AR-AR SA is a big IF, in case of inter-domain (I am guessing
>you are dealing with more than just one new AR, right). Now, since
>inter-domain is a should, I give up on this, lets move to the second
>issue, you seem to be assuming that from oldAR-MN and oldAR-NewAR
>SA you can deduce newAR-MN SA? How, you said that CAR comes before
>Context transfer.


------> Agreed that old AR - new AR SA maybe a toughie, maybe SIKED can help 
us with this :)

But once that is established we can have two tunnels is it not? One tunnel 
to the old AR from the MN and then another tunnel to the new AR. Ofcourse, 
this is a trivial solution and may not be the optimal way to go, but wont 
this work?


[snip]
>Madjid>> Good point on capability issue,
>  but see my previous comment on security. BTW, did you agree on
>the policy issue, that I mentioned in previous email (above)?


-----> I agree that policy information may be important to transfer.
I also agree that nothing special signalling is required for policy as you 
seem to point out.






_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


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


From seamoby-admin@ietf.org  Tue Feb 26 18:20:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24731
	for ; Tue, 26 Feb 2002 18:20:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27363;
	Tue, 26 Feb 2002 18:09:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27295
	for ; Tue, 26 Feb 2002 18:09:40 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24491
	for ; Tue, 26 Feb 2002 18:09:36 -0500 (EST)
From: Dirk.Trossen@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QNBjx26055
	for ; Tue, 26 Feb 2002 17:11:45 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 26 Feb 2002 17:09:40 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 26 Feb 2002 17:08:28 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments
Date: Tue, 26 Feb 2002 18:08:27 -0500
Message-ID: 
Thread-Topic: [Seamoby] CAR Discovery Requirements ... Call for Comments
Thread-Index: AcG+W8/efSD2VDx+TGeXh4pSrwl0xAAvDfUg
To: 
Cc: 
X-OriginalArrivalTime: 26 Feb 2002 23:08:28.0118 (UTC) FILETIME=[80087F60:01C1BF1A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA27296
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 8bit

Hi Madjid,

thanks for your response, see comments below.

> -----Original Message-----
> From: ext Nakhjiri Madjid-MNAKHJI1 
> [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Monday,February 25,2002 7:23 PM
> To: Trossen Dirk (NRC/Boston); Nakhjiri Madjid-MNAKHJI1
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] CAR Discovery Requirements ... Call 
> for Comments
> 
> 
> Dirk,
> 
> Thanks for your email, see below.
> 
> BR,
> Madjid
> 
> -----Original Message-----
> From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> Sent: Monday, February 25, 2002 7:37 AM
> To: Madjid Nakhjiri
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] CAR Discovery Requirements ... Call 
> for Comments
> 
> 
> Hi Madjid,
> 
> Thanks for your comments, see my comments inline.
> 
> > 1-I didn't see any security requirements, it depends on how
> > much of the policy and capability information can be shared
> > with the MN, one example is the location and info of all the 
> > network management units behind the ARs, another is the network
> > topology information.
> 
> I don't quite understand what you're exactly after. The cap. 
> information 
> as such is to be tranfered in a secure manner which is 
> included in the 
> requirements. The question whether it makes sense to share 
> said information 
> with an MN is a different discussion. It is up to the AR (as a member
> of a particular domain) to share information. If the AR is revealing 
> such sensitive information, it is not the problem of CAR discovery,
> apart from the mere transfer aspect.
> 
> Madjid>> I responded to Govind on this issue. However, to respond
> to the above, my issue is, say the MN needs some information before
> the handover, that the AR thinks it is too sensitive to be 
> shared, then
> the whole thing would fall apart in an inter-domain scenario??

In an MN-based decision approach, the selection of a TAR is still possible
in general since it is always under the constraint of the revealed
information. It is certainly true that this constraint is more stringent
in the N case. But that's a drawback which lies in the fact to put the 
decision in the MN. You could do this also in the AR. 

> 
> > 
> > 2-since CAR is carrying capability information (I am guessing
> > this would also mean availibility of resources) then signaling
> > of network policies might be an issue. I did not see any info
> > on policy.
> 
> CAR discovery is supposed to cover capability information exchange.
> However, it is not within the scope of CAR WHICH information 
> eventually
> will be transfered. But in the problem statement, exchange of policy
> information is mentioned as an example what could be exchanged in such
> capability transfer. I don't think that we have to put this again in
> the requirements draft.
> 
> Madjid>> Sounds fair. However, If you need an AR-AR signaling,
> you can extend Context transfer to handle capability (this
> was discussed a lot last year). if you need
> AR-MN signaling  you would still have the issue of AR-MN trust.  
> 
> Just a thought,

I don't want to go too much into using context transfer for
AR capability transfer since it is certainly not the scope of
CT to do this. Though I'm not saying that the pure transfer of 
the capabilities is much different from the transport of context.
But with this thinking, you probably have to redefine lots of CT
requirements (I'm not that much in this to explicitly point out which
ones) to cover AR-related information exchange in general.

Right now, the requirements cover the capability exchange which is
meant to happen between ARs. As for a capability transfer from the
AR to an MN for performing a TAR selection in the MN, we could 
incorporate this by extending requirement 3.4 in the way that
each transfer of capability information within CAR has to happen
in a secure manner. We should probably then also rename the heading
of 3.4 in 'capability transfer'. You should also keep in mind that
that the MN gets the information from the old AR, so it is enough
to an SA between MN and old AR. The old AR (hopefully) has information
regarding the potential new ARs (AKA CARs) which are then transferred
to the MN. I have to admit that I didn't get your comment in a mail
to Govind that you need an MN-newAR SA? For what is this in the 
context of CAR. CAR discovery is meant to determine the new AR, so
why should I have an SA to this entity in the process of CAR??

Regarding the inter-domain SHOULD issue, I agree that CAR without
inter-domain reduces the relevance of CAR a lot. That's why I think
that MUST is better.

Regards,



Dirk

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


From seamoby-admin@ietf.org  Tue Feb 26 19:39:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26444
	for ; Tue, 26 Feb 2002 19:39:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01069;
	Tue, 26 Feb 2002 19:21:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01042
	for ; Tue, 26 Feb 2002 19:21:22 -0500 (EST)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26159
	for ; Tue, 26 Feb 2002 19:21:19 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1R0KpX15225
	for ; Tue, 26 Feb 2002 18:20:51 -0600 (CST)
Message-ID: <3C7C2662.5050804@alcatel.com>
Date: Tue, 26 Feb 2002 18:20:50 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment          Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF670@daebe001.NOE.Nokia.com> <3C7AD346.2070200@alcatel.com> <3C7C0EF2.CD828B31@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Hello Theo,
  Good to hear from you, the last evaluator has finally spoken out.

My only comment is that your assumption of a single solution 
unfortunately does not consider the discussion on Requirements 4.7 and 4.8.

If there must be several DHMA protocols to be developed, you still would 
recommend that we go through the formal procedure you outlined for each 
separately?

People will say may be it is too much.

Regards,


Theo Pagtzis wrote:

>Hello all,
>
>May I suggest that I would find personally unfair to go ahead with a
>selection of a single solution since _none_ was satisfying in absolute
>terms specific marks required for a weighted consideration as an WG
>item. I personally stated the following in the evaluation team which I
>would just reiterate: at this stage no protocol must be selected amongst
>all. Having read all drafts I feel that none is fittest than another. I
>am also talking as an evaluator that has no interest in any of them in
>terms of selection. Right now the authors of the drafts needed to go
>back on their drawing board and consider the comments that the
>evaluation team gave (hence the output draft). The authors must rework
>their solutions in the light of these comments.
>
>A last round of evaluation must then be carried out by the same team
>since it already has the initial view of the problem. A final decision
>must be taken past the last changes and amendments of the DHMA protocol
>solutions, which must not be disputed by anybody under objective
>criteria and no arguments against the evaluators that they missed this
>or did not see that. 
>
>The results from the review would then come up as a revised draft and in
>public scrutiny to the interested individuals that must be considered
>objectively (no company hats) if we ever want to see something moving
>forward. If the results from the criteria pass a last call from the
>community then the chair will announce the protocol that dominates
>overall in marks. Then we proceed and take it further.
>
>Alternatively the authors of the draft get together and they build a
>single protocol by unifying the concepts that the evaluation team found
>to stand out from each proposal. The authors converge and bring their
>elements together in a single solution that is decided if to be
>independent of any mobility protocol or not.
>
>The chair declares a concensus on the matter, a single protocol is
>defined and considered an WG item. 
>
>We can then proceed in peace and evolution of the DHMA solution.
>
>Please consider..
>
>
>regards
>
>Theo
>UCL/Mobile Systems
>
--behcet

>



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


From seamoby-admin@ietf.org  Tue Feb 26 19:44:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26525
	for ; Tue, 26 Feb 2002 19:44:08 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01158;
	Tue, 26 Feb 2002 19:22:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01131
	for ; Tue, 26 Feb 2002 19:22:36 -0500 (EST)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26166
	for ; Tue, 26 Feb 2002 19:22:33 -0500 (EST)
From: Srinivas.Sreemanthula@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R0M3303759
	for ; Wed, 27 Feb 2002 02:22:03 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 27 Feb 2002 02:22:30 +0200
Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 27 Feb 2002 02:22:27 +0200
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 26 Feb 2002 18:22:10 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment         Draft
Date: Tue, 26 Feb 2002 18:21:24 -0600
Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment         Draft
Thread-Index: AcG/FqwV2DGrw85LTU6ykx2lOzGumQACpEhw
To: , 
Cc: 
X-OriginalArrivalTime: 27 Feb 2002 00:22:10.0706 (UTC) FILETIME=[CC19DF20:01C1BF24]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA01132
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 8bit

I agree with Theo that no single draft qualifies as a base proposal on it's own. But, rewriting individual proposals and reevaluating will leave us again in the same situation as before, wasting valuable time.  Instead, we can speed up things by converging what we have and improvising on the common solution. 

I ask the WG to rethink if we actually need paging for simple-ip cases. I posed this question before, from lack of responses, I see that no one seems to have interest in it. Now, the WG should put more importance on the mobility requirement (4.8). 

With emphasis on mobility, draft-renker does not have a better solution than others. As a matter of fact (also as the  draft-renker evaluator), I can comment that it falls short of complete description of the protocol behaviour in the implicit (mipv6) mode. Therefore, the best approach would be to choose the strongest mobility based proposals and combine them into one single proposal. 

Thanks,
Srini

-----Original Message-----
From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
Sent: 26 February, 2002 4:41 PM
To: Vinod Kumar Choyi
Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


Hello all,

May I suggest that I would find personally unfair to go ahead with a
selection of a single solution since _none_ was satisfying in absolute
terms specific marks required for a weighted consideration as an WG
item. I personally stated the following in the evaluation team which I
would just reiterate: at this stage no protocol must be selected amongst
all. Having read all drafts I feel that none is fittest than another. I
am also talking as an evaluator that has no interest in any of them in
terms of selection. Right now the authors of the drafts needed to go
back on their drawing board and consider the comments that the
evaluation team gave (hence the output draft). The authors must rework
their solutions in the light of these comments.

A last round of evaluation must then be carried out by the same team
since it already has the initial view of the problem. A final decision
must be taken past the last changes and amendments of the DHMA protocol
solutions, which must not be disputed by anybody under objective
criteria and no arguments against the evaluators that they missed this
or did not see that. 

The results from the review would then come up as a revised draft and in
public scrutiny to the interested individuals that must be considered
objectively (no company hats) if we ever want to see something moving
forward. If the results from the criteria pass a last call from the
community then the chair will announce the protocol that dominates
overall in marks. Then we proceed and take it further.

Alternatively the authors of the draft get together and they build a
single protocol by unifying the concepts that the evaluation team found
to stand out from each proposal. The authors converge and bring their
elements together in a single solution that is decided if to be
independent of any mobility protocol or not.

The chair declares a concensus on the matter, a single protocol is
defined and considered an WG item. 

We can then proceed in peace and evolution of the DHMA solution.

Please consider..


regards

Theo
UCL/Mobile Systems

Vinod Kumar Choyi wrote:
> 
> Srinivas,
> 
> Mobile devices  (that do not have any home or do not use MIP)could
> also use just Simple IP, but I agree with you that the emphasis should
> be more on mobility.
> 
> regards
> vinod
> 
> Srinivas.Sreemanthula@nokia.com wrote:
> 
> > Bechet,
> > You are stretching your interpretation of my mail and presenting as
> > my views.
> > 1. There may be a solution that fits all. I am not against it. But
> > who wants to use simple-ip? "Independence to mobility protocol" was
> > a key point in decision making, as indicated in the
> > paging-assessment draft.  Paging protocol is most likely will always
> > be used with mobile devices, hence the successful and wide
> > acceptance of paging protocol depends on a solution that takes more
> > of mobility into consideration. Sacrificing this point may well make
> > the final paging protocol not so useful, at best.
> > 2. I am not particularly inclined for HA based solutions. My point
> > is, while defining a mobility based paging protocol we should not
> > take a particular LMM method (for e.g. HMIPv6) as  solution, like
> > draft-sarikaya. But instead a generalised LMM approach. HA based
> > solution will also be needed for non-LMM cases.
> > Srini
> > -----Original Message-----
> > From: e
> > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > Sent: 25 February, 2002 9:32 AM
> > To: seamoby@ietf.org
> > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > Assessment Draft
> > Dear all,
> >   Several mails have been sent over the weekend I'll try to give my
> > views in one mail.
> > Regarding Srinivas' email, my understanding is that he is against
> > Alternative 1 (one size fits all solution) and he is for the
> > Alternative
> > 2. In that he is suggesting that we concentrate on Requirement 4.8
> > rather than 4.7. As for the drafts, he seems to be inclined to home
> > agent based architectures which is demonstrated in draft-renker.
> > This is
> > an architectural choice, I think that his choice of alternatives is
> > clear.
> >   Besides, I think that the chairs would like to choose draft/drafts
> > a
> > s
> > soon as possible and ask people to submit their 01 drafts by March
> > 1st
> > and move on. We do not have a lot of time for doing this.
> > Regarding Yoshi's email, I am quoting the abstract of RFC 3103:
> >
> >> This document presents a protocol with which to implement Realm
> >>    Specific IP (RSIP).  The protocol defined herein allows
> >> negotiation
> >>    of resources between an RSIP host and gateway, so that the host
> >> can
> >>    lease some of the gateway's addressing parameters in order to
> >>    establish a global network presence.  This protocol is designed
> >> to
> >>    operate on the application layer and to use its own TCP or UDP
> >> port.
> >>    In particular, the protocol allows a gateway to allocate
> >> addressing
> >>    and control parameters to a host such that a flow policy can be
> >>    enforced at the gateway.
> >>
> > Yoshi, I think that the functionalities summarized above of RSIP
> > have
> > nothing to do with IP Paging. Can we define a port specific to  IP
> > Paging , if yes then how does IP Paging capture all packets to the
> > dormant hosts?
> > Added to this, please see Pars' email,
> >
> >> This is serious, because "paging" which is intended for
> >> optimizing bandwidth use, may become a bandwidth threat.
> >> IP layer solutions may be necessary. This is, perhaps, one more
> >> motivation for IP paging.
> >>
> > Let us get motivated for IP Paging.
> > Regards,
> > Srinivas.Sreemanthula@nokia.com wrote:
> >

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


From seamoby-admin@ietf.org  Tue Feb 26 20:33:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27206
	for ; Tue, 26 Feb 2002 20:33:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03760;
	Tue, 26 Feb 2002 20:21:23 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03732
	for ; Tue, 26 Feb 2002 20:21:21 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27019
	for ; Tue, 26 Feb 2002 20:21:17 -0500 (EST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id ; Wed, 27 Feb 2002 01:21:10 +0000
Message-ID: <3C7C3487.96BD79E8@cs.ucl.ac.uk>
Date: Wed, 27 Feb 2002 01:21:11 +0000
From: Theo Pagtzis 
Reply-To: t.pagtzis@cs.ucl.ac.uk
Organization: UCL/Mobile Systems Group
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: Behcet Sarikaya 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment 
         Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF670@daebe001.NOE.Nokia.com> <3C7AD346.2070200@alcatel.com> <3C7C0EF2.CD828B31@cs.ucl.ac.uk> <3C7C2662.5050804@alcatel.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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Hello Bechet !

I wanted to see what the constituency felt about the selection process
and to be honest I was not far at all from my initial feeling. This is
not a AD prophesy sort of thing..

My recommendation for a single joint solution must be viewed in the
light of the following: We need to be specific what is meant by 4.7 i.e.
independence from Mobility protocols. Does that even include base
mobility?

What I would not like to see is reinvention of mechanisms that are
already in place for mobile IP..pretty much like static binding of
libraries in binary executable as opposed to a dynamic one...the first
solution is fatter but can stand on its own...so we need to be careful
with what is really meant independent...but _still_ lightweight..

Of course 4.8 means that you can support it but can obviously live with
out it. If it supports a mobility protocol it means that it can plug in
it, give it the information of interest and then hook off without
breaking the mobility protocol. The authors are advised to consider how
well do they do that in their solution.

Dependency on an LMM mechanism is a bit dangerous..if people expect to
enforce LMM to get paging working...I think it would be a long shot this
one..it is important to differentiate whether the proposal uses the idea
of localisation as opposed literally an LMM agent. If the two notion can
be co-located in a single entity..so the better..it fullfills also
4.8...but it must strive to satisfy 4.7 or it becomes a contradiction in
requirements.

The procedure that I outlined if we are to urge the author to go back
and revisit their designs implies that the authors have a finite time to
reconsider their designs in the face of the team recommendations. The
team will have a second round of reviews and if then the proposals stick
to the same incosistencies they will unfortunately have to be ruled
out.. unless they have strong grounds to stick to their guns..but the
constituency needs to see that ..

So we are not going to take each protocol in turn in the list and
analyse/paralyse it. The team will have to review them again and on
these ground come to a conclusion with respect to satisfying the
requirements. Since there is more than one solutions the competition is
stiff and of course there is no bending of the criteria...like "seems
good but will get better later on.."

I personaly do not believe it is too much. In fact if I consider the
bandwidth spend on the deliberations about which DHMA proto and why...I
believe we would have finished by now... :)

cheers

Theo
UCL/Mobile Systems

Behcet Sarikaya wrote:
> 
> Hello Theo,
>   Good to hear from you, the last evaluator has finally spoken out.
> 
> My only comment is that your assumption of a single solution
> unfortunately does not consider the discussion on Requirements 4.7 and 4.8.
> 
> If there must be several DHMA protocols to be developed, you still would
> recommend that we go through the formal procedure you outlined for each
> separately?
> 
> People will say may be it is too much.
> 
> Regards,
> 
> Theo Pagtzis wrote:
> 
> >Hello all,
> >
> >May I suggest that I would find personally unfair to go ahead with a
> >selection of a single solution since _none_ was satisfying in absolute
> >terms specific marks required for a weighted consideration as an WG
> >item. I personally stated the following in the evaluation team which I
> >would just reiterate: at this stage no protocol must be selected amongst
> >all. Having read all drafts I feel that none is fittest than another. I
> >am also talking as an evaluator that has no interest in any of them in
> >terms of selection. Right now the authors of the drafts needed to go
> >back on their drawing board and consider the comments that the
> >evaluation team gave (hence the output draft). The authors must rework
> >their solutions in the light of these comments.
> >
> >A last round of evaluation must then be carried out by the same team
> >since it already has the initial view of the problem. A final decision
> >must be taken past the last changes and amendments of the DHMA protocol
> >solutions, which must not be disputed by anybody under objective
> >criteria and no arguments against the evaluators that they missed this
> >or did not see that.
> >
> >The results from the review would then come up as a revised draft and in
> >public scrutiny to the interested individuals that must be considered
> >objectively (no company hats) if we ever want to see something moving
> >forward. If the results from the criteria pass a last call from the
> >community then the chair will announce the protocol that dominates
> >overall in marks. Then we proceed and take it further.
> >
> >Alternatively the authors of the draft get together and they build a
> >single protocol by unifying the concepts that the evaluation team found
> >to stand out from each proposal. The authors converge and bring their
> >elements together in a single solution that is decided if to be
> >independent of any mobility protocol or not.
> >
> >The chair declares a concensus on the matter, a single protocol is
> >defined and considered an WG item.
> >
> >We can then proceed in peace and evolution of the DHMA solution.
> >
> >Please consider..
> >
> >
> >regards
> >
> >Theo
> >UCL/Mobile Systems
> >
> --behcet
> 
> >
> 
> _______________________________________________
> 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  Tue Feb 26 20:35:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27241
	for ; Tue, 26 Feb 2002 20:35:47 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03926;
	Tue, 26 Feb 2002 20:25:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03895
	for ; Tue, 26 Feb 2002 20:25:09 -0500 (EST)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27097
	for ; Tue, 26 Feb 2002 20:25:06 -0500 (EST)
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1R1OQd1020477;
	Tue, 26 Feb 2002 20:24:27 -0500 (EST)
Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id UAA03617;
	Tue, 26 Feb 2002 20:24:20 -0500 (EST)
Date: Tue, 26 Feb 2002 20:24:25 -0500
To: Srinivas.Sreemanthula@nokia.com
Cc: t.pagtzis@cs.ucl.ac.uk, vinod.choyi@alcatel.com, seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment         Draft
Message-ID: <20020227012425.GA2323@catfish>
Mail-Followup-To: Srinivas.Sreemanthula@nokia.com, t.pagtzis@cs.ucl.ac.uk,
	vinod.choyi@alcatel.com, seamoby@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
User-Agent: Mutt/1.3.27i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 174
X-Virus-Scanned: by AMaViS-perl11-milter
 (http://amavis.org/)
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


DHMA for simple-ip is needed for office and home environments
especically for the purpose of filtering unimportant packets while a
host is dormant, and different filtering rule should be able to be
applied to different hosts.  I don't understand why we should not
support easier case (supporting DMHA for simple-ip hosts is much
easier than supporting DMHA for mobile hosts).

Yoshihiro Ohba


In-Reply-To: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com>

On Tue, Feb 26, 2002 at 06:21:24PM -0600, Srinivas.Sreemanthula@nokia.com wrote:
> I agree with Theo that no single draft qualifies as a base proposal on it's own. But, rewriting individual proposals and reevaluating will leave us again in the same situation as before, wasting valuable time.  Instead, we can speed up things by converging what we have and improvising on the common solution. 
> 
> I ask the WG to rethink if we actually need paging for simple-ip cases. I posed this question before, from lack of responses, I see that no one seems to have interest in it. Now, the WG should put more importance on the mobility requirement (4.8). 

> 
> With emphasis on mobility, draft-renker does not have a better solution than others. As a matter of fact (also as the  draft-renker evaluator), I can comment that it falls short of complete description of the protocol behaviour in the implicit (mipv6) mode. Therefore, the best approach would be to choose the strongest mobility based proposals and combine them into one single proposal. 
> 
> Thanks,
> Srini
> 
> -----Original Message-----
> From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> Sent: 26 February, 2002 4:41 PM
> To: Vinod Kumar Choyi
> Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> Assessment Draft
> 
> 
> Hello all,
> 
> May I suggest that I would find personally unfair to go ahead with a
> selection of a single solution since _none_ was satisfying in absolute
> terms specific marks required for a weighted consideration as an WG
> item. I personally stated the following in the evaluation team which I
> would just reiterate: at this stage no protocol must be selected amongst
> all. Having read all drafts I feel that none is fittest than another. I
> am also talking as an evaluator that has no interest in any of them in
> terms of selection. Right now the authors of the drafts needed to go
> back on their drawing board and consider the comments that the
> evaluation team gave (hence the output draft). The authors must rework
> their solutions in the light of these comments.
> 
> A last round of evaluation must then be carried out by the same team
> since it already has the initial view of the problem. A final decision
> must be taken past the last changes and amendments of the DHMA protocol
> solutions, which must not be disputed by anybody under objective
> criteria and no arguments against the evaluators that they missed this
> or did not see that. 
> 
> The results from the review would then come up as a revised draft and in
> public scrutiny to the interested individuals that must be considered
> objectively (no company hats) if we ever want to see something moving
> forward. If the results from the criteria pass a last call from the
> community then the chair will announce the protocol that dominates
> overall in marks. Then we proceed and take it further.
> 
> Alternatively the authors of the draft get together and they build a
> single protocol by unifying the concepts that the evaluation team found
> to stand out from each proposal. The authors converge and bring their
> elements together in a single solution that is decided if to be
> independent of any mobility protocol or not.
> 
> The chair declares a concensus on the matter, a single protocol is
> defined and considered an WG item. 
> 
> We can then proceed in peace and evolution of the DHMA solution.
> 
> Please consider..
> 
> 
> regards
> 
> Theo
> UCL/Mobile Systems
> 
> Vinod Kumar Choyi wrote:
> > 
> > Srinivas,
> > 
> > Mobile devices  (that do not have any home or do not use MIP)could
> > also use just Simple IP, but I agree with you that the emphasis should
> > be more on mobility.
> > 
> > regards
> > vinod
> > 
> > Srinivas.Sreemanthula@nokia.com wrote:
> > 
> > > Bechet,
> > > You are stretching your interpretation of my mail and presenting as
> > > my views.
> > > 1. There may be a solution that fits all. I am not against it. But
> > > who wants to use simple-ip? "Independence to mobility protocol" was
> > > a key point in decision making, as indicated in the
> > > paging-assessment draft.  Paging protocol is most likely will always
> > > be used with mobile devices, hence the successful and wide
> > > acceptance of paging protocol depends on a solution that takes more
> > > of mobility into consideration. Sacrificing this point may well make
> > > the final paging protocol not so useful, at best.
> > > 2. I am not particularly inclined for HA based solutions. My point
> > > is, while defining a mobility based paging protocol we should not
> > > take a particular LMM method (for e.g. HMIPv6) as  solution, like
> > > draft-sarikaya. But instead a generalised LMM approach. HA based
> > > solution will also be needed for non-LMM cases.
> > > Srini
> > > -----Original Message-----
> > > From: e
> > > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > > Sent: 25 February, 2002 9:32 AM
> > > To: seamoby@ietf.org
> > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > > Assessment Draft
> > > Dear all,
> > >   Several mails have been sent over the weekend I'll try to give my
> > > views in one mail.
> > > Regarding Srinivas' email, my understanding is that he is against
> > > Alternative 1 (one size fits all solution) and he is for the
> > > Alternative
> > > 2. In that he is suggesting that we concentrate on Requirement 4.8
> > > rather than 4.7. As for the drafts, he seems to be inclined to home
> > > agent based architectures which is demonstrated in draft-renker.
> > > This is
> > > an architectural choice, I think that his choice of alternatives is
> > > clear.
> > >   Besides, I think that the chairs would like to choose draft/drafts
> > > a
> > > s
> > > soon as possible and ask people to submit their 01 drafts by March
> > > 1st
> > > and move on. We do not have a lot of time for doing this.
> > > Regarding Yoshi's email, I am quoting the abstract of RFC 3103:
> > >
> > >> This document presents a protocol with which to implement Realm
> > >>    Specific IP (RSIP).  The protocol defined herein allows
> > >> negotiation
> > >>    of resources between an RSIP host and gateway, so that the host
> > >> can
> > >>    lease some of the gateway's addressing parameters in order to
> > >>    establish a global network presence.  This protocol is designed
> > >> to
> > >>    operate on the application layer and to use its own TCP or UDP
> > >> port.
> > >>    In particular, the protocol allows a gateway to allocate
> > >> addressing
> > >>    and control parameters to a host such that a flow policy can be
> > >>    enforced at the gateway.
> > >>
> > > Yoshi, I think that the functionalities summarized above of RSIP
> > > have
> > > nothing to do with IP Paging. Can we define a port specific to  IP
> > > Paging , if yes then how does IP Paging capture all packets to the
> > > dormant hosts?
> > > Added to this, please see Pars' email,
> > >
> > >> This is serious, because "paging" which is intended for
> > >> optimizing bandwidth use, may become a bandwidth threat.
> > >> IP layer solutions may be necessary. This is, perhaps, one more
> > >> motivation for IP paging.
> > >>
> > > Let us get motivated for IP Paging.
> > > Regards,
> > > Srinivas.Sreemanthula@nokia.com wrote:
> > >
> 
> _______________________________________________
> 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  Tue Feb 26 20:52:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27422
	for ; Tue, 26 Feb 2002 20:52:43 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04757;
	Tue, 26 Feb 2002 20:37:48 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04690
	for ; Tue, 26 Feb 2002 20:37:45 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27262
	for ; Tue, 26 Feb 2002 20:37:41 -0500 (EST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id ; Wed, 27 Feb 2002 01:36:22 +0000
Message-ID: <3C7C3816.B73D9A9A@cs.ucl.ac.uk>
Date: Wed, 27 Feb 2002 01:36:22 +0000
From: Theo Pagtzis 
Reply-To: t.pagtzis@cs.ucl.ac.uk
Organization: UCL/Mobile Systems Group
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: Srinivas.Sreemanthula@nokia.com
CC: "vinod.choyi" , seamoby 
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment 
         Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com>
Content-Type: text/plain; charset=iso-8859-7
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Hi Srinivas,

  With all due respect I do not believe that any time is lost..even if
we asked _now_ the authors to go back and come in 4 weeks with a revised
design. In fact the authors would literally have known better and
compete in fair grounds in giving their best effort for a better
candidate..nobody can say then that they did not understand what was
meant by requirement X.Y.

Still the unified solution finds me in agreement since the fundamental
point is to get a robust design. Involvement of the individual authors
would be acknowledged and the contribution would be explicit.

The important point is to learn from the review and not repeat the same
mistakes in the next steps of the DHMA proto evolution. I am personal in
favour of a revisit in the designs by their creators since this in any
case will put solutions into perspective even for a unified one..

Regs. 

Theo
UCL/Mobile Systems


Srinivas.Sreemanthula@nokia.com wrote:
> 
> I agree with Theo that no single draft qualifies as a base proposal on it's own. But, rewriting individual proposals and reevaluating will leave us again in the same situation as before, wasting valuable time.  Instead, we can speed up things by converging what we have and improvising on the common solution.
> 
> I ask the WG to rethink if we actually need paging for simple-ip cases. I posed this question before, from lack of responses, I see that no one seems to have interest in it. Now, the WG should put more importance on the mobility requirement (4.8).
> 
> With emphasis on mobility, draft-renker does not have a better solution than others. As a matter of fact (also as the  draft-renker evaluator), I can comment that it falls short of complete description of the protocol behaviour in the implicit (mipv6) mode. Therefore, the best approach would be to choose the strongest mobility based proposals and combine them into one single proposal.
> 
> Thanks,
> Srini
> 
> -----Original Message-----
> From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> Sent: 26 February, 2002 4:41 PM
> To: Vinod Kumar Choyi
> Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> Assessment Draft
> 
> Hello all,
> 
> May I suggest that I would find personally unfair to go ahead with a
> selection of a single solution since _none_ was satisfying in absolute
> terms specific marks required for a weighted consideration as an WG
> item. I personally stated the following in the evaluation team which I
> would just reiterate: at this stage no protocol must be selected amongst
> all. Having read all drafts I feel that none is fittest than another. I
> am also talking as an evaluator that has no interest in any of them in
> terms of selection. Right now the authors of the drafts needed to go
> back on their drawing board and consider the comments that the
> evaluation team gave (hence the output draft). The authors must rework
> their solutions in the light of these comments.
> 
> A last round of evaluation must then be carried out by the same team
> since it already has the initial view of the problem. A final decision
> must be taken past the last changes and amendments of the DHMA protocol
> solutions, which must not be disputed by anybody under objective
> criteria and no arguments against the evaluators that they missed this
> or did not see that.
> 
> The results from the review would then come up as a revised draft and in
> public scrutiny to the interested individuals that must be considered
> objectively (no company hats) if we ever want to see something moving
> forward. If the results from the criteria pass a last call from the
> community then the chair will announce the protocol that dominates
> overall in marks. Then we proceed and take it further.
> 
> Alternatively the authors of the draft get together and they build a
> single protocol by unifying the concepts that the evaluation team found
> to stand out from each proposal. The authors converge and bring their
> elements together in a single solution that is decided if to be
> independent of any mobility protocol or not.
> 
> The chair declares a concensus on the matter, a single protocol is
> defined and considered an WG item.
> 
> We can then proceed in peace and evolution of the DHMA solution.
> 
> Please consider..
> 
> regards
> 
> Theo
> UCL/Mobile Systems
> 
> Vinod Kumar Choyi wrote:
> >
> > Srinivas,
> >
> > Mobile devices  (that do not have any home or do not use MIP)could
> > also use just Simple IP, but I agree with you that the emphasis should
> > be more on mobility.
> >
> > regards
> > vinod
> >
> > Srinivas.Sreemanthula@nokia.com wrote:
> >
> > > Bechet,
> > > You are stretching your interpretation of my mail and presenting as
> > > my views.
> > > 1. There may be a solution that fits all. I am not against it. But
> > > who wants to use simple-ip? "Independence to mobility protocol" was
> > > a key point in decision making, as indicated in the
> > > paging-assessment draft.  Paging protocol is most likely will always
> > > be used with mobile devices, hence the successful and wide
> > > acceptance of paging protocol depends on a solution that takes more
> > > of mobility into consideration. Sacrificing this point may well make
> > > the final paging protocol not so useful, at best.
> > > 2. I am not particularly inclined for HA based solutions. My point
> > > is, while defining a mobility based paging protocol we should not
> > > take a particular LMM method (for e.g. HMIPv6) as  solution, like
> > > draft-sarikaya. But instead a generalised LMM approach. HA based
> > > solution will also be needed for non-LMM cases.
> > > Srini
> > > -----Original Message-----
> > > From: e
> > > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > > Sent: 25 February, 2002 9:32 AM
> > > To: seamoby@ietf.org
> > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > > Assessment Draft
> > > Dear all,
> > >   Several mails have been sent over the weekend I'll try to give my
> > > views in one mail.
> > > Regarding Srinivas' email, my understanding is that he is against
> > > Alternative 1 (one size fits all solution) and he is for the
> > > Alternative
> > > 2. In that he is suggesting that we concentrate on Requirement 4.8
> > > rather than 4.7. As for the drafts, he seems to be inclined to home
> > > agent based architectures which is demonstrated in draft-renker.
> > > This is
> > > an architectural choice, I think that his choice of alternatives is
> > > clear.
> > >   Besides, I think that the chairs would like to choose draft/drafts
> > > a
> > > s
> > > soon as possible and ask people to submit their 01 drafts by March
> > > 1st
> > > and move on. We do not have a lot of time for doing this.
> > > Regarding Yoshi's email, I am quoting the abstract of RFC 3103:
> > >
> > >> This document presents a protocol with which to implement Realm
> > >>    Specific IP (RSIP).  The protocol defined herein allows
> > >> negotiation
> > >>    of resources between an RSIP host and gateway, so that the host
> > >> can
> > >>    lease some of the gateway's addressing parameters in order to
> > >>    establish a global network presence.  This protocol is designed
> > >> to
> > >>    operate on the application layer and to use its own TCP or UDP
> > >> port.
> > >>    In particular, the protocol allows a gateway to allocate
> > >> addressing
> > >>    and control parameters to a host such that a flow policy can be
> > >>    enforced at the gateway.
> > >>
> > > Yoshi, I think that the functionalities summarized above of RSIP
> > > have
> > > nothing to do with IP Paging. Can we define a port specific to  IP
> > > Paging , if yes then how does IP Paging capture all packets to the
> > > dormant hosts?
> > > Added to this, please see Pars' email,
> > >
> > >> This is serious, because "paging" which is intended for
> > >> optimizing bandwidth use, may become a bandwidth threat.
> > >> IP layer solutions may be necessary. This is, perhaps, one more
> > >> motivation for IP paging.
> > >>
> > > Let us get motivated for IP Paging.
> > > Regards,
> > > Srinivas.Sreemanthula@nokia.com wrote:
> > >
> 
> _______________________________________________
> 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  Tue Feb 26 20:52:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27434
	for ; Tue, 26 Feb 2002 20:52:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04853;
	Tue, 26 Feb 2002 20:39:47 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04824
	for ; Tue, 26 Feb 2002 20:39:45 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27290
	for ; Tue, 26 Feb 2002 20:39:41 -0500 (EST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id ; Wed, 27 Feb 2002 01:38:18 +0000
Message-ID: <3C7C388A.90B865E3@cs.ucl.ac.uk>
Date: Wed, 27 Feb 2002 01:38:18 +0000
From: Theo Pagtzis 
Reply-To: t.pagtzis@cs.ucl.ac.uk
Organization: UCL/Mobile Systems Group
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: Yoshihiro Ohba 
CC: Srinivas.Sreemanthula@nokia.com, vinod.choyi@alcatel.com, seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment 
         Draft
References: <20020227012425.GA2323@catfish>
Content-Type: text/plain; charset=iso-8859-7
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

On this I concur with Yoshi..

Regs.

Theo
UCL/MobiSys Group

Yoshihiro Ohba wrote:
> 
> DHMA for simple-ip is needed for office and home environments
> especically for the purpose of filtering unimportant packets while a
> host is dormant, and different filtering rule should be able to be
> applied to different hosts.  I don't understand why we should not
> support easier case (supporting DMHA for simple-ip hosts is much
> easier than supporting DMHA for mobile hosts).
> 
> Yoshihiro Ohba
> 
> In-Reply-To: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com>
> 
> On Tue, Feb 26, 2002 at 06:21:24PM -0600, Srinivas.Sreemanthula@nokia.com wrote:
> > I agree with Theo that no single draft qualifies as a base proposal on it's own. But, rewriting individual proposals and reevaluating will leave us again in the same situation as before, wasting valuable time.  Instead, we can speed up things by converging what we have and improvising on the common solution.
> >
> > I ask the WG to rethink if we actually need paging for simple-ip cases. I posed this question before, from lack of responses, I see that no one seems to have interest in it. Now, the WG should put more importance on the mobility requirement (4.8).
> 
> >
> > With emphasis on mobility, draft-renker does not have a better solution than others. As a matter of fact (also as the  draft-renker evaluator), I can comment that it falls short of complete description of the protocol behaviour in the implicit (mipv6) mode. Therefore, the best approach would be to choose the strongest mobility based proposals and combine them into one single proposal.
> >
> > Thanks,
> > Srini
> >
> > -----Original Message-----
> > From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> > Sent: 26 February, 2002 4:41 PM
> > To: Vinod Kumar Choyi
> > Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > Assessment Draft
> >
> >
> > Hello all,
> >
> > May I suggest that I would find personally unfair to go ahead with a
> > selection of a single solution since _none_ was satisfying in absolute
> > terms specific marks required for a weighted consideration as an WG
> > item. I personally stated the following in the evaluation team which I
> > would just reiterate: at this stage no protocol must be selected amongst
> > all. Having read all drafts I feel that none is fittest than another. I
> > am also talking as an evaluator that has no interest in any of them in
> > terms of selection. Right now the authors of the drafts needed to go
> > back on their drawing board and consider the comments that the
> > evaluation team gave (hence the output draft). The authors must rework
> > their solutions in the light of these comments.
> >
> > A last round of evaluation must then be carried out by the same team
> > since it already has the initial view of the problem. A final decision
> > must be taken past the last changes and amendments of the DHMA protocol
> > solutions, which must not be disputed by anybody under objective
> > criteria and no arguments against the evaluators that they missed this
> > or did not see that.
> >
> > The results from the review would then come up as a revised draft and in
> > public scrutiny to the interested individuals that must be considered
> > objectively (no company hats) if we ever want to see something moving
> > forward. If the results from the criteria pass a last call from the
> > community then the chair will announce the protocol that dominates
> > overall in marks. Then we proceed and take it further.
> >
> > Alternatively the authors of the draft get together and they build a
> > single protocol by unifying the concepts that the evaluation team found
> > to stand out from each proposal. The authors converge and bring their
> > elements together in a single solution that is decided if to be
> > independent of any mobility protocol or not.
> >
> > The chair declares a concensus on the matter, a single protocol is
> > defined and considered an WG item.
> >
> > We can then proceed in peace and evolution of the DHMA solution.
> >
> > Please consider..
> >
> >
> > regards
> >
> > Theo
> > UCL/Mobile Systems
> >
> > Vinod Kumar Choyi wrote:
> > >
> > > Srinivas,
> > >
> > > Mobile devices  (that do not have any home or do not use MIP)could
> > > also use just Simple IP, but I agree with you that the emphasis should
> > > be more on mobility.
> > >
> > > regards
> > > vinod
> > >
> > > Srinivas.Sreemanthula@nokia.com wrote:
> > >
> > > > Bechet,
> > > > You are stretching your interpretation of my mail and presenting as
> > > > my views.
> > > > 1. There may be a solution that fits all. I am not against it. But
> > > > who wants to use simple-ip? "Independence to mobility protocol" was
> > > > a key point in decision making, as indicated in the
> > > > paging-assessment draft.  Paging protocol is most likely will always
> > > > be used with mobile devices, hence the successful and wide
> > > > acceptance of paging protocol depends on a solution that takes more
> > > > of mobility into consideration. Sacrificing this point may well make
> > > > the final paging protocol not so useful, at best.
> > > > 2. I am not particularly inclined for HA based solutions. My point
> > > > is, while defining a mobility based paging protocol we should not
> > > > take a particular LMM method (for e.g. HMIPv6) as  solution, like
> > > > draft-sarikaya. But instead a generalised LMM approach. HA based
> > > > solution will also be needed for non-LMM cases.
> > > > Srini
> > > > -----Original Message-----
> > > > From: e
> > > > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > > > Sent: 25 February, 2002 9:32 AM
> > > > To: seamoby@ietf.org
> > > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > > > Assessment Draft
> > > > Dear all,
> > > >   Several mails have been sent over the weekend I'll try to give my
> > > > views in one mail.
> > > > Regarding Srinivas' email, my understanding is that he is against
> > > > Alternative 1 (one size fits all solution) and he is for the
> > > > Alternative
> > > > 2. In that he is suggesting that we concentrate on Requirement 4.8
> > > > rather than 4.7. As for the drafts, he seems to be inclined to home
> > > > agent based architectures which is demonstrated in draft-renker.
> > > > This is
> > > > an architectural choice, I think that his choice of alternatives is
> > > > clear.
> > > >   Besides, I think that the chairs would like to choose draft/drafts
> > > > a
> > > > s
> > > > soon as possible and ask people to submit their 01 drafts by March
> > > > 1st
> > > > and move on. We do not have a lot of time for doing this.
> > > > Regarding Yoshi's email, I am quoting the abstract of RFC 3103:
> > > >
> > > >> This document presents a protocol with which to implement Realm
> > > >>    Specific IP (RSIP).  The protocol defined herein allows
> > > >> negotiation
> > > >>    of resources between an RSIP host and gateway, so that the host
> > > >> can
> > > >>    lease some of the gateway's addressing parameters in order to
> > > >>    establish a global network presence.  This protocol is designed
> > > >> to
> > > >>    operate on the application layer and to use its own TCP or UDP
> > > >> port.
> > > >>    In particular, the protocol allows a gateway to allocate
> > > >> addressing
> > > >>    and control parameters to a host such that a flow policy can be
> > > >>    enforced at the gateway.
> > > >>
> > > > Yoshi, I think that the functionalities summarized above of RSIP
> > > > have
> > > > nothing to do with IP Paging. Can we define a port specific to  IP
> > > > Paging , if yes then how does IP Paging capture all packets to the
> > > > dormant hosts?
> > > > Added to this, please see Pars' email,
> > > >
> > > >> This is serious, because "paging" which is intended for
> > > >> optimizing bandwidth use, may become a bandwidth threat.
> > > >> IP layer solutions may be necessary. This is, perhaps, one more
> > > >> motivation for IP paging.
> > > >>
> > > > Let us get motivated for IP Paging.
> > > > Regards,
> > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > >
> >
> > _______________________________________________
> > 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  Tue Feb 26 20:54:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27455
	for ; Tue, 26 Feb 2002 20:54:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04975;
	Tue, 26 Feb 2002 20:42:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04949
	for ; Tue, 26 Feb 2002 20:42:53 -0500 (EST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27312
	for ; Tue, 26 Feb 2002 20:42:50 -0500 (EST)
From: Srinivas.Sreemanthula@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R1h7G02981
	for ; Tue, 26 Feb 2002 19:43:07 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 26 Feb 2002 19:42:51 -0600
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 26 Feb 2002 19:42:51 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment         Draft
Date: Tue, 26 Feb 2002 19:42:41 -0600
Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF674@daebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment         Draft
Thread-Index: AcG/LYVWGAUfzBSySnKsh8hRBPgb/AAAG5Ww
To: 
Cc: 
X-OriginalArrivalTime: 27 Feb 2002 01:42:51.0529 (UTC) FILETIME=[1174D790:01C1BF30]
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

I feel that using DMHA for packet filtering is an inappropriate use. This also requires that the Paging Function to determine different kinds of packets. A better way for packet filtering must be an application level functionality, we should use application (or services) level differentiation on what services are enabled when the device/host is in a certain mode (not necessarily dormant).  IMPP WG is working on presence services which will be more suitable for such differentiation.  The important requirement for DMHA is power saving (for power starving devices). Frequent mobility updates drains power and hence, DMHA.

The importance should be on mobillity. we should not support the simple-ip case just because it is easy.

Regards

-----Original Message-----
From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
Sent: 26 February, 2002 7:24 PM
To: Sreemanthula Srinivas (NRC/Dallas)
Cc: t.pagtzis@cs.ucl.ac.uk; vinod.choyi@alcatel.com; seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment Draft



DHMA for simple-ip is needed for office and home environments
especically for the purpose of filtering unimportant packets while a
host is dormant, and different filtering rule should be able to be
applied to different hosts.  I don't understand why we should not
support easier case (supporting DMHA for simple-ip hosts is much
easier than supporting DMHA for mobile hosts).

Yoshihiro Ohba


In-Reply-To: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com>

On Tue, Feb 26, 2002 at 06:21:24PM -0600, Srinivas.Sreemanthula@nokia.com wrote:
> I agree with Theo that no single draft qualifies as a base proposal on it's own. But, rewriting individual proposals and reevaluating will leave us again in the same situation as before, wasting valuable time.  Instead, we can speed up things by converging what we have and improvising on the common solution. 
> 
> I ask the WG to rethink if we actually need paging for simple-ip cases. I posed this question before, from lack of responses, I see that no one seems to have interest in it. Now, the WG should put more importance on the mobility requirement (4.8). 

> 
> With emphasis on mobility, draft-renker does not have a better solution than others. As a matter of fact (also as the  draft-renker evaluator), I can comment that it falls short of complete description of the protocol behaviour in the implicit (mipv6) mode. Therefore, the best approach would be to choose the strongest mobility based proposals and combine them into one single proposal. 
> 
> Thanks,
> Srini
> 
> -----Original Message-----
> From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> Sent: 26 February, 2002 4:41 PM
> To: Vinod Kumar Choyi
> Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> Assessment Draft
> 
> 
> Hello all,
> 
> May I suggest that I would find personally unfair to go ahead with a
> selection of a single solution since _none_ was satisfying in absolute
> terms specific marks required for a weighted consideration as an WG
> item. I personally stated the following in the evaluation team which I
> would just reiterate: at this stage no protocol must be selected amongst
> all. Having read all drafts I feel that none is fittest than another. I
> am also talking as an evaluator that has no interest in any of them in
> terms of selection. Right now the authors of the drafts needed to go
> back on their drawing board and consider the comments that the
> evaluation team gave (hence the output draft). The authors must rework
> their solutions in the light of these comments.
> 
> A last round of evaluation must then be carried out by the same team
> since it already has the initial view of the problem. A final decision
> must be taken past the last changes and amendments of the DHMA protocol
> solutions, which must not be disputed by anybody under objective
> criteria and no arguments against the evaluators that they missed this
> or did not see that. 
> 
> The results from the review would then come up as a revised draft and in
> public scrutiny to the interested individuals that must be considered
> objectively (no company hats) if we ever want to see something moving
> forward. If the results from the criteria pass a last call from the
> community then the chair will announce the protocol that dominates
> overall in marks. Then we proceed and take it further.
> 
> Alternatively the authors of the draft get together and they build a
> single protocol by unifying the concepts that the evaluation team found
> to stand out from each proposal. The authors converge and bring their
> elements together in a single solution that is decided if to be
> independent of any mobility protocol or not.
> 
> The chair declares a concensus on the matter, a single protocol is
> defined and considered an WG item. 
> 
> We can then proceed in peace and evolution of the DHMA solution.
> 
> Please consider..
> 
> 
> regards
> 
> Theo
> UCL/Mobile Systems
> 
> Vinod Kumar Choyi wrote:
> > 
> > Srinivas,
> > 
> > Mobile devices  (that do not have any home or do not use MIP)could
> > also use just Simple IP, but I agree with you that the emphasis should
> > be more on mobility.
> > 
> > regards
> > vinod
> > 
> > Srinivas.Sreemanthula@nokia.com wrote:
> > 
> > > Bechet,
> > > You are stretching your interpretation of my mail and presenting as
> > > my views.
> > > 1. There may be a solution that fits all. I am not against it. But
> > > who wants to use simple-ip? "Independence to mobility protocol" was
> > > a key point in decision making, as indicated in the
> > > paging-assessment draft.  Paging protocol is most likely will always
> > > be used with mobile devices, hence the successful and wide
> > > acceptance of paging protocol depends on a solution that takes more
> > > of mobility into consideration. Sacrificing this point may well make
> > > the final paging protocol not so useful, at best.
> > > 2. I am not particularly inclined for HA based solutions. My point
> > > is, while defining a mobility based paging protocol we should not
> > > take a particular LMM method (for e.g. HMIPv6) as  solution, like
> > > draft-sarikaya. But instead a generalised LMM approach. HA based
> > > solution will also be needed for non-LMM cases.
> > > Srini
> > > -----Original Message-----
> > > From: e
> > > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > > Sent: 25 February, 2002 9:32 AM
> > > To: seamoby@ietf.org
> > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > > Assessment Draft
> > > Dear all,
> > >   Several mails have been sent over the weekend I'll try to give my
> > > views in one mail.
> > > Regarding Srinivas' email, my understanding is that he is against
> > > Alternative 1 (one size fits all solution) and he is for the
> > > Alternative
> > > 2. In that he is suggesting that we concentrate on Requirement 4.8
> > > rather than 4.7. As for the drafts, he seems to be inclined to home
> > > agent based architectures which is demonstrated in draft-renker.
> > > This is
> > > an architectural choice, I think that his choice of alternatives is
> > > clear.
> > >   Besides, I think that the chairs would like to choose draft/drafts
> > > a
> > > s
> > > soon as possible and ask people to submit their 01 drafts by March
> > > 1st
> > > and move on. We do not have a lot of time for doing this.
> > > Regarding Yoshi's email, I am quoting the abstract of RFC 3103:
> > >
> > >> This document presents a protocol with which to implement Realm
> > >>    Specific IP (RSIP).  The protocol defined herein allows
> > >> negotiation
> > >>    of resources between an RSIP host and gateway, so that the host
> > >> can
> > >>    lease some of the gateway's addressing parameters in order to
> > >>    establish a global network presence.  This protocol is designed
> > >> to
> > >>    operate on the application layer and to use its own TCP or UDP
> > >> port.
> > >>    In particular, the protocol allows a gateway to allocate
> > >> addressing
> > >>    and control parameters to a host such that a flow policy can be
> > >>    enforced at the gateway.
> > >>
> > > Yoshi, I think that the functionalities summarized above of RSIP
> > > have
> > > nothing to do with IP Paging. Can we define a port specific to  IP
> > > Paging , if yes then how does IP Paging capture all packets to the
> > > dormant hosts?
> > > Added to this, please see Pars' email,
> > >
> > >> This is serious, because "paging" which is intended for
> > >> optimizing bandwidth use, may become a bandwidth threat.
> > >> IP layer solutions may be necessary. This is, perhaps, one more
> > >> motivation for IP paging.
> > >>
> > > Let us get motivated for IP Paging.
> > > Regards,
> > > Srinivas.Sreemanthula@nokia.com wrote:
> > >
> 
> _______________________________________________
> 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  Tue Feb 26 23:08:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01539
	for ; Tue, 26 Feb 2002 23:08:02 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10645;
	Tue, 26 Feb 2002 22:57:34 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10619
	for ; Tue, 26 Feb 2002 22:57:33 -0500 (EST)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01348
	for ; Tue, 26 Feb 2002 22:57:28 -0500 (EST)
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1R3uQd1028633;
	Tue, 26 Feb 2002 22:56:26 -0500 (EST)
Received: from localhost (tari.research.telcordia.com [207.3.232.66])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id WAA03844;
	Tue, 26 Feb 2002 22:56:20 -0500 (EST)
Date: Tue, 26 Feb 2002 22:56:23 -0500
To: Srinivas.Sreemanthula@nokia.com
Cc: yohba@tari.toshiba.com, seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment         Draft
Message-ID: <20020227035622.GA662@catfish>
Mail-Followup-To: Srinivas.Sreemanthula@nokia.com, yohba@tari.toshiba.com,
	seamoby@ietf.org
References: <07EE0E021034014F99A57B032BC9C0E50FF674@daebe001.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: <07EE0E021034014F99A57B032BC9C0E50FF674@daebe001.NOE.Nokia.com>
User-Agent: Mutt/1.3.27i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 17
X-Virus-Scanned: by AMaViS-perl11-milter
 (http://amavis.org/)
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

Hello Srini,

You seem to misunderstand something.  What I'm talking about is packet
filtering for DMHA, which is completely different from "DHMA for
packet filtering." and from instant messaging.  The goal of packet
filtering for DMHA is definitely for power saving.

Yoshihiro Ohba


On Tue, Feb 26, 2002 at 07:42:41PM -0600, Srinivas.Sreemanthula@nokia.com wrote:
> I feel that using DMHA for packet filtering is an inappropriate use. This also requires that the Paging Function to determine different kinds of packets. A better way for packet filtering must be an application level functionality, we should use application (or services) level differentiation on what services are enabled when the device/host is in a certain mode (not necessarily dormant).  IMPP WG is working on presence services which will be more suitable for such differentiation.  The important requirement for DMHA is power saving (for power starving devices). Frequent mobility updates drains power and hence, DMHA.
> 
> The importance should be on mobillity. we should not support the simple-ip case just because it is easy.
> 
> Regards
> 

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


From seamoby-admin@ietf.org  Wed Feb 27 03:57:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14072
	for ; Wed, 27 Feb 2002 03:57:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03500;
	Wed, 27 Feb 2002 03:45:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03432
	for ; Wed, 27 Feb 2002 03:45:46 -0500 (EST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13973
	for ; Wed, 27 Feb 2002 03:45:43 -0500 (EST)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g1R8j5U28609;
	Wed, 27 Feb 2002 09:45:05 +0100 (MET)
Message-ID: <3C7C9C91.C01CA2AF@inrialpes.fr>
Date: Wed, 27 Feb 2002 09:45:05 +0100
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Xiaofeng Xu 
CC: James Kempf ,
        Vinod Kumar Choyi , seamoby@ietf.org
Subject: Re: [Seamoby] Re: Where to put the TA?
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF> <3C7AD9B6.1000504@alcatel.com> <02d001c1be5c$a98970b0$7e6015ac@T23KEMPF> <3C7BBAE1.7070003@alcatel.com> <014601c1beee$29e76910$7e6015ac@T23KEMPF> <3C7C0479.3B80637E@alcatel.com>
Content-Type: multipart/alternative;
 boundary="------------F9EC03D7C7D3E44042B32DDA"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------F9EC03D7C7D3E44042B32DDA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hello,
This is not really new ...
FYI you've been working on this Paging Area size issue for IP Paging for some
time
now (wou can retrieve some papers/drafts on my web page)...
i am glad to see that people starts to understand how important this issue
is...

regards,

Claude.

Xiaofeng Xu wrote:

> Design of Paging Area size and placement of TA shall consider:
> 1) balance of registration sigalling load and paging signalling load
> 2) mobile node's mobility behaviour model
> 3) mobile node's originated and terminated traffic model
> 4) visited network distribution and configuration model
> 5) layer 2 technology characteristics
> ......
>
> There have been many studies on similar topic in cellular networks.
>
> Regards,
> Xiaofeng
>
> James Kempf wrote:
>
> > Vinod,
> >
> > > Yes, I am in favour of paging info maintained in the foreign network.
> > >
> >
> > So one argument you've made in favor of that architecture is that it
> > reduces the amount of signaling for smaller sized (like one subnet
> > sized) paging areas, right?  Any other issues?
> >
> > Have you seen Andrew Cambell's paper "P-MIP: Paging Extensions for
> > Mobile IP"? He has some measurements to show that even if you have one
> > paging area per subnet, paging signaling volume is less (and in some
> > cases, substantially less) than MIP signaling for a wide range of cells
> > per subnet. His design (for MIPv4) maintains the mobile node's location
> > information in the HA. I'm not advocating that we adopt his architecture
> > (for example, the architecture maintains the one to one mapping between
> > paging areas and subnets that we are trying to get rid of) but the
> > measurements seem convincing.
> >
> > The other issues I have with maintaining the TA in the foreign network
> > are the following:
> >
> > 1) Duplicate mobile node location information between the mobility
> > protocol and the paging protocol. This requires explicit
> > "deregistration" by the MN with the mobility protocol and "registration"
> > with the paging when  the MN goes into dormant mode, and the opposite
> > when it comes out of dormant mode. It would be desirable for the MN to
> > simply be able to time out and go to sleep.
> >
> > 2) Possibility of race conditions between the mobility protocol location
> > update and the paging protocol update. For example, what happens if a
> > packet comes in for the MN between the completion of "deregistration"
> > with the mobility protocol and "registration" with the paging protocol?
> >
> > 3) TA must maintain state associated with the MN. This leads to
> > expensive, large, stateful nodes that must be designed to be five 9's
> > reliable, instead of cheap, redundant nodes like routers are for
> > routing. In short, a telephony style node rather than an IP style node.
> >
> > There are some issues which I think having the TA in the foreign network
> > have in common with having it as part of the mobility protocol which
> > might be easier to solve:
> >
> > 1) Security. If the TA is part of the mobility protocol, it may require
> > the host to send any paging area updates to the HA for MIPv6 when it
> > moves paging area. This may increase power use on the host, and may not
> > maximally utilize L2 support. If the TA is part of the foreign network,
> > then the MN could set up a trust relationship with the TA initially
> > which allows the foreign network ARs to perform the paging area updates
> > so the MN doesn't have to wake up. This could maximize power saving and
> > increase use of L2 paging support.
> >
> > There are some issues which I think having the TA in the foreign network
> > is better:
> >
> > 1) Paging area update signaling can be confined to the network if L2
> > support w.o. IP information is available, provided the necessary trust
> > relationships are in place. This is linked to the security problem
> > above.
> >
> > And finally, there are some issues that bother me, but I can't quite put
> > my finger on how they might be a problem:
> >
> > 1) If the TA is in the foreign network and it goes down, then the
> > location information is lost. I think, using dynamic paging area
> > reconfiguration, that the MNs could be forced to reregister when this is
> > detected, but I'm not sure there isn't some other catch here.
> >
> > Comments?
> >
> >                     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

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------F9EC03D7C7D3E44042B32DDA
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Hello,

This is not really new ...

FYI you've been working on this Paging Area size issue for IP Paging
for some time

now (wou can retrieve some papers/drafts on my web page)...

i am glad to see that people starts to understand how important this
issue is...

regards,

Claude.

Xiaofeng Xu wrote:

Design of Paging Area size and placement of TA shall
consider:

1) balance of registration sigalling load and paging signalling load

2) mobile node's mobility behaviour model

3) mobile node's originated and terminated traffic model

4) visited network distribution and configuration model

5) layer 2 technology characteristics

......

There have been many studies on similar topic in cellular networks.

Regards,

Xiaofeng

James Kempf wrote:

> Vinod,

>

> > Yes, I am in favour of paging info maintained in the foreign network.

> >

>

> So one argument you've made in favor of that architecture is that
it

> reduces the amount of signaling for smaller sized (like one subnet

> sized) paging areas, right?  Any other issues?

>

> Have you seen Andrew Cambell's paper "P-MIP: Paging Extensions for

> Mobile IP"? He has some measurements to show that even if you have
one

> paging area per subnet, paging signaling volume is less (and in some

> cases, substantially less) than MIP signaling for a wide range of
cells

> per subnet. His design (for MIPv4) maintains the mobile node's location

> information in the HA. I'm not advocating that we adopt his architecture

> (for example, the architecture maintains the one to one mapping between

> paging areas and subnets that we are trying to get rid of) but the

> measurements seem convincing.

>

> The other issues I have with maintaining the TA in the foreign network

> are the following:

>

> 1) Duplicate mobile node location information between the mobility

> protocol and the paging protocol. This requires explicit

> "deregistration" by the MN with the mobility protocol and "registration"

> with the paging when  the MN goes into dormant mode, and the
opposite

> when it comes out of dormant mode. It would be desirable for the
MN to

> simply be able to time out and go to sleep.

>

> 2) Possibility of race conditions between the mobility protocol location

> update and the paging protocol update. For example, what happens
if a

> packet comes in for the MN between the completion of "deregistration"

> with the mobility protocol and "registration" with the paging protocol?

>

> 3) TA must maintain state associated with the MN. This leads to

> expensive, large, stateful nodes that must be designed to be five
9's

> reliable, instead of cheap, redundant nodes like routers are for

> routing. In short, a telephony style node rather than an IP style
node.

>

> There are some issues which I think having the TA in the foreign
network

> have in common with having it as part of the mobility protocol which

> might be easier to solve:

>

> 1) Security. If the TA is part of the mobility protocol, it may require

> the host to send any paging area updates to the HA for MIPv6 when
it

> moves paging area. This may increase power use on the host, and may
not

> maximally utilize L2 support. If the TA is part of the foreign network,

> then the MN could set up a trust relationship with the TA initially

> which allows the foreign network ARs to perform the paging area updates

> so the MN doesn't have to wake up. This could maximize power saving
and

> increase use of L2 paging support.

>

> There are some issues which I think having the TA in the foreign
network

> is better:

>

> 1) Paging area update signaling can be confined to the network if
L2

> support w.o. IP information is available, provided the necessary
trust

> relationships are in place. This is linked to the security problem

> above.

>

> And finally, there are some issues that bother me, but I can't quite
put

> my finger on how they might be a problem:

>

> 1) If the TA is in the foreign network and it goes down, then the

> location information is lost. I think, using dynamic paging area

> reconfiguration, that the MNs could be forced to reregister when
this is

> detected, but I'm not sure there isn't some other catch here.

>

> Comments?

>

>                    
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



-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------F9EC03D7C7D3E44042B32DDA--


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


From seamoby-admin@ietf.org  Wed Feb 27 04:10:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14499
	for ; Wed, 27 Feb 2002 04:10:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03989;
	Wed, 27 Feb 2002 03:58:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03960
	for ; Wed, 27 Feb 2002 03:58:31 -0500 (EST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14096
	for ; Wed, 27 Feb 2002 03:58:27 -0500 (EST)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g1R8vrU29049;
	Wed, 27 Feb 2002 09:57:53 +0100 (MET)
Message-ID: <3C7C9F90.A9315585@inrialpes.fr>
Date: Wed, 27 Feb 2002 09:57:53 +0100
From: Claude Castelluccia 
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Xiaofeng Xu ,
        James Kempf ,
        Vinod Kumar Choyi , seamoby@ietf.org
Subject: Re: [Seamoby] Re: Where to put the TA?
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF> <3C7AD9B6.1000504@alcatel.com> <02d001c1be5c$a98970b0$7e6015ac@T23KEMPF> <3C7BBAE1.7070003@alcatel.com> <014601c1beee$29e76910$7e6015ac@T23KEMPF> <3C7C0479.3B80637E@alcatel.com> <3C7C9C91.C01CA2AF@inrialpes.fr>
Content-Type: multipart/alternative;
 boundary="------------C7E130A539C51EEDEDE76E4D"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------C7E130A539C51EEDEDE76E4D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Claude Castelluccia wrote:

>
> Hello,
> This is not really new ...
> FYI you've been working on this Paging Area size issue for IP Paging
> for some time

oups i meant "we've been working..."...sorry about that ;-)

>
> now (wou can retrieve some papers/drafts on my web page)...
> i am glad to see that people starts to understand how important this
> issue is...
>
> regards,
>
> Claude.
>
> Xiaofeng Xu wrote:
>
>> Design of Paging Area size and placement of TA shall consider:
>> 1) balance of registration sigalling load and paging signalling load
>>
>> 2) mobile node's mobility behaviour model
>> 3) mobile node's originated and terminated traffic model
>> 4) visited network distribution and configuration model
>> 5) layer 2 technology characteristics
>> ......
>>
>> There have been many studies on similar topic in cellular networks.
>>
>> Regards,
>> Xiaofeng
>>
>> James Kempf wrote:
>>
>> > Vinod,
>> >
>> > > Yes, I am in favour of paging info maintained in the foreign
>> network.
>> > >
>> >
>> > So one argument you've made in favor of that architecture is that
>> it
>> > reduces the amount of signaling for smaller sized (like one subnet
>>
>> > sized) paging areas, right?  Any other issues?
>> >
>> > Have you seen Andrew Cambell's paper "P-MIP: Paging Extensions for
>>
>> > Mobile IP"? He has some measurements to show that even if you have
>> one
>> > paging area per subnet, paging signaling volume is less (and in
>> some
>> > cases, substantially less) than MIP signaling for a wide range of
>> cells
>> > per subnet. His design (for MIPv4) maintains the mobile node's
>> location
>> > information in the HA. I'm not advocating that we adopt his
>> architecture
>> > (for example, the architecture maintains the one to one mapping
>> between
>> > paging areas and subnets that we are trying to get rid of) but the
>>
>> > measurements seem convincing.
>> >
>> > The other issues I have with maintaining the TA in the foreign
>> network
>> > are the following:
>> >
>> > 1) Duplicate mobile node location information between the mobility
>>
>> > protocol and the paging protocol. This requires explicit
>> > "deregistration" by the MN with the mobility protocol and
>> "registration"
>> > with the paging when  the MN goes into dormant mode, and the
>> opposite
>> > when it comes out of dormant mode. It would be desirable for the
>> MN to
>> > simply be able to time out and go to sleep.
>> >
>> > 2) Possibility of race conditions between the mobility protocol
>> location
>> > update and the paging protocol update. For example, what happens
>> if a
>> > packet comes in for the MN between the completion of
>> "deregistration"
>> > with the mobility protocol and "registration" with the paging
>> protocol?
>> >
>> > 3) TA must maintain state associated with the MN. This leads to
>> > expensive, large, stateful nodes that must be designed to be five
>> 9's
>> > reliable, instead of cheap, redundant nodes like routers are for
>> > routing. In short, a telephony style node rather than an IP style
>> node.
>> >
>> > There are some issues which I think having the TA in the foreign
>> network
>> > have in common with having it as part of the mobility protocol
>> which
>> > might be easier to solve:
>> >
>> > 1) Security. If the TA is part of the mobility protocol, it may
>> require
>> > the host to send any paging area updates to the HA for MIPv6 when
>> it
>> > moves paging area. This may increase power use on the host, and
>> may not
>> > maximally utilize L2 support. If the TA is part of the foreign
>> network,
>> > then the MN could set up a trust relationship with the TA
>> initially
>> > which allows the foreign network ARs to perform the paging area
>> updates
>> > so the MN doesn't have to wake up. This could maximize power
>> saving and
>> > increase use of L2 paging support.
>> >
>> > There are some issues which I think having the TA in the foreign
>> network
>> > is better:
>> >
>> > 1) Paging area update signaling can be confined to the network if
>> L2
>> > support w.o. IP information is available, provided the necessary
>> trust
>> > relationships are in place. This is linked to the security problem
>>
>> > above.
>> >
>> > And finally, there are some issues that bother me, but I can't
>> quite put
>> > my finger on how they might be a problem:
>> >
>> > 1) If the TA is in the foreign network and it goes down, then the
>> > location information is lost. I think, using dynamic paging area
>> > reconfiguration, that the MNs could be forced to reregister when
>> this is
>> > detected, but I'm not sure there isn't some other catch here.
>> >
>> > Comments?
>> >
>> >                     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
>
> --
>
> ----------------------------------------
> Claude CASTELLUCCIA, INRIA Rhone-Alpes
> ph:  +33 4.76.61.52.15 (fax: 52.52)
> http://www.inrialpes.fr/planete/
>
>

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------C7E130A539C51EEDEDE76E4D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Claude Castelluccia wrote:

 

Hello,

This is not really new ...

FYI you've been working on this Paging Area size issue for IP Paging
for some time

oups i meant "we've been working..."...sorry about that ;-)

 

now (wou can retrieve some papers/drafts on my web page)...

i am glad to see that people starts to understand how important this
issue is...

regards,

Claude.

Xiaofeng Xu wrote:

Design of Paging Area size and placement of TA shall
consider:

1) balance of registration sigalling load and paging signalling load

2) mobile node's mobility behaviour model

3) mobile node's originated and terminated traffic model

4) visited network distribution and configuration model

5) layer 2 technology characteristics

......

There have been many studies on similar topic in cellular networks.

Regards,

Xiaofeng

James Kempf wrote:

> Vinod,

>

> > Yes, I am in favour of paging info maintained in the foreign network.

> >

>

> So one argument you've made in favor of that architecture is that
it

> reduces the amount of signaling for smaller sized (like one subnet

> sized) paging areas, right?  Any other issues?

>

> Have you seen Andrew Cambell's paper "P-MIP: Paging Extensions for

> Mobile IP"? He has some measurements to show that even if you have
one

> paging area per subnet, paging signaling volume is less (and in some

> cases, substantially less) than MIP signaling for a wide range of
cells

> per subnet. His design (for MIPv4) maintains the mobile node's location

> information in the HA. I'm not advocating that we adopt his architecture

> (for example, the architecture maintains the one to one mapping between

> paging areas and subnets that we are trying to get rid of) but the

> measurements seem convincing.

>

> The other issues I have with maintaining the TA in the foreign network

> are the following:

>

> 1) Duplicate mobile node location information between the mobility

> protocol and the paging protocol. This requires explicit

> "deregistration" by the MN with the mobility protocol and "registration"

> with the paging when  the MN goes into dormant mode, and the
opposite

> when it comes out of dormant mode. It would be desirable for the
MN to

> simply be able to time out and go to sleep.

>

> 2) Possibility of race conditions between the mobility protocol location

> update and the paging protocol update. For example, what happens
if a

> packet comes in for the MN between the completion of "deregistration"

> with the mobility protocol and "registration" with the paging protocol?

>

> 3) TA must maintain state associated with the MN. This leads to

> expensive, large, stateful nodes that must be designed to be five
9's

> reliable, instead of cheap, redundant nodes like routers are for

> routing. In short, a telephony style node rather than an IP style
node.

>

> There are some issues which I think having the TA in the foreign
network

> have in common with having it as part of the mobility protocol which

> might be easier to solve:

>

> 1) Security. If the TA is part of the mobility protocol, it may require

> the host to send any paging area updates to the HA for MIPv6 when
it

> moves paging area. This may increase power use on the host, and may
not

> maximally utilize L2 support. If the TA is part of the foreign network,

> then the MN could set up a trust relationship with the TA initially

> which allows the foreign network ARs to perform the paging area updates

> so the MN doesn't have to wake up. This could maximize power saving
and

> increase use of L2 paging support.

>

> There are some issues which I think having the TA in the foreign
network

> is better:

>

> 1) Paging area update signaling can be confined to the network if
L2

> support w.o. IP information is available, provided the necessary
trust

> relationships are in place. This is linked to the security problem

> above.

>

> And finally, there are some issues that bother me, but I can't quite
put

> my finger on how they might be a problem:

>

> 1) If the TA is in the foreign network and it goes down, then the

> location information is lost. I think, using dynamic paging area

> reconfiguration, that the MNs could be forced to reregister when
this is

> detected, but I'm not sure there isn't some other catch here.

>

> Comments?

>

>                    
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



-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 



-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------C7E130A539C51EEDEDE76E4D--


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


From seamoby-admin@ietf.org  Wed Feb 27 07:39:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19430
	for ; Wed, 27 Feb 2002 07:39:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15253;
	Wed, 27 Feb 2002 07:24:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15224
	for ; Wed, 27 Feb 2002 07:24:00 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17971;
	Wed, 27 Feb 2002 07:23:56 -0500 (EST)
Message-Id: <200202271223.HAA17971@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: Wed, 27 Feb 2002 07:23:56 -0500
Subject: [Seamoby] I-D ACTION:draft-mutaf-paging-threats-00.txt
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: IP Paging Threat Analysis
	Author(s)	: P. Mutaf, C. Castelluccia
	Filename	: draft-mutaf-paging-threats-00.txt
	Pages		: 17
	Date		: 26-Feb-02
	
This document is an analysis of threats that arise from using 
link layer paging technologies or IP paging in the Internet 
where denial-of-service attacks are common and easy. These 
problems fall in the scope of IP paging, since link layer paging
technologies do not have provisions for repelling such threats 
and the source of an attack may be anywhere in the Internet. In 
addition, vulnerabilities that may be added by IP paging are 
also discussed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mutaf-paging-threats-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-mutaf-paging-threats-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-mutaf-paging-threats-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:	<20020226130541.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mutaf-paging-threats-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mutaf-paging-threats-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



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


From seamoby-admin@ietf.org  Wed Feb 27 12:00:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03092
	for ; Wed, 27 Feb 2002 12:00:29 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01205;
	Wed, 27 Feb 2002 11:47:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01138
	for ; Wed, 27 Feb 2002 11:47:43 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01685
	for ; Wed, 27 Feb 2002 11:47:38 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1RGkNe10132;
	Wed, 27 Feb 2002 08:46:23 -0800 (PST)
Message-ID: <001e01c1bfae$1a1234a0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: , 
Cc: 
References: <07EE0E021034014F99A57B032BC9C0E50FF674@daebe001.NOE.Nokia.com>
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment         Draft
Date: Wed, 27 Feb 2002 08:44:47 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

I agree with Srini on this.

            jak

----- Original Message -----
From: 
To: 
Cc: 
Sent: Tuesday, February 26, 2002 5:42 PM
Subject: RE: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


> I feel that using DMHA for packet filtering is an inappropriate use.
This also requires that the Paging Function to determine different kinds
of packets. A better way for packet filtering must be an application
level functionality, we should use application (or services) level
differentiation on what services are enabled when the device/host is in
a certain mode (not necessarily dormant).  IMPP WG is working on
presence services which will be more suitable for such differentiation.
The important requirement for DMHA is power saving (for power starving
devices). Frequent mobility updates drains power and hence, DMHA.
>
> The importance should be on mobillity. we should not support the
simple-ip case just because it is easy.
>
> Regards
>
> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: 26 February, 2002 7:24 PM
> To: Sreemanthula Srinivas (NRC/Dallas)
> Cc: t.pagtzis@cs.ucl.ac.uk; vinod.choyi@alcatel.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft
>
>
>
> DHMA for simple-ip is needed for office and home environments
> especically for the purpose of filtering unimportant packets while a
> host is dormant, and different filtering rule should be able to be
> applied to different hosts.  I don't understand why we should not
> support easier case (supporting DMHA for simple-ip hosts is much
> easier than supporting DMHA for mobile hosts).
>
> Yoshihiro Ohba
>
>
> In-Reply-To:
<07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com>
>
> On Tue, Feb 26, 2002 at 06:21:24PM -0600,
Srinivas.Sreemanthula@nokia.com wrote:
> > I agree with Theo that no single draft qualifies as a base proposal
on it's own. But, rewriting individual proposals and reevaluating will
leave us again in the same situation as before, wasting valuable time.
Instead, we can speed up things by converging what we have and
improvising on the common solution.
> >
> > I ask the WG to rethink if we actually need paging for simple-ip
cases. I posed this question before, from lack of responses, I see that
no one seems to have interest in it. Now, the WG should put more
importance on the mobility requirement (4.8).
>
> >
> > With emphasis on mobility, draft-renker does not have a better
solution than others. As a matter of fact (also as the  draft-renker
evaluator), I can comment that it falls short of complete description of
the protocol behaviour in the implicit (mipv6) mode. Therefore, the best
approach would be to choose the strongest mobility based proposals and
combine them into one single proposal.
> >
> > Thanks,
> > Srini
> >
> > -----Original Message-----
> > From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> > Sent: 26 February, 2002 4:41 PM
> > To: Vinod Kumar Choyi
> > Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > Assessment Draft
> >
> >
> > Hello all,
> >
> > May I suggest that I would find personally unfair to go ahead with a
> > selection of a single solution since _none_ was satisfying in
absolute
> > terms specific marks required for a weighted consideration as an WG
> > item. I personally stated the following in the evaluation team which
I
> > would just reiterate: at this stage no protocol must be selected
amongst
> > all. Having read all drafts I feel that none is fittest than
another. I
> > am also talking as an evaluator that has no interest in any of them
in
> > terms of selection. Right now the authors of the drafts needed to go
> > back on their drawing board and consider the comments that the
> > evaluation team gave (hence the output draft). The authors must
rework
> > their solutions in the light of these comments.
> >
> > A last round of evaluation must then be carried out by the same team
> > since it already has the initial view of the problem. A final
decision
> > must be taken past the last changes and amendments of the DHMA
protocol
> > solutions, which must not be disputed by anybody under objective
> > criteria and no arguments against the evaluators that they missed
this
> > or did not see that.
> >
> > The results from the review would then come up as a revised draft
and in
> > public scrutiny to the interested individuals that must be
considered
> > objectively (no company hats) if we ever want to see something
moving
> > forward. If the results from the criteria pass a last call from the
> > community then the chair will announce the protocol that dominates
> > overall in marks. Then we proceed and take it further.
> >
> > Alternatively the authors of the draft get together and they build a
> > single protocol by unifying the concepts that the evaluation team
found
> > to stand out from each proposal. The authors converge and bring
their
> > elements together in a single solution that is decided if to be
> > independent of any mobility protocol or not.
> >
> > The chair declares a concensus on the matter, a single protocol is
> > defined and considered an WG item.
> >
> > We can then proceed in peace and evolution of the DHMA solution.
> >
> > Please consider..
> >
> >
> > regards
> >
> > Theo
> > UCL/Mobile Systems
> >
> > Vinod Kumar Choyi wrote:
> > >
> > > Srinivas,
> > >
> > > Mobile devices  (that do not have any home or do not use MIP)could
> > > also use just Simple IP, but I agree with you that the emphasis
should
> > > be more on mobility.
> > >
> > > regards
> > > vinod
> > >
> > > Srinivas.Sreemanthula@nokia.com wrote:
> > >
> > > > Bechet,
> > > > You are stretching your interpretation of my mail and presenting
as
> > > > my views.
> > > > 1. There may be a solution that fits all. I am not against it.
But
> > > > who wants to use simple-ip? "Independence to mobility protocol"
was
> > > > a key point in decision making, as indicated in the
> > > > paging-assessment draft.  Paging protocol is most likely will
always
> > > > be used with mobile devices, hence the successful and wide
> > > > acceptance of paging protocol depends on a solution that takes
more
> > > > of mobility into consideration. Sacrificing this point may well
make
> > > > the final paging protocol not so useful, at best.
> > > > 2. I am not particularly inclined for HA based solutions. My
point
> > > > is, while defining a mobility based paging protocol we should
not
> > > > take a particular LMM method (for e.g. HMIPv6) as  solution,
like
> > > > draft-sarikaya. But instead a generalised LMM approach. HA based
> > > > solution will also be needed for non-LMM cases.
> > > > Srini
> > > > -----Original Message-----
> > > > From: e
> > > > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > > > Sent: 25 February, 2002 9:32 AM
> > > > To: seamoby@ietf.org
> > > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
Paging
> > > > Assessment Draft
> > > > Dear all,
> > > >   Several mails have been sent over the weekend I'll try to give
my
> > > > views in one mail.
> > > > Regarding Srinivas' email, my understanding is that he is
against
> > > > Alternative 1 (one size fits all solution) and he is for the
> > > > Alternative
> > > > 2. In that he is suggesting that we concentrate on Requirement
4.8
> > > > rather than 4.7. As for the drafts, he seems to be inclined to
home
> > > > agent based architectures which is demonstrated in draft-renker.
> > > > This is
> > > > an architectural choice, I think that his choice of alternatives
is
> > > > clear.
> > > >   Besides, I think that the chairs would like to choose
draft/drafts
> > > > a
> > > > s
> > > > soon as possible and ask people to submit their 01 drafts by
March
> > > > 1st
> > > > and move on. We do not have a lot of time for doing this.
> > > > Regarding Yoshi's email, I am quoting the abstract of RFC 3103:
> > > >
> > > >> This document presents a protocol with which to implement Realm
> > > >>    Specific IP (RSIP).  The protocol defined herein allows
> > > >> negotiation
> > > >>    of resources between an RSIP host and gateway, so that the
host
> > > >> can
> > > >>    lease some of the gateway's addressing parameters in order
to
> > > >>    establish a global network presence.  This protocol is
designed
> > > >> to
> > > >>    operate on the application layer and to use its own TCP or
UDP
> > > >> port.
> > > >>    In particular, the protocol allows a gateway to allocate
> > > >> addressing
> > > >>    and control parameters to a host such that a flow policy can
be
> > > >>    enforced at the gateway.
> > > >>
> > > > Yoshi, I think that the functionalities summarized above of RSIP
> > > > have
> > > > nothing to do with IP Paging. Can we define a port specific to
IP
> > > > Paging , if yes then how does IP Paging capture all packets to
the
> > > > dormant hosts?
> > > > Added to this, please see Pars' email,
> > > >
> > > >> This is serious, because "paging" which is intended for
> > > >> optimizing bandwidth use, may become a bandwidth threat.
> > > >> IP layer solutions may be necessary. This is, perhaps, one more
> > > >> motivation for IP paging.
> > > >>
> > > > Let us get motivated for IP Paging.
> > > > Regards,
> > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > >
> >
> > _______________________________________________
> > 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  Wed Feb 27 12:01:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03157
	for ; Wed, 27 Feb 2002 12:01:16 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01088;
	Wed, 27 Feb 2002 11:46:14 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01057
	for ; Wed, 27 Feb 2002 11:46:13 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01574
	for ; Wed, 27 Feb 2002 11:46:08 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1RGjSe10110;
	Wed, 27 Feb 2002 08:45:28 -0800 (PST)
Message-ID: <001401c1bfad$f049a450$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: , 
Cc: "vinod.choyi" , "seamoby" 
References: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com> <3C7C3816.B73D9A9A@cs.ucl.ac.uk>
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment          Draft
Date: Wed, 27 Feb 2002 08:43:52 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

We are not debating the process. We did a concensus call on what the WG
wanted in early Feb. and the result was that concensus is for starting
with a base draft. The question now is whether there are any comments on
the assessment draft
before we send it to IESG and last call on that ended Monday. Pat and I
will be sending out an email
shortly about the results.

            jak

----- Original Message -----
From: "Theo Pagtzis" 
To: 
Cc: "vinod.choyi" ; "seamoby"

Sent: Tuesday, February 26, 2002 5:36 PM
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


> Hi Srinivas,
>
>   With all due respect I do not believe that any time is lost..even if
> we asked _now_ the authors to go back and come in 4 weeks with a
revised
> design. In fact the authors would literally have known better and
> compete in fair grounds in giving their best effort for a better
> candidate..nobody can say then that they did not understand what was
> meant by requirement X.Y.
>
> Still the unified solution finds me in agreement since the fundamental
> point is to get a robust design. Involvement of the individual authors
> would be acknowledged and the contribution would be explicit.
>
> The important point is to learn from the review and not repeat the
same
> mistakes in the next steps of the DHMA proto evolution. I am personal
in
> favour of a revisit in the designs by their creators since this in any
> case will put solutions into perspective even for a unified one..
>
> Regs.
>
> Theo
> UCL/Mobile Systems
>
>
> Srinivas.Sreemanthula@nokia.com wrote:
> >
> > I agree with Theo that no single draft qualifies as a base proposal
on it's own. But, rewriting individual proposals and reevaluating will
leave us again in the same situation as before, wasting valuable time.
Instead, we can speed up things by converging what we have and
improvising on the common solution.
> >
> > I ask the WG to rethink if we actually need paging for simple-ip
cases. I posed this question before, from lack of responses, I see that
no one seems to have interest in it. Now, the WG should put more
importance on the mobility requirement (4.8).
> >
> > With emphasis on mobility, draft-renker does not have a better
solution than others. As a matter of fact (also as the  draft-renker
evaluator), I can comment that it falls short of complete description of
the protocol behaviour in the implicit (mipv6) mode. Therefore, the best
approach would be to choose the strongest mobility based proposals and
combine them into one single proposal.
> >
> > Thanks,
> > Srini
> >
> > -----Original Message-----
> > From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> > Sent: 26 February, 2002 4:41 PM
> > To: Vinod Kumar Choyi
> > Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > Assessment Draft
> >
> > Hello all,
> >
> > May I suggest that I would find personally unfair to go ahead with a
> > selection of a single solution since _none_ was satisfying in
absolute
> > terms specific marks required for a weighted consideration as an WG
> > item. I personally stated the following in the evaluation team which
I
> > would just reiterate: at this stage no protocol must be selected
amongst
> > all. Having read all drafts I feel that none is fittest than
another. I
> > am also talking as an evaluator that has no interest in any of them
in
> > terms of selection. Right now the authors of the drafts needed to go
> > back on their drawing board and consider the comments that the
> > evaluation team gave (hence the output draft). The authors must
rework
> > their solutions in the light of these comments.
> >
> > A last round of evaluation must then be carried out by the same team
> > since it already has the initial view of the problem. A final
decision
> > must be taken past the last changes and amendments of the DHMA
protocol
> > solutions, which must not be disputed by anybody under objective
> > criteria and no arguments against the evaluators that they missed
this
> > or did not see that.
> >
> > The results from the review would then come up as a revised draft
and in
> > public scrutiny to the interested individuals that must be
considered
> > objectively (no company hats) if we ever want to see something
moving
> > forward. If the results from the criteria pass a last call from the
> > community then the chair will announce the protocol that dominates
> > overall in marks. Then we proceed and take it further.
> >
> > Alternatively the authors of the draft get together and they build a
> > single protocol by unifying the concepts that the evaluation team
found
> > to stand out from each proposal. The authors converge and bring
their
> > elements together in a single solution that is decided if to be
> > independent of any mobility protocol or not.
> >
> > The chair declares a concensus on the matter, a single protocol is
> > defined and considered an WG item.
> >
> > We can then proceed in peace and evolution of the DHMA solution.
> >
> > Please consider..
> >
> > regards
> >
> > Theo
> > UCL/Mobile Systems
> >
> > Vinod Kumar Choyi wrote:
> > >
> > > Srinivas,
> > >
> > > Mobile devices  (that do not have any home or do not use MIP)could
> > > also use just Simple IP, but I agree with you that the emphasis
should
> > > be more on mobility.
> > >
> > > regards
> > > vinod
> > >
> > > Srinivas.Sreemanthula@nokia.com wrote:
> > >
> > > > Bechet,
> > > > You are stretching your interpretation of my mail and presenting
as
> > > > my views.
> > > > 1. There may be a solution that fits all. I am not against it.
But
> > > > who wants to use simple-ip? "Independence to mobility protocol"
was
> > > > a key point in decision making, as indicated in the
> > > > paging-assessment draft.  Paging protocol is most likely will
always
> > > > be used with mobile devices, hence the successful and wide
> > > > acceptance of paging protocol depends on a solution that takes
more
> > > > of mobility into consideration. Sacrificing this point may well
make
> > > > the final paging protocol not so useful, at best.
> > > > 2. I am not particularly inclined for HA based solutions. My
point
> > > > is, while defining a mobility based paging protocol we should
not
> > > > take a particular LMM method (for e.g. HMIPv6) as  solution,
like
> > > > draft-sarikaya. But instead a generalised LMM approach. HA based
> > > > solution will also be needed for non-LMM cases.
> > > > Srini
> > > > -----Original Message-----
> > > > From: e
> > > > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > > > Sent: 25 February, 2002 9:32 AM
> > > > To: seamoby@ietf.org
> > > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
Paging
> > > > Assessment Draft
> > > > Dear all,
> > > >   Several mails have been sent over the weekend I'll try to give
my
> > > > views in one mail.
> > > > Regarding Srinivas' email, my understanding is that he is
against
> > > > Alternative 1 (one size fits all solution) and he is for the
> > > > Alternative
> > > > 2. In that he is suggesting that we concentrate on Requirement
4.8
> > > > rather than 4.7. As for the drafts, he seems to be inclined to
home
> > > > agent based architectures which is demonstrated in draft-renker.
> > > > This is
> > > > an architectural choice, I think that his choice of alternatives
is
> > > > clear.
> > > >   Besides, I think that the chairs would like to choose
draft/drafts
> > > > a
> > > > s
> > > > soon as possible and ask people to submit their 01 drafts by
March
> > > > 1st
> > > > and move on. We do not have a lot of time for doing this.
> > > > Regarding Yoshi's email, I am quoting the abstract of RFC 3103:
> > > >
> > > >> This document presents a protocol with which to implement Realm
> > > >>    Specific IP (RSIP).  The protocol defined herein allows
> > > >> negotiation
> > > >>    of resources between an RSIP host and gateway, so that the
host
> > > >> can
> > > >>    lease some of the gateway's addressing parameters in order
to
> > > >>    establish a global network presence.  This protocol is
designed
> > > >> to
> > > >>    operate on the application layer and to use its own TCP or
UDP
> > > >> port.
> > > >>    In particular, the protocol allows a gateway to allocate
> > > >> addressing
> > > >>    and control parameters to a host such that a flow policy can
be
> > > >>    enforced at the gateway.
> > > >>
> > > > Yoshi, I think that the functionalities summarized above of RSIP
> > > > have
> > > > nothing to do with IP Paging. Can we define a port specific to
IP
> > > > Paging , if yes then how does IP Paging capture all packets to
the
> > > > dormant hosts?
> > > > Added to this, please see Pars' email,
> > > >
> > > >> This is serious, because "paging" which is intended for
> > > >> optimizing bandwidth use, may become a bandwidth threat.
> > > >> IP layer solutions may be necessary. This is, perhaps, one more
> > > >> motivation for IP paging.
> > > >>
> > > > Let us get motivated for IP Paging.
> > > > Regards,
> > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > >
> >
> > _______________________________________________
> > 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  Wed Feb 27 12:07:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03528
	for ; Wed, 27 Feb 2002 12:07:50 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01608;
	Wed, 27 Feb 2002 11:55:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01581
	for ; Wed, 27 Feb 2002 11:55:40 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02724
	for ; Wed, 27 Feb 2002 11:55:35 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1RGt0e10401;
	Wed, 27 Feb 2002 08:55:00 -0800 (PST)
Message-ID: <005101c1bfaf$455a6aa0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Claude Castelluccia" ,
        "Xiaofeng Xu" 
Cc: "Vinod Kumar Choyi" , 
References:  <017c01c1be35$cec69730$7e6015ac@T23KEMPF> <3C7ACD92.4040502@alcatel.com> <028001c1be52$90f07d00$7e6015ac@T23KEMPF> <3C7AD9B6.1000504@alcatel.com> <02d001c1be5c$a98970b0$7e6015ac@T23KEMPF> <3C7BBAE1.7070003@alcatel.com> <014601c1beee$29e76910$7e6015ac@T23KEMPF> <3C7C0479.3B80637E@alcatel.com> <3C7C9C91.C01CA2AF@inrialpes.fr>
Subject: Re: [Seamoby] Re: Where to put the TA?
Date: Wed, 27 Feb 2002 08:53:24 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit


>
> Hello,
> This is not really new ...
> FYI you've been working on this Paging Area size issue for IP Paging
for some
> time
> now (wou can retrieve some papers/drafts on my web page)...
> i am glad to see that people starts to understand how important this
issue
> is...
>

Yes, and I think this is orthogonal to the architectural issue of where
to put the TA. There are two meta-choices:

1) Have the paging protocol manage the mobile's location information in
dormant mode, so there is a separate, stateful TA for paging,
2) Have the mobility protocol manage the mobile's location in dormant
mode, so the TA is bundled with and dependent on the mobility protocol.

How paging areas are maintained is a policy question, not an
architectural question (though the architecture will influence the
mechanism used to maintain paging areas).

The original list of concerns I posted was relevant to picking one of
the two choices above.

            jak

> regards,
>
> Claude.
>
> Xiaofeng Xu wrote:
>
> > Design of Paging Area size and placement of TA shall consider:
> > 1) balance of registration sigalling load and paging signalling load
> > 2) mobile node's mobility behaviour model
> > 3) mobile node's originated and terminated traffic model
> > 4) visited network distribution and configuration model
> > 5) layer 2 technology characteristics
> > ......
> >
> > There have been many studies on similar topic in cellular networks.
> >
> > Regards,
> > Xiaofeng
> >
> > James Kempf wrote:
> >
> > > Vinod,
> > >
> > > > Yes, I am in favour of paging info maintained in the foreign
network.
> > > >
> > >
> > > So one argument you've made in favor of that architecture is that
it
> > > reduces the amount of signaling for smaller sized (like one subnet
> > > sized) paging areas, right?  Any other issues?
> > >
> > > Have you seen Andrew Cambell's paper "P-MIP: Paging Extensions for
> > > Mobile IP"? He has some measurements to show that even if you have
one
> > > paging area per subnet, paging signaling volume is less (and in
some
> > > cases, substantially less) than MIP signaling for a wide range of
cells
> > > per subnet. His design (for MIPv4) maintains the mobile node's
location
> > > information in the HA. I'm not advocating that we adopt his
architecture
> > > (for example, the architecture maintains the one to one mapping
between
> > > paging areas and subnets that we are trying to get rid of) but the
> > > measurements seem convincing.
> > >
> > > The other issues I have with maintaining the TA in the foreign
network
> > > are the following:
> > >
> > > 1) Duplicate mobile node location information between the mobility
> > > protocol and the paging protocol. This requires explicit
> > > "deregistration" by the MN with the mobility protocol and
"registration"
> > > with the paging when  the MN goes into dormant mode, and the
opposite
> > > when it comes out of dormant mode. It would be desirable for the
MN to
> > > simply be able to time out and go to sleep.
> > >
> > > 2) Possibility of race conditions between the mobility protocol
location
> > > update and the paging protocol update. For example, what happens
if a
> > > packet comes in for the MN between the completion of
"deregistration"
> > > with the mobility protocol and "registration" with the paging
protocol?
> > >
> > > 3) TA must maintain state associated with the MN. This leads to
> > > expensive, large, stateful nodes that must be designed to be five
9's
> > > reliable, instead of cheap, redundant nodes like routers are for
> > > routing. In short, a telephony style node rather than an IP style
node.
> > >
> > > There are some issues which I think having the TA in the foreign
network
> > > have in common with having it as part of the mobility protocol
which
> > > might be easier to solve:
> > >
> > > 1) Security. If the TA is part of the mobility protocol, it may
require
> > > the host to send any paging area updates to the HA for MIPv6 when
it
> > > moves paging area. This may increase power use on the host, and
may not
> > > maximally utilize L2 support. If the TA is part of the foreign
network,
> > > then the MN could set up a trust relationship with the TA
initially
> > > which allows the foreign network ARs to perform the paging area
updates
> > > so the MN doesn't have to wake up. This could maximize power
saving and
> > > increase use of L2 paging support.
> > >
> > > There are some issues which I think having the TA in the foreign
network
> > > is better:
> > >
> > > 1) Paging area update signaling can be confined to the network if
L2
> > > support w.o. IP information is available, provided the necessary
trust
> > > relationships are in place. This is linked to the security problem
> > > above.
> > >
> > > And finally, there are some issues that bother me, but I can't
quite put
> > > my finger on how they might be a problem:
> > >
> > > 1) If the TA is in the foreign network and it goes down, then the
> > > location information is lost. I think, using dynamic paging area
> > > reconfiguration, that the MNs could be forced to reregister when
this is
> > > detected, but I'm not sure there isn't some other catch here.
> > >
> > > Comments?
> > >
> > >                     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
>
> --
>
> ----------------------------------------
> Claude CASTELLUCCIA, INRIA Rhone-Alpes
> ph:  +33 4.76.61.52.15 (fax: 52.52)
> http://www.inrialpes.fr/planete/
>
>
>


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


From seamoby-admin@ietf.org  Wed Feb 27 12:40:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05474
	for ; Wed, 27 Feb 2002 12:40:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04513;
	Wed, 27 Feb 2002 12:29:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04483
	for ; Wed, 27 Feb 2002 12:29:46 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04850
	for ; Wed, 27 Feb 2002 12:29:41 -0500 (EST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id ; Wed, 27 Feb 2002 17:29:11 +0000
Message-ID: <3C7D1767.D75A8D0F@cs.ucl.ac.uk>
Date: Wed, 27 Feb 2002 17:29:11 +0000
From: Theo Pagtzis 
Reply-To: t.pagtzis@cs.ucl.ac.uk
Organization: UCL/Mobile Systems Group
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: James Kempf 
CC: "Srinivas.Sreemanthula" ,
        "vinod.choyi" , seamoby 
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment 
         Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com> <3C7C3816.B73D9A9A@cs.ucl.ac.uk> <001401c1bfad$f049a450$7e6015ac@T23KEMPF>
Content-Type: text/plain; charset=iso-8859-7
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Fair enough..and what would the base draft comprize of?


Theo
UCL/MobiSys Group
James Kempf wrote:
> 
> We are not debating the process. We did a concensus call on what the WG
> wanted in early Feb. and the result was that concensus is for starting
> with a base draft. The question now is whether there are any comments on
> the assessment draft
> before we send it to IESG and last call on that ended Monday. Pat and I
> will be sending out an email
> shortly about the results.
> 
>             jak
> 
> ----- Original Message -----
> From: "Theo Pagtzis" 
> To: 
> Cc: "vinod.choyi" ; "seamoby"
> 
> Sent: Tuesday, February 26, 2002 5:36 PM
> Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> Assessment Draft
> 
> > Hi Srinivas,
> >
> >   With all due respect I do not believe that any time is lost..even if
> > we asked _now_ the authors to go back and come in 4 weeks with a
> revised
> > design. In fact the authors would literally have known better and
> > compete in fair grounds in giving their best effort for a better
> > candidate..nobody can say then that they did not understand what was
> > meant by requirement X.Y.
> >
> > Still the unified solution finds me in agreement since the fundamental
> > point is to get a robust design. Involvement of the individual authors
> > would be acknowledged and the contribution would be explicit.
> >
> > The important point is to learn from the review and not repeat the
> same
> > mistakes in the next steps of the DHMA proto evolution. I am personal
> in
> > favour of a revisit in the designs by their creators since this in any
> > case will put solutions into perspective even for a unified one..
> >
> > Regs.
> >
> > Theo
> > UCL/Mobile Systems
> >
> >
> > Srinivas.Sreemanthula@nokia.com wrote:
> > >
> > > I agree with Theo that no single draft qualifies as a base proposal
> on it's own. But, rewriting individual proposals and reevaluating will
> leave us again in the same situation as before, wasting valuable time.
> Instead, we can speed up things by converging what we have and
> improvising on the common solution.
> > >
> > > I ask the WG to rethink if we actually need paging for simple-ip
> cases. I posed this question before, from lack of responses, I see that
> no one seems to have interest in it. Now, the WG should put more
> importance on the mobility requirement (4.8).
> > >
> > > With emphasis on mobility, draft-renker does not have a better
> solution than others. As a matter of fact (also as the  draft-renker
> evaluator), I can comment that it falls short of complete description of
> the protocol behaviour in the implicit (mipv6) mode. Therefore, the best
> approach would be to choose the strongest mobility based proposals and
> combine them into one single proposal.
> > >
> > > Thanks,
> > > Srini
> > >
> > > -----Original Message-----
> > > From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> > > Sent: 26 February, 2002 4:41 PM
> > > To: Vinod Kumar Choyi
> > > Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > > Assessment Draft
> > >
> > > Hello all,
> > >
> > > May I suggest that I would find personally unfair to go ahead with a
> > > selection of a single solution since _none_ was satisfying in
> absolute
> > > terms specific marks required for a weighted consideration as an WG
> > > item. I personally stated the following in the evaluation team which
> I
> > > would just reiterate: at this stage no protocol must be selected
> amongst
> > > all. Having read all drafts I feel that none is fittest than
> another. I
> > > am also talking as an evaluator that has no interest in any of them
> in
> > > terms of selection. Right now the authors of the drafts needed to go
> > > back on their drawing board and consider the comments that the
> > > evaluation team gave (hence the output draft). The authors must
> rework
> > > their solutions in the light of these comments.
> > >
> > > A last round of evaluation must then be carried out by the same team
> > > since it already has the initial view of the problem. A final
> decision
> > > must be taken past the last changes and amendments of the DHMA
> protocol
> > > solutions, which must not be disputed by anybody under objective
> > > criteria and no arguments against the evaluators that they missed
> this
> > > or did not see that.
> > >
> > > The results from the review would then come up as a revised draft
> and in
> > > public scrutiny to the interested individuals that must be
> considered
> > > objectively (no company hats) if we ever want to see something
> moving
> > > forward. If the results from the criteria pass a last call from the
> > > community then the chair will announce the protocol that dominates
> > > overall in marks. Then we proceed and take it further.
> > >
> > > Alternatively the authors of the draft get together and they build a
> > > single protocol by unifying the concepts that the evaluation team
> found
> > > to stand out from each proposal. The authors converge and bring
> their
> > > elements together in a single solution that is decided if to be
> > > independent of any mobility protocol or not.
> > >
> > > The chair declares a concensus on the matter, a single protocol is
> > > defined and considered an WG item.
> > >
> > > We can then proceed in peace and evolution of the DHMA solution.
> > >
> > > Please consider..
> > >
> > > regards
> > >
> > > Theo
> > > UCL/Mobile Systems
> > >
> > > Vinod Kumar Choyi wrote:
> > > >
> > > > Srinivas,
> > > >
> > > > Mobile devices  (that do not have any home or do not use MIP)could
> > > > also use just Simple IP, but I agree with you that the emphasis
> should
> > > > be more on mobility.
> > > >
> > > > regards
> > > > vinod
> > > >
> > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > >
> > > > > Bechet,
> > > > > You are stretching your interpretation of my mail and presenting
> as
> > > > > my views.
> > > > > 1. There may be a solution that fits all. I am not against it.
> But
> > > > > who wants to use simple-ip? "Independence to mobility protocol"
> was
> > > > > a key point in decision making, as indicated in the
> > > > > paging-assessment draft.  Paging protocol is most likely will
> always
> > > > > be used with mobile devices, hence the successful and wide
> > > > > acceptance of paging protocol depends on a solution that takes
> more
> > > > > of mobility into consideration. Sacrificing this point may well
> make
> > > > > the final paging protocol not so useful, at best.
> > > > > 2. I am not particularly inclined for HA based solutions. My
> point
> > > > > is, while defining a mobility based paging protocol we should
> not
> > > > > take a particular LMM method (for e.g. HMIPv6) as  solution,
> like
> > > > > draft-sarikaya. But instead a generalised LMM approach. HA based
> > > > > solution will also be needed for non-LMM cases.
> > > > > Srini
> > > > > -----Original Message-----
> > > > > From: e
> > > > > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > > > > Sent: 25 February, 2002 9:32 AM
> > > > > To: seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
> Paging
> > > > > Assessment Draft
> > > > > Dear all,
> > > > >   Several mails have been sent over the weekend I'll try to give
> my
> > > > > views in one mail.
> > > > > Regarding Srinivas' email, my understanding is that he is
> against
> > > > > Alternative 1 (one size fits all solution) and he is for the
> > > > > Alternative
> > > > > 2. In that he is suggesting that we concentrate on Requirement
> 4.8
> > > > > rather than 4.7. As for the drafts, he seems to be inclined to
> home
> > > > > agent based architectures which is demonstrated in draft-renker.
> > > > > This is
> > > > > an architectural choice, I think that his choice of alternatives
> is
> > > > > clear.
> > > > >   Besides, I think that the chairs would like to choose
> draft/drafts
> > > > > a
> > > > > s
> > > > > soon as possible and ask people to submit their 01 drafts by
> March
> > > > > 1st
> > > > > and move on. We do not have a lot of time for doing this.
> > > > > Regarding Yoshi's email, I am quoting the abstract of RFC 3103:
> > > > >
> > > > >> This document presents a protocol with which to implement Realm
> > > > >>    Specific IP (RSIP).  The protocol defined herein allows
> > > > >> negotiation
> > > > >>    of resources between an RSIP host and gateway, so that the
> host
> > > > >> can
> > > > >>    lease some of the gateway's addressing parameters in order
> to
> > > > >>    establish a global network presence.  This protocol is
> designed
> > > > >> to
> > > > >>    operate on the application layer and to use its own TCP or
> UDP
> > > > >> port.
> > > > >>    In particular, the protocol allows a gateway to allocate
> > > > >> addressing
> > > > >>    and control parameters to a host such that a flow policy can
> be
> > > > >>    enforced at the gateway.
> > > > >>
> > > > > Yoshi, I think that the functionalities summarized above of RSIP
> > > > > have
> > > > > nothing to do with IP Paging. Can we define a port specific to
> IP
> > > > > Paging , if yes then how does IP Paging capture all packets to
> the
> > > > > dormant hosts?
> > > > > Added to this, please see Pars' email,
> > > > >
> > > > >> This is serious, because "paging" which is intended for
> > > > >> optimizing bandwidth use, may become a bandwidth threat.
> > > > >> IP layer solutions may be necessary. This is, perhaps, one more
> > > > >> motivation for IP paging.
> > > > >>
> > > > > Let us get motivated for IP Paging.
> > > > > Regards,
> > > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > > >
> > >
> > > _______________________________________________
> > > 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

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


From seamoby-admin@ietf.org  Wed Feb 27 13:20:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08129
	for ; Wed, 27 Feb 2002 13:20:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07447;
	Wed, 27 Feb 2002 13:06:18 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07421
	for ; Wed, 27 Feb 2002 13:06:16 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06927
	for ; Wed, 27 Feb 2002 13:06:13 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1RI5Ze13435;
	Wed, 27 Feb 2002 10:05:35 -0800 (PST)
Message-ID: <010701c1bfb9$220718f0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Cc: "Srinivas.Sreemanthula" ,
        "vinod.choyi" , "seamoby" 
References: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com> <3C7C3816.B73D9A9A@cs.ucl.ac.uk> <001401c1bfad$f049a450$7e6015ac@T23KEMPF> <3C7D1767.D75A8D0F@cs.ucl.ac.uk>
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment          Draft
Date: Wed, 27 Feb 2002 10:03:59 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

The proposal in the assessment draft is for Marco, as the WG draft
editor, to take draft-renker and work through it to revise parts that
were found lacking in the assessment, adding solutions after WG
concensus has been established on
them. In addition, a suggestion was made to have the document discuss
the network (not functional) architecture in more detail. We are
currently working  through some architectural questions on where to put
the TA and DMA, and what the relationship with the mobility protocol
should be, in a separate thread on this list.

            jak

----- Original Message -----
From: "Theo Pagtzis" 
To: "James Kempf" 
Cc: "Srinivas.Sreemanthula" ;
"vinod.choyi" ; "seamoby" 
Sent: Wednesday, February 27, 2002 9:29 AM
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


> Fair enough..and what would the base draft comprize of?
>
>
> Theo
> UCL/MobiSys Group
> James Kempf wrote:
> >
> > We are not debating the process. We did a concensus call on what the
WG
> > wanted in early Feb. and the result was that concensus is for
starting
> > with a base draft. The question now is whether there are any
comments on
> > the assessment draft
> > before we send it to IESG and last call on that ended Monday. Pat
and I
> > will be sending out an email
> > shortly about the results.
> >
> >             jak
> >
> > ----- Original Message -----
> > From: "Theo Pagtzis" 
> > To: 
> > Cc: "vinod.choyi" ; "seamoby"
> > 
> > Sent: Tuesday, February 26, 2002 5:36 PM
> > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > Assessment Draft
> >
> > > Hi Srinivas,
> > >
> > >   With all due respect I do not believe that any time is
lost..even if
> > > we asked _now_ the authors to go back and come in 4 weeks with a
> > revised
> > > design. In fact the authors would literally have known better and
> > > compete in fair grounds in giving their best effort for a better
> > > candidate..nobody can say then that they did not understand what
was
> > > meant by requirement X.Y.
> > >
> > > Still the unified solution finds me in agreement since the
fundamental
> > > point is to get a robust design. Involvement of the individual
authors
> > > would be acknowledged and the contribution would be explicit.
> > >
> > > The important point is to learn from the review and not repeat the
> > same
> > > mistakes in the next steps of the DHMA proto evolution. I am
personal
> > in
> > > favour of a revisit in the designs by their creators since this in
any
> > > case will put solutions into perspective even for a unified one..
> > >
> > > Regs.
> > >
> > > Theo
> > > UCL/Mobile Systems
> > >
> > >
> > > Srinivas.Sreemanthula@nokia.com wrote:
> > > >
> > > > I agree with Theo that no single draft qualifies as a base
proposal
> > on it's own. But, rewriting individual proposals and reevaluating
will
> > leave us again in the same situation as before, wasting valuable
time.
> > Instead, we can speed up things by converging what we have and
> > improvising on the common solution.
> > > >
> > > > I ask the WG to rethink if we actually need paging for simple-ip
> > cases. I posed this question before, from lack of responses, I see
that
> > no one seems to have interest in it. Now, the WG should put more
> > importance on the mobility requirement (4.8).
> > > >
> > > > With emphasis on mobility, draft-renker does not have a better
> > solution than others. As a matter of fact (also as the  draft-renker
> > evaluator), I can comment that it falls short of complete
description of
> > the protocol behaviour in the implicit (mipv6) mode. Therefore, the
best
> > approach would be to choose the strongest mobility based proposals
and
> > combine them into one single proposal.
> > > >
> > > > Thanks,
> > > > Srini
> > > >
> > > > -----Original Message-----
> > > > From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> > > > Sent: 26 February, 2002 4:41 PM
> > > > To: Vinod Kumar Choyi
> > > > Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> > > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
Paging
> > > > Assessment Draft
> > > >
> > > > Hello all,
> > > >
> > > > May I suggest that I would find personally unfair to go ahead
with a
> > > > selection of a single solution since _none_ was satisfying in
> > absolute
> > > > terms specific marks required for a weighted consideration as an
WG
> > > > item. I personally stated the following in the evaluation team
which
> > I
> > > > would just reiterate: at this stage no protocol must be selected
> > amongst
> > > > all. Having read all drafts I feel that none is fittest than
> > another. I
> > > > am also talking as an evaluator that has no interest in any of
them
> > in
> > > > terms of selection. Right now the authors of the drafts needed
to go
> > > > back on their drawing board and consider the comments that the
> > > > evaluation team gave (hence the output draft). The authors must
> > rework
> > > > their solutions in the light of these comments.
> > > >
> > > > A last round of evaluation must then be carried out by the same
team
> > > > since it already has the initial view of the problem. A final
> > decision
> > > > must be taken past the last changes and amendments of the DHMA
> > protocol
> > > > solutions, which must not be disputed by anybody under objective
> > > > criteria and no arguments against the evaluators that they
missed
> > this
> > > > or did not see that.
> > > >
> > > > The results from the review would then come up as a revised
draft
> > and in
> > > > public scrutiny to the interested individuals that must be
> > considered
> > > > objectively (no company hats) if we ever want to see something
> > moving
> > > > forward. If the results from the criteria pass a last call from
the
> > > > community then the chair will announce the protocol that
dominates
> > > > overall in marks. Then we proceed and take it further.
> > > >
> > > > Alternatively the authors of the draft get together and they
build a
> > > > single protocol by unifying the concepts that the evaluation
team
> > found
> > > > to stand out from each proposal. The authors converge and bring
> > their
> > > > elements together in a single solution that is decided if to be
> > > > independent of any mobility protocol or not.
> > > >
> > > > The chair declares a concensus on the matter, a single protocol
is
> > > > defined and considered an WG item.
> > > >
> > > > We can then proceed in peace and evolution of the DHMA solution.
> > > >
> > > > Please consider..
> > > >
> > > > regards
> > > >
> > > > Theo
> > > > UCL/Mobile Systems
> > > >
> > > > Vinod Kumar Choyi wrote:
> > > > >
> > > > > Srinivas,
> > > > >
> > > > > Mobile devices  (that do not have any home or do not use
MIP)could
> > > > > also use just Simple IP, but I agree with you that the
emphasis
> > should
> > > > > be more on mobility.
> > > > >
> > > > > regards
> > > > > vinod
> > > > >
> > > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > > >
> > > > > > Bechet,
> > > > > > You are stretching your interpretation of my mail and
presenting
> > as
> > > > > > my views.
> > > > > > 1. There may be a solution that fits all. I am not against
it.
> > But
> > > > > > who wants to use simple-ip? "Independence to mobility
protocol"
> > was
> > > > > > a key point in decision making, as indicated in the
> > > > > > paging-assessment draft.  Paging protocol is most likely
will
> > always
> > > > > > be used with mobile devices, hence the successful and wide
> > > > > > acceptance of paging protocol depends on a solution that
takes
> > more
> > > > > > of mobility into consideration. Sacrificing this point may
well
> > make
> > > > > > the final paging protocol not so useful, at best.
> > > > > > 2. I am not particularly inclined for HA based solutions. My
> > point
> > > > > > is, while defining a mobility based paging protocol we
should
> > not
> > > > > > take a particular LMM method (for e.g. HMIPv6) as  solution,
> > like
> > > > > > draft-sarikaya. But instead a generalised LMM approach. HA
based
> > > > > > solution will also be needed for non-LMM cases.
> > > > > > Srini
> > > > > > -----Original Message-----
> > > > > > From: e
> > > > > > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > > > > > Sent: 25 February, 2002 9:32 AM
> > > > > > To: seamoby@ietf.org
> > > > > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call
for
> > Paging
> > > > > > Assessment Draft
> > > > > > Dear all,
> > > > > >   Several mails have been sent over the weekend I'll try to
give
> > my
> > > > > > views in one mail.
> > > > > > Regarding Srinivas' email, my understanding is that he is
> > against
> > > > > > Alternative 1 (one size fits all solution) and he is for the
> > > > > > Alternative
> > > > > > 2. In that he is suggesting that we concentrate on
Requirement
> > 4.8
> > > > > > rather than 4.7. As for the drafts, he seems to be inclined
to
> > home
> > > > > > agent based architectures which is demonstrated in
draft-renker.
> > > > > > This is
> > > > > > an architectural choice, I think that his choice of
alternatives
> > is
> > > > > > clear.
> > > > > >   Besides, I think that the chairs would like to choose
> > draft/drafts
> > > > > > a
> > > > > > s
> > > > > > soon as possible and ask people to submit their 01 drafts by
> > March
> > > > > > 1st
> > > > > > and move on. We do not have a lot of time for doing this.
> > > > > > Regarding Yoshi's email, I am quoting the abstract of RFC
3103:
> > > > > >
> > > > > >> This document presents a protocol with which to implement
Realm
> > > > > >>    Specific IP (RSIP).  The protocol defined herein allows
> > > > > >> negotiation
> > > > > >>    of resources between an RSIP host and gateway, so that
the
> > host
> > > > > >> can
> > > > > >>    lease some of the gateway's addressing parameters in
order
> > to
> > > > > >>    establish a global network presence.  This protocol is
> > designed
> > > > > >> to
> > > > > >>    operate on the application layer and to use its own TCP
or
> > UDP
> > > > > >> port.
> > > > > >>    In particular, the protocol allows a gateway to allocate
> > > > > >> addressing
> > > > > >>    and control parameters to a host such that a flow policy
can
> > be
> > > > > >>    enforced at the gateway.
> > > > > >>
> > > > > > Yoshi, I think that the functionalities summarized above of
RSIP
> > > > > > have
> > > > > > nothing to do with IP Paging. Can we define a port specific
to
> > IP
> > > > > > Paging , if yes then how does IP Paging capture all packets
to
> > the
> > > > > > dormant hosts?
> > > > > > Added to this, please see Pars' email,
> > > > > >
> > > > > >> This is serious, because "paging" which is intended for
> > > > > >> optimizing bandwidth use, may become a bandwidth threat.
> > > > > >> IP layer solutions may be necessary. This is, perhaps, one
more
> > > > > >> motivation for IP paging.
> > > > > >>
> > > > > > Let us get motivated for IP Paging.
> > > > > > Regards,
> > > > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > > > >
> > > >
> > > > _______________________________________________
> > > > 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
>


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


From seamoby-admin@ietf.org  Wed Feb 27 14:48:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13580
	for ; Wed, 27 Feb 2002 14:48:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23651;
	Wed, 27 Feb 2002 14:35:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23583
	for ; Wed, 27 Feb 2002 14:35:41 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12713
	for ; Wed, 27 Feb 2002 14:35:36 -0500 (EST)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id ; Wed, 27 Feb 2002 19:35:15 +0000
Message-ID: <3C7D34F3.FC5C5CD5@cs.ucl.ac.uk>
Date: Wed, 27 Feb 2002 19:35:15 +0000
From: Theo Pagtzis 
Reply-To: t.pagtzis@cs.ucl.ac.uk
Organization: UCL/Mobile Systems Group
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: James Kempf 
CC: "Srinivas.Sreemanthula" ,
        "vinod.choyi" , seamoby 
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment 
         Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com> <3C7C3816.B73D9A9A@cs.ucl.ac.uk> <001401c1bfad$f049a450$7e6015ac@T23KEMPF> <3C7D1767.D75A8D0F@cs.ucl.ac.uk> <010701c1bfb9$220718f0$7e6015ac@T23KEMPF>
Content-Type: text/plain; charset=iso-8859-7
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit



ok.. sounds good to me then..have the other authors raised any points
that should be considered more closely beyond the TA/DMA or is that the
only thing that needs looking at..?

Theo
UCL/MobiSys Group


thanks Jak

James Kempf wrote:
> 
> The proposal in the assessment draft is for Marco, as the WG draft
> editor, to take draft-renker and work through it to revise parts that
> were found lacking in the assessment, adding solutions after WG
> concensus has been established on
> them. In addition, a suggestion was made to have the document discuss
> the network (not functional) architecture in more detail. We are
> currently working  through some architectural questions on where to put
> the TA and DMA, and what the relationship with the mobility protocol
> should be, in a separate thread on this list.
> 
>             jak
> 
> ----- Original Message -----
> From: "Theo Pagtzis" 
> To: "James Kempf" 
> Cc: "Srinivas.Sreemanthula" ;
> "vinod.choyi" ; "seamoby" 
> Sent: Wednesday, February 27, 2002 9:29 AM
> Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> Assessment Draft
> 
> > Fair enough..and what would the base draft comprize of?
> >
> >
> > Theo
> > UCL/MobiSys Group
> > James Kempf wrote:
> > >
> > > We are not debating the process. We did a concensus call on what the
> WG
> > > wanted in early Feb. and the result was that concensus is for
> starting
> > > with a base draft. The question now is whether there are any
> comments on
> > > the assessment draft
> > > before we send it to IESG and last call on that ended Monday. Pat
> and I
> > > will be sending out an email
> > > shortly about the results.
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Theo Pagtzis" 
> > > To: 
> > > Cc: "vinod.choyi" ; "seamoby"
> > > 
> > > Sent: Tuesday, February 26, 2002 5:36 PM
> > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > > Assessment Draft
> > >
> > > > Hi Srinivas,
> > > >
> > > >   With all due respect I do not believe that any time is
> lost..even if
> > > > we asked _now_ the authors to go back and come in 4 weeks with a
> > > revised
> > > > design. In fact the authors would literally have known better and
> > > > compete in fair grounds in giving their best effort for a better
> > > > candidate..nobody can say then that they did not understand what
> was
> > > > meant by requirement X.Y.
> > > >
> > > > Still the unified solution finds me in agreement since the
> fundamental
> > > > point is to get a robust design. Involvement of the individual
> authors
> > > > would be acknowledged and the contribution would be explicit.
> > > >
> > > > The important point is to learn from the review and not repeat the
> > > same
> > > > mistakes in the next steps of the DHMA proto evolution. I am
> personal
> > > in
> > > > favour of a revisit in the designs by their creators since this in
> any
> > > > case will put solutions into perspective even for a unified one..
> > > >
> > > > Regs.
> > > >
> > > > Theo
> > > > UCL/Mobile Systems
> > > >
> > > >
> > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > > >
> > > > > I agree with Theo that no single draft qualifies as a base
> proposal
> > > on it's own. But, rewriting individual proposals and reevaluating
> will
> > > leave us again in the same situation as before, wasting valuable
> time.
> > > Instead, we can speed up things by converging what we have and
> > > improvising on the common solution.
> > > > >
> > > > > I ask the WG to rethink if we actually need paging for simple-ip
> > > cases. I posed this question before, from lack of responses, I see
> that
> > > no one seems to have interest in it. Now, the WG should put more
> > > importance on the mobility requirement (4.8).
> > > > >
> > > > > With emphasis on mobility, draft-renker does not have a better
> > > solution than others. As a matter of fact (also as the  draft-renker
> > > evaluator), I can comment that it falls short of complete
> description of
> > > the protocol behaviour in the implicit (mipv6) mode. Therefore, the
> best
> > > approach would be to choose the strongest mobility based proposals
> and
> > > combine them into one single proposal.
> > > > >
> > > > > Thanks,
> > > > > Srini
> > > > >
> > > > > -----Original Message-----
> > > > > From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> > > > > Sent: 26 February, 2002 4:41 PM
> > > > > To: Vinod Kumar Choyi
> > > > > Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
> Paging
> > > > > Assessment Draft
> > > > >
> > > > > Hello all,
> > > > >
> > > > > May I suggest that I would find personally unfair to go ahead
> with a
> > > > > selection of a single solution since _none_ was satisfying in
> > > absolute
> > > > > terms specific marks required for a weighted consideration as an
> WG
> > > > > item. I personally stated the following in the evaluation team
> which
> > > I
> > > > > would just reiterate: at this stage no protocol must be selected
> > > amongst
> > > > > all. Having read all drafts I feel that none is fittest than
> > > another. I
> > > > > am also talking as an evaluator that has no interest in any of
> them
> > > in
> > > > > terms of selection. Right now the authors of the drafts needed
> to go
> > > > > back on their drawing board and consider the comments that the
> > > > > evaluation team gave (hence the output draft). The authors must
> > > rework
> > > > > their solutions in the light of these comments.
> > > > >
> > > > > A last round of evaluation must then be carried out by the same
> team
> > > > > since it already has the initial view of the problem. A final
> > > decision
> > > > > must be taken past the last changes and amendments of the DHMA
> > > protocol
> > > > > solutions, which must not be disputed by anybody under objective
> > > > > criteria and no arguments against the evaluators that they
> missed
> > > this
> > > > > or did not see that.
> > > > >
> > > > > The results from the review would then come up as a revised
> draft
> > > and in
> > > > > public scrutiny to the interested individuals that must be
> > > considered
> > > > > objectively (no company hats) if we ever want to see something
> > > moving
> > > > > forward. If the results from the criteria pass a last call from
> the
> > > > > community then the chair will announce the protocol that
> dominates
> > > > > overall in marks. Then we proceed and take it further.
> > > > >
> > > > > Alternatively the authors of the draft get together and they
> build a
> > > > > single protocol by unifying the concepts that the evaluation
> team
> > > found
> > > > > to stand out from each proposal. The authors converge and bring
> > > their
> > > > > elements together in a single solution that is decided if to be
> > > > > independent of any mobility protocol or not.
> > > > >
> > > > > The chair declares a concensus on the matter, a single protocol
> is
> > > > > defined and considered an WG item.
> > > > >
> > > > > We can then proceed in peace and evolution of the DHMA solution.
> > > > >
> > > > > Please consider..
> > > > >
> > > > > regards
> > > > >
> > > > > Theo
> > > > > UCL/Mobile Systems
> > > > >
> > > > > Vinod Kumar Choyi wrote:
> > > > > >
> > > > > > Srinivas,
> > > > > >
> > > > > > Mobile devices  (that do not have any home or do not use
> MIP)could
> > > > > > also use just Simple IP, but I agree with you that the
> emphasis
> > > should
> > > > > > be more on mobility.
> > > > > >
> > > > > > regards
> > > > > > vinod
> > > > > >
> > > > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > > > >
> > > > > > > Bechet,
> > > > > > > You are stretching your interpretation of my mail and
> presenting
> > > as
> > > > > > > my views.
> > > > > > > 1. There may be a solution that fits all. I am not against
> it.
> > > But
> > > > > > > who wants to use simple-ip? "Independence to mobility
> protocol"
> > > was
> > > > > > > a key point in decision making, as indicated in the
> > > > > > > paging-assessment draft.  Paging protocol is most likely
> will
> > > always
> > > > > > > be used with mobile devices, hence the successful and wide
> > > > > > > acceptance of paging protocol depends on a solution that
> takes
> > > more
> > > > > > > of mobility into consideration. Sacrificing this point may
> well
> > > make
> > > > > > > the final paging protocol not so useful, at best.
> > > > > > > 2. I am not particularly inclined for HA based solutions. My
> > > point
> > > > > > > is, while defining a mobility based paging protocol we
> should
> > > not
> > > > > > > take a particular LMM method (for e.g. HMIPv6) as  solution,
> > > like
> > > > > > > draft-sarikaya. But instead a generalised LMM approach. HA
> based
> > > > > > > solution will also be needed for non-LMM cases.
> > > > > > > Srini
> > > > > > > -----Original Message-----
> > > > > > > From: e
> > > > > > > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > > > > > > Sent: 25 February, 2002 9:32 AM
> > > > > > > To: seamoby@ietf.org
> > > > > > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call
> for
> > > Paging
> > > > > > > Assessment Draft
> > > > > > > Dear all,
> > > > > > >   Several mails have been sent over the weekend I'll try to
> give
> > > my
> > > > > > > views in one mail.
> > > > > > > Regarding Srinivas' email, my understanding is that he is
> > > against
> > > > > > > Alternative 1 (one size fits all solution) and he is for the
> > > > > > > Alternative
> > > > > > > 2. In that he is suggesting that we concentrate on
> Requirement
> > > 4.8
> > > > > > > rather than 4.7. As for the drafts, he seems to be inclined
> to
> > > home
> > > > > > > agent based architectures which is demonstrated in
> draft-renker.
> > > > > > > This is
> > > > > > > an architectural choice, I think that his choice of
> alternatives
> > > is
> > > > > > > clear.
> > > > > > >   Besides, I think that the chairs would like to choose
> > > draft/drafts
> > > > > > > a
> > > > > > > s
> > > > > > > soon as possible and ask people to submit their 01 drafts by
> > > March
> > > > > > > 1st
> > > > > > > and move on. We do not have a lot of time for doing this.
> > > > > > > Regarding Yoshi's email, I am quoting the abstract of RFC
> 3103:
> > > > > > >
> > > > > > >> This document presents a protocol with which to implement
> Realm
> > > > > > >>    Specific IP (RSIP).  The protocol defined herein allows
> > > > > > >> negotiation
> > > > > > >>    of resources between an RSIP host and gateway, so that
> the
> > > host
> > > > > > >> can
> > > > > > >>    lease some of the gateway's addressing parameters in
> order
> > > to
> > > > > > >>    establish a global network presence.  This protocol is
> > > designed
> > > > > > >> to
> > > > > > >>    operate on the application layer and to use its own TCP
> or
> > > UDP
> > > > > > >> port.
> > > > > > >>    In particular, the protocol allows a gateway to allocate
> > > > > > >> addressing
> > > > > > >>    and control parameters to a host such that a flow policy
> can
> > > be
> > > > > > >>    enforced at the gateway.
> > > > > > >>
> > > > > > > Yoshi, I think that the functionalities summarized above of
> RSIP
> > > > > > > have
> > > > > > > nothing to do with IP Paging. Can we define a port specific
> to
> > > IP
> > > > > > > Paging , if yes then how does IP Paging capture all packets
> to
> > > the
> > > > > > > dormant hosts?
> > > > > > > Added to this, please see Pars' email,
> > > > > > >
> > > > > > >> This is serious, because "paging" which is intended for
> > > > > > >> optimizing bandwidth use, may become a bandwidth threat.
> > > > > > >> IP layer solutions may be necessary. This is, perhaps, one
> more
> > > > > > >> motivation for IP paging.
> > > > > > >>
> > > > > > > Let us get motivated for IP Paging.
> > > > > > > Regards,
> > > > > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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
> >
> 
> _______________________________________________
> 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  Wed Feb 27 15:16:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15226
	for ; Wed, 27 Feb 2002 15:16:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25708;
	Wed, 27 Feb 2002 15:04:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25678
	for ; Wed, 27 Feb 2002 15:04:38 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14606
	for ; Wed, 27 Feb 2002 15:04:33 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1RK3xe19029;
	Wed, 27 Feb 2002 12:03:59 -0800 (PST)
Message-ID: <016a01c1bfc9$aba0d320$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Cc: "Srinivas.Sreemanthula" ,
        "vinod.choyi" , "seamoby" 
References: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com> <3C7C3816.B73D9A9A@cs.ucl.ac.uk> <001401c1bfad$f049a450$7e6015ac@T23KEMPF> <3C7D1767.D75A8D0F@cs.ucl.ac.uk> <010701c1bfb9$220718f0$7e6015ac@T23KEMPF> <3C7D34F3.FC5C5CD5@cs.ucl.ac.uk>
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment          Draft
Date: Wed, 27 Feb 2002 12:02:23 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Theo,

There are a variety of issues, we will be discussing them at the
meeting, but if you want to start a thread
on some of the others, please feel free.

            jak

----- Original Message -----
From: "Theo Pagtzis" 
To: "James Kempf" 
Cc: "Srinivas.Sreemanthula" ;
"vinod.choyi" ; "seamoby" 
Sent: Wednesday, February 27, 2002 11:35 AM
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


>
>
> ok.. sounds good to me then..have the other authors raised any points
> that should be considered more closely beyond the TA/DMA or is that
the
> only thing that needs looking at..?
>
> Theo
> UCL/MobiSys Group
>
>
> thanks Jak
>
> James Kempf wrote:
> >
> > The proposal in the assessment draft is for Marco, as the WG draft
> > editor, to take draft-renker and work through it to revise parts
that
> > were found lacking in the assessment, adding solutions after WG
> > concensus has been established on
> > them. In addition, a suggestion was made to have the document
discuss
> > the network (not functional) architecture in more detail. We are
> > currently working  through some architectural questions on where to
put
> > the TA and DMA, and what the relationship with the mobility protocol
> > should be, in a separate thread on this list.
> >
> >             jak
> >
> > ----- Original Message -----
> > From: "Theo Pagtzis" 
> > To: "James Kempf" 
> > Cc: "Srinivas.Sreemanthula" ;
> > "vinod.choyi" ; "seamoby"

> > Sent: Wednesday, February 27, 2002 9:29 AM
> > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> > Assessment Draft
> >
> > > Fair enough..and what would the base draft comprize of?
> > >
> > >
> > > Theo
> > > UCL/MobiSys Group
> > > James Kempf wrote:
> > > >
> > > > We are not debating the process. We did a concensus call on what
the
> > WG
> > > > wanted in early Feb. and the result was that concensus is for
> > starting
> > > > with a base draft. The question now is whether there are any
> > comments on
> > > > the assessment draft
> > > > before we send it to IESG and last call on that ended Monday.
Pat
> > and I
> > > > will be sending out an email
> > > > shortly about the results.
> > > >
> > > >             jak
> > > >
> > > > ----- Original Message -----
> > > > From: "Theo Pagtzis" 
> > > > To: 
> > > > Cc: "vinod.choyi" ; "seamoby"
> > > > 
> > > > Sent: Tuesday, February 26, 2002 5:36 PM
> > > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
Paging
> > > > Assessment Draft
> > > >
> > > > > Hi Srinivas,
> > > > >
> > > > >   With all due respect I do not believe that any time is
> > lost..even if
> > > > > we asked _now_ the authors to go back and come in 4 weeks with
a
> > > > revised
> > > > > design. In fact the authors would literally have known better
and
> > > > > compete in fair grounds in giving their best effort for a
better
> > > > > candidate..nobody can say then that they did not understand
what
> > was
> > > > > meant by requirement X.Y.
> > > > >
> > > > > Still the unified solution finds me in agreement since the
> > fundamental
> > > > > point is to get a robust design. Involvement of the individual
> > authors
> > > > > would be acknowledged and the contribution would be explicit.
> > > > >
> > > > > The important point is to learn from the review and not repeat
the
> > > > same
> > > > > mistakes in the next steps of the DHMA proto evolution. I am
> > personal
> > > > in
> > > > > favour of a revisit in the designs by their creators since
this in
> > any
> > > > > case will put solutions into perspective even for a unified
one..
> > > > >
> > > > > Regs.
> > > > >
> > > > > Theo
> > > > > UCL/Mobile Systems
> > > > >
> > > > >
> > > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > > > >
> > > > > > I agree with Theo that no single draft qualifies as a base
> > proposal
> > > > on it's own. But, rewriting individual proposals and
reevaluating
> > will
> > > > leave us again in the same situation as before, wasting valuable
> > time.
> > > > Instead, we can speed up things by converging what we have and
> > > > improvising on the common solution.
> > > > > >
> > > > > > I ask the WG to rethink if we actually need paging for
simple-ip
> > > > cases. I posed this question before, from lack of responses, I
see
> > that
> > > > no one seems to have interest in it. Now, the WG should put more
> > > > importance on the mobility requirement (4.8).
> > > > > >
> > > > > > With emphasis on mobility, draft-renker does not have a
better
> > > > solution than others. As a matter of fact (also as the
draft-renker
> > > > evaluator), I can comment that it falls short of complete
> > description of
> > > > the protocol behaviour in the implicit (mipv6) mode. Therefore,
the
> > best
> > > > approach would be to choose the strongest mobility based
proposals
> > and
> > > > combine them into one single proposal.
> > > > > >
> > > > > > Thanks,
> > > > > > Srini
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> > > > > > Sent: 26 February, 2002 4:41 PM
> > > > > > To: Vinod Kumar Choyi
> > > > > > Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> > > > > > Subject: Re: [Seamoby] Deadline Approaching: WG Last Call
for
> > Paging
> > > > > > Assessment Draft
> > > > > >
> > > > > > Hello all,
> > > > > >
> > > > > > May I suggest that I would find personally unfair to go
ahead
> > with a
> > > > > > selection of a single solution since _none_ was satisfying
in
> > > > absolute
> > > > > > terms specific marks required for a weighted consideration
as an
> > WG
> > > > > > item. I personally stated the following in the evaluation
team
> > which
> > > > I
> > > > > > would just reiterate: at this stage no protocol must be
selected
> > > > amongst
> > > > > > all. Having read all drafts I feel that none is fittest than
> > > > another. I
> > > > > > am also talking as an evaluator that has no interest in any
of
> > them
> > > > in
> > > > > > terms of selection. Right now the authors of the drafts
needed
> > to go
> > > > > > back on their drawing board and consider the comments that
the
> > > > > > evaluation team gave (hence the output draft). The authors
must
> > > > rework
> > > > > > their solutions in the light of these comments.
> > > > > >
> > > > > > A last round of evaluation must then be carried out by the
same
> > team
> > > > > > since it already has the initial view of the problem. A
final
> > > > decision
> > > > > > must be taken past the last changes and amendments of the
DHMA
> > > > protocol
> > > > > > solutions, which must not be disputed by anybody under
objective
> > > > > > criteria and no arguments against the evaluators that they
> > missed
> > > > this
> > > > > > or did not see that.
> > > > > >
> > > > > > The results from the review would then come up as a revised
> > draft
> > > > and in
> > > > > > public scrutiny to the interested individuals that must be
> > > > considered
> > > > > > objectively (no company hats) if we ever want to see
something
> > > > moving
> > > > > > forward. If the results from the criteria pass a last call
from
> > the
> > > > > > community then the chair will announce the protocol that
> > dominates
> > > > > > overall in marks. Then we proceed and take it further.
> > > > > >
> > > > > > Alternatively the authors of the draft get together and they
> > build a
> > > > > > single protocol by unifying the concepts that the evaluation
> > team
> > > > found
> > > > > > to stand out from each proposal. The authors converge and
bring
> > > > their
> > > > > > elements together in a single solution that is decided if to
be
> > > > > > independent of any mobility protocol or not.
> > > > > >
> > > > > > The chair declares a concensus on the matter, a single
protocol
> > is
> > > > > > defined and considered an WG item.
> > > > > >
> > > > > > We can then proceed in peace and evolution of the DHMA
solution.
> > > > > >
> > > > > > Please consider..
> > > > > >
> > > > > > regards
> > > > > >
> > > > > > Theo
> > > > > > UCL/Mobile Systems
> > > > > >
> > > > > > Vinod Kumar Choyi wrote:
> > > > > > >
> > > > > > > Srinivas,
> > > > > > >
> > > > > > > Mobile devices  (that do not have any home or do not use
> > MIP)could
> > > > > > > also use just Simple IP, but I agree with you that the
> > emphasis
> > > > should
> > > > > > > be more on mobility.
> > > > > > >
> > > > > > > regards
> > > > > > > vinod
> > > > > > >
> > > > > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > > > > >
> > > > > > > > Bechet,
> > > > > > > > You are stretching your interpretation of my mail and
> > presenting
> > > > as
> > > > > > > > my views.
> > > > > > > > 1. There may be a solution that fits all. I am not
against
> > it.
> > > > But
> > > > > > > > who wants to use simple-ip? "Independence to mobility
> > protocol"
> > > > was
> > > > > > > > a key point in decision making, as indicated in the
> > > > > > > > paging-assessment draft.  Paging protocol is most likely
> > will
> > > > always
> > > > > > > > be used with mobile devices, hence the successful and
wide
> > > > > > > > acceptance of paging protocol depends on a solution that
> > takes
> > > > more
> > > > > > > > of mobility into consideration. Sacrificing this point
may
> > well
> > > > make
> > > > > > > > the final paging protocol not so useful, at best.
> > > > > > > > 2. I am not particularly inclined for HA based
solutions. My
> > > > point
> > > > > > > > is, while defining a mobility based paging protocol we
> > should
> > > > not
> > > > > > > > take a particular LMM method (for e.g. HMIPv6) as
solution,
> > > > like
> > > > > > > > draft-sarikaya. But instead a generalised LMM approach.
HA
> > based
> > > > > > > > solution will also be needed for non-LMM cases.
> > > > > > > > Srini
> > > > > > > > -----Original Message-----
> > > > > > > > From: e
> > > > > > > > xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > > > > > > > Sent: 25 February, 2002 9:32 AM
> > > > > > > > To: seamoby@ietf.org
> > > > > > > > Subject: Re: [Seamoby] Deadline Approaching: WG Last
Call
> > for
> > > > Paging
> > > > > > > > Assessment Draft
> > > > > > > > Dear all,
> > > > > > > >   Several mails have been sent over the weekend I'll try
to
> > give
> > > > my
> > > > > > > > views in one mail.
> > > > > > > > Regarding Srinivas' email, my understanding is that he
is
> > > > against
> > > > > > > > Alternative 1 (one size fits all solution) and he is for
the
> > > > > > > > Alternative
> > > > > > > > 2. In that he is suggesting that we concentrate on
> > Requirement
> > > > 4.8
> > > > > > > > rather than 4.7. As for the drafts, he seems to be
inclined
> > to
> > > > home
> > > > > > > > agent based architectures which is demonstrated in
> > draft-renker.
> > > > > > > > This is
> > > > > > > > an architectural choice, I think that his choice of
> > alternatives
> > > > is
> > > > > > > > clear.
> > > > > > > >   Besides, I think that the chairs would like to choose
> > > > draft/drafts
> > > > > > > > a
> > > > > > > > s
> > > > > > > > soon as possible and ask people to submit their 01
drafts by
> > > > March
> > > > > > > > 1st
> > > > > > > > and move on. We do not have a lot of time for doing
this.
> > > > > > > > Regarding Yoshi's email, I am quoting the abstract of
RFC
> > 3103:
> > > > > > > >
> > > > > > > >> This document presents a protocol with which to
implement
> > Realm
> > > > > > > >>    Specific IP (RSIP).  The protocol defined herein
allows
> > > > > > > >> negotiation
> > > > > > > >>    of resources between an RSIP host and gateway, so
that
> > the
> > > > host
> > > > > > > >> can
> > > > > > > >>    lease some of the gateway's addressing parameters in
> > order
> > > > to
> > > > > > > >>    establish a global network presence.  This protocol
is
> > > > designed
> > > > > > > >> to
> > > > > > > >>    operate on the application layer and to use its own
TCP
> > or
> > > > UDP
> > > > > > > >> port.
> > > > > > > >>    In particular, the protocol allows a gateway to
allocate
> > > > > > > >> addressing
> > > > > > > >>    and control parameters to a host such that a flow
policy
> > can
> > > > be
> > > > > > > >>    enforced at the gateway.
> > > > > > > >>
> > > > > > > > Yoshi, I think that the functionalities summarized above
of
> > RSIP
> > > > > > > > have
> > > > > > > > nothing to do with IP Paging. Can we define a port
specific
> > to
> > > > IP
> > > > > > > > Paging , if yes then how does IP Paging capture all
packets
> > to
> > > > the
> > > > > > > > dormant hosts?
> > > > > > > > Added to this, please see Pars' email,
> > > > > > > >
> > > > > > > >> This is serious, because "paging" which is intended for
> > > > > > > >> optimizing bandwidth use, may become a bandwidth
threat.
> > > > > > > >> IP layer solutions may be necessary. This is, perhaps,
one
> > more
> > > > > > > >> motivation for IP paging.
> > > > > > > >>
> > > > > > > > Let us get motivated for IP Paging.
> > > > > > > > Regards,
> > > > > > > > Srinivas.Sreemanthula@nokia.com wrote:
> > > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > >
> >
> > _______________________________________________
> > 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  Wed Feb 27 15:27:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15784
	for ; Wed, 27 Feb 2002 15:27:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26203;
	Wed, 27 Feb 2002 15:15:18 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26151
	for ; Wed, 27 Feb 2002 15:15:15 -0500 (EST)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15118
	for ; Wed, 27 Feb 2002 15:15:10 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1RKEfq18332
	for ; Wed, 27 Feb 2002 14:14:41 -0600 (CST)
Message-ID: <3C7D3E2F.9090209@alcatel.com>
Date: Wed, 27 Feb 2002 14:14:39 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby 
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment          Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com> <3C7C3816.B73D9A9A@cs.ucl.ac.uk> <001401c1bfad$f049a450$7e6015ac@T23KEMPF> <3C7D1767.D75A8D0F@cs.ucl.ac.uk> <010701c1bfb9$220718f0$7e6015ac@T23KEMPF>
Content-Type: text/plain; charset=ISO-8859-7; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Dear all,
  It seems to me that there has been persistent discussions on the 
architecture and this points to the fact that we skipped one important 
step a little too quickly for IP Paging (it may be not too late for CAR 
Discovery and CT), that is when a new protocol is to be defined a 
framework/architecture document should be developed.
  RFC 3154 tries to do this together with the requirements. However what 
RFC 3154 does is to come up with the functional entities. Can we take it 
as a framework or architecture document? Certainly no. Even James, the 
editor of RFC 3154 is asking where to put TA?
  If Seamoby developed a detailed architecture document including a 
discussion of Mobile IP architectures, the players would not have come 
up with so much differing drafts.
  Regards,

James Kempf wrote:

>The proposal in the assessment draft is for Marco, as the WG draft
>editor, to take draft-renker and work through it to revise parts that
>were found lacking in the assessment, adding solutions after WG
>concensus has been established on
>them. In addition, a suggestion was made to have the document discuss
>the network (not functional) architecture in more detail. We are
>currently working  through some architectural questions on where to put
>the TA and DMA, and what the relationship with the mobility protocol
>should be, in a separate thread on this list.
>
>            jak
>
--behcet


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


From seamoby-admin@ietf.org  Wed Feb 27 16:50:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20788
	for ; Wed, 27 Feb 2002 16:50:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00639;
	Wed, 27 Feb 2002 16:27:34 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29077
	for ; Wed, 27 Feb 2002 16:03:57 -0500 (EST)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17955
	for ; Wed, 27 Feb 2002 16:03:49 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1RL2oX14604;
	Wed, 27 Feb 2002 15:02:50 -0600 (CST)
Message-ID: <3C7D5CF3.5070000@alcatel.com>
Date: Wed, 27 Feb 2002 16:25:55 -0600
From: Vinod Kumar Choyi 
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: James Kempf 
CC: t.pagtzis@cs.ucl.ac.uk,
        "Srinivas.Sreemanthula" ,
        seamoby 
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment          Draft
References: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com> <3C7C3816.B73D9A9A@cs.ucl.ac.uk> <001401c1bfad$f049a450$7e6015ac@T23KEMPF> <3C7D1767.D75A8D0F@cs.ucl.ac.uk> <010701c1bfb9$220718f0$7e6015ac@T23KEMPF>
Content-Type: multipart/alternative;
 boundary="------------020204040700080304020908"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------020204040700080304020908
Content-Type: text/plain; charset=ISO-8859-7; format=flowed
Content-Transfer-Encoding: 7bit

James,

But shouldn't the first step be, to assess the assessment draft itself, 
which is why we had discussions (based on the assessment). Once a 
consensus has been reached on the draft and its outcome, we move to the 
next step. Isn't that the procedure, is it not the logical one ?

regards
vinod


James Kempf wrote:

>The proposal in the assessment draft is for Marco, as the WG draft
>editor, to take draft-renker and work through it to revise parts that
>were found lacking in the assessment, adding solutions after WG
>concensus has been established on
>them. In addition, a suggestion was made to have the document discuss
>the network (not functional) architecture in more detail. We are
>currently working  through some architectural questions on where to put
>the TA and DMA, and what the relationship with the mobility protocol
>should be, in a separate thread on this list.
>
>            jak
>
>----- Original Message -----
>From: "Theo Pagtzis" 
>To: "James Kempf" 
>Cc: "Srinivas.Sreemanthula" ;
>"vinod.choyi" ; "seamoby" 
>Sent: Wednesday, February 27, 2002 9:29 AM
>Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
>Assessment Draft
>
>
>>Fair enough..and what would the base draft comprize of?
>>
>>
>>Theo
>>UCL/MobiSys Group
>>James Kempf wrote:
>>
>>>We are not debating the process. We did a concensus call on what the
>>>
>WG
>
>>>wanted in early Feb. and the result was that concensus is for
>>>
>starting
>
>>>with a base draft. The question now is whether there are any
>>>
>comments on
>
>>>the assessment draft
>>>before we send it to IESG and last call on that ended Monday. Pat
>>>
>and I
>
>>>will be sending out an email
>>>shortly about the results.
>>>
>>>            jak
>>>
>>>----- Original Message -----
>>>From: "Theo Pagtzis" 
>>>To: 
>>>Cc: "vinod.choyi" ; "seamoby"
>>>
>>>Sent: Tuesday, February 26, 2002 5:36 PM
>>>Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
>>>Assessment Draft
>>>
>>>>Hi Srinivas,
>>>>
>>>>  With all due respect I do not believe that any time is
>>>>
>lost..even if
>
>>>>we asked _now_ the authors to go back and come in 4 weeks with a
>>>>
>>>revised
>>>
>>>>design. In fact the authors would literally have known better and
>>>>compete in fair grounds in giving their best effort for a better
>>>>candidate..nobody can say then that they did not understand what
>>>>
>was
>
>>>>meant by requirement X.Y.
>>>>
>>>>Still the unified solution finds me in agreement since the
>>>>
>fundamental
>
>>>>point is to get a robust design. Involvement of the individual
>>>>
>authors
>
>>>>would be acknowledged and the contribution would be explicit.
>>>>
>>>>The important point is to learn from the review and not repeat the
>>>>
>>>same
>>>
>>>>mistakes in the next steps of the DHMA proto evolution. I am
>>>>
>personal
>
>>>in
>>>
>>>>favour of a revisit in the designs by their creators since this in
>>>>
>any
>
>>>>case will put solutions into perspective even for a unified one..
>>>>
>>>>Regs.
>>>>
>>>>Theo
>>>>UCL/Mobile Systems
>>>>
>>>>
>>>>Srinivas.Sreemanthula@nokia.com wrote:
>>>>
>>>>>I agree with Theo that no single draft qualifies as a base
>>>>>
>proposal
>
>>>on it's own. But, rewriting individual proposals and reevaluating
>>>
>will
>
>>>leave us again in the same situation as before, wasting valuable
>>>
>time.
>
>>>Instead, we can speed up things by converging what we have and
>>>improvising on the common solution.
>>>
>>>>>I ask the WG to rethink if we actually need paging for simple-ip
>>>>>
>>>cases. I posed this question before, from lack of responses, I see
>>>
>that
>
>>>no one seems to have interest in it. Now, the WG should put more
>>>importance on the mobility requirement (4.8).
>>>
>>>>>With emphasis on mobility, draft-renker does not have a better
>>>>>
>>>solution than others. As a matter of fact (also as the  draft-renker
>>>evaluator), I can comment that it falls short of complete
>>>
>description of
>
>>>the protocol behaviour in the implicit (mipv6) mode. Therefore, the
>>>
>best
>
>>>approach would be to choose the strongest mobility based proposals
>>>
>and
>
>>>combine them into one single proposal.
>>>
>>>>>Thanks,
>>>>>Srini
>>>>>
>>>>>-----Original Message-----
>>>>>From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
>>>>>Sent: 26 February, 2002 4:41 PM
>>>>>To: Vinod Kumar Choyi
>>>>>Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
>>>>>Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
>>>>>
>Paging
>
>>>>>Assessment Draft
>>>>>
>>>>>Hello all,
>>>>>
>>>>>May I suggest that I would find personally unfair to go ahead
>>>>>
>with a
>
>>>>>selection of a single solution since _none_ was satisfying in
>>>>>
>>>absolute
>>>
>>>>>terms specific marks required for a weighted consideration as an
>>>>>
>WG
>
>>>>>item. I personally stated the following in the evaluation team
>>>>>
>which
>
>>>I
>>>
>>>>>would just reiterate: at this stage no protocol must be selected
>>>>>
>>>amongst
>>>
>>>>>all. Having read all drafts I feel that none is fittest than
>>>>>
>>>another. I
>>>
>>>>>am also talking as an evaluator that has no interest in any of
>>>>>
>them
>
>>>in
>>>
>>>>>terms of selection. Right now the authors of the drafts needed
>>>>>
>to go
>
>>>>>back on their drawing board and consider the comments that the
>>>>>evaluation team gave (hence the output draft). The authors must
>>>>>
>>>rework
>>>
>>>>>their solutions in the light of these comments.
>>>>>
>>>>>A last round of evaluation must then be carried out by the same
>>>>>
>team
>
>>>>>since it already has the initial view of the problem. A final
>>>>>
>>>decision
>>>
>>>>>must be taken past the last changes and amendments of the DHMA
>>>>>
>>>protocol
>>>
>>>>>solutions, which must not be disputed by anybody under objective
>>>>>criteria and no arguments against the evaluators that they
>>>>>
>missed
>
>>>this
>>>
>>>>>or did not see that.
>>>>>
>>>>>The results from the review would then come up as a revised
>>>>>
>draft
>
>>>and in
>>>
>>>>>public scrutiny to the interested individuals that must be
>>>>>
>>>considered
>>>
>>>>>objectively (no company hats) if we ever want to see something
>>>>>
>>>moving
>>>
>>>>>forward. If the results from the criteria pass a last call from
>>>>>
>the
>
>>>>>community then the chair will announce the protocol that
>>>>>
>dominates
>
>>>>>overall in marks. Then we proceed and take it further.
>>>>>
>>>>>Alternatively the authors of the draft get together and they
>>>>>
>build a
>
>>>>>single protocol by unifying the concepts that the evaluation
>>>>>
>team
>
>>>found
>>>
>>>>>to stand out from each proposal. The authors converge and bring
>>>>>
>>>their
>>>
>>>>>elements together in a single solution that is decided if to be
>>>>>independent of any mobility protocol or not.
>>>>>
>>>>>The chair declares a concensus on the matter, a single protocol
>>>>>
>is
>
>>>>>defined and considered an WG item.
>>>>>
>>>>>We can then proceed in peace and evolution of the DHMA solution.
>>>>>
>>>>>Please consider..
>>>>>
>>>>>regards
>>>>>
>>>>>Theo
>>>>>UCL/Mobile Systems
>>>>>
>>>>>Vinod Kumar Choyi wrote:
>>>>>
>>>>>>Srinivas,
>>>>>>
>>>>>>Mobile devices  (that do not have any home or do not use
>>>>>>
>MIP)could
>
>>>>>>also use just Simple IP, but I agree with you that the
>>>>>>
>emphasis
>
>>>should
>>>
>>>>>>be more on mobility.
>>>>>>
>>>>>>regards
>>>>>>vinod
>>>>>>
>>>>>>Srinivas.Sreemanthula@nokia.com wrote:
>>>>>>
>>>>>>>Bechet,
>>>>>>>You are stretching your interpretation of my mail and
>>>>>>>
>presenting
>
>>>as
>>>
>>>>>>>my views.
>>>>>>>1. There may be a solution that fits all. I am not against
>>>>>>>
>it.
>
>>>But
>>>
>>>>>>>who wants to use simple-ip? "Independence to mobility
>>>>>>>
>protocol"
>
>>>was
>>>
>>>>>>>a key point in decision making, as indicated in the
>>>>>>>paging-assessment draft.  Paging protocol is most likely
>>>>>>>
>will
>
>>>always
>>>
>>>>>>>be used with mobile devices, hence the successful and wide
>>>>>>>acceptance of paging protocol depends on a solution that
>>>>>>>
>takes
>
>>>more
>>>
>>>>>>>of mobility into consideration. Sacrificing this point may
>>>>>>>
>well
>
>>>make
>>>
>>>>>>>the final paging protocol not so useful, at best.
>>>>>>>2. I am not particularly inclined for HA based solutions. My
>>>>>>>
>>>point
>>>
>>>>>>>is, while defining a mobility based paging protocol we
>>>>>>>
>should
>
>>>not
>>>
>>>>>>>take a particular LMM method (for e.g. HMIPv6) as  solution,
>>>>>>>
>>>like
>>>
>>>>>>>draft-sarikaya. But instead a generalised LMM approach. HA
>>>>>>>
>based
>
>>>>>>>solution will also be needed for non-LMM cases.
>>>>>>>Srini
>>>>>>>-----Original Message-----
>>>>>>>From: e
>>>>>>>xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
>>>>>>>Sent: 25 February, 2002 9:32 AM
>>>>>>>To: seamoby@ietf.org
>>>>>>>Subject: Re: [Seamoby] Deadline Approaching: WG Last Call
>>>>>>>
>for
>
>>>Paging
>>>
>>>>>>>Assessment Draft
>>>>>>>Dear all,
>>>>>>>  Several mails have been sent over the weekend I'll try to
>>>>>>>
>give
>
>>>my
>>>
>>>>>>>views in one mail.
>>>>>>>Regarding Srinivas' email, my understanding is that he is
>>>>>>>
>>>against
>>>
>>>>>>>Alternative 1 (one size fits all solution) and he is for the
>>>>>>>Alternative
>>>>>>>2. In that he is suggesting that we concentrate on
>>>>>>>
>Requirement
>
>>>4.8
>>>
>>>>>>>rather than 4.7. As for the drafts, he seems to be inclined
>>>>>>>
>to
>
>>>home
>>>
>>>>>>>agent based architectures which is demonstrated in
>>>>>>>
>draft-renker.
>
>>>>>>>This is
>>>>>>>an architectural choice, I think that his choice of
>>>>>>>
>alternatives
>
>>>is
>>>
>>>>>>>clear.
>>>>>>>  Besides, I think that the chairs would like to choose
>>>>>>>
>>>draft/drafts
>>>
>>>>>>>a
>>>>>>>s
>>>>>>>soon as possible and ask people to submit their 01 drafts by
>>>>>>>
>>>March
>>>
>>>>>>>1st
>>>>>>>and move on. We do not have a lot of time for doing this.
>>>>>>>Regarding Yoshi's email, I am quoting the abstract of RFC
>>>>>>>
>3103:
>
>>>>>>>>This document presents a protocol with which to implement
>>>>>>>>
>Realm
>
>>>>>>>>   Specific IP (RSIP).  The protocol defined herein allows
>>>>>>>>negotiation
>>>>>>>>   of resources between an RSIP host and gateway, so that
>>>>>>>>
>the
>
>>>host
>>>
>>>>>>>>can
>>>>>>>>   lease some of the gateway's addressing parameters in
>>>>>>>>
>order
>
>>>to
>>>
>>>>>>>>   establish a global network presence.  This protocol is
>>>>>>>>
>>>designed
>>>
>>>>>>>>to
>>>>>>>>   operate on the application layer and to use its own TCP
>>>>>>>>
>or
>
>>>UDP
>>>
>>>>>>>>port.
>>>>>>>>   In particular, the protocol allows a gateway to allocate
>>>>>>>>addressing
>>>>>>>>   and control parameters to a host such that a flow policy
>>>>>>>>
>can
>
>>>be
>>>
>>>>>>>>   enforced at the gateway.
>>>>>>>>
>>>>>>>Yoshi, I think that the functionalities summarized above of
>>>>>>>
>RSIP
>
>>>>>>>have
>>>>>>>nothing to do with IP Paging. Can we define a port specific
>>>>>>>
>to
>
>>>IP
>>>
>>>>>>>Paging , if yes then how does IP Paging capture all packets
>>>>>>>
>to
>
>>>the
>>>
>>>>>>>dormant hosts?
>>>>>>>Added to this, please see Pars' email,
>>>>>>>
>>>>>>>>This is serious, because "paging" which is intended for
>>>>>>>>optimizing bandwidth use, may become a bandwidth threat.
>>>>>>>>IP layer solutions may be necessary. This is, perhaps, one
>>>>>>>>
>more
>
>>>>>>>>motivation for IP paging.
>>>>>>>>
>>>>>>>Let us get motivated for IP Paging.
>>>>>>>Regards,
>>>>>>>Srinivas.Sreemanthula@nokia.com wrote:
>>>>>>>
>>>>>_______________________________________________
>>>>>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
>>>
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>


--------------020204040700080304020908
Content-Type: text/html; charset=ISO-8859-7
Content-Transfer-Encoding: 7bit





James,



But shouldn't the first step be, to assess the assessment draft itself, which
is why we had discussions (based on the assessment). Once a consensus has
been reached on the draft and its outcome, we move to the next step. Isn't
that the procedure, is it not the logical one ?



regards

vinod





James Kempf wrote:



  
The proposal in the assessment draft is for Marco, as the WG draft
editor, to take draft-renker and work through it to revise parts that
were found lacking in the assessment, adding solutions after WG
concensus has been established on
them. In addition, a suggestion was made to have the document discuss
the network (not functional) architecture in more detail. We are
currently working  through some architectural questions on where to put
the TA and DMA, and what the relationship with the mobility protocol
should be, in a separate thread on this list.

            jak

----- Original Message -----
From: "Theo Pagtzis" <t.pagtzis@cs.ucl.ac.uk>
To: "James Kempf" <kempf@docomolabs-usa.com>
Cc: "Srinivas.Sreemanthula" <Srinivas.Sreemanthula@nokia.com>;
"vinod.choyi" <vinod.choyi@alcatel.com>; "seamoby" <seamoby@ietf.org>
Sent: Wednesday, February 27, 2002 9:29 AM
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft



  

    
Fair enough..and what would the base draft comprize of?


Theo
UCL/MobiSys Group
James Kempf wrote:

    

      
We are not debating the process. We did a concensus call on what the

      

      

      
WG

      

        

          
wanted in early Feb. and the result was that concensus is for

          

          

          
starting

          

            

              
with a base draft. The question now is whether there are any

              

              

              
comments on

              

                

                  
the assessment draft
before we send it to IESG and last call on that ended Monday. Pat

                  

                  

                  
and I

                  

                    

                      
will be sending out an email
shortly about the results.

            jak

----- Original Message -----
From: "Theo Pagtzis" <t.pagtzis@cs.ucl.ac.uk>
To: <Srinivas.Sreemanthula@nokia.com>
Cc: "vinod.choyi" <vinod.choyi@alcatel.com>; "seamoby"
<seamoby@ietf.org>
Sent: Tuesday, February 26, 2002 5:36 PM
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


                      

                        
Hi Srinivas,

  With all due respect I do not believe that any time is

                        

                        

                        

                        
lost..even if

                        

                          

                            

                              
we asked _now_ the authors to go back and come in 4 weeks with a

                              

                              
revised

                              

                                
design. In fact the authors would literally have known better and
compete in fair grounds in giving their best effort for a better
candidate..nobody can say then that they did not understand what

                                

                                

                                

                                
was

                                

                                  

                                    

                                      
meant by requirement X.Y.

Still the unified solution finds me in agreement since the

                                      

                                      

                                      

                                      
fundamental

                                      

                                        

                                          

                                            
point is to get a robust design. Involvement of the individual

                                            

                                            

                                            

                                            
authors

                                            

                                              

                                                

                                                  
would be acknowledged and the contribution would be explicit.

The important point is to learn from the review and not repeat the

                                                  

                                                  
same

                                                  

                                                    
mistakes in the next steps of the DHMA proto evolution. I am

                                                    

                                                    

                                                    

                                                    
personal

                                                    

                                                      

                                                        
in

                                                        

                                                          
favour of a revisit in the designs by their creators since this in

                                                          

                                                          

                                                          

                                                          
any

                                                          

                                                            

                                                              

                                                                
case will put solutions into perspective even for a unified one..

Regs.

Theo
UCL/Mobile Systems


Srinivas.Sreemanthula@nokia.com wrote:

                                                                

                                                                  
I agree with Theo that no single draft qualifies as a base

                                                                  

                                                                  

                                                                  

                                                                  

                                                                  
proposal

                                                                  

                                                                    

                                                                      
on it's own. But, rewriting individual proposals and reevaluating

                                                                      

                                                                      

                                                                      
will

                                                                      

                                                                        

                                                                          
leave us again in the same situation as before, wasting valuable

                                                                          

                                                                          

                                                                          
time.

                                                                          

                                                                            

                                                                              
Instead, we can speed up things by converging what we have and
improvising on the common solution.

                                                                              

                                                                                

                                                                                  
I ask the WG to rethink if we actually need paging for simple-ip

                                                                                  

                                                                                  

                                                                                  
cases. I posed this question before, from lack of responses, I see

                                                                                  

                                                                                  

                                                                                  
that

                                                                                  

                                                                                    

                                                                                      
no one seems to have interest in it. Now, the WG should put more
importance on the mobility requirement (4.8).

                                                                                      

                                                                                        

                                                                                          
With emphasis on mobility, draft-renker does not have a better

                                                                                          

                                                                                          

                                                                                          
solution than others. As a matter of fact (also as the  draft-renker
evaluator), I can comment that it falls short of complete

                                                                                          

                                                                                          

                                                                                          
description of

                                                                                          

                                                                                            

                                                                                              
the protocol behaviour in the implicit (mipv6) mode. Therefore, the

                                                                                              

                                                                                              

                                                                                              
best

                                                                                              

                                                                                                

                                                                                                  
approach would be to choose the strongest mobility based proposals

                                                                                                  

                                                                                                  

                                                                                                  
and

                                                                                                  

                                                                                                    

                                                                                                      
combine them into one single proposal.

                                                                                                      

                                                                                                        

                                                                                                          
Thanks,
Srini

-----Original Message-----
From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
Sent: 26 February, 2002 4:41 PM
To: Vinod Kumar Choyi
Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for

                                                                                                          

                                                                                                          

                                                                                                          

                                                                                                          

                                                                                                          
Paging

                                                                                                          

                                                                                                            

                                                                                                              

                                                                                                                

                                                                                                                  
Assessment Draft

Hello all,

May I suggest that I would find personally unfair to go ahead

                                                                                                                  

                                                                                                                  

                                                                                                                  

                                                                                                                  

                                                                                                                  
with a

                                                                                                                  

                                                                                                                    

                                                                                                                      

                                                                                                                        

                                                                                                                          
selection of a single solution since _none_ was satisfying in

                                                                                                                          

                                                                                                                          

                                                                                                                          
absolute

                                                                                                                          

                                                                                                                            

                                                                                                                              
terms specific marks required for a weighted consideration as an

                                                                                                                              

                                                                                                                              

                                                                                                                              

                                                                                                                              

                                                                                                                              
WG

                                                                                                                              

                                                                                                                                

                                                                                                                                  

                                                                                                                                    

                                                                                                                                      
item. I personally stated the following in the evaluation team

                                                                                                                                      

                                                                                                                                      

                                                                                                                                      

                                                                                                                                      

                                                                                                                                      
which

                                                                                                                                      

                                                                                                                                        

                                                                                                                                          
I

                                                                                                                                          

                                                                                                                                            

                                                                                                                                              
would just reiterate: at this stage no protocol must be selected

                                                                                                                                              

                                                                                                                                              

                                                                                                                                              
amongst

                                                                                                                                              

                                                                                                                                                

                                                                                                                                                  
all. Having read all drafts I feel that none is fittest than

                                                                                                                                                  

                                                                                                                                                  

                                                                                                                                                  
another. I

                                                                                                                                                  

                                                                                                                                                    

                                                                                                                                                      
am also talking as an evaluator that has no interest in any of

                                                                                                                                                      

                                                                                                                                                      

                                                                                                                                                      

                                                                                                                                                      

                                                                                                                                                      
them

                                                                                                                                                      

                                                                                                                                                        

                                                                                                                                                          
in

                                                                                                                                                          

                                                                                                                                                            

                                                                                                                                                              
terms of selection. Right now the authors of the drafts needed

                                                                                                                                                              

                                                                                                                                                              

                                                                                                                                                              

                                                                                                                                                              

                                                                                                                                                              
to go

                                                                                                                                                              

                                                                                                                                                                

                                                                                                                                                                  

                                                                                                                                                                    

                                                                                                                                                                      
back on their drawing board and consider the comments that the
evaluation team gave (hence the output draft). The authors must

                                                                                                                                                                      

                                                                                                                                                                      

                                                                                                                                                                      
rework

                                                                                                                                                                      

                                                                                                                                                                        

                                                                                                                                                                          
their solutions in the light of these comments.

A last round of evaluation must then be carried out by the same

                                                                                                                                                                          

                                                                                                                                                                          

                                                                                                                                                                          

                                                                                                                                                                          

                                                                                                                                                                          
team

                                                                                                                                                                          

                                                                                                                                                                            

                                                                                                                                                                              

                                                                                                                                                                                

                                                                                                                                                                                  
since it already has the initial view of the problem. A final

                                                                                                                                                                                  

                                                                                                                                                                                  

                                                                                                                                                                                  
decision

                                                                                                                                                                                  

                                                                                                                                                                                    

                                                                                                                                                                                      
must be taken past the last changes and amendments of the DHMA

                                                                                                                                                                                      

                                                                                                                                                                                      

                                                                                                                                                                                      
protocol

                                                                                                                                                                                      

                                                                                                                                                                                        

                                                                                                                                                                                          
solutions, which must not be disputed by anybody under objective
criteria and no arguments against the evaluators that they

                                                                                                                                                                                          

                                                                                                                                                                                          

                                                                                                                                                                                          

                                                                                                                                                                                          

                                                                                                                                                                                          
missed

                                                                                                                                                                                          

                                                                                                                                                                                            

                                                                                                                                                                                              
this

                                                                                                                                                                                              

                                                                                                                                                                                                

                                                                                                                                                                                                  
or did not see that.

The results from the review would then come up as a revised

                                                                                                                                                                                                  

                                                                                                                                                                                                  

                                                                                                                                                                                                  

                                                                                                                                                                                                  

                                                                                                                                                                                                  
draft

                                                                                                                                                                                                  

                                                                                                                                                                                                    

                                                                                                                                                                                                      
and in

                                                                                                                                                                                                      

                                                                                                                                                                                                        

                                                                                                                                                                                                          
public scrutiny to the interested individuals that must be

                                                                                                                                                                                                          

                                                                                                                                                                                                          

                                                                                                                                                                                                          
considered

                                                                                                                                                                                                          

                                                                                                                                                                                                            

                                                                                                                                                                                                              
objectively (no company hats) if we ever want to see something

                                                                                                                                                                                                              

                                                                                                                                                                                                              

                                                                                                                                                                                                              
moving

                                                                                                                                                                                                              

                                                                                                                                                                                                                

                                                                                                                                                                                                                  
forward. If the results from the criteria pass a last call from

                                                                                                                                                                                                                  

                                                                                                                                                                                                                  

                                                                                                                                                                                                                  

                                                                                                                                                                                                                  

                                                                                                                                                                                                                  
the

                                                                                                                                                                                                                  

                                                                                                                                                                                                                    

                                                                                                                                                                                                                      

                                                                                                                                                                                                                        

                                                                                                                                                                                                                          
community then the chair will announce the protocol that

                                                                                                                                                                                                                          

                                                                                                                                                                                                                          

                                                                                                                                                                                                                          

                                                                                                                                                                                                                          

                                                                                                                                                                                                                          
dominates

                                                                                                                                                                                                                          

                                                                                                                                                                                                                            

                                                                                                                                                                                                                              

                                                                                                                                                                                                                                

                                                                                                                                                                                                                                  
overall in marks. Then we proceed and take it further.

Alternatively the authors of the draft get together and they

                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                  
build a

                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                          
single protocol by unifying the concepts that the evaluation

                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                          
team

                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                              
found

                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                  
to stand out from each proposal. The authors converge and bring

                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                  
their

                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                      
elements together in a single solution that is decided if to be
independent of any mobility protocol or not.

The chair declares a concensus on the matter, a single protocol

                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                      
is

                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                              
defined and considered an WG item.

We can then proceed in peace and evolution of the DHMA solution.

Please consider..

regards

Theo
UCL/Mobile Systems

Vinod Kumar Choyi wrote:

                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                
Srinivas,

Mobile devices  (that do not have any home or do not use

                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                
MIP)could

                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                          
also use just Simple IP, but I agree with you that the

                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                          
emphasis

                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                              
should

                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                    
be more on mobility.

regards
vinod

Srinivas.Sreemanthula@nokia.com wrote:


                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                      
Bechet,
You are stretching your interpretation of my mail and

                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                      
presenting

                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                          
as

                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                  
my views.
1. There may be a solution that fits all. I am not against

                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                  
it.

                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                      
But

                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                              
who wants to use simple-ip? "Independence to mobility

                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                              
protocol"

                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                  
was

                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                          
a key point in decision making, as indicated in the
paging-assessment draft.  Paging protocol is most likely

                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                          
will

                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                              
always

                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                      
be used with mobile devices, hence the successful and wide
acceptance of paging protocol depends on a solution that

                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                      
takes

                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                          
more

                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                  
of mobility into consideration. Sacrificing this point may

                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                  
well

                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                      
make

                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                              
the final paging protocol not so useful, at best.
2. I am not particularly inclined for HA based solutions. My

                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                              
point

                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                      
is, while defining a mobility based paging protocol we

                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                      
should

                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                          
not

                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                  
take a particular LMM method (for e.g. HMIPv6) as  solution,

                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                  
like

                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                          
draft-sarikaya. But instead a generalised LMM approach. HA

                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                          
based

                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                      
solution will also be needed for non-LMM cases.
Srini
-----Original Message-----
From: e
xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: 25 February, 2002 9:32 AM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call

                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                      
for

                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                          
Paging

                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                  
Assessment Draft
Dear all,
  Several mails have been sent over the weekend I'll try to

                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                  
give

                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                      
my

                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                              
views in one mail.
Regarding Srinivas' email, my understanding is that he is

                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                              
against

                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                      
Alternative 1 (one size fits all solution) and he is for the
Alternative
2. In that he is suggesting that we concentrate on

                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                      
Requirement

                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                          
4.8

                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                  
rather than 4.7. As for the drafts, he seems to be inclined

                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                  
to

                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                      
home

                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                              
agent based architectures which is demonstrated in

                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                              
draft-renker.

                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                          
This is
an architectural choice, I think that his choice of

                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                          
alternatives

                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                              
is

                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      
clear.
  Besides, I think that the chairs would like to choose

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      
draft/drafts

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              
a
s
soon as possible and ask people to submit their 01 drafts by

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              
March

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      
1st
and move on. We do not have a lot of time for doing this.
Regarding Yoshi's email, I am quoting the abstract of RFC

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      
3103:

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    
This document presents a protocol with which to implement

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    
Realm

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  
   Specific IP (RSIP).  The protocol defined herein allows
negotiation
   of resources between an RSIP host and gateway, so that

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  
the

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      
host

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
can
   lease some of the gateway's addressing parameters in

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
order

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    
to

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              
   establish a global network presence.  This protocol is

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              
designed

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
to
   operate on the application layer and to use its own TCP

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
or

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
UDP

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      
port.
   In particular, the protocol allows a gateway to allocate
addressing
   and control parameters to a host such that a flow policy

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      
can

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          
be

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    
   enforced at the gateway.


                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    
Yoshi, I think that the functionalities summarized above of

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    
RSIP

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
have
nothing to do with IP Paging. Can we define a port specific

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
to

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    
IP

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
Paging , if yes then how does IP Paging capture all packets

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
to

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
the

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
dormant hosts?
Added to this, please see Pars' email,


                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          
This is serious, because "paging" which is intended for
optimizing bandwidth use, may become a bandwidth threat.
IP layer solutions may be necessary. This is, perhaps, one

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          
more

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
motivation for IP paging.


                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
Let us get motivated for IP Paging.
Regards,
Srinivas.Sreemanthula@nokia.com wrote:


                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
_______________________________________________
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

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        


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

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

--------------020204040700080304020908--



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


From seamoby-admin@ietf.org  Wed Feb 27 17:29:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22430
	for ; Wed, 27 Feb 2002 17:29:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03430;
	Wed, 27 Feb 2002 17:10:01 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03389
	for ; Wed, 27 Feb 2002 17:09:59 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21546
	for ; Wed, 27 Feb 2002 17:09:53 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1RM83e24449;
	Wed, 27 Feb 2002 14:08:03 -0800 (PST)
Message-ID: <019a01c1bfdb$00769900$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Vinod Kumar Choyi" 
Cc: ,
        "Srinivas.Sreemanthula" ,
        "seamoby" 
References: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com> <3C7C3816.B73D9A9A@cs.ucl.ac.uk> <001401c1bfad$f049a450$7e6015ac@T23KEMPF> <3C7D1767.D75A8D0F@cs.ucl.ac.uk> <010701c1bfb9$220718f0$7e6015ac@T23KEMPF> <3C7D5CF3.5070000@alcatel.com>
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment          Draft
Date: Wed, 27 Feb 2002 14:06:26 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

The last call was on the assessment draft. The assessment draft contains
a recommendation about how to get started on the design of the paging
protocol which we will send to IESG. The intent is to achieve closure,
so that we can finally start recording WG decisions on the protocol in a
WG draft describing the paging protocol.

            jak

----- Original Message -----
From: "Vinod Kumar Choyi" 
To: "James Kempf" 
Cc: ; "Srinivas.Sreemanthula"
; "seamoby" 
Sent: Wednesday, February 27, 2002 2:25 PM
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


> James,
>
> But shouldn't the first step be, to assess the assessment draft
itself,
> which is why we had discussions (based on the assessment). Once a
> consensus has been reached on the draft and its outcome, we move to
the
> next step. Isn't that the procedure, is it not the logical one ?
>
> regards
> vinod
>
>
> James Kempf wrote:
>
> >The proposal in the assessment draft is for Marco, as the WG draft
> >editor, to take draft-renker and work through it to revise parts that
> >were found lacking in the assessment, adding solutions after WG
> >concensus has been established on
> >them. In addition, a suggestion was made to have the document discuss
> >the network (not functional) architecture in more detail. We are
> >currently working  through some architectural questions on where to
put
> >the TA and DMA, and what the relationship with the mobility protocol
> >should be, in a separate thread on this list.
> >
> >            jak
> >
> >----- Original Message -----
> >From: "Theo Pagtzis" 
> >To: "James Kempf" 
> >Cc: "Srinivas.Sreemanthula" ;
> >"vinod.choyi" ; "seamoby" 
> >Sent: Wednesday, February 27, 2002 9:29 AM
> >Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> >Assessment Draft
> >
> >
> >>Fair enough..and what would the base draft comprize of?
> >>
> >>
> >>Theo
> >>UCL/MobiSys Group
> >>James Kempf wrote:
> >>
> >>>We are not debating the process. We did a concensus call on what
the
> >>>
> >WG
> >
> >>>wanted in early Feb. and the result was that concensus is for
> >>>
> >starting
> >
> >>>with a base draft. The question now is whether there are any
> >>>
> >comments on
> >
> >>>the assessment draft
> >>>before we send it to IESG and last call on that ended Monday. Pat
> >>>
> >and I
> >
> >>>will be sending out an email
> >>>shortly about the results.
> >>>
> >>>            jak
> >>>
> >>>----- Original Message -----
> >>>From: "Theo Pagtzis" 
> >>>To: 
> >>>Cc: "vinod.choyi" ; "seamoby"
> >>>
> >>>Sent: Tuesday, February 26, 2002 5:36 PM
> >>>Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
Paging
> >>>Assessment Draft
> >>>
> >>>>Hi Srinivas,
> >>>>
> >>>>  With all due respect I do not believe that any time is
> >>>>
> >lost..even if
> >
> >>>>we asked _now_ the authors to go back and come in 4 weeks with a
> >>>>
> >>>revised
> >>>
> >>>>design. In fact the authors would literally have known better and
> >>>>compete in fair grounds in giving their best effort for a better
> >>>>candidate..nobody can say then that they did not understand what
> >>>>
> >was
> >
> >>>>meant by requirement X.Y.
> >>>>
> >>>>Still the unified solution finds me in agreement since the
> >>>>
> >fundamental
> >
> >>>>point is to get a robust design. Involvement of the individual
> >>>>
> >authors
> >
> >>>>would be acknowledged and the contribution would be explicit.
> >>>>
> >>>>The important point is to learn from the review and not repeat the
> >>>>
> >>>same
> >>>
> >>>>mistakes in the next steps of the DHMA proto evolution. I am
> >>>>
> >personal
> >
> >>>in
> >>>
> >>>>favour of a revisit in the designs by their creators since this in
> >>>>
> >any
> >
> >>>>case will put solutions into perspective even for a unified one..
> >>>>
> >>>>Regs.
> >>>>
> >>>>Theo
> >>>>UCL/Mobile Systems
> >>>>
> >>>>
> >>>>Srinivas.Sreemanthula@nokia.com wrote:
> >>>>
> >>>>>I agree with Theo that no single draft qualifies as a base
> >>>>>
> >proposal
> >
> >>>on it's own. But, rewriting individual proposals and reevaluating
> >>>
> >will
> >
> >>>leave us again in the same situation as before, wasting valuable
> >>>
> >time.
> >
> >>>Instead, we can speed up things by converging what we have and
> >>>improvising on the common solution.
> >>>
> >>>>>I ask the WG to rethink if we actually need paging for simple-ip
> >>>>>
> >>>cases. I posed this question before, from lack of responses, I see
> >>>
> >that
> >
> >>>no one seems to have interest in it. Now, the WG should put more
> >>>importance on the mobility requirement (4.8).
> >>>
> >>>>>With emphasis on mobility, draft-renker does not have a better
> >>>>>
> >>>solution than others. As a matter of fact (also as the
draft-renker
> >>>evaluator), I can comment that it falls short of complete
> >>>
> >description of
> >
> >>>the protocol behaviour in the implicit (mipv6) mode. Therefore, the
> >>>
> >best
> >
> >>>approach would be to choose the strongest mobility based proposals
> >>>
> >and
> >
> >>>combine them into one single proposal.
> >>>
> >>>>>Thanks,
> >>>>>Srini
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> >>>>>Sent: 26 February, 2002 4:41 PM
> >>>>>To: Vinod Kumar Choyi
> >>>>>Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> >>>>>Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
> >>>>>
> >Paging
> >
> >>>>>Assessment Draft
> >>>>>
> >>>>>Hello all,
> >>>>>
> >>>>>May I suggest that I would find personally unfair to go ahead
> >>>>>
> >with a
> >
> >>>>>selection of a single solution since _none_ was satisfying in
> >>>>>
> >>>absolute
> >>>
> >>>>>terms specific marks required for a weighted consideration as an
> >>>>>
> >WG
> >
> >>>>>item. I personally stated the following in the evaluation team
> >>>>>
> >which
> >
> >>>I
> >>>
> >>>>>would just reiterate: at this stage no protocol must be selected
> >>>>>
> >>>amongst
> >>>
> >>>>>all. Having read all drafts I feel that none is fittest than
> >>>>>
> >>>another. I
> >>>
> >>>>>am also talking as an evaluator that has no interest in any of
> >>>>>
> >them
> >
> >>>in
> >>>
> >>>>>terms of selection. Right now the authors of the drafts needed
> >>>>>
> >to go
> >
> >>>>>back on their drawing board and consider the comments that the
> >>>>>evaluation team gave (hence the output draft). The authors must
> >>>>>
> >>>rework
> >>>
> >>>>>their solutions in the light of these comments.
> >>>>>
> >>>>>A last round of evaluation must then be carried out by the same
> >>>>>
> >team
> >
> >>>>>since it already has the initial view of the problem. A final
> >>>>>
> >>>decision
> >>>
> >>>>>must be taken past the last changes and amendments of the DHMA
> >>>>>
> >>>protocol
> >>>
> >>>>>solutions, which must not be disputed by anybody under objective
> >>>>>criteria and no arguments against the evaluators that they
> >>>>>
> >missed
> >
> >>>this
> >>>
> >>>>>or did not see that.
> >>>>>
> >>>>>The results from the review would then come up as a revised
> >>>>>
> >draft
> >
> >>>and in
> >>>
> >>>>>public scrutiny to the interested individuals that must be
> >>>>>
> >>>considered
> >>>
> >>>>>objectively (no company hats) if we ever want to see something
> >>>>>
> >>>moving
> >>>
> >>>>>forward. If the results from the criteria pass a last call from
> >>>>>
> >the
> >
> >>>>>community then the chair will announce the protocol that
> >>>>>
> >dominates
> >
> >>>>>overall in marks. Then we proceed and take it further.
> >>>>>
> >>>>>Alternatively the authors of the draft get together and they
> >>>>>
> >build a
> >
> >>>>>single protocol by unifying the concepts that the evaluation
> >>>>>
> >team
> >
> >>>found
> >>>
> >>>>>to stand out from each proposal. The authors converge and bring
> >>>>>
> >>>their
> >>>
> >>>>>elements together in a single solution that is decided if to be
> >>>>>independent of any mobility protocol or not.
> >>>>>
> >>>>>The chair declares a concensus on the matter, a single protocol
> >>>>>
> >is
> >
> >>>>>defined and considered an WG item.
> >>>>>
> >>>>>We can then proceed in peace and evolution of the DHMA solution.
> >>>>>
> >>>>>Please consider..
> >>>>>
> >>>>>regards
> >>>>>
> >>>>>Theo
> >>>>>UCL/Mobile Systems
> >>>>>
> >>>>>Vinod Kumar Choyi wrote:
> >>>>>
> >>>>>>Srinivas,
> >>>>>>
> >>>>>>Mobile devices  (that do not have any home or do not use
> >>>>>>
> >MIP)could
> >
> >>>>>>also use just Simple IP, but I agree with you that the
> >>>>>>
> >emphasis
> >
> >>>should
> >>>
> >>>>>>be more on mobility.
> >>>>>>
> >>>>>>regards
> >>>>>>vinod
> >>>>>>
> >>>>>>Srinivas.Sreemanthula@nokia.com wrote:
> >>>>>>
> >>>>>>>Bechet,
> >>>>>>>You are stretching your interpretation of my mail and
> >>>>>>>
> >presenting
> >
> >>>as
> >>>
> >>>>>>>my views.
> >>>>>>>1. There may be a solution that fits all. I am not against
> >>>>>>>
> >it.
> >
> >>>But
> >>>
> >>>>>>>who wants to use simple-ip? "Independence to mobility
> >>>>>>>
> >protocol"
> >
> >>>was
> >>>
> >>>>>>>a key point in decision making, as indicated in the
> >>>>>>>paging-assessment draft.  Paging protocol is most likely
> >>>>>>>
> >will
> >
> >>>always
> >>>
> >>>>>>>be used with mobile devices, hence the successful and wide
> >>>>>>>acceptance of paging protocol depends on a solution that
> >>>>>>>
> >takes
> >
> >>>more
> >>>
> >>>>>>>of mobility into consideration. Sacrificing this point may
> >>>>>>>
> >well
> >
> >>>make
> >>>
> >>>>>>>the final paging protocol not so useful, at best.
> >>>>>>>2. I am not particularly inclined for HA based solutions. My
> >>>>>>>
> >>>point
> >>>
> >>>>>>>is, while defining a mobility based paging protocol we
> >>>>>>>
> >should
> >
> >>>not
> >>>
> >>>>>>>take a particular LMM method (for e.g. HMIPv6) as  solution,
> >>>>>>>
> >>>like
> >>>
> >>>>>>>draft-sarikaya. But instead a generalised LMM approach. HA
> >>>>>>>
> >based
> >
> >>>>>>>solution will also be needed for non-LMM cases.
> >>>>>>>Srini
> >>>>>>>-----Original Message-----
> >>>>>>>From: e
> >>>>>>>xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> >>>>>>>Sent: 25 February, 2002 9:32 AM
> >>>>>>>To: seamoby@ietf.org
> >>>>>>>Subject: Re: [Seamoby] Deadline Approaching: WG Last Call
> >>>>>>>
> >for
> >
> >>>Paging
> >>>
> >>>>>>>Assessment Draft
> >>>>>>>Dear all,
> >>>>>>>  Several mails have been sent over the weekend I'll try to
> >>>>>>>
> >give
> >
> >>>my
> >>>
> >>>>>>>views in one mail.
> >>>>>>>Regarding Srinivas' email, my understanding is that he is
> >>>>>>>
> >>>against
> >>>
> >>>>>>>Alternative 1 (one size fits all solution) and he is for the
> >>>>>>>Alternative
> >>>>>>>2. In that he is suggesting that we concentrate on
> >>>>>>>
> >Requirement
> >
> >>>4.8
> >>>
> >>>>>>>rather than 4.7. As for the drafts, he seems to be inclined
> >>>>>>>
> >to
> >
> >>>home
> >>>
> >>>>>>>agent based architectures which is demonstrated in
> >>>>>>>
> >draft-renker.
> >
> >>>>>>>This is
> >>>>>>>an architectural choice, I think that his choice of
> >>>>>>>
> >alternatives
> >
> >>>is
> >>>
> >>>>>>>clear.
> >>>>>>>  Besides, I think that the chairs would like to choose
> >>>>>>>
> >>>draft/drafts
> >>>
> >>>>>>>a
> >>>>>>>s
> >>>>>>>soon as possible and ask people to submit their 01 drafts by
> >>>>>>>
> >>>March
> >>>
> >>>>>>>1st
> >>>>>>>and move on. We do not have a lot of time for doing this.
> >>>>>>>Regarding Yoshi's email, I am quoting the abstract of RFC
> >>>>>>>
> >3103:
> >
> >>>>>>>>This document presents a protocol with which to implement
> >>>>>>>>
> >Realm
> >
> >>>>>>>>   Specific IP (RSIP).  The protocol defined herein allows
> >>>>>>>>negotiation
> >>>>>>>>   of resources between an RSIP host and gateway, so that
> >>>>>>>>
> >the
> >
> >>>host
> >>>
> >>>>>>>>can
> >>>>>>>>   lease some of the gateway's addressing parameters in
> >>>>>>>>
> >order
> >
> >>>to
> >>>
> >>>>>>>>   establish a global network presence.  This protocol is
> >>>>>>>>
> >>>designed
> >>>
> >>>>>>>>to
> >>>>>>>>   operate on the application layer and to use its own TCP
> >>>>>>>>
> >or
> >
> >>>UDP
> >>>
> >>>>>>>>port.
> >>>>>>>>   In particular, the protocol allows a gateway to allocate
> >>>>>>>>addressing
> >>>>>>>>   and control parameters to a host such that a flow policy
> >>>>>>>>
> >can
> >
> >>>be
> >>>
> >>>>>>>>   enforced at the gateway.
> >>>>>>>>
> >>>>>>>Yoshi, I think that the functionalities summarized above of
> >>>>>>>
> >RSIP
> >
> >>>>>>>have
> >>>>>>>nothing to do with IP Paging. Can we define a port specific
> >>>>>>>
> >to
> >
> >>>IP
> >>>
> >>>>>>>Paging , if yes then how does IP Paging capture all packets
> >>>>>>>
> >to
> >
> >>>the
> >>>
> >>>>>>>dormant hosts?
> >>>>>>>Added to this, please see Pars' email,
> >>>>>>>
> >>>>>>>>This is serious, because "paging" which is intended for
> >>>>>>>>optimizing bandwidth use, may become a bandwidth threat.
> >>>>>>>>IP layer solutions may be necessary. This is, perhaps, one
> >>>>>>>>
> >more
> >
> >>>>>>>>motivation for IP paging.
> >>>>>>>>
> >>>>>>>Let us get motivated for IP Paging.
> >>>>>>>Regards,
> >>>>>>>Srinivas.Sreemanthula@nokia.com wrote:
> >>>>>>>
> >>>>>_______________________________________________
> >>>>>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
> >>>
> >
> >
> >_______________________________________________
> >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  Wed Feb 27 17:54:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23231
	for ; Wed, 27 Feb 2002 17:54:40 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05702;
	Wed, 27 Feb 2002 17:43:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05635
	for ; Wed, 27 Feb 2002 17:43:37 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22983
	for ; Wed, 27 Feb 2002 17:43:32 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1RMgxe25941;
	Wed, 27 Feb 2002 14:43:00 -0800 (PST)
Message-ID: <01d401c1bfdf$e233eab0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "James Kempf" ,
        "Vinod Kumar Choyi" 
Cc: ,
        "Srinivas.Sreemanthula" ,
        "seamoby" 
References: <07EE0E021034014F99A57B032BC9C0E50FF673@daebe001.NOE.Nokia.com> <3C7C3816.B73D9A9A@cs.ucl.ac.uk> <001401c1bfad$f049a450$7e6015ac@T23KEMPF> <3C7D1767.D75A8D0F@cs.ucl.ac.uk> <010701c1bfb9$220718f0$7e6015ac@T23KEMPF> <3C7D5CF3.5070000@alcatel.com> <019a01c1bfdb$00769900$7e6015ac@T23KEMPF>
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging Assessment          Draft
Date: Wed, 27 Feb 2002 14:41:23 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Sorry, what I meant to say was that the recommendation about how to get
started on the base draft will be sent to IESG, not the base draft
itself.

            jak

----- Original Message -----
From: "James Kempf" 
To: "Vinod Kumar Choyi" 
Cc: ; "Srinivas.Sreemanthula"
; "seamoby" 
Sent: Wednesday, February 27, 2002 2:06 PM
Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
Assessment Draft


> The last call was on the assessment draft. The assessment draft
contains
> a recommendation about how to get started on the design of the paging
> protocol which we will send to IESG. The intent is to achieve closure,
> so that we can finally start recording WG decisions on the protocol in
a
> WG draft describing the paging protocol.
>
>             jak
>
> ----- Original Message -----
> From: "Vinod Kumar Choyi" 
> To: "James Kempf" 
> Cc: ; "Srinivas.Sreemanthula"
> ; "seamoby" 
> Sent: Wednesday, February 27, 2002 2:25 PM
> Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for Paging
> Assessment Draft
>
>
> > James,
> >
> > But shouldn't the first step be, to assess the assessment draft
> itself,
> > which is why we had discussions (based on the assessment). Once a
> > consensus has been reached on the draft and its outcome, we move to
> the
> > next step. Isn't that the procedure, is it not the logical one ?
> >
> > regards
> > vinod
> >
> >
> > James Kempf wrote:
> >
> > >The proposal in the assessment draft is for Marco, as the WG draft
> > >editor, to take draft-renker and work through it to revise parts
that
> > >were found lacking in the assessment, adding solutions after WG
> > >concensus has been established on
> > >them. In addition, a suggestion was made to have the document
discuss
> > >the network (not functional) architecture in more detail. We are
> > >currently working  through some architectural questions on where to
> put
> > >the TA and DMA, and what the relationship with the mobility
protocol
> > >should be, in a separate thread on this list.
> > >
> > >            jak
> > >
> > >----- Original Message -----
> > >From: "Theo Pagtzis" 
> > >To: "James Kempf" 
> > >Cc: "Srinivas.Sreemanthula" ;
> > >"vinod.choyi" ; "seamoby"

> > >Sent: Wednesday, February 27, 2002 9:29 AM
> > >Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
Paging
> > >Assessment Draft
> > >
> > >
> > >>Fair enough..and what would the base draft comprize of?
> > >>
> > >>
> > >>Theo
> > >>UCL/MobiSys Group
> > >>James Kempf wrote:
> > >>
> > >>>We are not debating the process. We did a concensus call on what
> the
> > >>>
> > >WG
> > >
> > >>>wanted in early Feb. and the result was that concensus is for
> > >>>
> > >starting
> > >
> > >>>with a base draft. The question now is whether there are any
> > >>>
> > >comments on
> > >
> > >>>the assessment draft
> > >>>before we send it to IESG and last call on that ended Monday. Pat
> > >>>
> > >and I
> > >
> > >>>will be sending out an email
> > >>>shortly about the results.
> > >>>
> > >>>            jak
> > >>>
> > >>>----- Original Message -----
> > >>>From: "Theo Pagtzis" 
> > >>>To: 
> > >>>Cc: "vinod.choyi" ; "seamoby"
> > >>>
> > >>>Sent: Tuesday, February 26, 2002 5:36 PM
> > >>>Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
> Paging
> > >>>Assessment Draft
> > >>>
> > >>>>Hi Srinivas,
> > >>>>
> > >>>>  With all due respect I do not believe that any time is
> > >>>>
> > >lost..even if
> > >
> > >>>>we asked _now_ the authors to go back and come in 4 weeks with a
> > >>>>
> > >>>revised
> > >>>
> > >>>>design. In fact the authors would literally have known better
and
> > >>>>compete in fair grounds in giving their best effort for a better
> > >>>>candidate..nobody can say then that they did not understand what
> > >>>>
> > >was
> > >
> > >>>>meant by requirement X.Y.
> > >>>>
> > >>>>Still the unified solution finds me in agreement since the
> > >>>>
> > >fundamental
> > >
> > >>>>point is to get a robust design. Involvement of the individual
> > >>>>
> > >authors
> > >
> > >>>>would be acknowledged and the contribution would be explicit.
> > >>>>
> > >>>>The important point is to learn from the review and not repeat
the
> > >>>>
> > >>>same
> > >>>
> > >>>>mistakes in the next steps of the DHMA proto evolution. I am
> > >>>>
> > >personal
> > >
> > >>>in
> > >>>
> > >>>>favour of a revisit in the designs by their creators since this
in
> > >>>>
> > >any
> > >
> > >>>>case will put solutions into perspective even for a unified
one..
> > >>>>
> > >>>>Regs.
> > >>>>
> > >>>>Theo
> > >>>>UCL/Mobile Systems
> > >>>>
> > >>>>
> > >>>>Srinivas.Sreemanthula@nokia.com wrote:
> > >>>>
> > >>>>>I agree with Theo that no single draft qualifies as a base
> > >>>>>
> > >proposal
> > >
> > >>>on it's own. But, rewriting individual proposals and reevaluating
> > >>>
> > >will
> > >
> > >>>leave us again in the same situation as before, wasting valuable
> > >>>
> > >time.
> > >
> > >>>Instead, we can speed up things by converging what we have and
> > >>>improvising on the common solution.
> > >>>
> > >>>>>I ask the WG to rethink if we actually need paging for
simple-ip
> > >>>>>
> > >>>cases. I posed this question before, from lack of responses, I
see
> > >>>
> > >that
> > >
> > >>>no one seems to have interest in it. Now, the WG should put more
> > >>>importance on the mobility requirement (4.8).
> > >>>
> > >>>>>With emphasis on mobility, draft-renker does not have a better
> > >>>>>
> > >>>solution than others. As a matter of fact (also as the
> draft-renker
> > >>>evaluator), I can comment that it falls short of complete
> > >>>
> > >description of
> > >
> > >>>the protocol behaviour in the implicit (mipv6) mode. Therefore,
the
> > >>>
> > >best
> > >
> > >>>approach would be to choose the strongest mobility based
proposals
> > >>>
> > >and
> > >
> > >>>combine them into one single proposal.
> > >>>
> > >>>>>Thanks,
> > >>>>>Srini
> > >>>>>
> > >>>>>-----Original Message-----
> > >>>>>From: ext Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> > >>>>>Sent: 26 February, 2002 4:41 PM
> > >>>>>To: Vinod Kumar Choyi
> > >>>>>Cc: Sreemanthula Srinivas (NRC/Dallas); seamoby@ietf.org
> > >>>>>Subject: Re: [Seamoby] Deadline Approaching: WG Last Call for
> > >>>>>
> > >Paging
> > >
> > >>>>>Assessment Draft
> > >>>>>
> > >>>>>Hello all,
> > >>>>>
> > >>>>>May I suggest that I would find personally unfair to go ahead
> > >>>>>
> > >with a
> > >
> > >>>>>selection of a single solution since _none_ was satisfying in
> > >>>>>
> > >>>absolute
> > >>>
> > >>>>>terms specific marks required for a weighted consideration as
an
> > >>>>>
> > >WG
> > >
> > >>>>>item. I personally stated the following in the evaluation team
> > >>>>>
> > >which
> > >
> > >>>I
> > >>>
> > >>>>>would just reiterate: at this stage no protocol must be
selected
> > >>>>>
> > >>>amongst
> > >>>
> > >>>>>all. Having read all drafts I feel that none is fittest than
> > >>>>>
> > >>>another. I
> > >>>
> > >>>>>am also talking as an evaluator that has no interest in any of
> > >>>>>
> > >them
> > >
> > >>>in
> > >>>
> > >>>>>terms of selection. Right now the authors of the drafts needed
> > >>>>>
> > >to go
> > >
> > >>>>>back on their drawing board and consider the comments that the
> > >>>>>evaluation team gave (hence the output draft). The authors must
> > >>>>>
> > >>>rework
> > >>>
> > >>>>>their solutions in the light of these comments.
> > >>>>>
> > >>>>>A last round of evaluation must then be carried out by the same
> > >>>>>
> > >team
> > >
> > >>>>>since it already has the initial view of the problem. A final
> > >>>>>
> > >>>decision
> > >>>
> > >>>>>must be taken past the last changes and amendments of the DHMA
> > >>>>>
> > >>>protocol
> > >>>
> > >>>>>solutions, which must not be disputed by anybody under
objective
> > >>>>>criteria and no arguments against the evaluators that they
> > >>>>>
> > >missed
> > >
> > >>>this
> > >>>
> > >>>>>or did not see that.
> > >>>>>
> > >>>>>The results from the review would then come up as a revised
> > >>>>>
> > >draft
> > >
> > >>>and in
> > >>>
> > >>>>>public scrutiny to the interested individuals that must be
> > >>>>>
> > >>>considered
> > >>>
> > >>>>>objectively (no company hats) if we ever want to see something
> > >>>>>
> > >>>moving
> > >>>
> > >>>>>forward. If the results from the criteria pass a last call from
> > >>>>>
> > >the
> > >
> > >>>>>community then the chair will announce the protocol that
> > >>>>>
> > >dominates
> > >
> > >>>>>overall in marks. Then we proceed and take it further.
> > >>>>>
> > >>>>>Alternatively the authors of the draft get together and they
> > >>>>>
> > >build a
> > >
> > >>>>>single protocol by unifying the concepts that the evaluation
> > >>>>>
> > >team
> > >
> > >>>found
> > >>>
> > >>>>>to stand out from each proposal. The authors converge and bring
> > >>>>>
> > >>>their
> > >>>
> > >>>>>elements together in a single solution that is decided if to be
> > >>>>>independent of any mobility protocol or not.
> > >>>>>
> > >>>>>The chair declares a concensus on the matter, a single protocol
> > >>>>>
> > >is
> > >
> > >>>>>defined and considered an WG item.
> > >>>>>
> > >>>>>We can then proceed in peace and evolution of the DHMA
solution.
> > >>>>>
> > >>>>>Please consider..
> > >>>>>
> > >>>>>regards
> > >>>>>
> > >>>>>Theo
> > >>>>>UCL/Mobile Systems
> > >>>>>
> > >>>>>Vinod Kumar Choyi wrote:
> > >>>>>
> > >>>>>>Srinivas,
> > >>>>>>
> > >>>>>>Mobile devices  (that do not have any home or do not use
> > >>>>>>
> > >MIP)could
> > >
> > >>>>>>also use just Simple IP, but I agree with you that the
> > >>>>>>
> > >emphasis
> > >
> > >>>should
> > >>>
> > >>>>>>be more on mobility.
> > >>>>>>
> > >>>>>>regards
> > >>>>>>vinod
> > >>>>>>
> > >>>>>>Srinivas.Sreemanthula@nokia.com wrote:
> > >>>>>>
> > >>>>>>>Bechet,
> > >>>>>>>You are stretching your interpretation of my mail and
> > >>>>>>>
> > >presenting
> > >
> > >>>as
> > >>>
> > >>>>>>>my views.
> > >>>>>>>1. There may be a solution that fits all. I am not against
> > >>>>>>>
> > >it.
> > >
> > >>>But
> > >>>
> > >>>>>>>who wants to use simple-ip? "Independence to mobility
> > >>>>>>>
> > >protocol"
> > >
> > >>>was
> > >>>
> > >>>>>>>a key point in decision making, as indicated in the
> > >>>>>>>paging-assessment draft.  Paging protocol is most likely
> > >>>>>>>
> > >will
> > >
> > >>>always
> > >>>
> > >>>>>>>be used with mobile devices, hence the successful and wide
> > >>>>>>>acceptance of paging protocol depends on a solution that
> > >>>>>>>
> > >takes
> > >
> > >>>more
> > >>>
> > >>>>>>>of mobility into consideration. Sacrificing this point may
> > >>>>>>>
> > >well
> > >
> > >>>make
> > >>>
> > >>>>>>>the final paging protocol not so useful, at best.
> > >>>>>>>2. I am not particularly inclined for HA based solutions. My
> > >>>>>>>
> > >>>point
> > >>>
> > >>>>>>>is, while defining a mobility based paging protocol we
> > >>>>>>>
> > >should
> > >
> > >>>not
> > >>>
> > >>>>>>>take a particular LMM method (for e.g. HMIPv6) as  solution,
> > >>>>>>>
> > >>>like
> > >>>
> > >>>>>>>draft-sarikaya. But instead a generalised LMM approach. HA
> > >>>>>>>
> > >based
> > >
> > >>>>>>>solution will also be needed for non-LMM cases.
> > >>>>>>>Srini
> > >>>>>>>-----Original Message-----
> > >>>>>>>From: e
> > >>>>>>>xt Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > >>>>>>>Sent: 25 February, 2002 9:32 AM
> > >>>>>>>To: seamoby@ietf.org
> > >>>>>>>Subject: Re: [Seamoby] Deadline Approaching: WG Last Call
> > >>>>>>>
> > >for
> > >
> > >>>Paging
> > >>>
> > >>>>>>>Assessment Draft
> > >>>>>>>Dear all,
> > >>>>>>>  Several mails have been sent over the weekend I'll try to
> > >>>>>>>
> > >give
> > >
> > >>>my
> > >>>
> > >>>>>>>views in one mail.
> > >>>>>>>Regarding Srinivas' email, my understanding is that he is
> > >>>>>>>
> > >>>against
> > >>>
> > >>>>>>>Alternative 1 (one size fits all solution) and he is for the
> > >>>>>>>Alternative
> > >>>>>>>2. In that he is suggesting that we concentrate on
> > >>>>>>>
> > >Requirement
> > >
> > >>>4.8
> > >>>
> > >>>>>>>rather than 4.7. As for the drafts, he seems to be inclined
> > >>>>>>>
> > >to
> > >
> > >>>home
> > >>>
> > >>>>>>>agent based architectures which is demonstrated in
> > >>>>>>>
> > >draft-renker.
> > >
> > >>>>>>>This is
> > >>>>>>>an architectural choice, I think that his choice of
> > >>>>>>>
> > >alternatives
> > >
> > >>>is
> > >>>
> > >>>>>>>clear.
> > >>>>>>>  Besides, I think that the chairs would like to choose
> > >>>>>>>
> > >>>draft/drafts
> > >>>
> > >>>>>>>a
> > >>>>>>>s
> > >>>>>>>soon as possible and ask people to submit their 01 drafts by
> > >>>>>>>
> > >>>March
> > >>>
> > >>>>>>>1st
> > >>>>>>>and move on. We do not have a lot of time for doing this.
> > >>>>>>>Regarding Yoshi's email, I am quoting the abstract of RFC
> > >>>>>>>
> > >3103:
> > >
> > >>>>>>>>This document presents a protocol with which to implement
> > >>>>>>>>
> > >Realm
> > >
> > >>>>>>>>   Specific IP (RSIP).  The protocol defined herein allows
> > >>>>>>>>negotiation
> > >>>>>>>>   of resources between an RSIP host and gateway, so that
> > >>>>>>>>
> > >the
> > >
> > >>>host
> > >>>
> > >>>>>>>>can
> > >>>>>>>>   lease some of the gateway's addressing parameters in
> > >>>>>>>>
> > >order
> > >
> > >>>to
> > >>>
> > >>>>>>>>   establish a global network presence.  This protocol is
> > >>>>>>>>
> > >>>designed
> > >>>
> > >>>>>>>>to
> > >>>>>>>>   operate on the application layer and to use its own TCP
> > >>>>>>>>
> > >or
> > >
> > >>>UDP
> > >>>
> > >>>>>>>>port.
> > >>>>>>>>   In particular, the protocol allows a gateway to allocate
> > >>>>>>>>addressing
> > >>>>>>>>   and control parameters to a host such that a flow policy
> > >>>>>>>>
> > >can
> > >
> > >>>be
> > >>>
> > >>>>>>>>   enforced at the gateway.
> > >>>>>>>>
> > >>>>>>>Yoshi, I think that the functionalities summarized above of
> > >>>>>>>
> > >RSIP
> > >
> > >>>>>>>have
> > >>>>>>>nothing to do with IP Paging. Can we define a port specific
> > >>>>>>>
> > >to
> > >
> > >>>IP
> > >>>
> > >>>>>>>Paging , if yes then how does IP Paging capture all packets
> > >>>>>>>
> > >to
> > >
> > >>>the
> > >>>
> > >>>>>>>dormant hosts?
> > >>>>>>>Added to this, please see Pars' email,
> > >>>>>>>
> > >>>>>>>>This is serious, because "paging" which is intended for
> > >>>>>>>>optimizing bandwidth use, may become a bandwidth threat.
> > >>>>>>>>IP layer solutions may be necessary. This is, perhaps, one
> > >>>>>>>>
> > >more
> > >
> > >>>>>>>>motivation for IP paging.
> > >>>>>>>>
> > >>>>>>>Let us get motivated for IP Paging.
> > >>>>>>>Regards,
> > >>>>>>>Srinivas.Sreemanthula@nokia.com wrote:
> > >>>>>>>
> > >>>>>_______________________________________________
> > >>>>>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
> > >>>
> > >
> > >
> > >_______________________________________________
> > >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  Wed Feb 27 19:34:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25973
	for ; Wed, 27 Feb 2002 19:34:54 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11054;
	Wed, 27 Feb 2002 19:24:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11025
	for ; Wed, 27 Feb 2002 19:24:06 -0500 (EST)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25748
	for ; Wed, 27 Feb 2002 19:24:03 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1S0N4X27882;
	Wed, 27 Feb 2002 18:23:04 -0600 (CST)
Message-ID: <3C7D7867.6000402@alcatel.com>
Date: Wed, 27 Feb 2002 18:23:03 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Yoshihiro Ohba 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References: <20020215165336.GA593@catfish> <3C70E5D0.590A56F7@ccrle.nec.de> <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020220182424.GE3759@catfish> <3C751D75.40907@alcatel.com> <20020221175437.GB2971@catfish> <3C75851D.2060706@alcatel.com> <20020222001118.GB3148@catfish> <3C768B32.1080605@alcatel.com> <20020223023523.GD3543@catfish>
Content-Type: multipart/alternative;
 boundary="------------000505040505010903020809"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------000505040505010903020809
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Hi Yoshi,
I just saw a paper entitled Application Layer Mobility Using SIP by
Schulzrinne in which as part of SIP which is an application layer
protocol a paging protocol is very shortly described. Paging is used to
alert the mobile host in dormant mode in order to forward SIP Invite
request.
You can certainly define such things for specific applications but then
for each application, another paging protocol will have to be defined.
In the same paper mobility is defined for SIP not using Mobile IP.

Maybe now you will be convinced where IP Paging should be placed in
layering.

Yoshihiro Ohba wrote:

>On Fri, Feb 22, 2002 at 12:17:22PM -0600, Behcet Sarikaya wrote:
>
>>
>
>Not yet.  I have a counter example.  Realm-Specific IP (RFC3103),
>which is a NAT technology, defines an application layer protocol for
>controlling a NAT box, while actual data packet transfer through the
>NAT box is version dependent.
>
>Yoshihiro Ohba
>

-- 
Behcet 



--------------000505040505010903020809
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit





Hi Yoshi,

  I just saw a paper entitled Application Layer Mobility Using SIP by Schulzrinne
in which as part of SIP which is an application layer protocol a paging protocol
is very shortly described. Paging is used to alert the mobile host in dormant
mode in order to forward SIP Invite request.

  You can certainly define such things for specific applications but then
for each application, another paging protocol will have to be defined.

  In the same paper mobility is defined for SIP not using Mobile IP.

  

  Maybe now you will be convinced where IP Paging should be placed in layering.



Yoshihiro Ohba wrote:



  
On Fri, Feb 22, 2002 at 12:17:22PM -0600, Behcet Sarikaya wrote:

  

    


    

    

Not yet.  I have a counter example.  Realm-Specific IP (RFC3103),
which is a NAT technology, defines an application layer protocol for
controlling a NAT box, while actual data packet transfer through the
NAT box is version dependent.

Yoshihiro Ohba

    

  

    
-- 
Behcet 

    

    
    

--------------000505040505010903020809--


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


From seamoby-admin@ietf.org  Wed Feb 27 20:20:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27136
	for ; Wed, 27 Feb 2002 20:20:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13412;
	Wed, 27 Feb 2002 20:09:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13386
	for ; Wed, 27 Feb 2002 20:09:40 -0500 (EST)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26772
	for ; Wed, 27 Feb 2002 20:09:36 -0500 (EST)
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1S18Yd1009214;
	Wed, 27 Feb 2002 20:08:34 -0500 (EST)
Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id UAA06760;
	Wed, 27 Feb 2002 20:08:28 -0500 (EST)
Date: Wed, 27 Feb 2002 20:08:33 -0500
To: Behcet Sarikaya 
Cc: Yoshihiro Ohba , seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Message-ID: <20020228010833.GA2922@catfish>
Mail-Followup-To: Behcet Sarikaya ,
	Yoshihiro Ohba , seamoby@ietf.org
References: <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020220182424.GE3759@catfish> <3C751D75.40907@alcatel.com> <20020221175437.GB2971@catfish> <3C75851D.2060706@alcatel.com> <20020222001118.GB3148@catfish> <3C768B32.1080605@alcatel.com> <20020223023523.GD3543@catfish> <3C7D7867.6000402@alcatel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: <3C7D7867.6000402@alcatel.com>
User-Agent: Mutt/1.3.27i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 25
X-Virus-Scanned: by AMaViS-perl11-milter
 (http://amavis.org/)
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

On Wed, Feb 27, 2002 at 06:23:03PM -0600, Behcet Sarikaya wrote:
> Hi Yoshi,
> I just saw a paper entitled Application Layer Mobility Using SIP by
> Schulzrinne in which as part of SIP which is an application layer
> protocol a paging protocol is very shortly described. Paging is used to
> alert the mobile host in dormant mode in order to forward SIP Invite
> request.
> You can certainly define such things for specific applications but then
> for each application, another paging protocol will have to be defined.
> In the same paper mobility is defined for SIP not using Mobile IP.
> 
> Maybe now you will be convinced where IP Paging should be placed in
> layering.
> 

Not yet.

As long as IP Paging is defined as a separate protocol which is
independent of any existing application layer protocol such as SIP, it
logically does not matter whichever layer it is defined and thus
defining IP paging in application layer is also valid in this regard.
There must be other factors to determine the layer where IP paging is
defined.

Yoshihiro Ohba

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


From seamoby-admin@ietf.org  Wed Feb 27 20:57:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28157
	for ; Wed, 27 Feb 2002 20:57:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15399;
	Wed, 27 Feb 2002 20:45:54 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15370
	for ; Wed, 27 Feb 2002 20:45:52 -0500 (EST)
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27796
	for ; Wed, 27 Feb 2002 20:45:48 -0500 (EST)
Received: (cpmta 2581 invoked from network); 27 Feb 2002 17:45:20 -0800
Received: from 65.187.225.53 (HELO Study)
  by smtp.directvinternet.com (209.228.33.206) with SMTP; 27 Feb 2002 17:45:20 -0800
X-Sent: 28 Feb 2002 01:45:20 GMT
Message-ID: <000901c1bff9$9bea25a0$1802a8c0@Study>
From: "pdn \(N9FCW\) in FL" 
To: "Behcet Sarikaya" ,
        "Yoshihiro Ohba" 
Cc: "Yoshihiro Ohba" , 
References: <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020220182424.GE3759@catfish> <3C751D75.40907@alcatel.com> <20020221175437.GB2971@catfish> <3C75851D.2060706@alcatel.com> <20020222001118.GB3148@catfish> <3C768B32.1080605@alcatel.com> <20020223023523.GD3543@catfish> <3C7D7867.6000402@alcatel.com> <20020228010833.GA2922@catfish>
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Date: Wed, 27 Feb 2002 20:45:31 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

With the challenges facing mobile hosts these days, cross layer design is
becoming the
"way things are built".  The layers are only really useful as design
abstractions.  I believe
most implementers are finding that they must build tight coupling between
the PHY-MAC
LLC--IP and in some cases the routing layer for higher speed mobile nodes.
Of course there
is a solution which seems to have died several deaths in the IETF.  That is,
a generic
and efficeint triggering system into and out of IP, for the express purposes
of cross layer
design.

-pdn

----- Original Message -----
From: "Yoshihiro Ohba" 
> On Wed, Feb 27, 2002 at 06:23:03PM -0600, Behcet Sarikaya wrote:
> > Hi Yoshi,
> > I just saw a paper entitled Application Layer Mobility Using SIP by
> > Schulzrinne in which as part of SIP which is an application layer
> > protocol a paging protocol is very shortly described. Paging is used to
> > alert the mobile host in dormant mode in order to forward SIP Invite
> > request.
> > You can certainly define such things for specific applications but then
> > for each application, another paging protocol will have to be defined.
> > In the same paper mobility is defined for SIP not using Mobile IP.
> >
> > Maybe now you will be convinced where IP Paging should be placed in
> > layering.
> >
>
> Not yet.
>
> As long as IP Paging is defined as a separate protocol which is
> independent of any existing application layer protocol such as SIP, it
> logically does not matter whichever layer it is defined and thus
> defining IP paging in application layer is also valid in this regard.
> There must be other factors to determine the layer where IP paging is
> defined.
>
> Yoshihiro Ohba
>
> _______________________________________________
> 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  Thu Feb 28 07:17:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18749
	for ; Thu, 28 Feb 2002 07:17:28 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23814;
	Thu, 28 Feb 2002 07:05:45 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23781
	for ; Thu, 28 Feb 2002 07:05:43 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17653;
	Thu, 28 Feb 2002 07:05:40 -0500 (EST)
Message-Id: <200202281205.HAA17653@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: Thu, 28 Feb 2002 07:05:39 -0500
Subject: [Seamoby] I-D ACTION:draft-forsberg-seamoby-aaa-relocate-00.txt
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Context Relocation of AAA Parameters in IP Networks
	Author(s)	: D. Forsberg, R. Koodli, C. Perkins
	Filename	: draft-forsberg-seamoby-aaa-relocate-00.txt
	Pages		: 11
	Date		: 27-Feb-02
	
Network access authentication and authorization is used for
providing unabused access to users and for billing and accounting
purposes.  AAA has been proposed as an infrastructure that could
provide such support.  With AAA, an access router can be configured
with packet filtering rules to allow controlled access.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-forsberg-seamoby-aaa-relocate-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-forsberg-seamoby-aaa-relocate-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-forsberg-seamoby-aaa-relocate-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:	<20020227124740.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-forsberg-seamoby-aaa-relocate-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-forsberg-seamoby-aaa-relocate-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



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


From seamoby-admin@ietf.org  Thu Feb 28 09:49:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25973
	for ; Thu, 28 Feb 2002 09:49:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02826;
	Thu, 28 Feb 2002 09:34:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02798
	for ; Thu, 28 Feb 2002 09:34:33 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25054
	for ; Thu, 28 Feb 2002 09:34:30 -0500 (EST)
From: rene.purnadi@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SEacx15207
	for ; Thu, 28 Feb 2002 08:36:38 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 28 Feb 2002 08:34:32 -0600
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 28 Feb 2002 08:34:32 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Date: Thu, 28 Feb 2002 08:34:32 -0600
Message-ID: <748E8123D183394982E32A511DB3E73610B0F3@daebe005.NOE.Nokia.com>
Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Thread-Index: AcG/9LhmtSQVWZ0CSpC+6n9fMcSYVwAb9Jzg
To: , 
Cc: 
X-OriginalArrivalTime: 28 Feb 2002 14:34:32.0395 (UTC) FILETIME=[095611B0:01C1C065]
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Hi Yoshi and Bechet,

I agree with Yoshi, IP Paging should be defined independent of any existing application layer protocol such as SIP. The packet containing the SIP Invite message could be just a trigger for the IP paging.

Best Regards,
Rene Purnadi
Phone: +1 972.894.4897
Mobile: +1 972.342.3503
e-mail: rene.purnadi@nokia.com


-----Original Message-----
From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
Sent: Wednesday, February 27, 2002 7:09 PM
To: Behcet Sarikaya
Cc: Yoshihiro Ohba; seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues


On Wed, Feb 27, 2002 at 06:23:03PM -0600, Behcet Sarikaya wrote:
> Hi Yoshi,
> I just saw a paper entitled Application Layer Mobility Using SIP by
> Schulzrinne in which as part of SIP which is an application layer
> protocol a paging protocol is very shortly described. Paging is used to
> alert the mobile host in dormant mode in order to forward SIP Invite
> request.
> You can certainly define such things for specific applications but then
> for each application, another paging protocol will have to be defined.
> In the same paper mobility is defined for SIP not using Mobile IP.
> 
> Maybe now you will be convinced where IP Paging should be placed in
> layering.
> 

Not yet.

As long as IP Paging is defined as a separate protocol which is
independent of any existing application layer protocol such as SIP, it
logically does not matter whichever layer it is defined and thus
defining IP paging in application layer is also valid in this regard.
There must be other factors to determine the layer where IP paging is
defined.

Yoshihiro Ohba

_______________________________________________
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  Thu Feb 28 11:24:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01571
	for ; Thu, 28 Feb 2002 11:24:38 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08791;
	Thu, 28 Feb 2002 11:06:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08766
	for ; Thu, 28 Feb 2002 11:06:29 -0500 (EST)
Received: from kaikoura.fel.tno.nl (kaikoura-tnonet.fel.tno.nl [134.221.46.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00375
	for ; Thu, 28 Feb 2002 11:06:25 -0500 (EST)
Received: by kaikoura.fel.tno.nl; id RAA03514; Thu, 28 Feb 2002 17:05:54 +0100 (MET)
Received: from fs1.fel.tno.nl(134.203.8.201) by kaikoura.fel.tno.nl via smap (V1.0)
	id xma003255; Thu, 28 Feb 02 17:05:31 +0100
Received: from pc1928.fel.tno.nl ([134.203.9.113]) by
          fs1.fel.tno.nl (Netscape Messaging Server 4.15) with SMTP id
          GS93DA00.SGS for ; Thu, 28 Feb 2002 17:05:34 +0100 
Received: FROM fel.tno.nl BY pc1928.fel.tno.nl ; Thu Feb 28 17:05:33 2002 +0100
Message-ID: <3C7E554C.E22F9242@fel.tno.nl>
Date: Thu, 28 Feb 2002 17:05:32 +0100
From: "BA Kock" 
Organization: TNO-FEL
X-Mailer: Mozilla 4.78 [en]C-Netscape2000  (Win98; U)
X-Accept-Language: en,nl,fr,de
MIME-Version: 1.0
To: seamoby@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] (no subject)
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit





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


From seamoby-admin@ietf.org  Thu Feb 28 11:37:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02500
	for ; Thu, 28 Feb 2002 11:37:05 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09763;
	Thu, 28 Feb 2002 11:23:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09732
	for ; Thu, 28 Feb 2002 11:23:01 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01468
	for ; Thu, 28 Feb 2002 11:22:56 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1SGMUl08771
	for ; Thu, 28 Feb 2002 10:22:30 -0600 (CST)
Message-ID: <3C7E5945.4050503@alcatel.com>
Date: Thu, 28 Feb 2002 10:22:29 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References: <748E8123D183394982E32A511DB3E73610B0F3@daebe005.NOE.Nokia.com>
Content-Type: multipart/alternative;
 boundary="------------020303090505050903080404"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------020303090505050903080404
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

In case of SIP based paging, the MH does dormant mode registrations to
the SIP servers. SIP servers take part in doing the paging (finding the
MH) and then forward SIP Invite message.

The mechanism of paging as described in the paper I mentioned is very
similar to what we defined in draft-sarikaya or draft-guri.

The point here is that the trigger is SIP Invite message which means the
application layer header should be processed in order to trigger the paging.

Therefore if you want to trigger paging for another application you need
to define it in another application layer protocol.

However if paging is defined as IP layer protocol, the paging will be
automatically triggered looking into IP header. This requires the paging
infrastructure setup independent of any application, using paging
protocol entities.

Note that similar arguments exist for Mobile IP. Terminal mobility can
be handled at the application layer, like SIP based terminal mobility
described in Henning's paper. Again what is done is in fact very similar
to Mobile IP operation.

These are very well known facts on layering, surprising how some find it
confusing.

Rene,the issue here is, if IP Paging is an IP layer protocol then we
have define for different protocols (simple IPv4 simple IPv6 mobile IPv4
and mobile IPv6 based IP Paging). All of these are independent of any
application. This is the issue.

Regards,

rene.purnadi@nokia.com wrote:

>Hi Yoshi and Bechet,
>
>I agree with Yoshi, IP Paging should be defined independent of any existing application layer protocol such as SIP. The packet containing the SIP Invite message could be just a trigger for the IP paging.
>
>Best Regards,
>Rene Purnadi
>Phone: +1 972.894.4897
>Mobile: +1 972.342.3503
>e-mail: rene.purnadi@nokia.com
>
>
>-----Original Message-----
>From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
>Sent: Wednesday, February 27, 2002 7:09 PM
>To: Behcet Sarikaya
>Cc: Yoshihiro Ohba; seamoby@ietf.org
>Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
>Protocol Issues
>
>
>On Wed, Feb 27, 2002 at 06:23:03PM -0600, Behcet Sarikaya wrote:
>
>>Hi Yoshi,
>>I just saw a paper entitled Application Layer Mobility Using SIP by
>>Schulzrinne in which as part of SIP which is an application layer
>>protocol a paging protocol is very shortly described. Paging is used to
>>alert the mobile host in dormant mode in order to forward SIP Invite
>>request.
>>You can certainly define such things for specific applications but then
>>for each application, another paging protocol will have to be defined.
>>In the same paper mobility is defined for SIP not using Mobile IP.
>>
>>Maybe now you will be convinced where IP Paging should be placed in
>>layering.
>>
>
>Not yet.
>
>As long as IP Paging is defined as a separate protocol which is
>independent of any existing application layer protocol such as SIP, it
>logically does not matter whichever layer it is defined and thus
>defining IP paging in application layer is also valid in this regard.
>There must be other factors to determine the layer where IP paging is
>defined.
>
>Yoshihiro Ohba
>
--behcet

>


--------------020303090505050903080404
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit





In case of SIP based paging, the MH does dormant mode registrations to the
SIP servers. SIP servers take part in doing the paging (finding the MH) and
then forward SIP Invite message.



The mechanism of paging as described in the paper I mentioned is very similar
to  what we defined in draft-sarikaya or draft-guri.



The point here is that the trigger is SIP Invite message which means the
application layer header should be processed in order to trigger the paging.



Therefore if you want to trigger paging for another application you need
to define it in another application layer protocol.



However if paging is defined as IP layer protocol, the paging will be
automatically triggered looking into IP header. This requires the paging
infrastructure setup independent of any application, using paging protocol
entities.



Note that similar arguments exist for Mobile IP. Terminal mobility can be
handled at the application layer, like SIP based terminal mobility described
in Henning's paper. Again what is done is in fact very similar to Mobile
IP operation. 



These are very well known facts on layering, surprising how some find it
confusing.



Rene,the issue here is, if IP Paging is an IP layer protocol then we have
define for different protocols (simple IPv4 simple IPv6 mobile IPv4 and mobile
IPv6 based IP Paging). All of these are independent of any application. This
is the issue.



Regards,



rene.purnadi@nokia.com wrote:



  
Hi Yoshi and Bechet,

I agree with Yoshi, IP Paging should be defined independent of any existing application layer protocol such as SIP. The packet containing the SIP Invite message could be just a trigger for the IP paging.

Best Regards,
Rene Purnadi
Phone: +1 972.894.4897
Mobile: +1 972.342.3503
e-mail: rene.purnadi@nokia.com


-----Original Message-----
From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
Sent: Wednesday, February 27, 2002 7:09 PM
To: Behcet Sarikaya
Cc: Yoshihiro Ohba; seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues


On Wed, Feb 27, 2002 at 06:23:03PM -0600, Behcet Sarikaya wrote:

  

    
Hi Yoshi,
I just saw a paper entitled Application Layer Mobility Using SIP by
Schulzrinne in which as part of SIP which is an application layer
protocol a paging protocol is very shortly described. Paging is used to
alert the mobile host in dormant mode in order to forward SIP Invite
request.
You can certainly define such things for specific applications but then
for each application, another paging protocol will have to be defined.
In the same paper mobility is defined for SIP not using Mobile IP.

Maybe now you will be convinced where IP Paging should be placed in
layering.


    

    

Not yet.

As long as IP Paging is defined as a separate protocol which is
independent of any existing application layer protocol such as SIP, it
logically does not matter whichever layer it is defined and thus
defining IP paging in application layer is also valid in this regard.
There must be other factors to determine the layer where IP paging is
defined.

Yoshihiro Ohba


    

--behcet

    

      


      

      

      
      

--------------020303090505050903080404--


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


From seamoby-admin@ietf.org  Thu Feb 28 12:08:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04964
	for ; Thu, 28 Feb 2002 12:08:43 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12418;
	Thu, 28 Feb 2002 11:53:07 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12389
	for ; Thu, 28 Feb 2002 11:53:04 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03682
	for ; Thu, 28 Feb 2002 11:53:00 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1SGq0e23554;
	Thu, 28 Feb 2002 08:52:00 -0800 (PST)
Message-ID: <004201c1c078$049c5f90$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "pdn \(N9FCW\) in FL" ,
        "Behcet Sarikaya" ,
        "Yoshihiro Ohba" 
Cc: "Yoshihiro Ohba" , 
References: <005001c1b8da$8c60f3f0$8e6015ac@T23KEMPF> <3C7257CB.39937220@ccrle.nec.de> <20020220182424.GE3759@catfish> <3C751D75.40907@alcatel.com> <20020221175437.GB2971@catfish> <3C75851D.2060706@alcatel.com> <20020222001118.GB3148@catfish> <3C768B32.1080605@alcatel.com> <20020223023523.GD3543@catfish> <3C7D7867.6000402@alcatel.com> <20020228010833.GA2922@catfish> <000901c1bff9$9bea25a0$1802a8c0@Study>
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Date: Thu, 28 Feb 2002 08:50:24 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Phil,

> With the challenges facing mobile hosts these days, cross layer design
is
> becoming the
> "way things are built".  The layers are only really useful as design
> abstractions.  I believe
> most implementers are finding that they must build tight coupling
between
> the PHY-MAC
> LLC--IP and in some cases the routing layer for higher speed mobile
nodes.
> Of course there
> is a solution which seems to have died several deaths in the IETF.
That is,
> a generic
> and efficeint triggering system into and out of IP, for the express
purposes
> of cross layer
> design.
>

I think a better design principle is to keep a clear idea of what each
layer is supposed to
accomplish and what information is needed from lower layers or higher
layers to accomplish it. Rather than
a tight coupling, I think a collection of design abstractions that
clearly deliniate the contract
between layers is more useful. One can do that with abstract triggers,
and I believe there may be some hope for work on this in the IETF.

            jak


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


From seamoby-admin@ietf.org  Thu Feb 28 12:28:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06599
	for ; Thu, 28 Feb 2002 12:28:32 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15663;
	Thu, 28 Feb 2002 12:14:27 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15630
	for ; Thu, 28 Feb 2002 12:14:25 -0500 (EST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05447
	for ; Thu, 28 Feb 2002 12:14:20 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1SHDse24319
	for ; Thu, 28 Feb 2002 09:13:54 -0800 (PST)
Message-ID: <008b01c1c07b$1354f5d0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Date: Thu, 28 Feb 2002 09:12:18 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] CAR Discovery Requirements Draft and Discussion at IETF 53
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Folks,

Pat and I have asked Govind to submit an update to draft-krishnamurthi
prior to the 01+ draft deadline this Fri because we cannot change the
name to draft-ietf-seamboy since that would revert the version number
back to 00. After the gate opens and presuming we've reached closure on
the requirements, Govind will submit another draft after IETF 53 with
the working group draft file name and we will go to Working Group Last
Call.

We would like to have a comprehensive and through discussion on
requirements at IETF 53. We urge people who care about CAR discovery to
read the requirements and consider what they believe must be added or
clarified, and to bring these issues up at the meeting. If you have an
issue, please try to come up with some constructive suggestion for text
that might be added, changed, or removed in the requirements draft in
order to clarify or address the issue. We have limited time at the
meeting, and when people come up and simply criticize, it often takes
longer to come to agreement about what needs to be changed and what
wording will work to clarify the point in question. A proposal for text
is easier for people to consider than simply a criticism. If it will
help, we could also do online editing so that people can see the text in
the context of the document, but this is often more time consuming.

Remember, our goal is not to engage in a spirited and lively debate
(though that might happen) but rather to come to agreement about a set
of requirements that will guide our solution to the problem.

            jak


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


From seamoby-admin@ietf.org  Thu Feb 28 13:28:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10850
	for ; Thu, 28 Feb 2002 13:28:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19387;
	Thu, 28 Feb 2002 13:14:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19356
	for ; Thu, 28 Feb 2002 13:14:06 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09886
	for ; Thu, 28 Feb 2002 13:14:03 -0500 (EST)
From: rene.purnadi@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SIG4x08047
	for ; Thu, 28 Feb 2002 12:16:09 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 28 Feb 2002 12:13:58 -0600
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 28 Feb 2002 12:13:05 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Date: Thu, 28 Feb 2002 12:13:05 -0600
Message-ID: <748E8123D183394982E32A511DB3E73610B0F4@daebe005.NOE.Nokia.com>
Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Thread-Index: AcHAdE4sVrZS/NBRSbKjYpkwoCXGnAADieow
To: , 
X-OriginalArrivalTime: 28 Feb 2002 18:13:05.0901 (UTC) FILETIME=[919849D0:01C1C083]
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Bechet,
 
I understood that if IP Paging is an IP layer protocol then we have to define different protocols (simple IPv4, simple IPv6, mobile IPv4 and mobile IPv6 based IP Paging, although we should de-emphasize the need of paging in simple IP). But if we put the paging protocol as an application layer protocol, then to trigger paging for another application you need to define another paging application layer protocol. Is it what we want?
 
Best Regards,


Rene Purnadi 
Phone: +1 972.894.4897 
Mobile: +1 972.342.3503 
e-mail: rene.purnadi@nokia.com 

 

-----Original Message-----
From: ext Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Thursday, February 28, 2002 10:22 AM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues


In case of SIP based paging, the MH does dormant mode registrations to the SIP servers. SIP servers take part in doing the paging (finding the MH) and then forward SIP Invite message.

The mechanism of paging as described in the paper I mentioned is very similar to  what we defined in draft-sarikaya or draft-guri.

The point here is that the trigger is SIP Invite message which means the application layer header should be processed in order to trigger the paging.

Therefore if you want to trigger paging for another application you need to define it in another application layer protocol.

However if paging is defined as IP layer protocol, the paging will be automatically triggered looking into IP header. This requires the paging infrastructure setup independent of any application, using paging protocol entities.

Note that similar arguments exist for Mobile IP. Terminal mobility can be handled at the application layer, like SIP based terminal mobility described in Henning's paper. Again what is done is in fact very similar to Mobile IP operation. 

These are very well known facts on layering, surprising how some find it confusing.

Rene,the issue here is, if IP Paging is an IP layer protocol then we have define for different protocols (simple IPv4 simple IPv6 mobile IPv4 and mobile IPv6 based IP Paging). All of these are independent of any application. This is the issue.

Regards,

rene.purnadi@nokia.com wrote:


Hi Yoshi and Bechet,

I agree with Yoshi, IP Paging should be defined independent of any existing application layer protocol such as SIP. The packet containing the SIP Invite message could be just a trigger for the IP paging.

Best Regards,
Rene Purnadi
Phone: +1 972.894.4897
Mobile: +1 972.342.3503
e-mail:  rene.purnadi@nokia.com


-----Original Message-----
From: ext Yoshihiro Ohba [ mailto:yohba@tari.toshiba.com]
Sent: Wednesday, February 27, 2002 7:09 PM
To: Behcet Sarikaya
Cc: Yoshihiro Ohba;  seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues


On Wed, Feb 27, 2002 at 06:23:03PM -0600, Behcet Sarikaya wrote:

Hi Yoshi,
I just saw a paper entitled Application Layer Mobility Using SIP by
Schulzrinne in which as part of SIP which is an application layer
protocol a paging protocol is very shortly described. Paging is used to
alert the mobile host in dormant mode in order to forward SIP Invite
request.
You can certainly define such things for specific applications but then
for each application, another paging protocol will have to be defined.
In the same paper mobility is defined for SIP not using Mobile IP.

Maybe now you will be convinced where IP Paging should be placed in
layering.



Not yet.

As long as IP Paging is defined as a separate protocol which is
independent of any existing application layer protocol such as SIP, it
logically does not matter whichever layer it is defined and thus
defining IP paging in application layer is also valid in this regard.
There must be other factors to determine the layer where IP paging is
defined.

Yoshihiro Ohba


--behcet






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


From seamoby-admin@ietf.org  Thu Feb 28 16:33:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20955
	for ; Thu, 28 Feb 2002 16:33:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01539;
	Thu, 28 Feb 2002 16:23:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01512
	for ; Thu, 28 Feb 2002 16:23:10 -0500 (EST)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20340
	for ; Thu, 28 Feb 2002 16:23:04 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1SLMbX23943
	for ; Thu, 28 Feb 2002 15:22:37 -0600 (CST)
Message-ID: <3C7E9F9C.4080301@alcatel.com>
Date: Thu, 28 Feb 2002 15:22:36 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References: <748E8123D183394982E32A511DB3E73610B0F4@daebe005.NOE.Nokia.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Rene,

rene.purnadi@nokia.com wrote:

>Bechet,
> 
>I understood that if IP Paging is an IP layer protocol then we have to define different protocols (simple IPv4, simple IPv6, mobile IPv4 and mobile IPv6 based IP Paging, although we should de-emphasize the need of paging in simple IP). 
>
Agreed.

>But if we put the paging protocol as an application layer protocol, then to trigger paging for another application you need to define another paging application layer protocol. Is it what we want?
> 
>Best Regards,
>
>
>Rene Purnadi 
>Phone: +1 972.894.4897 
>Mobile: +1 972.342.3503 
>e-mail: rene.purnadi@nokia.com 
>
Of course not.

--bechet




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


From seamoby-admin@ietf.org  Thu Feb 28 17:13:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22615
	for ; Thu, 28 Feb 2002 17:13:23 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04448;
	Thu, 28 Feb 2002 17:02:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04418
	for ; Thu, 28 Feb 2002 17:02:51 -0500 (EST)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22157
	for ; Thu, 28 Feb 2002 17:02:47 -0500 (EST)
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g1SM28d1010372;
	Thu, 28 Feb 2002 17:02:09 -0500 (EST)
Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id RAA09067;
	Thu, 28 Feb 2002 17:02:03 -0500 (EST)
Date: Thu, 28 Feb 2002 17:02:07 -0500
To: rene.purnadi@nokia.com
Cc: behcet.sarikaya@alcatel.com, seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Message-ID: <20020228220207.GD2463@catfish>
Mail-Followup-To: rene.purnadi@nokia.com, behcet.sarikaya@alcatel.com,
	seamoby@ietf.org
References: <748E8123D183394982E32A511DB3E73610B0F4@daebe005.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: <748E8123D183394982E32A511DB3E73610B0F4@daebe005.NOE.Nokia.com>
User-Agent: Mutt/1.3.27i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 19
X-Virus-Scanned: by AMaViS-perl11-milter
 (http://amavis.org/)
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

On Thu, Feb 28, 2002 at 12:13:05PM -0600, rene.purnadi@nokia.com wrote:
> Bechet,
>  
> I understood that if IP Paging is an IP layer protocol then we have to define different protocols (simple IPv4, simple IPv6, mobile IPv4 and mobile IPv6 based IP Paging, although we should de-emphasize the need of paging in simple IP).

Are there any particular reason for de-emphasizing the need of DMHA
for simple-ip?  I think the reason for using the word "DMHA" instead
of "IP paging" is as a result of consideration of dormant simple-ip
hosts as well as dormant mobile hosts.  We should also consider 
simple-ip for the reason as I mentioned earlier.

> But if we put the paging protocol as an application layer protocol, then to trigger paging for another application you need to define another paging application layer protocol. Is it what we want?

I don't understand why we need another paging apllication layer protocol 
if we put the paging protocol as an application layer protocol.  

Yoshihiro Ohba



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


From seamoby-admin@ietf.org  Thu Feb 28 18:24:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25641
	for ; Thu, 28 Feb 2002 18:24:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08765;
	Thu, 28 Feb 2002 18:12:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08737
	for ; Thu, 28 Feb 2002 18:12:35 -0500 (EST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25326
	for ; Thu, 28 Feb 2002 18:12:31 -0500 (EST)
From: Srinivas.Sreemanthula@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SNCoG28622
	for ; Thu, 28 Feb 2002 17:12:50 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 28 Feb 2002 17:12:34 -0600
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 28 Feb 2002 17:11:57 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Date: Thu, 28 Feb 2002 17:11:57 -0600
Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF676@daebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Thread-Index: AcHAo7qsPQSn1WX7RwWSUQfgizwbpwABfTXw
To: , 
Cc: , 
X-OriginalArrivalTime: 28 Feb 2002 23:11:57.0954 (UTC) FILETIME=[51EE6E20:01C1C0AD]
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

>>Are there any particular reason for de-emphasizing the need of DMHA
for simple-ip?  I think the reason for using the word "DMHA" instead
of "IP paging" is as a result of consideration of dormant simple-ip
hosts as well as dormant mobile hosts.  We should also consider 
simple-ip for the reason as I mentioned earlier.

Yes. When we talk about about simple-ip, we mean static hosts that are plugged into the power source which don't have any mobility built in them. Therefore, they don't require any dormancy. Please remember the first requirement for DMHA is to save power for lean terminals running on limited power (mobile, ofcourse). Now, can you exactly tell why we need DMHA for simple-ip?

>>I don't understand why we need another paging apllication layer protocol 
if we put the paging protocol as an application layer protocol. 

If we leave the simple-ip out (as we should),  it is only natural that paging protocol makes as an extension to the existing mobility protocol(s).  As of now, the applications (or application servers) are not aware of the mobility of the hosts.  For the same reason, paging protocol must be independent of the application layers above. 


_______________________________________________
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  Thu Feb 28 19:46:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27789
	for ; Thu, 28 Feb 2002 19:46:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12532;
	Thu, 28 Feb 2002 19:31:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12505
	for ; Thu, 28 Feb 2002 19:31:37 -0500 (EST)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27577
	for ; Thu, 28 Feb 2002 19:31:34 -0500 (EST)
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g210URd1021006;
	Thu, 28 Feb 2002 19:30:27 -0500 (EST)
Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id TAA09380;
	Thu, 28 Feb 2002 19:30:21 -0500 (EST)
Date: Thu, 28 Feb 2002 19:30:24 -0500
To: Srinivas.Sreemanthula@nokia.com
Cc: yohba@tari.toshiba.com, rene.purnadi@nokia.com,
        behcet.sarikaya@alcatel.com, seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
Message-ID: <20020301003023.GA653@catfish>
Mail-Followup-To: Srinivas.Sreemanthula@nokia.com, yohba@tari.toshiba.com,
	rene.purnadi@nokia.com, behcet.sarikaya@alcatel.com,
	seamoby@ietf.org
References: <07EE0E021034014F99A57B032BC9C0E50FF676@daebe001.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: <07EE0E021034014F99A57B032BC9C0E50FF676@daebe001.NOE.Nokia.com>
User-Agent: Mutt/1.3.27i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 29
X-Virus-Scanned: by AMaViS-perl11-milter
 (http://amavis.org/)
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org

On Thu, Feb 28, 2002 at 05:11:57PM -0600, Srinivas.Sreemanthula@nokia.com wrote:
> >>Are there any particular reason for de-emphasizing the need of DMHA
> for simple-ip?  I think the reason for using the word "DMHA" instead
> of "IP paging" is as a result of consideration of dormant simple-ip
> hosts as well as dormant mobile hosts.  We should also consider 
> simple-ip for the reason as I mentioned earlier.
> 
> Yes. When we talk about about simple-ip, we mean static hosts that are plugged into the power source which don't have any mobility built in them. Therefore, they don't require any dormancy. Please remember the first requirement for DMHA is to save power for lean terminals running on limited power (mobile, ofcourse). Now, can you exactly tell why we need DMHA for simple-ip?

Why do you exclude a simple-ip host that is not plugged into the power
source?

Moreover, why should we ignore power saving for plugged-in hosts?


DMHA for simple-ip is required for stationary dormant hosts not to 
spend power (battery or plugged-in power) for processing unimportant 
packets (thus filtering trigger packets is necessary for DMHA).

> 
> >>I don't understand why we need another paging apllication layer protocol 
> if we put the paging protocol as an application layer protocol. 
> 
> If we leave the simple-ip out (as we should),  it is only natural that paging protocol makes as an extension to the existing mobility protocol(s).  As of now, the applications (or application servers) are not aware of the mobility of the hosts.  For the same reason, paging protocol must be independent of the application layers above. 

Now one important requirement is going to be compromized, 
independence of any mobility management protocol.  I disagree.

Yoshihiro Ohba

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


From seamoby-admin@ietf.org  Thu Feb 28 20:22:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28404
	for ; Thu, 28 Feb 2002 20:22:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14410;
	Thu, 28 Feb 2002 20:10:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14379
	for ; Thu, 28 Feb 2002 20:10:53 -0500 (EST)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28159
	for ; Thu, 28 Feb 2002 20:10:49 -0500 (EST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g2119mX06955;
	Thu, 28 Feb 2002 19:09:48 -0600 (CST)
Message-ID: <3C7EE838.10806@alcatel.com>
Date: Thu, 28 Feb 2002 20:32:24 -0600
From: Vinod Kumar Choyi 
Reply-To: vinod.choyi@alcatel.com
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Yoshihiro Ohba 
CC: Srinivas.Sreemanthula@nokia.com, rene.purnadi@nokia.com,
        behcet.sarikaya@alcatel.com, seamoby@ietf.org
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues
References: <07EE0E021034014F99A57B032BC9C0E50FF676@daebe001.NOE.Nokia.com> <20020301003023.GA653@catfish>
Content-Type: multipart/alternative;
 boundary="------------050506000802040804020405"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


--------------050506000802040804020405
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Instead of the term Simple IP we could say: Hosts that do not use MIP,
they could be wireless or fixed. I do not think we should completely
ignore paging support for these hosts.
Having a design such that paging entities and their interactions are
within a local network (Foreign network takes care of paging when MN is
in a visited network and Home network takes care of paging when MN is at
home) could provide a solution for both MIP hosts and Simple IP hosts
(do not use MIP).
The MAIN difference (not the only difference) between Simple IP service
and MIP service is the involvement of Home Agent (Home network, AAAH
etc), so if we were to avoid anything to do with Home we could have a
BASE solution that supports both hosts. To me, that BASE solution should
be Home - Independent.
To have optimized solutions (whatever OPTIMIZED means), we would need to
use the base solution to come up with a solutions for Simple IP, MIPv4
and MIPv6.

regards
vinod

Yoshihiro Ohba wrote:

>On Thu, Feb 28, 2002 at 05:11:57PM -0600, Srinivas.Sreemanthula@nokia.com wrote:
>
>>>>Are there any particular reason for de-emphasizing the need of DMHA
>>>>
>>for simple-ip?  I think the reason for using the word "DMHA" instead
>>of "IP paging" is as a result of consideration of dormant simple-ip
>>hosts as well as dormant mobile hosts.  We should also consider 
>>simple-ip for the reason as I mentioned earlier.
>>
>>Yes. When we talk about about simple-ip, we mean static hosts that are plugged into the power source which don't have any mobility built in them. Therefore, they don't require any dormancy. Please remember the first requirement for DMHA is to save power for lean terminals running on limited power (mobile, ofcourse). Now, can you exactly tell why we need DMHA for simple-ip?
>>
>
>Why do you exclude a simple-ip host that is not plugged into the power
>source?
>
>Moreover, why should we ignore power saving for plugged-in hosts?
>
>
>DMHA for simple-ip is required for stationary dormant hosts not to 
>spend power (battery or plugged-in power) for processing unimportant 
>packets (thus filtering trigger packets is necessary for DMHA).
>
>>>>I don't understand why we need another paging apllication layer protocol 
>>>>
>>if we put the paging protocol as an application layer protocol. 
>>
>>If we leave the simple-ip out (as we should),  it is only natural that paging protocol makes as an extension to the existing mobility protocol(s).  As of now, the applications (or application servers) are not aware of the mobility of the hosts.  For the same reason, paging protocol must be independent of the application layers above. 
>>
>
>Now one important requirement is going to be compromized, 
>independence of any mobility management protocol.  I disagree.
>
>Yoshihiro Ohba
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>


--------------050506000802040804020405
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit





Instead of the term Simple IP we could say: Hosts that do not use MIP, they
could be wireless or fixed. I do not think we should completely ignore paging
support for these hosts.

Having a design such that paging entities and their interactions are within
a local network (Foreign network takes care of paging when MN is in a visited
network and Home network takes care of paging when MN is at home) could provide
a solution for both MIP hosts and Simple IP hosts (do not use MIP).

The MAIN difference (not the only difference) between Simple IP service and
MIP service is the involvement of  Home Agent (Home network, AAAH etc), so
if we were to avoid anything to do with Home we could have a BASE solution
that supports both hosts. To me, that BASE solution should be Home - Independent.

To have optimized solutions (whatever OPTIMIZED means), we would need to
use the base solution to come up with a solutions for Simple IP, MIPv4 and
MIPv6. 



regards

vinod



Yoshihiro Ohba wrote:



  
On Thu, Feb 28, 2002 at 05:11:57PM -0600, Srinivas.Sreemanthula@nokia.com wrote:

  

    

      

        
Are there any particular reason for de-emphasizing the need of DMHA

        

        

        
for simple-ip?  I think the reason for using the word "DMHA" instead
of "IP paging" is as a result of consideration of dormant simple-ip
hosts as well as dormant mobile hosts.  We should also consider 
simple-ip for the reason as I mentioned earlier.

Yes. When we talk about about simple-ip, we mean static hosts that are plugged into the power source which don't have any mobility built in them. Therefore, they don't require any dormancy. Please remember the first requirement for DMHA is to save power for lean terminals running on limited power (mobile, ofcourse). Now, can you exactly tell why we need DMHA for simple-ip?

        

        

Why do you exclude a simple-ip host that is not plugged into the power
source?

Moreover, why should we ignore power saving for plugged-in hosts?


DMHA for simple-ip is required for stationary dormant hosts not to 
spend power (battery or plugged-in power) for processing unimportant 
packets (thus filtering trigger packets is necessary for DMHA).


        

          

            

              
I don't understand why we need another paging apllication layer protocol 

              

              

              
if we put the paging protocol as an application layer protocol. 

If we leave the simple-ip out (as we should),  it is only natural that paging protocol makes as an extension to the existing mobility protocol(s).  As of now, the applications (or application servers) are not aware of the mobility of the hosts.  For the same reason, paging protocol must be independent of the application layers above. 

              

              

Now one important requirement is going to be compromized, 
independence of any mobility management protocol.  I disagree.

Yoshihiro Ohba

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

              

              

              
              

--------------050506000802040804020405--


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