From mailman-owner@ietf.org Tue Jan 1 06:56: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 GAA11694 for ; Tue, 1 Jan 2002 06:56: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 GAA16166 for ; Tue, 1 Jan 2002 06:56:48 -0500 (EST) Date: Tue, 1 Jan 2002 06:56:48 -0500 (EST) Message-Id: <200201011156.GAA16166@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 Tue Jan 1 07:01: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 HAA11795 for ; Tue, 1 Jan 2002 07:01: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 HAA18525 for ; Tue, 1 Jan 2002 07:01:59 -0500 (EST) Date: Tue, 1 Jan 2002 07:01:59 -0500 (EST) Message-Id: <200201011201.HAA18525@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 Wed Jan 2 06:16: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 GAA02399 for ; Wed, 2 Jan 2002 06:16: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 FAA02059; Wed, 2 Jan 2002 05:54: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 FAA02030 for ; Wed, 2 Jan 2002 05:54:24 -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 FAA02090 for ; Wed, 2 Jan 2002 05:54:20 -0500 (EST) From: ralf.schmitz@ccrle.nec.de Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g02As5A66042; Wed, 2 Jan 2002 11:54:05 +0100 (CET) Received: from DVORAK (dvorak.mobility.ccrle.nec.de [192.168.101.42]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 27576C052; Wed, 2 Jan 2002 11:54:05 +0100 (CET) To: "Jari T. Malinen" Date: Wed, 2 Jan 2002 11:53:53 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [Seamoby] framework for DMHA protocol Cc: seamoby@ietf.org Message-ID: <3C32F4D1.20791.BDBD84@localhost> Priority: normal In-reply-to: <3C23D802.5E052D52@iprg.nokia.com> X-mailer: Pegasus Mail for Win32 (v3.12c) 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 21 Dec 2001, at 16:46, Jari T. Malinen wrote: Hi Jari, please see my comments in line... > Hello, > > Having a design team framework document is ok, currently the draft-renker > gives a multitude of choices to do a protocol. Ultimately we'll need something > simple and unambiguous. => Agreed. We'll need something simple and unambiguous, but at the same time we should not restrict ourself too much at this early stage of the protocol design. The 'multitude of choices' offer a variety of possibilities in order to be as flexible and open as possible. All the choices are up for discussion so that the group can (hopefully) come out with the desired simple and unambiguous protocol. > This would need strong modification to become a > real protocol from its current format which looks more like an architecture > with candidate modes for several functionalities. > > I second that the requirement for protocol independence is important. > Hence, I suggest structuring the document in a way that decouples the protocol > from all other protocols (MIPv6 etc. included) so much that they do not need > ideally to be even refered to at all. If needed, there should be appendices > describing interaction but only in the case it is essential for the > working of the protocol in some mode etc. Interdependences should be > minimized. => Isn't this exactly what Marco proposed in his mail (seebelow)?! I think, the idea of 'moving the Mobile IPv6 options ... into the Annex .. ' is a good step forward towards the required protocol independance. kind regards ralf > > Merry Christmas and a Happy New year all, > > -Jari > > On Fri, Dec 21, 2001 at 06:45:59PM +0100, Marco Liebsch wrote: > > Dear all, > > I will try to structure a draft framework, which is then for discussion > > on the list, taking first the protocol as it is now and moving the > > Mobile IPv6 options to be considered for MIP optimization purposes into > > the Annex (open). We have to think about extensions and address the > > parts the assessment draft refers to. Until first framework is > > available, please be referred to the current version of the base-line > > concept draft-renker-paging-ipv6-01.txt and also think of issues to be > > clarifed with respect to what is already written. So we can address > > these issues and have enhancements in the first draft version, which > > could be submitted end of January, if the WG agrees and we proceed. What > > do you think? > > > > I wish you all a merry Christmas and a happy new year. I will be back in > > the office around Jan, 10th. > > > > Marco > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > -- Ralf Schmitz NEC Europe Ltd. - Network Laboratories E-Mail: Ralf.Schmitz@ccrle.nec.de http://www.ccrle.nec.de/ Adenauerplatz 6 D-69115 Heidelberg - Germany Phone: +49 (0)6221/ 13 70 8 - 12 Fax: +49 (0)6221/ 13 70 8 - 28 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 2 14:11: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 OAA08789 for ; Wed, 2 Jan 2002 14:11: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 NAA16417; Wed, 2 Jan 2002 13:58: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 NAA16389 for ; Wed, 2 Jan 2002 13:58:15 -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 NAA08606 for ; Wed, 2 Jan 2002 13:58:13 -0500 (EST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id MAA28484 for ; Wed, 2 Jan 2002 12:57:45 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g02Ivir15623 for ; Wed, 2 Jan 2002 12:57:44 -0600 (CST) Message-ID: <3C335823.5030009@alcatel.com> Date: Wed, 02 Jan 2002 12:57: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@ietf.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] IP Paging ]Framework discussion 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, I went thru the emails that I missed on the list during holiday period. You referred to our work several times, do I have right to rebuttal? -James Kempf said in his mail to Yoshi: --Something like the time-slotted --paging support in draft-sarikaya is what is needed in --the final protocol. We have included a shortedned version of time-slotted paging in the LAHAP draft. You seem to ignore the LAHAP draft always, why? (I think the answer is implicit in your other mail, parts of it I am copying here) -James Kempf said in his mail: --There must be a TA per paging area, not per subnet. In the case of --L2 paging areas, the TA is identified as the entity that is taking --the L2 paging area update and coverting it into an L3 paging --area update. So it plays an important role there. The movement at IP level is based on the subnet so if we are going to track movement then TA functionality is needed in every subnet. If every subnet is a L3 paging area then this becomes what you said. -James Kempf said in his mail: --I view the Paging Agent as the entity that initiates the actual page --directly --to the MN. This may be an L2 page or it may be an L3 page. I view it --as similar to the last hop router. The last hop router can take part in paging in communication with the Paging Agent. In case L3 paging area contains several IP subnets, then don't you need an upper level entity to take care of the paging process? We have been discussing these issues with Hideaki from Fujitsu whom I never met, several months back, I am enclosing the email from Seamoby archive. -------- Original Message -------- Subject: [seamoby] Re: [Fwd: questions on LAHAP draft] Date: Wed, 07 Nov 2001 14:10:31 -0500 From: Behcet Sarikaya To: h.takusagawa@jp.fujitsu.com CC: seamoby References: Hi Hideaki, L2 paging areas are what we have now in public cellular networks. Our protocols (Lahap and mipv6hp) are designed to work with them and therefore have a minimum L3 paging protocol such as registration. In this case we do not use L3 paging areas because there is no need. L3 paging areas need to be set up in a 4G type of network where there are no L2 paging areas. In this case our protocols define maximum L3 paging protocol operations because all IP paging need to be performed in Layer 3, except on-link paging. On-link paging such as paging channel on cellular networks is a nice feature to have from the point of view of L3 paging. If there is on-link paging support, then our protocols exploit it to the maximum advantage of L3 paging, together with L3 paging areas. If there is no onlink paging support then our protocols define time-slot based on-link paging operations. Regarding the triggers, the triggers are designed to be used with L2 paging areas. In case of Layer 3 paging areas, the paging area ID is multicast in the router advertisements which are Layer 3 messages. So how the host or MN get this info in dormant mode depends on how on-link paging is supported. I guess we need to do more work on this, it was good you raised this issue. Thanks. See you in Salt Lake. Hideaki Takusagawa wrote: > hi Behcet, > > thanks for the reply. > i did check for that mail on Oct 5 but it wasn't there, > there must have been some problems in redirecting mail > between my 2 accounts.... sorry about that. > > > In the case when Layer 3 paging areas are supported, > > whenever MN changes paging area, TA in the new subnet is notified using > > layer 2 trigger. If the new TA is in the same layer 3 paging area, MN does > > not perform any registration. > > how does the MN know of the L3 paging area, > i was under the impression that the trigger was only > to inform of the L2 paging area. > > > Since the paging request sent by PA is multicast in the layer 3 > > paging area, the new TA also receives the paging request. > > yep, i understand now, if MN has moved within a L3 paging area, IP paging > goes > DMA -> first TA in L3 paging area that MN was under -> DMA -> PA -> current > TA. -> Host > > but this requires DMA to map L2 paging area to a PA that handles > L3 paging area right? > (that didn't sound right to me before....) > > and what about the case when MN is still under that first TA in > in the L3 paging area, couldn't there be some shortcuts here? > > hideaki > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Hideaki Takusagawa > Network Systems Laboratories FUJITSU LABORATORIES LTD. > Phone: (Ext) 044-754-2786 (Int) 7112-6146 Fax: 044-754-2786 > Email: h.takusagawa@jp.fujitsu.com -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 2 15:06: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 PAA09817 for ; Wed, 2 Jan 2002 15:06: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 OAA19166; Wed, 2 Jan 2002 14:55: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 OAA19141 for ; Wed, 2 Jan 2002 14:55:02 -0500 (EST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09605 for ; Wed, 2 Jan 2002 14:54:59 -0500 (EST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g02JsJS24177; Wed, 2 Jan 2002 11:54:19 -0800 (PST) Message-ID: <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , References: <3C335823.5030009@alcatel.com> Subject: Re: [Seamoby] IP Paging ]Framework discussion Date: Wed, 2 Jan 2002 11:52:43 -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 Hi Behcet, Hope you had a pleasant holiday. > I went thru the emails that I missed on the list during holiday > period. You referred to our work several times, do I have right to rebuttal? Sure. > -James Kempf said in his mail to Yoshi: > --Something like the time-slotted > --paging support in draft-sarikaya is what is needed in > --the final protocol. > We have included a shortedned version of time-slotted paging in the > LAHAP draft. You seem to ignore the LAHAP draft always, why? (I think > the answer is implicit in your other mail, parts of it I am copying here) No evil intent, it was strictly a matter of oversight. > -James Kempf said in his mail: > --There must be a TA per paging area, not per subnet. In the case of > --L2 paging areas, the TA is identified as the entity that is taking > --the L2 paging area update and coverting it into an L3 paging > --area update. So it plays an important role there. > > The movement at IP level is based on the subnet so if we are going to > track movement then TA functionality is needed in every subnet. If every > subnet is a L3 paging area then this becomes what you said. > The requirements specifically state that the paging area needs to be independent of subnet (Requirement 4.12 Orthogonality of Paging Area and Subnet). How the TA converts the mobile's L2 paging area update to an L3 paging area update is TBD in the design. It could involve the AR doing the conversion, for example, or it could involve the TA itself doing the conversion. To maintain independence of paging area from subnet, the former seems like probably the better choice. Draft-renker, which is now the basis for future work, does not address this issue. If you have any thoughts about how this should be done within the context of draft-renker, please send them to Marco and to the list. > -James Kempf said in his mail: > --I view the Paging Agent as the entity that initiates the actual page > --directly > --to the MN. This may be an L2 page or it may be an L3 page. I view it > --as similar to the last hop router. > The last hop router can take part in paging in communication with the > Paging Agent. In case L3 paging area contains several IP subnets, then > don't you need an upper level entity to take care of the paging process? > Right, if you look at the diagram on pg. 13 of draft-renker, you will see what I was trying to get at. The AR would have to initiate an L2 page. The PA signals the ARs for subnets it covers. So the PA in that case would be the upper level entity, AR would take care of the conversion. In general, I think having the AR perform the L3 to L2 conversion is probably the best way to maintain paging area independence from subnet. As for (copied from you email to Hideaki): >L3 paging areas need to be set up in a 4G type of network where >there are >no L2 paging areas. In this case our protocols define maximum L3 paging >protocol >operations because all IP paging need to be performed in Layer 3, except >on-link >paging. One of the uses of IP paging for seamless mobility is the ability to abstract across a variety of different L2 paging protocols. Suppose a device has five wireless interfaces, three of which define L2 paging protocols specific to their particular medium. In this case, confining the L2 paging information to the AR would simplify management of paging within the network. L3 paging areas could be used to abstract across various L2 paging protocols, in the same way that an IP subnet abstracts across a different L2 link. In this case, I think there is an advantage to having L3 paging areas even if there is already L2 support. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 2 16:07: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 QAA10845 for ; Wed, 2 Jan 2002 16:07: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 PAA21360; Wed, 2 Jan 2002 15: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 PAA21334 for ; Wed, 2 Jan 2002 15:55:23 -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 PAA10659 for ; Wed, 2 Jan 2002 15:55:19 -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 OAA19911; Wed, 2 Jan 2002 14:54:52 -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 g02Ksqm15515; Wed, 2 Jan 2002 14:54:52 -0600 (CST) Message-ID: <3C337390.4000109@alcatel.com> Date: Wed, 02 Jan 2002 14:54: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: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] IP Paging ]Framework discussion References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------030300030305030501040403" 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 --------------030300030305030501040403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jim, James Kempf wrote: >> You seem to ignore the LAHAP draft always, why? (I think >>the answer is implicit in your other mail, parts of it I am copying >> >here) > >No evil intent, it was strictly a matter of oversight. > Therefore the assessment process is moot, sorry for coming back to this conclusion again. I think that this will be more evident when the meeting slides are ever posted with the mnutes, I had specifically asked during the meeting if there are any slides on LAHAP draft and you said no. > > >One of the uses of IP paging for seamless mobility is the ability >to abstract across a variety of different L2 paging protocols. >Suppose a device has five wireless interfaces, three of >which define L2 paging protocols specific to their >particular medium. In this case, confining the L2 >paging information to the AR would simplify >management of paging within the network. L3 >paging areas could be used to abstract across >various L2 paging protocols, in the same way >that an IP subnet abstracts across a different >L2 link. In this case, I think there is an advantage >to having L3 paging areas even if there is >already L2 support. > > jak > You seem to refer to Yoshi"s mail on orthogonality and also assume that L2 paging areas always exist. Orthogonality or L2 paging area configuration regardless of IP subnet structure can only happen in 2G voice-based cellular networks where the mobile is searched with its link address, e.g. IMSI. In 2.5G and 3G cellular networks IP communication is of prime concern. L2 paging areas regardless of IP subnet configuration when the mobile has to be searched with its IP address seems a wrong approach to me, its only justification could be to reuse old paging areas already configured for 2G networks. Also I don't think IP Paging protocol could go into so much to link-related issues. Secondly L2 paging areas exist only on cellular network links and not of a given to any link.In where it exists (GPRS, 3GPP), would they be interested in IETF's IP Paging protocol is a big question mark, IMHO. Regarding renker draft, firstly renker-00 draft was based on MIPv6 and it was home agent based paging. Jim mentioned in one of his previous emails the disadvantageous of HA based paging. Now, renker-01 draft is a mess as Marco admits, and its architecture is based on lumping everything together, which means, the authors do not know what to do with each architectural entity, so lets combine them. I also agree with Yoshi on the marks given by the assessment team correctly marked it low. Regards, -- Behcet --------------030300030305030501040403 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jim,


James Kempf wrote:
  You seem to ignore the LAHAP draft always, why? (I think
the answer is implicit in your other mail, parts of it I am copying
here)

No evil intent, it was strictly a matter of oversight.
Therefore the assessment process is moot, sorry for coming back to this conclusion again. I think that this will be more evident when the meeting slides are ever posted with the mnutes, I had specifically asked during the meeting if there are any slides on LAHAP draft and you said no.



One of the uses of IP paging for seamless mobility is the ability
to abstract across a variety of different L2 paging protocols.
Suppose a device has five wireless interfaces, three of
which define L2 paging protocols specific to their
particular medium. In this case, confining the L2
paging information to the AR would simplify
management of paging within the network. L3
paging areas could be used to abstract across
various L2 paging protocols, in the same way
that an IP subnet abstracts across a different
L2 link. In this case, I think there is an advantage
to having L3 paging areas even if there is
already L2 support.

                        jak

You seem to refer to Yoshi"s mail on orthogonality and also assume that L2 paging areas always exist. Orthogonality or L2 paging area configuration regardless of IP subnet structure can only happen in 2G voice-based cellular networks where the mobile is searched with its link address, e.g. IMSI. In 2.5G and 3G cellular networks IP communication is of prime concern.  L2 paging areas regardless of IP subnet configuration when  the mobile has to be searched with its IP address seems a wrong approach to me, its only justification could be to reuse old paging areas already configured for 2G networks. Also I don't think IP Paging protocol could go into so much to link-related issues.
  Secondly L2 paging areas exist only on cellular network links and not of a given to any link.In where it exists (GPRS, 3GPP),  would they be interested in  IETF's IP Paging protocol is a big question mark, IMHO.

  Regarding renker draft, firstly renker-00 draft was based on MIPv6 and it was home agent based paging. Jim mentioned in one of his previous emails the disadvantageous of HA based paging. Now, renker-01 draft is a mess as Marco admits, and its architecture is based on lumping everything together, which means, the authors do not know what to do with each architectural entity, so lets combine them. I also agree with Yoshi on the marks given by the assessment team correctly marked it low.

 Regards, 

        

        
-- 
Behcet 


        

        
        

--------------030300030305030501040403--


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


From seamoby-admin@ietf.org  Wed Jan  2 16:51: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 QAA11666
	for ; Wed, 2 Jan 2002 16:51: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 QAA23039;
	Wed, 2 Jan 2002 16:34: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 QAA23008
	for ; Wed, 2 Jan 2002 16:34:54 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11219
	for ; Wed, 2 Jan 2002 16:34:50 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g02LYMS27530;
	Wed, 2 Jan 2002 13:34:22 -0800 (PST)
Message-ID: <01fe01c193d5$04e33200$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" 
Cc: 
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com>
Subject: Re: [Seamoby] IP Paging ]Framework discussion
Date: Wed, 2 Jan 2002 13:32:46 -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,

> Therefore the assessment process is moot, sorry for coming back to
this
> conclusion again. I think that this will be more evident when the
> meeting slides are ever posted with the mnutes, I had specifically
asked
> during the meeting if there are any slides on LAHAP draft and you said
no.
>

I do not understand your point. If you believe there is something in
the LAHAP draft that can add to the protocol design, then
by all means post it, or send it to Marco. If you don't,
then don't. I don't understand what that does or doesn't
have to do with the protocol assessment. I don't
know how many time I need to say this.

> You seem to refer to Yoshi"s mail on orthogonality and also assume
that
> L2 paging areas always exist.

No, I don't. L2 paging areas may or may not exist. The L3
paging design needs to accommodate both, according to
the requirements.

> Orthogonality or L2 paging area
> configuration regardless of IP subnet structure can only happen in 2G
> voice-based cellular networks where the mobile is searched with its
link
> address, e.g. IMSI.

I'm sorry, I don't understand where you are coming from here. If one
defines a L3 paging area independently of the L2 paging area,
what difference does it make what the L2 identifier is? One
can define an abstraction to use.

> In 2.5G and 3G cellular networks IP communication is
> of prime concern. L2 paging areas regardless of IP subnet
configuration
> when  the mobile has to be searched with its IP address seems a wrong
> approach to me,

Which IP address? If it's MIP, then there are two. I don't think it
is possible to use the IP address of the MN to page, since one
use of dormant mode is to remove the need to maintain
routes.

>its only justification could be to reuse old paging
> areas already configured for 2G networks. Also I don't think IP Paging
> protocol could go into so much to link-related issues.

Sure, that's why it is important to design an appropriate abstraction
for L2 paging identifiers.

>   Secondly L2 paging areas exist only on cellular network links and
not
> of a given to any link.In where it exists (GPRS, 3GPP),  would they be
> interested in  IETF's IP Paging protocol is a big question mark, IMHO.
>

Well, I don't think existing cellular networks would be all that
interested,
frankly. They have Location Area Identifiers and updates for them
that are based on a paging area to subnet mapping. One of the
goals of the IP paging design is to move to an independent design.

>   Regarding renker draft, firstly renker-00 draft was based on MIPv6
and
> it was home agent based paging.

There were two cases, one with and one without MIPv6. The
requirements say that the protocol must be independent
of mobility protocol  but support existing mobility protocols.
It is up to the working group discussion as to
how to modify draft-renker to do this. Please
state your opinion if you have one.

>Jim mentioned in one of his previous
> emails the disadvantageous of HA based paging. Now, renker-01 draft is
a
> mess as Marco admits,

This is an inaccurate characterization of Marco's email. It was not any
more "a mess" then any of the other drafts. It needs cleaning up
w.r.t. holes and overspecifications.

>and its architecture is based on lumping
> everything together, which means, the authors do not know what to do
> with each architectural entity, so lets combine them. I also agree
with
> Yoshi on the marks given by the assessment team correctly marked it
low.
>

Behcet, instead of posting these negative generalizations of the
assessment
process, the selected draft, etc., I wish you would move on and
try to contribute something positive to actually defining the
protocol. As I've said, I think your team's contributions in
the area of time-slotted paging and L2 paging interface
were good, and your team's experience in this area would
be useful for the end result.

Rough concensus doesn't mean everybody agrees, it means
that almost everyone does. My reading of the list traffic
and the meeting is that we've got rough concensus
on starting the process of harmonizing the designs
based on draft-renker. Let's move on.

            jak



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


From seamoby-admin@ietf.org  Thu Jan  3 12:01: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 MAA06098
	for ; Thu, 3 Jan 2002 12:01: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 LAA08545;
	Thu, 3 Jan 2002 11:47: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 LAA08514
	for ; Thu, 3 Jan 2002 11:47:28 -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 LAA05793
	for ; Thu, 3 Jan 2002 11:47:23 -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 KAA28690;
	Thu, 3 Jan 2002 10:46:57 -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 g03Gkum10642;
	Thu, 3 Jan 2002 10:46:56 -0600 (CST)
Message-ID: <3C348C0F.C0360646@alcatel.com>
Date: Thu, 03 Jan 2002 10:51:27 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] IP Paging ]Framework discussion
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <01fe01c193d5$04e33200$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

Hi Jim,
  You still have not posted the slides neither the minutes. How many times
should I ask this?
  My point is very simple. Here is someone who was brought on board to
cochair a WG in order to help in the protocol assessment of paging
proposals. This person has very many opinions. He makes sure to give a reply
to any message posted on the mailing list.
  However this same person somehow forgets to make any opinion on one the
paging proposals jeopardizing the assessment process.
  He seems to admit this and asks some way out on the one hand and he
insists on the false conclusion of the assessment on the other hand.
  The above is too good to believe. What do you think?

  The fact is that the assesment process is wrong. All IETF WGs receive
several protocol proposals, Seamoby is not the only WG. However the process
used by Seamoby is unique to Seamoby.
  Jim, I am ready to discuss this issue over the phone. My phone number is
below. Feel free to call me or give your phone number I am going to call
you.

Regards,

--
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road PB7,
Plano, TX 75075
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  Thu Jan  3 12:57: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 MAA07070
	for ; Thu, 3 Jan 2002 12:57: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 MAA11288;
	Thu, 3 Jan 2002 12: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 MAA11228
	for ; Thu, 3 Jan 2002 12:45:51 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06762
	for ; Thu, 3 Jan 2002 12:45:48 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g03HjHS00653;
	Thu, 3 Jan 2002 09:45:17 -0800 (PST)
Message-ID: <007701c1947e$2ecb7380$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" 
Cc: 
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <01fe01c193d5$04e33200$7e6015ac@T23KEMPF> <3C348C0F.C0360646@alcatel.com>
Subject: Re: [Seamoby] IP Paging ]Framework discussion
Date: Thu, 3 Jan 2002 09:43: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

Behcet,

>   You still have not posted the slides neither the minutes. How many
times
> should I ask this?

I will post the minutes today, the slides are on Pat's machine and he
has some kind of crisis at work that requires his full attention. When
Pat gets done, he will post the slides, though we currently do
not have a site because diameter.org went down due to @Home's
demise. Perhaps Alcatel would like to volunteer a publically accessable
place
until we find another home?

>   My point is very simple. Here is someone who was brought on board to
> cochair a WG in order to help in the protocol assessment of paging
> proposals. This person has very many opinions. He makes sure to give a
reply
> to any message posted on the mailing list.
>   However this same person somehow forgets to make any opinion on one
the
> paging proposals jeopardizing the assessment process.
>   He seems to admit this and asks some way out on the one hand and he
> insists on the false conclusion of the assessment on the other hand.
>   The above is too good to believe. What do you think?
>

Behcet, I haven't a clue about what you are talking about here. These
sound to me like some kind of accusation against me, though I cannot
be sure. If that is the case, then I suggest that you come right out
and make the accusation and I will deal with it.

>   The fact is that the assesment process is wrong. All IETF WGs
receive
> several protocol proposals, Seamoby is not the only WG. However the
process
> used by Seamoby is unique to Seamoby.
>   Jim, I am ready to discuss this issue over the phone. My phone
number is
> below. Feel free to call me or give your phone number I am going to
call
> you.
>
>

The  very same assessment process was used by the AAA group. You can
send email to Bernard Abboba if you care to confirm this. However, the
outcome was different. In that case, one of the protocol
proposals exhibited considerably more implementation and
design maturity than the others and met the requirements more
completely, and so the results of
the assessment team were definitive: that proposal was
selected.

At the request of Yoshi and Jari, I have written up a
description of the decision process we used, it is
currently under review by Pat and Allision for
inclusion into the assessment draft. The WG
will get to comment when the draft
goes through WG last call again. The difference
with the AAA group is that the assessment process
in Seamoby resulted in an indeterminate result.
The assessment team did not recommend one
of the protocol proposals as the basis for harmonization, they
recommended only that either harmonization begin
or the authors go through another round of design
work.

The working group co-chairs decided against the
latter, and decided to select one protocol
proposal as the basis for harmonization, subject
to WG concensus, of course. This was done,
the text to be included in the document
will explain the decision process. There
was a presentation at the WG meeting,
comments and concerns of the protocol
authors were duely noted.
If what you are complaining about is
that the WG chairs basically made
a judgement call about which protocol
proposal should be selected, then
I'm sorry to say that this is certainly
within the duties of IETF WG chairs,
provided the chairs abide by
WG concensus. I believe
we have concensus on how to proceed,
since you seem to be the only person
who continues to complain.

Behcet, as I have continued to say, your
team had positive contributions and I
would appreciate if you would bring
them to the list instead of making veiled
and unveiled accusations about the decision
process. The other protocol proposal
authors seem to be willing to work together
with Marco and the WG, even though they are probably
no more happy than you are that their
proposals were not selected as the
basis for harmonization.

            jak





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


From seamoby-admin@ietf.org  Thu Jan  3 13:45: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 NAA07944
	for ; Thu, 3 Jan 2002 13:45: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 NAA13366;
	Thu, 3 Jan 2002 13:34: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 NAA13335
	for ; Thu, 3 Jan 2002 13:34:13 -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 NAA07749
	for ; Thu, 3 Jan 2002 13:34:10 -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 MAA25135;
	Thu, 3 Jan 2002 12:33:42 -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 g03IXfm23348;
	Thu, 3 Jan 2002 12:33:41 -0600 (CST)
Message-ID: <3C34A514.2F9E3576@alcatel.com>
Date: Thu, 03 Jan 2002 12:38:12 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] IP Paging ]Framework discussion
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <01fe01c193d5$04e33200$7e6015ac@T23KEMPF> <3C348C0F.C0360646@alcatel.com> <007701c1947e$2ecb7380$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

Dear Jim,
  I had suggested a civilized phone call to resolve or at least talk about
the issues. Reading your mail I conclude you do not wish to talk over these
things, but rather resort to written communication.
  I have no personal accusations on any body. I am a professional, I am not
here to deal with persons. There are technical issues, and if I have
technical points to make, I believe I am entitled to my opinion as someone
who has been working on IP Paging issues for sometime probably longer than
many in the WG.
  It is the belief of our team that the renker draft is technically not the
right one as a base document. It is our belief that the base document should
have been dressed bottom up by getting consensus on the technical issues
starting with the architecture. Therefore it really does not matter if this
or that draft coauthor agrees to work on a wrong document. What matters is
the technical issues because we are talking about a protocol, not a
nontechnical issue.
  We may continue to work on our two protocol and one API drafts and if we
somehow come up with enhanced versions we wll share with IETF by submitting
them as I-Ds. Therefore we are unable to participate in the process you
prescribed in your email and this means of course the new draft makers
should not count on our drafts.
  As a final remark, if one of 5 candidate proposals is eliminated by giving
no opinion even though some aspects of this one draft are used as arguments
for eliminating some other drafts, this execution of the agreed upon
assessment process has unfortunately been buggy.

Kindest regards,


Behcet


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


From seamoby-admin@ietf.org  Thu Jan  3 13:58: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 NAA08235
	for ; Thu, 3 Jan 2002 13:58: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 NAA13719;
	Thu, 3 Jan 2002 13:47: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 NAA13690
	for ; Thu, 3 Jan 2002 13:47:21 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08018
	for ; Thu, 3 Jan 2002 13:47:18 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g03IknS02927;
	Thu, 3 Jan 2002 10:46:49 -0800 (PST)
Message-ID: <010e01c19486$c7bcc410$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" 
Cc: 
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <01fe01c193d5$04e33200$7e6015ac@T23KEMPF> <3C348C0F.C0360646@alcatel.com> <007701c1947e$2ecb7380$7e6015ac@T23KEMPF> <3C34A514.2F9E3576@alcatel.com>
Subject: Re: [Seamoby] IP Paging ]Framework discussion
Date: Thu, 3 Jan 2002 10:45:14 -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

Hi Behcet,

>   I had suggested a civilized phone call to resolve or at least talk
about
> the issues. Reading your mail I conclude you do not wish to talk over
these
> things, but rather resort to written communication.
>   I have no personal accusations on any body. I am a professional, I
am not
> here to deal with persons. There are technical issues, and if I have
> technical points to make, I believe I am entitled to my opinion as
someone
> who has been working on IP Paging issues for sometime probably longer
than
> many in the WG.

This is good to know. If you have technical issues, please by all means
post them.

>   It is the belief of our team that the renker draft is technically
not the
> right one as a base document. It is our belief that the base document
should
> have been dressed bottom up by getting consensus on the technical
issues
> starting with the architecture.

As I mentioned to you in previous email, the WG already has agreed
to the functional architecture, it is described in RFC 3154.
There is still a need for a network architecture, draft-renker
has a proposal that the WG will use as a start. If you have
specific technical issues with the network architecture in
draft-renker, then please post them to the list, and Marco
and the WG can begin to address them.

> Therefore it really does not matter if this
> or that draft coauthor agrees to work on a wrong document. What
matters is
> the technical issues because we are talking about a protocol, not a
> nontechnical issue.

Great!

>   We may continue to work on our two protocol and one API drafts and
if we
> somehow come up with enhanced versions we wll share with IETF by
submitting
> them as I-Ds. Therefore we are unable to participate in the process
you
> prescribed in your email and this means of course the new draft makers
> should not count on our drafts.

You are certainly free to submit your documents to the IESG as
informational
documents. I am sorry to hear that you don't want to participate
in the WG design on paging, we will certainly miss your expertise.

>   As a final remark, if one of 5 candidate proposals is eliminated by
giving
> no opinion even though some aspects of this one draft are used as
arguments
> for eliminating some other drafts, this execution of the agreed upon
> assessment process has unfortunately been buggy.
>

Well, my semantic analyzer comes up indeterminate on this statement, so
I guess
I will have to refrain from comment.

        jak


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


From seamoby-admin@ietf.org  Thu Jan  3 14:10: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 OAA08499
	for ; Thu, 3 Jan 2002 14:10: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 NAA13948;
	Thu, 3 Jan 2002 13:59: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 NAA13919
	for ; Thu, 3 Jan 2002 13:59:10 -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 NAA08257
	for ; Thu, 3 Jan 2002 13:59:07 -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 MAA19579;
	Thu, 3 Jan 2002 12:58:39 -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 g03Iwdm26924;
	Thu, 3 Jan 2002 12:58:39 -0600 (CST)
Message-ID: <3C34AAEE.68BFDBF7@alcatel.com>
Date: Thu, 03 Jan 2002 13:03:10 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] IP Paging ]Framework discussion
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <01fe01c193d5$04e33200$7e6015ac@T23KEMPF> <3C348C0F.C0360646@alcatel.com> <007701c1947e$2ecb7380$7e6015ac@T23KEMPF> <3C34A514.2F9E3576@alcatel.com> <010e01c19486$c7bcc410$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

Hi Jim,
  Please note that anybody can submit Internet Drafts (I-Ds), I-Ds are the
only way to make some progress in IETF. I-Ds are submitted to IETF not to
IESG.
  Also anybody can become a member of any WG mailing list and post his/her
opinions.
  These above two points are not within the power of WG cochairs, it is the
people out there who make the work and take the initiative.
  So as I said in my previous email, we may submit our contributions as
I-Ds.

  Hope that this email stays as clean as it is.

Regards,

--
Behcet


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


From seamoby-admin@ietf.org  Thu Jan  3 14:19: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 OAA08737
	for ; Thu, 3 Jan 2002 14:19: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 OAA14702;
	Thu, 3 Jan 2002 14:07: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 OAA14672
	for ; Thu, 3 Jan 2002 14:07:17 -0500 (EST)
Received: from frascone.com (goaway@adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08435
	for ; Thu, 3 Jan 2002 14:07:14 -0500 (EST)
Received: (qmail 24702 invoked by uid 507); 3 Jan 2002 19:07:15 -0000
Date: Thu, 3 Jan 2002 13:07:13 -0600
From: David Frascone 
To: James Kempf 
Cc: Behcet Sarikaya , seamoby@ietf.org
Subject: Re: [Seamoby] IP Paging ]Framework discussion
Message-ID: <20020103190713.GF16207@newman.frascone.com>
Mail-Followup-To: James Kempf ,
	Behcet Sarikaya , seamoby@ietf.org
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <01fe01c193d5$04e33200$7e6015ac@T23KEMPF> <3C348C0F.C0360646@alcatel.com> <007701c1947e$2ecb7380$7e6015ac@T23KEMPF>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <007701c1947e$2ecb7380$7e6015ac@T23KEMPF>
User-Agent: Mutt/1.3.25i
X-encrypt-payload: no
X-Virus-Scanned: by AMaViS perl-11
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 Thursday, 03 Jan 2002, James Kempf wrote:
> Behcet,
> 
> >   You still have not posted the slides neither the minutes. How many
> times
> > should I ask this?
> 
> I will post the minutes today, the slides are on Pat's machine and he
> has some kind of crisis at work that requires his full attention. When
> Pat gets done, he will post the slides, though we currently do
> not have a site because diameter.org went down due to @Home's
> demise. Perhaps Alcatel would like to volunteer a publically accessable
> place
> until we find another home?

I would be happy to donate seamoby.frascone.com.

-Dave

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


From seamoby-admin@ietf.org  Thu Jan  3 14:28: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 OAA08868
	for ; Thu, 3 Jan 2002 14:28: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 OAA14925;
	Thu, 3 Jan 2002 14:16: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 OAA14893
	for ; Thu, 3 Jan 2002 14:16:31 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08660
	for ; Thu, 3 Jan 2002 14:16:18 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g03JFoS03928;
	Thu, 3 Jan 2002 11:15:50 -0800 (PST)
Message-ID: <013701c1948a$d4faabc0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" 
Cc: 
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <01fe01c193d5$04e33200$7e6015ac@T23KEMPF> <3C348C0F.C0360646@alcatel.com> <007701c1947e$2ecb7380$7e6015ac@T23KEMPF> <3C34A514.2F9E3576@alcatel.com> <010e01c19486$c7bcc410$7e6015ac@T23KEMPF> <3C34AAEE.68BFDBF7@alcatel.com>
Subject: Re: [Seamoby] IP Paging ]Framework discussion
Date: Thu, 3 Jan 2002 11:14:14 -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,

>   Please note that anybody can submit Internet Drafts (I-Ds), I-Ds are
the
> only way to make some progress in IETF. I-Ds are submitted to IETF not
to
> IESG.
>   Also anybody can become a member of any WG mailing list and post
his/her
> opinions.
>   These above two points are not within the power of WG cochairs, it
is the
> people out there who make the work and take the initiative.
>   So as I said in my previous email, we may submit our contributions
as
> I-Ds.
>
>   Hope that this email stays as clean as it is.

Sure. What I was trying to say was that WG drafts are determined through
WG concensus, individual drafts are not. Individuals are free to
submit their drafts to the IETF for consideration as an informational
RFC, and the IESG will make a decision about them just as
they do for all other drafts.

As for posting to the list, you are correct, anyone can post,
anyone can attend WG meetings.

So if you want to submit your drafts as an individual contribution,
please feel free to do so.

I hope that is clearer.

            jak


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


From seamoby-admin@ietf.org  Thu Jan  3 14:29: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 OAA08906
	for ; Thu, 3 Jan 2002 14:29: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 OAA15043;
	Thu, 3 Jan 2002 14:18: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 OAA15009
	for ; Thu, 3 Jan 2002 14:18:53 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08727
	for ; Thu, 3 Jan 2002 14:18:36 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g03JHdS03981;
	Thu, 3 Jan 2002 11:17:39 -0800 (PST)
Message-ID: <014c01c1948b$16016640$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "David Frascone" 
Cc: 
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <01fe01c193d5$04e33200$7e6015ac@T23KEMPF> <3C348C0F.C0360646@alcatel.com> <007701c1947e$2ecb7380$7e6015ac@T23KEMPF> <20020103190713.GF16207@newman.frascone.com>
Subject: Re: [Seamoby] IP Paging ]Framework discussion
Date: Thu, 3 Jan 2002 11:16:03 -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

Dave,

Thanx! I'll send email offline to co-ordinate.

            jak

----- Original Message -----
From: "David Frascone" 
To: "James Kempf" 
Cc: "Behcet Sarikaya" ; 
Sent: Thursday, January 03, 2002 11:07 AM
Subject: Re: [Seamoby] IP Paging ]Framework discussion


>
>
> On Thursday, 03 Jan 2002, James Kempf wrote:
> > Behcet,
> >
> > >   You still have not posted the slides neither the minutes. How
many
> > times
> > > should I ask this?
> >
> > I will post the minutes today, the slides are on Pat's machine and
he
> > has some kind of crisis at work that requires his full attention.
When
> > Pat gets done, he will post the slides, though we currently do
> > not have a site because diameter.org went down due to @Home's
> > demise. Perhaps Alcatel would like to volunteer a publically
accessable
> > place
> > until we find another home?
>
> I would be happy to donate seamoby.frascone.com.
>
> -Dave
>


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


From seamoby-admin@ietf.org  Thu Jan  3 14:37: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 OAA09219
	for ; Thu, 3 Jan 2002 14:37: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 OAA15277;
	Thu, 3 Jan 2002 14:25: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 OAA15248
	for ; Thu, 3 Jan 2002 14:25:54 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08826
	for ; Thu, 3 Jan 2002 14:25:35 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g03JP7S04236
	for ; Thu, 3 Jan 2002 11:25:07 -0800 (PST)
Message-ID: <015801c1948c$215efc90$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Date: Thu, 3 Jan 2002 11:23:31 -0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0155_01C19449.1335A210"
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
Subject: [Seamoby] Minutes of Meeting at IETF 52
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_000_0155_01C19449.1335A210
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Attached. There is a one week comment period, ending on January 10.

            jak

------=_NextPart_000_0155_01C19449.1335A210
Content-Type: text/plain;
	name="Minutes IETF-52 seamoby.txt"
Content-Disposition: attachment;
	filename="Minutes IETF-52 seamoby.txt"
Content-Transfer-Encoding: quoted-printable


Milestone review

------
Paging Assessment Update

Four volunteers, each assigned a different protocol proposal.
There was an effort to calibrate the results across assessments.

All protocols had good points; all had problems.
Security was a particular problem.
- Some recommend IPSEC, some new, details lacking.

draft-ohba-seamoby-last-hop-dmha-02.txt
+ Good ...
- Ties paging agent directly to last hop subnet, so no
subnet-independent=20

Q: The second item is not correct because we don't mention
subnet-dependent PA.  The PA in our protocol can go anywhere.
A: OK.

draft-koodli-paging-00.txt
+ c

draft-sarikaya-seamoby-mipv6hp-00.txt
+ Good layer 2 integration
- No v4 support

Q: Was combining these a good idea?  These were completely different
proposals.
A: That is a fair statement.  We'll cover it later.

draft-renker-paging-ipv6-01.txt
+ Lots of details.
...

Next Step recommendations
1) another round of assessments or
2) Start work toward common protocol -- Allison et al

Marco Leibsch will be the draft editor.


Q: How should contributors put in recommendations.=20
A: If it is short, send it to the list.  If it is lengthy, contribute
as an ID.
Pat Calhoun: Rather than having folks submit draft, people should submit
proposed text to the list.

Q: How will we incorporate material from the other drafts?
James Kempf: Look at the assessment draft and see what is missing from =
the
Renker draft and submit the relevant pieces of the other drafts as
changes to specific sections.
Pat Calhoun:Assessment draft going to last call.
Jari Malnin: Last call will be a good idea for reviewing the assessment
draft.  Especially the security area needs a lot of attention.

ACTION ITEM: WG chairs will find somebody to do security assessment.

Q: Question about unifying ideas and
the feedback of the assessment.  Are the comments going into the
2nd version of the assessment?
A: The assessment draft is complete as it is.  People can submit
proposals during last call for changes.

-----------
CT Problem Statement

There were MAJOR comments from the IESG.  It is going back to the
IESG after WG Last Call completes.

------------
General Requirements for Context Transfer

There were a LOT of comments which we did NOT accept.  Some changes
were substantial so this doc will go through ANOTHER WG last call.

...
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.

New requirement
4.16 The CT solution MUST include methods for interworking w/any IETF IP
handover solution.

4.17 The CT solution MUST be scalable. =20

Pat Calhoun: That's kind of hard to quantify...
Scott Bradner: 3.5lbs of scalability.

------------
CT Next Steps

Follow the same process as DMHA
Due date for protocols is Feb 1st/

These dates give time to submit an ID in time for IETF-53.

Pat Calhoun: Are there things we should change about the DMHA process?
James Kempf: We REALLY encourage people to volunteer.  We really =
appreciate the
volunteers who worked through the assessment process.

---------
CAR Discovery Issues update
dis-cardiscovery-issues-01.txt=20

What's CAR discovery?
- Discover AR's that an MN can hand over to.

Changes from 00.txt
PAAR -> GAAR
New section to to illustrate GAARs separated by several domains
Example scenarios to justify CAR
New section demonstrating that existing protocols don't do this

Requirements:
MUST: L2 id -> L3 id.
MUST L2 devices of different technologies.
MUST: L2 devices in private/site-local spaces.
MUST: Capability communication between GAARs.
MUST&TBD: Standard format for capabilities.
SHOULD: Protocol applicability -- Interdomain as well as Intra-domain =
scope.
MUST NOT: Introduce new network elements for CAR discovery.
SHOULD: Minimize involvement of ARs which are not GAARs in CAR =
discovery.
MUST NOT: Depend on particular mobility protocol.

Q: Support for L2 devices in private/site-local spaces makes no sense
at all.
A: We think it can be done.

Phil Neumiller: You might consider a new requirements.  We have MANET =
and=20
MIP and there is very little bridging.  This could fill this gap.
A: So you want to support mobile routers also?
PN: We don't want to preclude mobile ARs.
A: I don't think we preclude that now, but if you want to add a SHOULD
for that we could do that.

Pat Calhoun: Looking at requirements I see something that's not on =
there.
The mobile provides its view of the network.  There
are some DoS attacks possible from this.
A: I don't see why we need to preclude that.  If the MN's are suitably
authenticated, it should not be a problem.
PC: Authentication is not the issue.  An MN can still inject erroneous
information about what the network looks like.
Scott Bradner: It is a long policy in the IETF for nodes not to know =
about
network topology.  It would have to be a REALLY GOOD idea to take
advantage of MN knowledge of network topology.

James Kempf: Are you talking about Localized Mobility Mangement?
James Kempf: It sounds like there may be some overlap w/MANET.
Phil Neumiller: MIP and MANETs are going to collide.  This is an ideal =
place to
deal with these requirements.
Pat Calhoun: Is Scott Corsen (co-chair of MANET) here?  Do you know =
anything=20
about this work?
Scott Corsen: Right now there is no specific item for this work.  There =
have
been submissions but none have been accepted.
PC: Any work that people try to submit there should be redirected to
here.

Concensus call:
SHOULD to MUST for Inter domain as well as Intra-domain scope?
[plenty of hands in support, none in dissent]

Slide discussion on issue involving MN detection of
network topologies:



Pat Calhoun: (Draws diagram with overlapping circles to represent
service areas).
A malicious dot (representing the MN) tells local cells about far away=20
cells.  This could "confuse" the local cells.

Some discussion about how critical the problem is, and
discussion on possible solutions.

James Kempf: There is clearly a problem to be solved.

Scott Bradner: Once you start down the path of letting the MN know about
topology, it gets you into the problem of what path to take and you
don't want to go there.

Comments about whether or not MNs do
continuous scanning.

Comment from an author: Neither proposal has this problem.

Security association discussion...

George Tsirtsis: What is the usefulness of know somebody is a neighbor =
other
than to create an SA?
Hesham Soliman: I am very concerned that the direction to go is to have
routers discover for each other, but we've found this doesn't scale.
Why doesn't each router just advertise for itself?

Pat Calhoun: It sounds like there are a lot of people who need to read =
and
comment on the problem statement.  We appear to be trying to discuss
multiple problems.

Ajoy Singh: I don't see that we have a strong scaling requirement. =20
This is how CDMA and GSM work today.


------------
CAR Next Steps

We wanted avoid a lengthy requirements phase, but that's sounding like
it might be a problem.

Is everybody comfortable with the requirements discussed?
Comment: If we add the MANET issues we should be OK.

Discussion about inter- v.s. intradomain discovery.

George Tsertsis: Automatic discovery of AR's from separate domains is =
not a
GOOD THING.

The discussion ended with moving this issue to the list.


-------
Following stuff has to happen before IETF-53

DMHA Protocol Design First Draft
CT Protocol Submission Complete and base Protocol Selected
CAR Problem Statement and Requirements Complete


------=_NextPart_000_0155_01C19449.1335A210--


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


From seamoby-admin@ietf.org  Thu Jan  3 15: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 PAA10254
	for ; Thu, 3 Jan 2002 15: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 PAA17817;
	Thu, 3 Jan 2002 15: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 PAA17788
	for ; Thu, 3 Jan 2002 15:06:16 -0500 (EST)
Received: from hotmail.com (f251.law7.hotmail.com [216.33.236.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10014
	for ; Thu, 3 Jan 2002 15:06:12 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 3 Jan 2002 12:05:44 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP;
	Thu, 03 Jan 2002 20:05:44 GMT
X-Originating-IP: [63.78.179.5]
From: "Hemant Chaskar" 
To: kempf@docomolabs-usa.com, seamoby@ietf.org
Subject: Re: [Seamoby] Minutes of Meeting at IETF 52
Date: Thu, 03 Jan 2002 20:05:44 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 03 Jan 2002 20:05:44.0857 (UTC) FILETIME=[071D2090:01C19492]
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 James:

In the "Slide discussion on issue involving MN detection of
network topologies:" discussion thread, there was the following point made 
at the end of the day:

- MN providing information to AR in order to aid CAR discovery is not to be 
precluded, if such a protocol does not compromise security and reliablity of 
information.

Hemant




>From: "James Kempf" 
>To: 
>Subject: [Seamoby] Minutes of Meeting at IETF 52
>Date: Thu, 3 Jan 2002 11:23:31 -0800
>
>Attached. There is a one week comment period, ending on January 10.
>
>             jak
><< MinutesIETF-52seamoby.txt >>


_________________________________________________________________
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  Thu Jan  3 15:41: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 PAA10857
	for ; Thu, 3 Jan 2002 15:41: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 PAA18626;
	Thu, 3 Jan 2002 15:30: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 PAA18592
	for ; Thu, 3 Jan 2002 15:30:18 -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 PAA10539
	for ; Thu, 3 Jan 2002 15:30:14 -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 OAA05788
	for ; Thu, 3 Jan 2002 14:29:46 -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 g03KTks18819
	for ; Thu, 3 Jan 2002 14:29:46 -0600 (CST)
Message-ID: <3C34C049.7611CD36@alcatel.com>
Date: Thu, 03 Jan 2002 14:34:17 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: [Seamoby] IP Paging ]Framework discussion
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

Dear All,

  Please note that anybody can submit Internet Drafts (I-Ds), I-Ds are
the
only way to make some progress in IETF. I-Ds are submitted to IETF not
to
IESG.
  Also anybody can become a member of any WG mailing list and post
his/her
opinions.
  These above two points are not within the power of WG cochairs, it is
the
people out there who make the work and take the initiative.
  So as I said in my previous email, we may submit our contributions as
I-Ds.

  Hope that this email stays as clean as it is.


--
Behcet


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


From seamoby-admin@ietf.org  Thu Jan  3 15:50: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 PAA11037
	for ; Thu, 3 Jan 2002 15:50: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 PAA19039;
	Thu, 3 Jan 2002 15:39: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 PAA19008
	for ; Thu, 3 Jan 2002 15:39:41 -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 PAA10800
	for ; Thu, 3 Jan 2002 15:39:37 -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 OAA12413;
	Thu, 3 Jan 2002 14:39:10 -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 g03Kd9s19757;
	Thu, 3 Jan 2002 14:39:09 -0600 (CST)
Message-ID: <3C34C27C.81B9852E@alcatel.com>
Date: Thu, 03 Jan 2002 14:43:40 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Minutes of Meeting at IETF 52
References: <015801c1948c$215efc90$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

Hi James,
  My question on the candidate draft draft-guri-seamoby-lahap-00.txt and your
answer are not included in the minutes, please amend it.
  Another point I remember seeing the AD Scott Bradner but not Allison at the
meeting yet her name is mentioned for starting the work on a common protocol.
What is the relationship of Allison and starting the work on a common
protocol?


--
Behcet


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


From seamoby-admin@ietf.org  Thu Jan  3 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 PAA11093
	for ; Thu, 3 Jan 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 PAA19180;
	Thu, 3 Jan 2002 15:43: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 PAA19154
	for ; Thu, 3 Jan 2002 15:43:26 -0500 (EST)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10898
	for ; Thu, 3 Jan 2002 15:43:21 -0500 (EST)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 3 Jan 2002 15:42:52 -0500
Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB8CD@ftmail>
From: George Tsirtsis 
To: "'James Kempf'" , seamoby@ietf.org
Subject: RE: [Seamoby] Minutes of Meeting at IETF 52
Date: Thu, 3 Jan 2002 15:42:50 -0500 
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

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


From seamoby-admin@ietf.org  Thu Jan  3 15:57: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 PAA11154
	for ; Thu, 3 Jan 2002 15:57: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 PAA19307;
	Thu, 3 Jan 2002 15:46: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 PAA19272
	for ; Thu, 3 Jan 2002 15:46:38 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10951
	for ; Thu, 3 Jan 2002 15:46:33 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g03Kk5S06897;
	Thu, 3 Jan 2002 12:46:05 -0800 (PST)
Message-ID: <01eb01c19497$70b18820$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" 
Cc: 
References: <015801c1948c$215efc90$7e6015ac@T23KEMPF> <3C34C27C.81B9852E@alcatel.com>
Subject: Re: [Seamoby] Minutes of Meeting at IETF 52
Date: Thu, 3 Jan 2002 12:44:29 -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,

>   My question on the candidate draft draft-guri-seamoby-lahap-00.txt
and your
> answer are not included in the minutes, please amend it.

Please send text you would like included.

>   Another point I remember seeing the AD Scott Bradner but not Allison
at the
> meeting yet her name is mentioned for starting the work on a common
protocol.
> What is the relationship of Allison and starting the work on a common
> protocol?
>

Pat and I consulted with Allison after completing the decision process
about which draft to choose as a starting point. As our AD, we
consult with her often on issues involving the WG.

            jak


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


From seamoby-admin@ietf.org  Thu Jan  3 15:59: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 PAA11176
	for ; Thu, 3 Jan 2002 15:59: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 PAA19416;
	Thu, 3 Jan 2002 15:48: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 PAA19378
	for ; Thu, 3 Jan 2002 15:48:34 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11002
	for ; Thu, 3 Jan 2002 15:48:29 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g03KlxS06948;
	Thu, 3 Jan 2002 12:47:59 -0800 (PST)
Message-ID: <01f501c19497$b4e6ed50$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "George Tsirtsis" , 
References: <8C92E23A3E87FB479988285F9E22BE465AB8CD@ftmail>
Subject: Re: [Seamoby] Minutes of Meeting at IETF 52
Date: Thu, 3 Jan 2002 12:46:23 -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

George,

So are you proposing that the minutes be amended to
include a statement of what Section 4.13 refers to?

            jak
----- Original Message -----
From: "George Tsirtsis" 
To: "'James Kempf'" ; 
Sent: Thursday, January 03, 2002 12:42 PM
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


From seamoby-admin@ietf.org  Thu Jan  3 16: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 QAA11295
	for ; Thu, 3 Jan 2002 16: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 PAA19636;
	Thu, 3 Jan 2002 15:56: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 PAA19605
	for ; Thu, 3 Jan 2002 15:55:59 -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 PAA11122
	for ; Thu, 3 Jan 2002 15:55:52 -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 OAA11158;
	Thu, 3 Jan 2002 14:55:25 -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 g03KtOm22308;
	Thu, 3 Jan 2002 14:55:24 -0600 (CST)
Message-ID: <3C34C64B.22C6FDAF@alcatel.com>
Date: Thu, 03 Jan 2002 14:59:55 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Minutes of Meeting at IETF 52
References: <015801c1948c$215efc90$7e6015ac@T23KEMPF> <3C34C27C.81B9852E@alcatel.com> <01eb01c19497$70b18820$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

Behcet Sarikaya: Do you have any slides on draft-guri-seamoby-lahap-00.txt?
James Kempf: No.
(frankly speaking the above is probably not exactly what was asked and
answered but it does reflect the semantics.)


James Kempf wrote:

> Behcet,
>
> >   My question on the candidate draft draft-guri-seamoby-lahap-00.txt
> and your
> > answer are not included in the minutes, please amend it.
>
> Please send text you would like included.
>

See above.

>
> >   Another point I remember seeing the AD Scott Bradner but not Allison
> at the
> > meeting yet her name is mentioned for starting the work on a common
> protocol.
> > What is the relationship of Allison and starting the work on a common
> > protocol?
> >
>
> Pat and I consulted with Allison after completing the decision process
> about which draft to choose as a starting point. As our AD, we
> consult with her often on issues involving the WG.
>
>             jak

People may misunderstand as if Allison was in the meeting and she said this
or something like that. So I suggest removing her name from the minutes.
  I hope that Allison would also agree with this. If not, you can keep the
text.

Regards,

--
Behcet


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


From seamoby-admin@ietf.org  Thu Jan  3 16:20: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 QAA11591
	for ; Thu, 3 Jan 2002 16:20: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 QAA20388;
	Thu, 3 Jan 2002 16:09: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 QAA20357
	for ; Thu, 3 Jan 2002 16:09:46 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11338
	for ; Thu, 3 Jan 2002 16:09:41 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g03L9DS07655;
	Thu, 3 Jan 2002 13:09:13 -0800 (PST)
Message-ID: <023901c1949a$ac45bb10$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" 
Cc: 
References: <015801c1948c$215efc90$7e6015ac@T23KEMPF> <3C34C27C.81B9852E@alcatel.com> <01eb01c19497$70b18820$7e6015ac@T23KEMPF> <3C34C64B.22C6FDAF@alcatel.com>
Subject: Re: [Seamoby] Minutes of Meeting at IETF 52
Date: Thu, 3 Jan 2002 13:07:37 -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 Sarikaya: Do you have any slides on
draft-guri-seamoby-lahap-00.txt?
> James Kempf: No.
> (frankly speaking the above is probably not exactly what was asked and
> answered but it does reflect the semantics.)
>

How about:

Q: Was combining these a good idea?  These were completely different
proposals.
A: That is a fair statement.  We'll cover it later.

which was included in the posted minutes. I recall
your asking a question of this nature, and I do definitely recall
this having been my reply.

            jak




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


From seamoby-admin@ietf.org  Thu Jan  3 16:38: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 QAA11889
	for ; Thu, 3 Jan 2002 16:38: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 QAA20728;
	Thu, 3 Jan 2002 16:27: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 QAA20699
	for ; Thu, 3 Jan 2002 16:27:38 -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 QAA11727
	for ; Thu, 3 Jan 2002 16:27:33 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA19646;
	Thu, 3 Jan 2002 15:27:06 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g03LR5r07865;
	Thu, 3 Jan 2002 15:27:05 -0600 (CST)
Message-ID: <3C34CDB7.DD255BE0@alcatel.com>
Date: Thu, 03 Jan 2002 15:31:36 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Minutes of Meeting at IETF 52
References: <015801c1948c$215efc90$7e6015ac@T23KEMPF> <3C34C27C.81B9852E@alcatel.com> <01eb01c19497$70b18820$7e6015ac@T23KEMPF> <3C34C64B.22C6FDAF@alcatel.com> <023901c1949a$ac45bb10$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

Please add both points, I did ask if you had slides on the lahap draft.

James Kempf wrote:

> > Behcet Sarikaya: Do you have any slides on
> draft-guri-seamoby-lahap-00.txt?
> > James Kempf: No.
>
>
>
>
> Q: Was combining these a good idea (draft-sarikaya-seamoby-mipv6hp-00.txt
> and draft-guri-seamoby-lahap-00.txt?)  These were completely different
> proposals.
> A: That is a fair statement.  We'll cover it later.
>
>

Also please add as the last statement, meeting adjurned at 10:15 am.

--
Behcet


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


From seamoby-admin@ietf.org  Thu Jan  3 16:40: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 QAA11929
	for ; Thu, 3 Jan 2002 16:40: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 QAA20791;
	Thu, 3 Jan 2002 16:29: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 QAA20764
	for ; Thu, 3 Jan 2002 16:29:40 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11753
	for ; Thu, 3 Jan 2002 16:29:35 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g03LT7S08381;
	Thu, 3 Jan 2002 13:29:07 -0800 (PST)
Message-ID: <028801c1949d$738cd3f0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" 
Cc: 
References: <015801c1948c$215efc90$7e6015ac@T23KEMPF> <3C34C27C.81B9852E@alcatel.com> <01eb01c19497$70b18820$7e6015ac@T23KEMPF> <3C34C64B.22C6FDAF@alcatel.com> <023901c1949a$ac45bb10$7e6015ac@T23KEMPF> <3C34CDB7.DD255BE0@alcatel.com>
Subject: Re: [Seamoby] Minutes of Meeting at IETF 52
Date: Thu, 3 Jan 2002 13:27:22 -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.

        jak

----- Original Message -----
From: "Behcet Sarikaya" 
To: "James Kempf" 
Cc: 
Sent: Thursday, January 03, 2002 1:31 PM
Subject: Re: [Seamoby] Minutes of Meeting at IETF 52


> Please add both points, I did ask if you had slides on the lahap
draft.
>
> James Kempf wrote:
>
> > > Behcet Sarikaya: Do you have any slides on
> > draft-guri-seamoby-lahap-00.txt?
> > > James Kempf: No.
> >
> >
> >
> >
> > Q: Was combining these a good idea
(draft-sarikaya-seamoby-mipv6hp-00.txt
> > and draft-guri-seamoby-lahap-00.txt?)  These were completely
different
> > proposals.
> > A: That is a fair statement.  We'll cover it later.
> >
> >
>
> Also please add as the last statement, meeting adjurned at 10:15 am.
>
> --
> Behcet
>
>


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


From seamoby-admin@ietf.org  Fri Jan  4 06:19: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 GAA00623
	for ; Fri, 4 Jan 2002 06:19: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 GAA18617;
	Fri, 4 Jan 2002 06:08: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 GAA18586
	for ; Fri, 4 Jan 2002 06:07:59 -0500 (EST)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00531
	for ; Fri, 4 Jan 2002 06:07:55 -0500 (EST)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 4 Jan 2002 06:07:27 -0500
Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB8D2@ftmail>
From: George Tsirtsis 
To: "'James Kempf'" , seamoby@ietf.org
Subject: RE: [Seamoby] Minutes of Meeting at IETF 52
Date: Fri, 4 Jan 2002 06:07:16 -0500 
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

James,

I do not care about the minutes. I pointed to what IMO needs to be changed
in the draft based on the discussion in the meeting.

George

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Thursday, January 03, 2002 8:46 PM
To: George Tsirtsis; seamoby@ietf.org
Subject: Re: [Seamoby] Minutes of Meeting at IETF 52


George,

So are you proposing that the minutes be amended to
include a statement of what Section 4.13 refers to?

            jak
----- Original Message -----
From: "George Tsirtsis" 
To: "'James Kempf'" ; 
Sent: Thursday, January 03, 2002 12:42 PM
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


From seamoby-admin@ietf.org  Fri Jan  4 10:25: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 KAA05339
	for ; Fri, 4 Jan 2002 10:25: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 KAA24472;
	Fri, 4 Jan 2002 10:13: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 KAA24443
	for ; Fri, 4 Jan 2002 10:12:58 -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 KAA04896
	for ; Fri, 4 Jan 2002 10:12:55 -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 g04FCQA14938;
	Fri, 4 Jan 2002 10:12:26 -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 g04FCOj20486;
	Fri, 4 Jan 2002 10:12:24 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 4 Jan 2002 10:10:47 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4738@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: Fri, 4 Jan 2002 10:10:53 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19532.00681890"
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_01C19532.00681890
Content-Type: text/plain;
	charset="iso-8859-1"

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_01C19532.00681890
Content-Type: text/html;
	charset="iso-8859-1"






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_01C19532.00681890--

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


From seamoby-admin@ietf.org  Fri Jan  4 11:22: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 LAA07530
	for ; Fri, 4 Jan 2002 11:22: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 KAA25995;
	Fri, 4 Jan 2002 10:52: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 KAA25965
	for ; Fri, 4 Jan 2002 10:52:25 -0500 (EST)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06551
	for ; Fri, 4 Jan 2002 10:52:22 -0500 (EST)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 4 Jan 2002 10:51:53 -0500
Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB8DC@ftmail>
From: George Tsirtsis 
To: "'Gary Kenward'" ,
        "'James Kempf'"
	 , seamoby@ietf.org
Subject: RE: [Seamoby] Minutes of Meeting at IETF 52
Date: Fri, 4 Jan 2002 10:49:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19537.56FB1540"
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_01C19537.56FB1540
Content-Type: text/plain;
	charset="iso-8859-1"

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 
 
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.
 
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.
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."

 
I sound like a broken record I know...sorry.
 
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_01C19537.56FB1540
Content-Type: text/html;
	charset="iso-8859-1"




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 


 


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.


 


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.


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."


 


I 
sound like a broken record I know...sorry.


 


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_01C19537.56FB1540--

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


From seamoby-admin@ietf.org  Fri Jan  4 11:57: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 LAA08545
	for ; Fri, 4 Jan 2002 11:57: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 LAA26923;
	Fri, 4 Jan 2002 11:20: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 LAA26893
	for ; Fri, 4 Jan 2002 11:20:30 -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 LAA07498
	for ; Fri, 4 Jan 2002 11:20:27 -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 g04GJvA14795;
	Fri, 4 Jan 2002 11:19:58 -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 g04GJtb26115;
	Fri, 4 Jan 2002 11:19:55 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 4 Jan 2002 11:18:19 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA473B@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: Fri, 4 Jan 2002 11:18:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1953B.6F798AD0"
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_01C1953B.6F798AD0
Content-Type: text/plain;
	charset="iso-8859-1"

George:

   Yes we agree, but I do not hear a recommendation for action that would
solve the problem of eliminating trivial requirements, while preventing
wheel spinning. I'm trying to avoid repeating how long we've been at these
requirements, and how many times we have re-visited the same issues (the
mobility issue was covered the first time way back when).

   I also agree with your observations about the requirements you have
singled
out, except for 5.5.2. As you probably recall, 5.5.2 is compromise wording
for
the very critical need to ensure that the context is transferred without
introducing errors (significant errors? more then 1 error in 10000000 bits?
*sigh* *shrug*). And so, I'm not sure why you see it as being
semi-irrelevant.
Maybe you see 5.5.2 as being ambiguous? Sure it is, but are you suggesting 
we go back 10 months, and spend another 5 weeks debating subjective terms
for error control?

  Finally, I do want you to understand that I am not in opposition to your
point of view, I am simply trying to explain the circumstances. I suggest
that you post a specific request to the working group to remove the
"semi-irrelevant" requirements, and dis-ambiguate the remaining
requirements.
You have my support.

Gary

BTW: is "broken record" a relevant phrase any more? would the more apropos
term be a "wacked CD"? my daughter loves to listen to music play on
purposely
"broken records" ("played" by DJ's of all things, on very expensive machines
designed specifically to permit "scratching" and "skipping"), so does this
make a "broken record" a good thing? *smile*

 
-----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 
 
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.
 
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.
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."

 
I sound like a broken record I know...sorry.
 
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_01C1953B.6F798AD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Minutes of Meeting at IETF 52




George:




   Yes we agree, but I do not hear a =
recommendation for action that would

solve the problem of eliminating trivial =
requirements, while preventing

wheel spinning. I'm trying to avoid repeating how =
long we've been at these

requirements, and how many times we have re-visited =
the same issues (the

mobility issue was covered the first time way back =
when).




   I also agree with your observations =
about the requirements you have singled

out, except for 5.5.2. As you probably recall, 5.5.2 =
is compromise wording for

the very critical need to ensure that the context is =
transferred without introducing errors (significant errors? more then 1 =
error in 10000000 bits?



*sigh* *shrug*). And so, I'm not sure why you see it =
as being semi-irrelevant.

Maybe you see 5.5.2 as being ambiguous? Sure it is, =
but are you suggesting 

we go back 10 months, and spend another 5 weeks =
debating subjective terms for error control?




  Finally, I do want you to understand that I am =
not in opposition to your

point of view, I am simply trying to explain the =
circumstances. I suggest

that you post a specific request to the working =
group to remove the "semi-irrelevant" requirements, and =
dis-ambiguate the remaining requirements.



You have my support.




Gary




BTW: is "broken record" a relevant phrase =
any more? would the more apropos

term be a "wacked CD"? my daughter loves =
to listen to music play on purposely

"broken records" ("played" by =
DJ's of all things, on very expensive machines

designed specifically to permit =
"scratching" and "skipping"), so does this make a =
"broken record" a good thing? *smile*




 

-----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 



 

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.



 

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.



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."




 

I sound like a broken record I know...sorry.

 

George

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

From: Gary Kenward [mailto:gkenward@nortelnetwor=
ks.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_01C1953B.6F798AD0--

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


From seamoby-admin@ietf.org  Fri Jan  4 12:45: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 MAA09438
	for ; Fri, 4 Jan 2002 12:45: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 MAA00600;
	Fri, 4 Jan 2002 12:33: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 MAA00571
	for ; Fri, 4 Jan 2002 12:33:36 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09192
	for ; Fri, 4 Jan 2002 12:33:32 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g04HWtS06903;
	Fri, 4 Jan 2002 09:32:55 -0800 (PST)
Message-ID: <007401c19545$9f2f3e00$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Gary Kenward" ,
        "George Tsirtsis" 
Cc: 
References: <9FBD322B7824D511B36900508BF93C9C01AA473B@zcard031.ca.nortel.com>
Date: Fri, 4 Jan 2002 09:31: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
Subject: [Seamoby] Removing CT 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

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


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


From seamoby-admin@ietf.org  Fri Jan  4 13:46: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 NAA10855
	for ; Fri, 4 Jan 2002 13:46: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 NAA02644;
	Fri, 4 Jan 2002 13:34: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 NAA02613
	for ; Fri, 4 Jan 2002 13:34: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 NAA10448
	for ; Fri, 4 Jan 2002 13:34: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 g04IXhE05585;
	Fri, 4 Jan 2002 13:33:44 -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 g04IXfA29728;
	Fri, 4 Jan 2002 13:33:42 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 4 Jan 2002 13:32:04 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA473D@zcard031.ca.nortel.com>
From: "Gary Kenward" 
To: "'James Kempf'" ,
        George Tsirtsis
	 
Cc: seamoby@ietf.org
Date: Fri, 4 Jan 2002 13:03:54 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1954A.2C7554D0"
Subject: [Seamoby] RE: Removing CT 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

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_01C1954A.2C7554D0
Content-Type: text/plain;
	charset="iso-8859-1"

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_01C1954A.2C7554D0
Content-Type: text/html;
	charset="iso-8859-1"






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_01C1954A.2C7554D0--

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


From seamoby-admin@ietf.org  Mon Jan  7 06:04: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 GAA12911
	for ; Mon, 7 Jan 2002 06:04: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 FAA01010;
	Mon, 7 Jan 2002 05:41: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 FAA00979
	for ; Mon, 7 Jan 2002 05:41:24 -0500 (EST)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12716
	for ; Mon, 7 Jan 2002 05:41:21 -0500 (EST)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 7 Jan 2002 05:40:53 -0500
Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB8E8@ftmail>
From: George Tsirtsis 
To: "'Gary Kenward'" ,
        "'James Kempf'"
	 ,
        George Tsirtsis 
Cc: seamoby@ietf.org
Date: Mon, 7 Jan 2002 05:40:50 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19767.C66F1980"
Subject: [Seamoby] RE: Removing CT 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

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_01C19767.C66F1980
Content-Type: text/plain;
	charset="iso-8859-1"

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_01C19767.C66F1980
Content-Type: text/html;
	charset="iso-8859-1"




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_01C19767.C66F1980--

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


From seamoby-admin@ietf.org  Tue Jan  8 14:02: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 OAA05321
	for ; Tue, 8 Jan 2002 14:02: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 NAA15192;
	Tue, 8 Jan 2002 13:50: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 NAA15161
	for ; Tue, 8 Jan 2002 13:50:37 -0500 (EST)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04727
	for ; Tue, 8 Jan 2002 13:50:35 -0500 (EST)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA03059 for ; Tue, 8 Jan 2002 11:50:35 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA22559 for ; Tue, 8 Jan 2002 11:50:35 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52)
	id ; Tue, 8 Jan 2002 12:50:34 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FD14@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'George Tsirtsis'" ,
        "'Gary Kenward'"
	 ,
        "'James Kempf'" 
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] RE: Removing CT Requirements
Date: Tue, 8 Jan 2002 12:50:33 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19875.5A0FE030"
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_01C19875.5A0FE030
Content-Type: text/plain;
	charset="iso-8859-1"

Without getting into details (we had debated some of this a lot), I don't
want to remove them.
You can work on rewording it, but removing it, make CT much more complex.
 
Madjid

-----Original Message-----
From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com]
Sent: Monday, January 07, 2002 4:41 AM
To: 'Gary Kenward'; '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_01C19875.5A0FE030
Content-Type: text/html;
	charset="iso-8859-1"




RE: Removing CT Requirements




Without getting into details (we had debated some of this a lot), I don't 
want to remove them.


You 
can work on rewording it, but removing it, make CT much more 
complex.


 


Madjid



  
-----Original Message-----
From: George Tsirtsis 
  [mailto:G.Tsirtsis@flarion.com]
Sent: Monday, January 07, 2002 4:41 
  AM
To: 'Gary Kenward'; '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_01C19875.5A0FE030--

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


From seamoby-admin@ietf.org  Wed Jan  9 11:50: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 LAA07132
	for ; Wed, 9 Jan 2002 11:50: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 LAA09527;
	Wed, 9 Jan 2002 11:37: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 LAA09498
	for ; Wed, 9 Jan 2002 11:37:55 -0500 (EST)
Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06862
	for ; Wed, 9 Jan 2002 11:37:52 -0500 (EST)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 9 Jan 2002 11:36:10 -0500
Message-ID: 
From: "Shahrier, Sharif M." 
To: "'mobileip@sunroof.eng.sun.com'" 
Cc: seamoby@ietf.org,
        "Shahrier, Sharif M."
	 
Subject: RE: [Seamoby] delay data requested
Date: Wed, 9 Jan 2002 11:36:09 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1992B.BDD59860"
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_01C1992B.BDD59860
Content-Type: text/plain;
	charset="iso-8859-1"

I am trying to do some calculations on the packet transfer delay between a
pair of ARs. I would like to know what is the raw delay (approx.) to
transfer a 32-bit word from the oldAR to the newAR. I expect this
information was used in some way in the calutations of handover protocols.
If someone can help, I would be grateful, if you can send me a direct
e-mail, as well as posting onto the list.
Thanks.
 
-Sharif.

------_=_NextPart_001_01C1992B.BDD59860
Content-Type: text/html;
	charset="iso-8859-1"




RE: Removing CT Requirements




I am 
trying to do some calculations on the packet transfer delay between a pair 
of ARs. I would like to know what is the raw delay (approx.) to transfer a 
32-bit word from the oldAR to the newAR. I expect this information was used in 
some way in the calutations of handover protocols. If someone can help, I would 
be grateful, if you can send me a direct e-mail, as well as posting onto the 
list.


Thanks.


 


-Sharif.


------_=_NextPart_001_01C1992B.BDD59860--

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


From seamoby-admin@ietf.org  Wed Jan  9 12:02: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 MAA07345
	for ; Wed, 9 Jan 2002 12:02: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 LAA09642;
	Wed, 9 Jan 2002 11:41: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 LAA09615
	for ; Wed, 9 Jan 2002 11:41:05 -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 LAA06946
	for ; Wed, 9 Jan 2002 11:40:57 -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 KAA16648;
	Wed, 9 Jan 2002 10:40:30 -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 g09GeUm28615;
	Wed, 9 Jan 2002 10:40:30 -0600 (CST)
Message-ID: <3C3C727A.4070404@alcatel.com>
Date: Wed, 09 Jan 2002 10:40:26 -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: Marco Liebsch 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] IP Paging ]Framework discussion
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <3C3C2C8B.47776F0C@ccrle.nec.de>
Content-Type: multipart/alternative;
 boundary="------------090104000608070409040806"
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


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

Hello Marco,
 
   I could not understand your email, you seem to be somewhat upset, you 
even forgot to include seamoby into your list :)
   First I think that you should be ready to be critisized, more to any 
technical arguments to your work. This is way of life unfortunately, 
people tend to critisize.
   Your recollection and mine about our IETF corridor talks do not seem 
to match. It is also not so clear how much you are aware of IP Paging 
field of study, what happened in the recent past, etc. For your 
information I made a presentation in MIP WG of a joint draft with my 
Nokia colleagues at IETF 49 in San Diego presenting an extension to 
MIPv6 for IP Paging. This work was dubbed an extension to MIPv6 not 
paging related optimizations for MIPv6. This seems to indicate only part 
of a confused mind set.
  My comments on your drafts are based on objective observations and are 
correct and are not negative.
  Your statement that the first seamoby draft will have the MIPv6 
related optimizations in the annex is a big statement which may refer to 
your own draft.

  Maybe something I wrote somehow made you upset, sorry about that.

Happy New Year to you too.
   
 
Marco Liebsch wrote:

> First: Happy new year.
>
> Furthermore:
>
> Behcet,
>
> as we talked in Salt Lake about several paging issues, you told me, 
> that you did not read our concept proposal I-D, but you tried to 
> 'convince me' that our proposal is MIP/HA based and specific. This is 
> not true, as I tried to explain you in Salt Lake already. The concept 
> is independent of the mobility platform, but explains how to integrate 
> the paging concept into a MIPv6 platform 'as an example' and proposes 
> some paging related optimization for MIPv6 as an option. The second 
> draft is not a mess in my opinion, therefore, why should I 'admit' 
> anything like this?
> Therefore, please read the draft thoroughly before giving such a 
> statement. For your info, the first seamoby draft on paging will have 
> the MIPv6 related optimizations proposed in he Annex, as already 
> written on the list.
>  
>
> Regards,
>
> marco.  
>  
>
> Behcet Sarikaya wrote:
>
>> Hi Jim,
>>  
>>
>> James Kempf wrote:
>>
>>>>  You seem to ignore the LAHAP draft always, why? (I think
>>>>the answer is implicit in your other mail, parts of it I am copying
>>>>
>>>here)
>>>
>>>No evil intent, it was strictly a matter of oversight.
>>>
>> Therefore the assessment process is moot, sorry for coming back to 
>> this conclusion again. I think that this will be more evident when 
>> the meeting slides are ever posted with the mnutes, I had 
>> specifically asked during the meeting if there are any slides on 
>> LAHAP draft and you said no.
>>  
>>
>>>One of the uses of IP paging for seamless mobility is the ability
>>>to abstract across a variety of different L2 paging protocols.
>>>Suppose a device has five wireless interfaces, three of
>>>which define L2 paging protocols specific to their
>>>particular medium. In this case, confining the L2
>>>paging information to the AR would simplify
>>>management of paging within the network. L3
>>>paging areas could be used to abstract across
>>>various L2 paging protocols, in the same way
>>>that an IP subnet abstracts across a different
>>>L2 link. In this case, I think there is an advantage
>>>to having L3 paging areas even if there is
>>>already L2 support.
>>>
>>>                        jak
>>>
>> You seem to refer to Yoshi"s mail on orthogonality and also assume 
>> that L2 paging areas always exist. Orthogonality or L2 paging area 
>> configuration regardless of IP subnet structure can only happen in 2G 
>> voice-based cellular networks where the mobile is searched with its 
>> link address, e.g. IMSI. In 2.5G and 3G cellular networks IP 
>> communication is of prime concern.  L2 paging areas regardless of IP 
>> subnet configuration when  the mobile has to be searched with its IP 
>> address seems a wrong approach to me, its only justification could be 
>> to reuse old paging areas already configured for 2G networks. Also I 
>> don't think IP Paging protocol could go into so much to link-related 
>> issues.
>>   Secondly L2 paging areas exist only on cellular network links and 
>> not of a given to any link.In where it exists (GPRS, 3GPP),  would 
>> they be interested in  IETF's IP Paging protocol is a big question 
>> mark, IMHO.
>>
>>   Regarding renker draft, firstly renker-00 draft was based on MIPv6 
>> and it was home agent based paging. Jim mentioned in one of his 
>> previous emails the disadvantageous of HA based paging. Now, 
>> renker-01 draft is a mess as Marco admits, and its architecture is 
>> based on lumping everything together, which means, the authors do not 
>> know what to do with each architectural entity, so lets combine them. 
>> I also agree with Yoshi on the marks given by the assessment team 
>> correctly marked it low.
>>
>>  Regards,
>>
>>-- 
>>Behcet
>>
>>  
>
>
>  


-- 
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



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





Hello Marco,

  

   I could not understand your email, you seem to be somewhat upset, you
even forgot to include seamoby into your list :)

   First I think that you should be ready to be critisized, more to any technical
arguments to your work. This is way of life unfortunately, people tend to
critisize.

   Your recollection and mine about our IETF corridor talks do not seem to
match. It is also not so clear how much you are aware of IP Paging field
of study, what happened in the recent past, etc. For your information I made
a presentation in MIP WG of a joint draft with my Nokia colleagues at IETF
49 in San Diego presenting an extension to MIPv6 for IP Paging. This work
was dubbed an extension to MIPv6 not paging related optimizations for MIPv6.
This seems to indicate only part of a confused mind set.

  My comments on your drafts are based on objective observations and are
correct and are not negative.

  Your statement that the first seamoby draft will have the MIPv6 related
optimizations in the annex is a big statement which may refer to your own
draft.



  Maybe something I wrote somehow made you upset, sorry about that.



Happy New Year to you too.

   

  

Marco Liebsch wrote:


  First:
Happy new year. 
  
Furthermore: 

  
Behcet, 

  
as we talked in Salt Lake about several paging issues, you told me, that
you did not read our concept proposal I-D, but you tried to 'convince me'
that our proposal is MIP/HA based and specific. This is not true, as I tried
to explain you in Salt Lake already. The concept is independent of the mobility
platform, but explains how to integrate the paging concept into a MIPv6 platform
'as an example' and proposes some paging related optimization for MIPv6 as
an option. The second draft is not a mess in my opinion, therefore, why should
I 'admit' anything like this? 

Therefore, please read the draft thoroughly before giving such a statement. 
For your info, the first seamoby draft on paging will have the MIPv6 related 
optimizations proposed in he Annex, as already written on the list. 

  

  
Regards, 

  
marco.   

  

  
Behcet Sarikaya wrote: 

  
Hi Jim, 

  
    
James Kempf wrote: 

    

      

        
  You seem to ignore the LAHAP draft always, why? (I think
the answer is implicit in your other mail, parts of it I am copying

        

        
here)

No evil intent, it was strictly a matter of oversight.

        

 Therefore the assessment process is moot, sorry for coming back to this conclusion
again. I think that this will be more evident when the meeting slides are
ever posted with the mnutes, I had specifically asked during the meeting
if there are any slides on LAHAP draft and you said no. 

  
        

          
One of the uses of IP paging for seamless mobility is the ability
to abstract across a variety of different L2 paging protocols.
Suppose a device has five wireless interfaces, three of
which define L2 paging protocols specific to their
particular medium. In this case, confining the L2
paging information to the AR would simplify
management of paging within the network. L3
paging areas could be used to abstract across
various L2 paging protocols, in the same way
that an IP subnet abstracts across a different
L2 link. In this case, I think there is an advantage
to having L3 paging areas even if there is
already L2 support.

                        jak


          

 You seem to refer to Yoshi"s mail on orthogonality and also assume that L2
paging areas always exist. Orthogonality or L2 paging area configuration regardless
of IP subnet structure can only happen in 2G voice-based cellular networks
where the mobile is searched with its link address, e.g. IMSI. In 2.5G and
3G cellular networks IP communication is of prime concern.  L2 paging areas
regardless of IP subnet configuration when  the mobile has to be searched
with its IP address seems a wrong approach to me, its only justification
could be to reuse old paging areas already configured for 2G networks. Also
I don't think IP Paging protocol could go into so much to link-related issues. 
          

  Secondly L2 paging areas exist only on cellular network links and not of
a given to any link.In where it exists (GPRS, 3GPP),  would they be interested
in  IETF's IP Paging protocol is a big question mark, IMHO. 
          
  Regarding renker draft, firstly renker-00 draft was based
on MIPv6 and it was home agent based paging. Jim mentioned in one of his
previous emails the disadvantageous of HA based paging. Now, renker-01 draft
is a mess as Marco admits, and its architecture is based on lumping everything 
together, which means, the authors do not know what to do with each architectural 
entity, so lets combine them. I also agree with Yoshi on the marks given by
the assessment team correctly marked it low. 

          
 Regards, 

          
-- 
Behcet

  

          

 

          

          
-- 
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


          

          
          

--------------090104000608070409040806--


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


From seamoby-admin@ietf.org  Wed Jan  9 12:35: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 MAA07898
	for ; Wed, 9 Jan 2002 12:35: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 MAA12136;
	Wed, 9 Jan 2002 12:24: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 MAA12107
	for ; Wed, 9 Jan 2002 12:24:30 -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 MAA07632
	for ; Wed, 9 Jan 2002 12:24:26 -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 LAA25912
	for ; Wed, 9 Jan 2002 11:24:00 -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 g09HNxm10696
	for ; Wed, 9 Jan 2002 11:24:00 -0600 (CST)
Message-ID: <3C3C7CAB.1090909@alcatel.com>
Date: Wed, 09 Jan 2002 11:23:55 -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] IP Paging ]Framework discussion
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <3C3C2C8B.47776F0C@ccrle.nec.de> <017901c19930$56eda7a0$7e6015ac@T23KEMPF>
Content-Type: multipart/alternative;
 boundary="------------090107010404010304070306"
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


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

This is a strange trend to keep the discussion away from the WG list?
I just checked, RFC 3154 which included everybody who was involved 
somehow on the requirements document did NOT contain Marco's name.
Maybe another source of confusion.

  Pls post any discussion on the mailing list.
  BTW it seems that there seems to be no archive kept for Seamoby ML. I 
may be wrong, please negate me.
  I hope the ADs are reading the mails.

Regards,


James Kempf wrote:

>Guys,
>
>Let's stop arguing about whose proposal is what and concentrate on
>getting started doing the protocol, OK?
>Behcet is entitled to his opinion, Pat and I clearly didn't share it.
>
>            jak
>
>----- Original Message -----
>From: "Marco Liebsch" 
>To: "Behcet Sarikaya" 
>Cc: "James Kempf" ; "Ralf Schmitz"
>
>Sent: Wednesday, January 09, 2002 3:42 AM
>Subject: Re: [Seamoby] IP Paging ]Framework discussion
>
>
>>First: Happy new year.
>>
>>Furthermore:
>>
>>Behcet,
>>
>>as we talked in Salt Lake about several paging issues, you told me,
>>
>that
>
>>you did not read our concept proposal I-D, but you tried to 'convince
>>me' that our proposal is MIP/HA based and specific. This is not true,
>>
>as
>
>>I tried to explain you in Salt Lake already. The concept is
>>
>independent
>
>>of the mobility platform, but explains how to integrate the paging
>>concept into a MIPv6 platform 'as an example' and proposes some paging
>>related optimization for MIPv6 as an option. The second draft is not a
>>mess in my opinion, therefore, why should I 'admit' anything like
>>
>this?
>
>>Therefore, please read the draft thoroughly before giving such a
>>statement. For your info, the first seamoby draft on paging will have
>>the MIPv6 related optimizations proposed in he Annex, as already
>>
>written
>
>>on the list.
>>
>>
>>Regards,
>>
>>marco.
>>
>>
>>Behcet Sarikaya wrote:
>>
>>>Hi Jim,
>>>
>>>
>>>James Kempf wrote:
>>>
>>>>>  You seem to ignore the LAHAP draft always, why? (I think
>>>>>the answer is implicit in your other mail, parts of it I am
>>>>>
>copying
>
>>>>here)
>>>>
>>>>No evil intent, it was strictly a matter of oversight.
>>>>
>>>Therefore the assessment process is moot, sorry for coming back to
>>>this conclusion again. I think that this will be more evident when
>>>
>the
>
>>>meeting slides are ever posted with the mnutes, I had specifically
>>>asked during the meeting if there are any slides on LAHAP draft and
>>>you said no.
>>>
>>>
>>>>One of the uses of IP paging for seamless mobility is the ability
>>>>to abstract across a variety of different L2 paging protocols.
>>>>Suppose a device has five wireless interfaces, three of
>>>>which define L2 paging protocols specific to their
>>>>particular medium. In this case, confining the L2
>>>>paging information to the AR would simplify
>>>>management of paging within the network. L3
>>>>paging areas could be used to abstract across
>>>>various L2 paging protocols, in the same way
>>>>that an IP subnet abstracts across a different
>>>>L2 link. In this case, I think there is an advantage
>>>>to having L3 paging areas even if there is
>>>>already L2 support.
>>>>
>>>>                        jak
>>>>
>>>>
>>>You seem to refer to Yoshi"s mail on orthogonality and also assume
>>>that L2 paging areas always exist. Orthogonality or L2 paging area
>>>configuration regardless of IP subnet structure can only happen in
>>>
>2G
>
>>>voice-based cellular networks where the mobile is searched with its
>>>link address, e.g. IMSI. In 2.5G and 3G cellular networks IP
>>>communication is of prime concern.  L2 paging areas regardless of IP
>>>subnet configuration when  the mobile has to be searched with its IP
>>>address seems a wrong approach to me, its only justification could
>>>
>be
>
>>>to reuse old paging areas already configured for 2G networks. Also I
>>>don't think IP Paging protocol could go into so much to link-related
>>>issues.
>>>  Secondly L2 paging areas exist only on cellular network links and
>>>not of a given to any link.In where it exists (GPRS, 3GPP),  would
>>>they be interested in  IETF's IP Paging protocol is a big question
>>>mark, IMHO.
>>>
>>>  Regarding renker draft, firstly renker-00 draft was based on MIPv6
>>>and it was home agent based paging. Jim mentioned in one of his
>>>previous emails the disadvantageous of HA based paging. Now,
>>>
>renker-01
>
>>>draft is a mess as Marco admits, and its architecture is based on
>>>lumping everything together, which means, the authors do not know
>>>
>what
>
>>>to do with each architectural entity, so lets combine them. I also
>>>agree with Yoshi on the marks given by the assessment team correctly
>>>marked it low.
>>>
>>> Regards,
>>>
>>>--
>>>Behcet
>>>
>>>
>>
>>
>

-- 
Behcet



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





This is a strange trend to keep the discussion away from the WG list?

I just checked, RFC 3154 which included everybody who was involved somehow
on the requirements document did NOT contain Marco's name.

Maybe another source of confusion.



  Pls post any discussion on the mailing list. 

  BTW it seems that there seems to be no archive kept for Seamoby ML. I may
be wrong, please negate me.

  I hope the ADs are reading the mails.



Regards,





James Kempf wrote:



  
Guys,

Let's stop arguing about whose proposal is what and concentrate on
getting started doing the protocol, OK?
Behcet is entitled to his opinion, Pat and I clearly didn't share it.

            jak

----- Original Message -----
From: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>
To: "Behcet Sarikaya" <behcet.sarikaya@alcatel.com>
Cc: "James Kempf" <kempf@docomolabs-usa.com>; "Ralf Schmitz"
<Ralf.Schmitz@ccrle.nec.de>
Sent: Wednesday, January 09, 2002 3:42 AM
Subject: Re: [Seamoby] IP Paging ]Framework discussion



  

    
First: Happy new year.

Furthermore:

Behcet,

as we talked in Salt Lake about several paging issues, you told me,

    

    
that

    

      
you did not read our concept proposal I-D, but you tried to 'convince
me' that our proposal is MIP/HA based and specific. This is not true,

      

      
as

      

        
I tried to explain you in Salt Lake already. The concept is

        

        
independent

        

          
of the mobility platform, but explains how to integrate the paging
concept into a MIPv6 platform 'as an example' and proposes some paging
related optimization for MIPv6 as an option. The second draft is not a
mess in my opinion, therefore, why should I 'admit' anything like

          

          
this?

          

            
Therefore, please read the draft thoroughly before giving such a
statement. For your info, the first seamoby draft on paging will have
the MIPv6 related optimizations proposed in he Annex, as already

            

            
written

            

              
on the list.


Regards,

marco.


Behcet Sarikaya wrote:


              

                
Hi Jim,


James Kempf wrote:


                

                  

                    
  You seem to ignore the LAHAP draft always, why? (I think
the answer is implicit in your other mail, parts of it I am

                    

                    

                    

                    

                    
copying

                    

                      

                        

                          
here)

No evil intent, it was strictly a matter of oversight.


                          

                          
Therefore the assessment process is moot, sorry for coming back to
this conclusion again. I think that this will be more evident when

                          

                          

                          
the

                          

                            

                              
meeting slides are ever posted with the mnutes, I had specifically
asked during the meeting if there are any slides on LAHAP draft and
you said no.



                              

                                
One of the uses of IP paging for seamless mobility is the ability
to abstract across a variety of different L2 paging protocols.
Suppose a device has five wireless interfaces, three of
which define L2 paging protocols specific to their
particular medium. In this case, confining the L2
paging information to the AR would simplify
management of paging within the network. L3
paging areas could be used to abstract across
various L2 paging protocols, in the same way
that an IP subnet abstracts across a different
L2 link. In this case, I think there is an advantage
to having L3 paging areas even if there is
already L2 support.

                        jak



                                

                                
You seem to refer to Yoshi"s mail on orthogonality and also assume
that L2 paging areas always exist. Orthogonality or L2 paging area
configuration regardless of IP subnet structure can only happen in

                                

                                

                                
2G

                                

                                  

                                    
voice-based cellular networks where the mobile is searched with its
link address, e.g. IMSI. In 2.5G and 3G cellular networks IP
communication is of prime concern.  L2 paging areas regardless of IP
subnet configuration when  the mobile has to be searched with its IP
address seems a wrong approach to me, its only justification could

                                    

                                    

                                    
be

                                    

                                      

                                        
to reuse old paging areas already configured for 2G networks. Also I
don't think IP Paging protocol could go into so much to link-related
issues.
  Secondly L2 paging areas exist only on cellular network links and
not of a given to any link.In where it exists (GPRS, 3GPP),  would
they be interested in  IETF's IP Paging protocol is a big question
mark, IMHO.

  Regarding renker draft, firstly renker-00 draft was based on MIPv6
and it was home agent based paging. Jim mentioned in one of his
previous emails the disadvantageous of HA based paging. Now,

                                        

                                        

                                        
renker-01

                                        

                                          

                                            
draft is a mess as Marco admits, and its architecture is based on
lumping everything together, which means, the authors do not know

                                            

                                            

                                            
what

                                            

                                              

                                                
to do with each architectural entity, so lets combine them. I also
agree with Yoshi on the marks given by the assessment team correctly
marked it low.

 Regards,

--
Behcet



                                                

                                                



                                                

                                                


                                                

                                                

                                                
-- 
Behcet

                                                

                                                
                                                

--------------090107010404010304070306--


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


From seamoby-admin@ietf.org  Wed Jan  9 14:25: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 OAA13128
	for ; Wed, 9 Jan 2002 14:25: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 OAA16338;
	Wed, 9 Jan 2002 14:07: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 OAA16308
	for ; Wed, 9 Jan 2002 14:07:40 -0500 (EST)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12331
	for ; Wed, 9 Jan 2002 14:07:37 -0500 (EST)
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 9 Jan 2002 14:07:24 -0500
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E04861667E@meshpdc.meshnetworks.com>
From: Phillip Neumiller 
To: "'Shahrier, Sharif M.'" ,
        "'mobileip@sunroof.eng.sun.com'" 
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] delay data requested
Date: Wed, 9 Jan 2002 14:07:18 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19940.DBE1A780"
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_01C19940.DBE1A780
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Shahrier,
 
This is a very good question.
 
1).  Since CT has to support inter-domain transfers, I would suspect these
would take 
      longer than intra-domain.  Then again, I am not sure if you are
referring to SeaMoby
      CT or something else???  The way the CT requirements read there is a
built in
      dependency on forming  a security association with the newAR before a
CT can
      take place, so that can also delay things considerably I imagine.
 
2).  In the best case, your ARs are joined on a fixed network with very low
latency
      probably << 1 ms I would imagine.
 
I am sure others will have some thoughts on this.  I am not sure if I
understood your
question though.
 
Best regards,
 
Phil
 

--
Mesh Networks, Inc. (www.meshnetworks.com)
Phillip D. Neumiller, Staff Scientist
pneumiller@meshnetworks.com PH: 1-407-659-5387 

-----Original Message-----
From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@interdigital.com]
Sent: Wednesday, January 09, 2002 11:36 AM
To: 'mobileip@sunroof.eng.sun.com'
Cc: seamoby@ietf.org; Shahrier, Sharif M.
Subject: RE: [Seamoby] delay data requested


I am trying to do some calculations on the packet transfer delay between a
pair of ARs. I would like to know what is the raw delay (approx.) to
transfer a 32-bit word from the oldAR to the newAR. I expect this
information was used in some way in the calutations of handover protocols.
If someone can help, I would be grateful, if you can send me a direct
e-mail, as well as posting onto the list.
Thanks.
 
-Sharif.

****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 

------_=_NextPart_001_01C19940.DBE1A780
Content-Type: text/html;
	charset="iso-8859-1"




RE: Removing CT Requirements




Hi 
Shahrier,


 


This 
is a very good question.


 


1).  Since CT has to support inter-domain 
transfers, I would suspect these would take 


      longer than 
intra-domain.  Then again, I am not sure if you are referring to 
SeaMoby


      CT or something 
else???  The way the CT requirements read there is a built 
in


      dependency on 
forming  a security association with the newAR before a 
CT can


      take place, so that can 
also delay things considerably I imagine.


 


2).  In the best case, your ARs are joined on 
a fixed network with very low latency


      probably << 1 
ms I would imagine.


 


I am 
sure others will have some thoughts on this.  I am not sure if I understood 
your


question though.


 


Best 
regards,


 


Phil


 


--
Mesh Networks, Inc. (www.meshnetworks.com)
Phillip D. 
Neumiller, Staff Scientist
pneumiller@meshnetworks.com PH: 
1-407-659-5387 



  
-----Original Message-----
From: Shahrier, Sharif M. 
  [mailto:Sharif.Shahrier@interdigital.com]
Sent: Wednesday, January 
  09, 2002 11:36 AM
To: 'mobileip@sunroof.eng.sun.com'
Cc: 
  seamoby@ietf.org; Shahrier, Sharif M.
Subject: RE: [Seamoby] delay 
  data requested


  
I am 
  trying to do some calculations on the packet transfer delay between a 
  pair of ARs. I would like to know what is the raw delay (approx.) to transfer 
  a 32-bit word from the oldAR to the newAR. I expect this information was used 
  in some way in the calutations of handover protocols. If someone can help, I 
  would be grateful, if you can send me a direct e-mail, as well as posting onto 
  the list.

  
Thanks.

  
 

  
-Sharif.



****************************************************************************This e-mail is intended only for the addressee named above and may contain confidential, proprietary or privileged information. If you are not the named addressee or the person responsible for delivering the message to the named addressee, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy. The contents should not be disclosed to anyone and no copies should be made. We take reasonable precautions to ensure that our emails are virus free. However we accept no responsibility for any virus transmitted by us and recommend that you subject any incoming e-mail to your own virus checking procedures. 


------_=_NextPart_001_01C19940.DBE1A780--

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


From seamoby-admin@ietf.org  Wed Jan  9 14:55: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 OAA13897
	for ; Wed, 9 Jan 2002 14:55: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 OAA17560;
	Wed, 9 Jan 2002 14:39: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 OAA17531
	for ; Wed, 9 Jan 2002 14:39:55 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13574
	for ; Wed, 9 Jan 2002 14:39:51 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g09JdKS18441;
	Wed, 9 Jan 2002 11:39:20 -0800 (PST)
Message-ID: <022201c19945$1bb9d040$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" , 
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <3C3C2C8B.47776F0C@ccrle.nec.de> <017901c19930$56eda7a0$7e6015ac@T23KEMPF> <3C3C7CAB.1090909@alcatel.com>
Subject: Re: [Seamoby] IP Paging ]Framework discussion
Date: Wed, 9 Jan 2002 11:37:43 -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,

Marco sent you a private email, and I replied privately because the
email was private.
Not everything needs to get said in public.

But, if you insist, I'll repeat the message here. I'd appreciate if we
could
stop arguing about who said what and get down to working on the
protocol.

            jak

----- Original Message -----
From: "Behcet Sarikaya" 
To: 
Sent: Wednesday, January 09, 2002 9:23 AM
Subject: Re: [Seamoby] IP Paging ]Framework discussion


> This is a strange trend to keep the discussion away from the WG list?
> I just checked, RFC 3154 which included everybody who was involved
> somehow on the requirements document did NOT contain Marco's name.
> Maybe another source of confusion.
>
>   Pls post any discussion on the mailing list.
>   BTW it seems that there seems to be no archive kept for Seamoby ML.
I
> may be wrong, please negate me.
>   I hope the ADs are reading the mails.
>
> Regards,
>
>
> James Kempf wrote:
>
> >Guys,
> >
> >Let's stop arguing about whose proposal is what and concentrate on
> >getting started doing the protocol, OK?
> >Behcet is entitled to his opinion, Pat and I clearly didn't share it.
> >
> >            jak
> >
> >----- Original Message -----
> >From: "Marco Liebsch" 
> >To: "Behcet Sarikaya" 
> >Cc: "James Kempf" ; "Ralf Schmitz"
> >
> >Sent: Wednesday, January 09, 2002 3:42 AM
> >Subject: Re: [Seamoby] IP Paging ]Framework discussion
> >
> >
> >>First: Happy new year.
> >>
> >>Furthermore:
> >>
> >>Behcet,
> >>
> >>as we talked in Salt Lake about several paging issues, you told me,
> >>
> >that
> >
> >>you did not read our concept proposal I-D, but you tried to
'convince
> >>me' that our proposal is MIP/HA based and specific. This is not
true,
> >>
> >as
> >
> >>I tried to explain you in Salt Lake already. The concept is
> >>
> >independent
> >
> >>of the mobility platform, but explains how to integrate the paging
> >>concept into a MIPv6 platform 'as an example' and proposes some
paging
> >>related optimization for MIPv6 as an option. The second draft is not
a
> >>mess in my opinion, therefore, why should I 'admit' anything like
> >>
> >this?
> >
> >>Therefore, please read the draft thoroughly before giving such a
> >>statement. For your info, the first seamoby draft on paging will
have
> >>the MIPv6 related optimizations proposed in he Annex, as already
> >>
> >written
> >
> >>on the list.
> >>
> >>
> >>Regards,
> >>
> >>marco.
> >>
> >>
> >>Behcet Sarikaya wrote:
> >>
> >>>Hi Jim,
> >>>
> >>>
> >>>James Kempf wrote:
> >>>
> >>>>>  You seem to ignore the LAHAP draft always, why? (I think
> >>>>>the answer is implicit in your other mail, parts of it I am
> >>>>>
> >copying
> >
> >>>>here)
> >>>>
> >>>>No evil intent, it was strictly a matter of oversight.
> >>>>
> >>>Therefore the assessment process is moot, sorry for coming back to
> >>>this conclusion again. I think that this will be more evident when
> >>>
> >the
> >
> >>>meeting slides are ever posted with the mnutes, I had specifically
> >>>asked during the meeting if there are any slides on LAHAP draft and
> >>>you said no.
> >>>
> >>>
> >>>>One of the uses of IP paging for seamless mobility is the ability
> >>>>to abstract across a variety of different L2 paging protocols.
> >>>>Suppose a device has five wireless interfaces, three of
> >>>>which define L2 paging protocols specific to their
> >>>>particular medium. In this case, confining the L2
> >>>>paging information to the AR would simplify
> >>>>management of paging within the network. L3
> >>>>paging areas could be used to abstract across
> >>>>various L2 paging protocols, in the same way
> >>>>that an IP subnet abstracts across a different
> >>>>L2 link. In this case, I think there is an advantage
> >>>>to having L3 paging areas even if there is
> >>>>already L2 support.
> >>>>
> >>>>                        jak
> >>>>
> >>>>
> >>>You seem to refer to Yoshi"s mail on orthogonality and also assume
> >>>that L2 paging areas always exist. Orthogonality or L2 paging area
> >>>configuration regardless of IP subnet structure can only happen in
> >>>
> >2G
> >
> >>>voice-based cellular networks where the mobile is searched with its
> >>>link address, e.g. IMSI. In 2.5G and 3G cellular networks IP
> >>>communication is of prime concern.  L2 paging areas regardless of
IP
> >>>subnet configuration when  the mobile has to be searched with its
IP
> >>>address seems a wrong approach to me, its only justification could
> >>>
> >be
> >
> >>>to reuse old paging areas already configured for 2G networks. Also
I
> >>>don't think IP Paging protocol could go into so much to
link-related
> >>>issues.
> >>>  Secondly L2 paging areas exist only on cellular network links and
> >>>not of a given to any link.In where it exists (GPRS, 3GPP),  would
> >>>they be interested in  IETF's IP Paging protocol is a big question
> >>>mark, IMHO.
> >>>
> >>>  Regarding renker draft, firstly renker-00 draft was based on
MIPv6
> >>>and it was home agent based paging. Jim mentioned in one of his
> >>>previous emails the disadvantageous of HA based paging. Now,
> >>>
> >renker-01
> >
> >>>draft is a mess as Marco admits, and its architecture is based on
> >>>lumping everything together, which means, the authors do not know
> >>>
> >what
> >
> >>>to do with each architectural entity, so lets combine them. I also
> >>>agree with Yoshi on the marks given by the assessment team
correctly
> >>>marked it low.
> >>>
> >>> Regards,
> >>>
> >>>--
> >>>Behcet
> >>>
> >>>
> >>
> >>
> >
>
> --
> Behcet
>
>
>


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


From seamoby-admin@ietf.org  Wed Jan  9 16:00: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 QAA15146
	for ; Wed, 9 Jan 2002 16:00: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 PAA19226;
	Wed, 9 Jan 2002 15:49: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 PAA19190
	for ; Wed, 9 Jan 2002 15:49:36 -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 PAA14845
	for ; Wed, 9 Jan 2002 15:49:31 -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 MAA04390;
	Wed, 9 Jan 2002 12:49:03 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g09Kn2Y23355;
	Wed, 9 Jan 2002 12:49:02 -0800
X-mProtect:  Wed, 9 Jan 2002 12:49:02 -0800 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.205, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdlw6SpT; Wed, 09 Jan 2002 12:49:00 PST
Message-ID: <3C3CAC07.3060308@iprg.nokia.com>
Date: Wed, 09 Jan 2002 12:45:59 -0800
From: Vijay Devarapalli 
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Shahrier, Sharif M." 
CC: "'mobileip@sunroof.eng.sun.com'" ,
        seamoby@ietf.org
Subject: Re: [Seamoby] delay data requested
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

Hi Sharif,

It depends on how the oldAR is connected to the newAR. if they are
connected directly, it takes less than 1 ms.

Vijay


Shahrier, Sharif M. wrote:

> I am trying to do some calculations on the packet transfer delay between 
> a pair of ARs. I would like to know what is the raw delay (approx.) to 
> transfer a 32-bit word from the oldAR to the newAR. I expect this 
> information was used in some way in the calutations of handover 
> protocols. If someone can help, I would be grateful, if you can send me 
> a direct e-mail, as well as posting onto the list.
> 
> Thanks.
> 
>  
> 
> -Sharif.
> 



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


From seamoby-admin@ietf.org  Wed Jan  9 16:16: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 QAA15913
	for ; Wed, 9 Jan 2002 16:15: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 QAA19916;
	Wed, 9 Jan 2002 16:03: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 QAA19885
	for ; Wed, 9 Jan 2002 16:03: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 QAA15361;
	Wed, 9 Jan 2002 16:03:37 -0500 (EST)
Message-Id: <200201092103.QAA15361@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, 09 Jan 2002 16:03:36 -0500
Subject: [Seamoby] I-D ACTION:draft-jung-seamoby-paging-buffload-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		: Reducing the Buffering Load of Paging Agent in IP 
                          Paging
	Author(s)	: H. Jung, S. Koh
	Filename	: draft-jung-seamoby-paging-buffload-00.txt
	Pages		: 6
	Date		: 08-Jan-02
	
This draft defines two procedures to distribute buffering load in IP
paging using PA.  A couple of documents using the PA, which includes
all functions defined RFC 3154 in an entity, have beee submitted for
cadidate protocol for IP paging. In this PA paging approach, the
centralized buffering in PA can be a bottleneck point if a PA has to
manage large paging area and a number of idle mobile hosts.  To
address the problem, it can be good solution to distribute buffering
load among ARs in the paging area

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jung-seamoby-paging-buffload-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-jung-seamoby-paging-buffload-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-jung-seamoby-paging-buffload-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:	<20020108150738.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-jung-seamoby-paging-buffload-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-jung-seamoby-paging-buffload-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020108150738.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 Jan  9 16:16: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 QAA15925
	for ; Wed, 9 Jan 2002 16:16: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 PAA19314;
	Wed, 9 Jan 2002 15:54: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 PAA19283
	for ; Wed, 9 Jan 2002 15:54:02 -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 PAA14929
	for ; Wed, 9 Jan 2002 15:53:58 -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 g09KrS619262;
	Wed, 9 Jan 2002 15:53: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 g09KrQG22979;
	Wed, 9 Jan 2002 15:53:26 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 9 Jan 2002 15:51:53 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4754@zcard031.ca.nortel.com>
From: "Gary Kenward"
To: "'Phillip Neumiller'" ,
        "'Shahrier, Sharif M.'" ,
        "'mobileip@sunroof.eng.sun.com'" 
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] delay data requested
Date: Wed, 9 Jan 2002 15:52:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1994F.7EE70520"
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_01C1994F.7EE70520
Content-Type: text/plain;
	charset="iso-8859-1"

Phil:

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: January 9, 2002 14:07
> To: 'Shahrier, Sharif M.'; 'mobileip@sunroof.eng.sun.com'
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] delay data requested
> 
> 
> Hi Shahrier,
>  
> This is a very good question.
>  
> 1).  Since CT has to support inter-domain transfers, I would suspect these
would take 
>       longer than intra-domain.  Then again, I am not sure if you are
referring to > > > SeaMoby
>       CT or something else???  The way the CT requirements read there is a
built in
>       dependency on forming  a security association with the newAR before
a CT can
>       take place, so that can also delay things considerably I imagine.
> 
[gwk] There was much discussion around this point. The requirement is only
that the 
association must exist for a ct to be performed. It does not specify when
the association is established. So, you can do it immediately prior to the
ct or  you can do it when you configure the network(s).
> 
> This is good, as it allows for both options.
> 
> 2).  In the best case, your ARs are joined on a fixed network with very
low latency
>       probably << 1 ms I would imagine.
> 
Let's see: a 1G link would introduce about 32 nano secs of transmission
delay. Everything else would be AR implementation dependent.

Gary
 
> I am sure others will have some thoughts on this.  I am not sure if I
understood your
> question though.
 
> Best regards,
 
> Phil

> --
> Mesh Networks, Inc. (www.meshnetworks.com)
> Phillip D. Neumiller, Staff Scientist
> pneumiller@meshnetworks.com PH: 1-407-659-5387 
> -----Original Message-----
> From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@interdigital.com]
> Sent: Wednesday, January 09, 2002 11:36 AM
> To: 'mobileip@sunroof.eng.sun.com'
> Cc: seamoby@ietf.org; Shahrier, Sharif M.
> Subject: RE: [Seamoby] delay data requested
> 

I am trying to do some calculations on the packet transfer delay between a
pair of ARs. I would like to know what is the raw delay (approx.) to
transfer a 32-bit word from the oldAR to the newAR. I expect this
information was used in some way in the calutations of handover protocols.
If someone can help, I would be grateful, if you can send me a direct
e-mail, as well as posting onto the list.
Thanks.
 
-Sharif.
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 

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






RE: [Seamoby] delay data requested




Phil:




> -----Original Message-----

> From: Phillip Neumiller [mailto:PNeumiller@MeshNetwor=
ks.com]

> Sent: January 9, 2002 14:07

> To: 'Shahrier, Sharif M.'; =
'mobileip@sunroof.eng.sun.com'

> Cc: seamoby@ietf.org

> Subject: RE: [Seamoby] delay data =
requested

> 

> 

> Hi Shahrier,

>  

> This is a very good question.

>  

> 1).  Since CT has to support inter-domain =
transfers, I would suspect these would take 

>       longer than =
intra-domain.  Then again, I am not sure if you are referring to =
> > > SeaMoby

>       CT or =
something else???  The way the CT requirements read there is a =
built in

>       dependency =
on forming  a security association with the newAR before a CT =
can

>       take place, =
so that can also delay things considerably I imagine.

> 

[gwk] There was much discussion around this point. =
The requirement is only that the 

association must exist for a ct to be performed. It =
does not specify when the association is established. So, you can do it =
immediately prior to the ct or  you can do it when you configure =
the network(s).



> 

> This is good, as it allows for both =
options.

> 

> 2).  In the best case, your ARs are joined =
on a fixed network with very low latency

>       probably =
<< 1 ms I would imagine.

> 

Let's see: a 1G link would introduce about 32 nano =
secs of transmission delay. Everything else would be AR implementation =
dependent.



Gary

 

> I am sure others will have some thoughts on =
this.  I am not sure if I understood your

> question though.

 

> Best regards,

 

> Phil




> --

> Mesh Networks, Inc. =
(www.meshnetworks.com)

> Phillip D. Neumiller, Staff Scientist

> pneumiller@meshnetworks.com PH: 1-407-659-5387 =


> -----Original Message-----

> From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@=
interdigital.com]

> Sent: Wednesday, January 09, 2002 11:36 =
AM

> To: 'mobileip@sunroof.eng.sun.com'

> Cc: seamoby@ietf.org; Shahrier, Sharif =
M.

> Subject: RE: [Seamoby] delay data =
requested

> 




I am trying to do some calculations on the packet =
transfer delay between a pair of ARs. I would like to know what is the =
raw delay (approx.) to transfer a 32-bit word from the oldAR to the =
newAR. I expect this information was used in some way in the =
calutations of handover protocols. If someone can help, I would be =
grateful, if you can send me a direct e-mail, as well as posting onto =
the list.



Thanks.

 

-Sharif.

***************************************************************=
*************This e-mail is intended only for the addressee named above =
and may contain confidential, proprietary or privileged information. If =
you are not the named addressee or the person responsible for =
delivering the message to the named addressee, please inform us =
promptly by reply e-mail, then delete the e-mail and destroy any =
printed copy. The contents should not be disclosed to anyone and no =
copies should be made. We take reasonable precautions to ensure that =
our emails are virus free. However we accept no responsibility for any =
virus transmitted by us and recommend that you subject any incoming =
e-mail to your own virus checking procedures. 




------_=_NextPart_001_01C1994F.7EE70520--

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


From seamoby-admin@ietf.org  Thu Jan 10 07:12: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 HAA13412
	for ; Thu, 10 Jan 2002 07:12: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 HAA23715;
	Thu, 10 Jan 2002 07:00: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 HAA23682
	for ; Thu, 10 Jan 2002 07:00:53 -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 HAA13323
	for ; Thu, 10 Jan 2002 07:00:51 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0AC0eH01446;
	Thu, 10 Jan 2002 13:00:40 +0100 (CET)
Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP
	id 8078DC052; Thu, 10 Jan 2002 13:00:12 +0100 (CET)
Date: Thu, 10 Jan 2002 13:11:35 +0100
From: Marcus Brunner 
Reply-To: brunner@ccrle.nec.de
To: Behcet Sarikaya ,
        Marco Liebsch 
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] IP Paging ]Framework discussion
Message-ID: <14348431.1010668295@[192.168.102.79]>
In-Reply-To: <3C3C727A.4070404@alcatel.com>
References: <3C335823.5030009@alcatel.com>
 <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com>
 <3C3C2C8B.47776F0C@ccrle.nec.de> <3C3C727A.4070404@alcatel.com>
X-Mailer: Mulberry/2.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 understand Marco if he is upset (you called his draft publically "a mess" 
(Message-ID: <3C337390.4000109@alcatel.com>).

That you make privatly sent mails public seams not to be a the right 
behavior if you still want to collaborate (but it seams you want to go out 
of the game, is this right?)

Plus he wants to start working on the protocol TOGETHER with everybody NOW.

Marcus

--On Wednesday, January 09, 2002 10:40 AM -0600 Behcet Sarikaya 
 wrote:

> Hello Marco,
>
>    I could not understand your email, you seem to be somewhat upset, you
> even forgot to include seamoby into your list :)    First I think that
> you should be ready to be critisized, more to any technical arguments to
> your work. This is way of life unfortunately, people tend to critisize.
> Your recollection and mine about our IETF corridor talks do not seem to
> match. It is also not so clear how much you are aware of IP Paging field
> of study, what happened in the recent past, etc. For your information I
> made a presentation in MIP WG of a joint draft with my Nokia colleagues
> at IETF 49 in San Diego presenting an extension to MIPv6 for IP Paging.
> This work was dubbed an extension to MIPv6 not paging related
> optimizations for MIPv6. This seems to indicate only part of a confused
> mind set.   My comments on your drafts are based on objective
> observations and are correct and are not negative.   Your statement that
> the first seamoby draft will have the MIPv6 related optimizations in the
> annex is a big statement which may refer to your own draft.
>
>   Maybe something I wrote somehow made you upset, sorry about that.
>
> Happy New Year to you too.
>
>
> Marco Liebsch wrote:
>
>  First: Happy new year.
>
> Furthermore:
>
> Behcet,
>
> as we talked in Salt Lake about several paging issues, you told me, that
> you did not read our concept proposal I-D, but you tried to 'convince me'
> that our proposal is MIP/HA based and specific. This is not true, as I
> tried to explain you in Salt Lake already. The concept is independent of
> the mobility platform, but explains how to integrate the paging concept
> into a MIPv6 platform 'as an example' and proposes some paging related
> optimization for MIPv6 as an option. The second draft is not a mess in my
> opinion, therefore, why should I 'admit' anything like this?  Therefore,
> please read the draft thoroughly before giving such a statement. For your
> info, the first seamoby draft on paging will have the MIPv6 related
> optimizations proposed in he Annex, as already written on the list.
>
> Regards,
>
> marco.
>
>
> Behcet Sarikaya wrote:
>
> Hi Jim,
>
>
> James Kempf wrote:
>
>
>
>   You seem to ignore the LAHAP draft always, why? (I think
> the answer is implicit in your other mail, parts of it I am copying
>
>
>
> here)
>
> No evil intent, it was strictly a matter of oversight.
>
>
> Therefore the assessment process is moot, sorry for coming back to this
> conclusion again. I think that this will be more evident when the meeting
> slides are ever posted with the mnutes, I had specifically asked during
> the meeting if there are any slides on LAHAP draft and you said no.
>
>
> One of the uses of IP paging for seamless mobility is the ability
> to abstract across a variety of different L2 paging protocols.
> Suppose a device has five wireless interfaces, three of
> which define L2 paging protocols specific to their
> particular medium. In this case, confining the L2
> paging information to the AR would simplify
> management of paging within the network. L3
> paging areas could be used to abstract across
> various L2 paging protocols, in the same way
> that an IP subnet abstracts across a different
> L2 link. In this case, I think there is an advantage
> to having L3 paging areas even if there is
> already L2 support.
>
>                         jak
>
>
>
>
> You seem to refer to Yoshi"s mail on orthogonality and also assume that
> L2 paging areas always exist. Orthogonality or L2 paging area
> configuration regardless of IP subnet structure can only happen in 2G
> voice-based cellular networks where the mobile is searched with its link
> address, e.g. IMSI. In 2.5G and 3G cellular networks IP communication is
> of prime concern.  L2 paging areas regardless of IP subnet configuration
> when  the mobile has to be searched with its IP address seems a wrong
> approach to me, its only justification could be to reuse old paging areas
> already configured for 2G networks. Also I don't think IP Paging protocol
> could go into so much to link-related issues.    Secondly L2 paging areas
> exist only on cellular network links and not of a given to any link.In
> where it exists (GPRS, 3GPP),  would they be interested in  IETF's IP
> Paging protocol is a big question mark, IMHO.
>
>   Regarding renker draft, firstly renker-00 draft was based on MIPv6 and
> it was home agent based paging. Jim mentioned in one of his previous
> emails the disadvantageous of HA based paging. Now, renker-01 draft is a
> mess as Marco admits, and its architecture is based on lumping everything
> together, which means, the authors do not know what to do with each
> architectural entity, so lets combine them. I also agree with Yoshi on
> the marks given by the assessment team correctly marked it low.
>
>  Regards,
> --
> Behcet
>
>
>
>
>
>
>
> --
> 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
>
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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


From seamoby-admin@ietf.org  Thu Jan 10 08:55: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 IAA14852
	for ; Thu, 10 Jan 2002 08:55: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 IAA26965;
	Thu, 10 Jan 2002 08:49: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 IAA26925
	for ; Thu, 10 Jan 2002 08:49:45 -0500 (EST)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14679
	for ; Thu, 10 Jan 2002 08:49:44 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.10.2/8.10.2) id g0ADnXQ06501;
	Thu, 10 Jan 2002 08:49:33 -0500 (EST)
Date: Thu, 10 Jan 2002 08:49:33 -0500 (EST)
From: Scott  Bradner 
Message-Id: <200201101349.g0ADnXQ06501@newdev.harvard.edu>
To: behcet.sarikaya@alcatel.com, seamoby@ietf.org
Subject: Re: [Seamoby] IP Paging ]Framework discussion
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

>  BTW it seems that there seems to be no archive kept for Seamoby ML

archive at: ftp://ftp.ietf.org/ietf-mail-archive/seamoby/

Scott

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


From seamoby-admin@ietf.org  Thu Jan 10 08:55: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 IAA14874
	for ; Thu, 10 Jan 2002 08:55: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 IAA26807;
	Thu, 10 Jan 2002 08:48: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 IAA26777
	for ; Thu, 10 Jan 2002 08:47:58 -0500 (EST)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14589
	for ; Thu, 10 Jan 2002 08:47:57 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.10.2/8.10.2) id g0ADlSl06498;
	Thu, 10 Jan 2002 08:47:28 -0500 (EST)
Date: Thu, 10 Jan 2002 08:47:28 -0500 (EST)
From: Scott  Bradner 
Message-Id: <200201101347.g0ADlSl06498@newdev.harvard.edu>
To: behcet.sarikaya@alcatel.com, seamoby@ietf.org
Subject: Re: [Seamoby] IP Paging ]Framework discussion
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 hope the ADs are reading the mails.

yes

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


From seamoby-admin@ietf.org  Thu Jan 10 12:55: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 MAA20274
	for ; Thu, 10 Jan 2002 12:55: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 MAA07739;
	Thu, 10 Jan 2002 12:51: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 MAA07710
	for ; Thu, 10 Jan 2002 12:51:00 -0500 (EST)
Received: from hotmail.com (f150.law9.hotmail.com [64.4.9.150])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20171
	for ; Thu, 10 Jan 2002 12:50:58 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 10 Jan 2002 09:50:28 -0800
Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP;
	Thu, 10 Jan 2002 17:50:28 GMT
X-Originating-IP: [63.78.179.5]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Cc: govind.krishnamurthi@nokia.com
Date: Thu, 10 Jan 2002 12:50:28 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 10 Jan 2002 17:50:28.0605 (UTC) FILETIME=[4A579AD0:01C199FF]
Subject: [Seamoby] 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

Hello all,
I wanted to send out a reminder about the CAR Discovery requirements. Does
anyone have any major revisions to the set of requirements that was posted 
earlier on the mailing list?
There requirements were

1. MUST translate L2 Ids (APs and ARs) to L3 Ids of ARs


2. MUST support L2 devices of different technologies


3. MUST (?) support for L2 devices (and ARs) in private/site-local spaces


4. MUST communicate capability information between GAARs in a secure and
reliable manner


5. MUST use standard format for capabilities..
and this is TBD

6. Protocol applicability ? SHOULD (?) (show of hands indicated that this
item should be changed to a MUST) support inter-domain as well
as Intra-domain scope


7. MUST NOT introduce network elements dedicated to CAR discovery.


8. SHOULD minimize involvement of ARs which are not GAARs in CAR
discovery


9. MUST NOT depend on a particular mobility management protocol



Thanks,
Govind.






_________________________________________________________________
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  Thu Jan 10 16:47: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 QAA24482
	for ; Thu, 10 Jan 2002 16:47: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 QAA15899;
	Thu, 10 Jan 2002 16:37: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 QAA15869
	for ; Thu, 10 Jan 2002 16:37:57 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24308
	for ; Thu, 10 Jan 2002 16:37:54 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0ALbQS07169
	for ; Thu, 10 Jan 2002 13:37:26 -0800 (PST)
Message-ID: <01b101c19a1e$c5615030$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Date: Thu, 10 Jan 2002 13:35:49 -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] Role of WG Document and WG Document Editor
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,

There seems to be a certain degree of misunderstanding
about what it means to be a WG document.

When a document is a WG document, the technical content
is the responsibility of the WG, not just the document editor.
WG members can and should contribute technical content
either by sending to the document editor or by sending
it to the list for discussion. The WG document editor is
reponsible for the editorial content of the document, making
sure it is easily readable and that deadlines are not missed.
Of course, the document editor can also contribute content,
and a document editor may request that a particular
point sent to him/her by a WG member be posted to the
list for discussion, if he/she thinks that the request requires
it.

Thus, the selection of draft-renker as a WG document for
paging doesn't mean that only Marco and his co-authors
get to contribute content. Everybody in the WG does, and
we really do need the co-operation of people with ideas
and perspectives on the problem, most especially the authors
of the other protocols. The current draft needs work,
as the assessment team report has indicated,
and Marco has indicated that he is ready to start taking
suggestions for improvement.

So, please, if you have suggestions for improvements,
send them to Marco or to the list for discussion.

                jak


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


From seamoby-admin@ietf.org  Thu Jan 10 16:52: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 QAA24633
	for ; Thu, 10 Jan 2002 16:52: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 QAA16134;
	Thu, 10 Jan 2002 16:49: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 QAA16105
	for ; Thu, 10 Jan 2002 16:49:25 -0500 (EST)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24551
	for ; Thu, 10 Jan 2002 16:49:23 -0500 (EST)
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 10 Jan 2002 16:49:08 -0500
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048616680@meshpdc.meshnetworks.com>
From: Phillip Neumiller 
To: "'Govind Krishnamurthi'" , seamoby@ietf.org
Cc: govind.krishnamurthi@nokia.com
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Thu, 10 Jan 2002 16:49:07 -0500
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 would like to see the following requirement added:

1).  It MUST support IPv4 and IPv6, but may take advantage of features
     in IPv6 that are not in IPv4.  For example anycast addressing may
     be useful as well address autoconfiguration.

2).  It MUST provide a query (client server) and/or a post (publish and
     subscribe) method to allow other mobility protocols like those being
     worked on in the MIP and MANET WGs to cooperate with this protocol.

Thanks,

Phil
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 

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


From seamoby-admin@ietf.org  Thu Jan 10 16: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 QAA24723
	for ; Thu, 10 Jan 2002 16: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 QAA16317;
	Thu, 10 Jan 2002 16:57: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 QAA16289
	for ; Thu, 10 Jan 2002 16:56:58 -0500 (EST)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24681
	for ; Thu, 10 Jan 2002 16:56:56 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.10.2/8.10.2) id g0ALufK09168;
	Thu, 10 Jan 2002 16:56:41 -0500 (EST)
Date: Thu, 10 Jan 2002 16:56:41 -0500 (EST)
From: Scott  Bradner 
Message-Id: <200201102156.g0ALufK09168@newdev.harvard.edu>
To: kempf@docomolabs-usa.com, seamoby@ietf.org
Subject: Re: [Seamoby] Role of WG Document and WG Document Editor
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 good reminder - but one clarification:

> WG members can and should contribute technical content
> either by sending to the document editor or by sending
> it to the list for discussion.

the doc needs to reflect the WG consensus so technical changes should not
be done in private between the editor and someone else - there should 
be discussion on the list to show that there is consensus on the
point before it gets added to the draft

scott

-----
From seamoby-admin@ietf.org  Thu Jan 10 16:50:03 2002
From: "James Kempf" 
To: 
Date: Thu, 10 Jan 2002 13:35:49 -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] Role of WG Document and WG Document Editor
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

Folks,

There seems to be a certain degree of misunderstanding
about what it means to be a WG document.

When a document is a WG document, the technical content
is the responsibility of the WG, not just the document editor.
WG members can and should contribute technical content
either by sending to the document editor or by sending
it to the list for discussion. The WG document editor is
reponsible for the editorial content of the document, making
sure it is easily readable and that deadlines are not missed.
Of course, the document editor can also contribute content,
and a document editor may request that a particular
point sent to him/her by a WG member be posted to the
list for discussion, if he/she thinks that the request requires
it.

Thus, the selection of draft-renker as a WG document for
paging doesn't mean that only Marco and his co-authors
get to contribute content. Everybody in the WG does, and
we really do need the co-operation of people with ideas
and perspectives on the problem, most especially the authors
of the other protocols. The current draft needs work,
as the assessment team report has indicated,
and Marco has indicated that he is ready to start taking
suggestions for improvement.

So, please, if you have suggestions for improvements,
send them to Marco or to the list for discussion.

                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 Jan 10 17:41: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 RAA25397
	for ; Thu, 10 Jan 2002 17:41: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 RAA18101;
	Thu, 10 Jan 2002 17:35: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 RAA18072
	for ; Thu, 10 Jan 2002 17:35: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 RAA25273
	for ; Thu, 10 Jan 2002 17:35:30 -0500 (EST)
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 g0AMb0Q25397
	for ; Thu, 10 Jan 2002 16:37:00 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 10 Jan 2002 16:35:30 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 10 Jan 2002 16:34:29 -0600
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR Discovery Requirements
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 10 Jan 2002 17:34:29 -0500
Message-ID: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcGaILNMafal+gYQEdaJYAAIx6TWpQABESIQ
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Phillip Neumiller'" ,
        "Govind Krishnamurthi" , 
Cc: "Krishnamurthi Govind (NRC/Boston)" 
X-OriginalArrivalTime: 10 Jan 2002 22:34:29.0996 (UTC) FILETIME=[F7CD82C0:01C19A26]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA18073
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 Phil,

comments inline

> I would like to see the following requirement added:
> 
> 1).  It MUST support IPv4 and IPv6, but may take advantage of features
>      in IPv6 that are not in IPv4.  For example anycast addressing may
>      be useful as well address autoconfiguration.

I can see the first part 'It MUST support IPv4 and IPv6' as a
requirement. 
I don't see the necessity for the rest of your comment. Either you
provide a 
solution that handles IPv4 and V6 in separate modules to fulfill said
first 
part of your requirement. Then I don't care that for the V6 part you're
using 
V6 features. Or you provide a combined solution which prohibits V6-only 
features since it would violate said first part.
In conclusion, only 'It MUST support IPv4 and IPv6' is a requirement we 
have to agree on.

> 
> 2).  It MUST provide a query (client server) and/or a post 
> (publish and
>      subscribe) method to allow other mobility protocols like 
> those being
>      worked on in the MIP and MANET WGs to cooperate with 
> this protocol.

Requirement 9 of the current list already states the independence of any
mobility management protocol. Why do you want to enforce specific
methods that have to be provided to ensure (from your point of view)
said independence? 
In conclusion, I think said requirement 9 is sufficient since it leave
more freedom for the actual solution.

Regards,




Dirk

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


From seamoby-admin@ietf.org  Thu Jan 10 18:56: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 SAA26410
	for ; Thu, 10 Jan 2002 18:56: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 SAA19652;
	Thu, 10 Jan 2002 18:49: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 SAA19625
	for ; Thu, 10 Jan 2002 18:49:42 -0500 (EST)
Received: from hotmail.com (f193.law9.hotmail.com [64.4.9.193])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26297
	for ; Thu, 10 Jan 2002 18:49:35 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 10 Jan 2002 15:49:08 -0800
Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP;
	Thu, 10 Jan 2002 23:49:07 GMT
X-Originating-IP: [63.78.179.5]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Thu, 10 Jan 2002 18:49:07 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 10 Jan 2002 23:49:08.0196 (UTC) FILETIME=[65049A40:01C19A31]
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 Phil,
Just adding to Dirk's comments, we do take care of this support for
IPv4 and IPv6 that you mention in the first point which says L2id to L3id 
(ARid) mapping is a MUST. The AR is an IP(v4 or v6) router.

Thanks,
Govind.
>
>Hi Phil,
>
>comments inline
>
> > I would like to see the following requirement added:
> >
> > 1).  It MUST support IPv4 and IPv6, but may take advantage of features
> >      in IPv6 that are not in IPv4.  For example anycast addressing may
> >      be useful as well address autoconfiguration.
>
>I can see the first part 'It MUST support IPv4 and IPv6' as a
>requirement.
>I don't see the necessity for the rest of your comment. Either you
>provide a
>solution that handles IPv4 and V6 in separate modules to fulfill said
>first
>part of your requirement. Then I don't care that for the V6 part you're
>using
>V6 features. Or you provide a combined solution which prohibits V6-only
>features since it would violate said first part.
>In conclusion, only 'It MUST support IPv4 and IPv6' is a requirement we
>have to agree on.
>
> >
> > 2).  It MUST provide a query (client server) and/or a post
> > (publish and
> >      subscribe) method to allow other mobility protocols like
> > those being
> >      worked on in the MIP and MANET WGs to cooperate with
> > this protocol.
>
>Requirement 9 of the current list already states the independence of any
>mobility management protocol. Why do you want to enforce specific
>methods that have to be provided to ensure (from your point of view)
>said independence?
>In conclusion, I think said requirement 9 is sufficient since it leave
>more freedom for the actual solution.
>
>Regards,
>
>
>
>
>Dirk
>
>_______________________________________________
>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  Thu Jan 10 19: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 TAA26818
	for ; Thu, 10 Jan 2002 19: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 TAA21391;
	Thu, 10 Jan 2002 19:49: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 TAA21363
	for ; Thu, 10 Jan 2002 19:49:32 -0500 (EST)
Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26791
	for ; Thu, 10 Jan 2002 19:49:30 -0500 (EST)
Received: (cpmta 15484 invoked from network); 10 Jan 2002 15:48:59 -0800
Received: from 65.187.225.53 (HELO Study)
  by smtp.directvinternet.com (209.228.33.219) with SMTP; 10 Jan 2002 15:48:59 -0800
X-Sent: 10 Jan 2002 23:48:59 GMT
Message-ID: <001501c19a31$72fd6a50$3502a8c0@Study>
From: "pdn \(N9FCW\) in FL" 
To: "Trossen Dirk \(NRC/Boston\)" ,
        "'ext Phillip Neumiller'" ,
        "Govind Krishnamurthi" , 
Cc: "Krishnamurthi Govind \(NRC/Boston\)" 
References: 
Subject: Re: [Seamoby] CAR Discovery Requirements
Date: Thu, 10 Jan 2002 18:49:30 -0500
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 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

This is just my opinion.

In my experience, interfaces between different protocols, are of crucial
importance in the  specifications stage.  If the goal is broad applicability
and inter-operability of whatever CAR becomes, we probably should
specify how information is pulled out of and put into CAR, i.e. the
interfaces, right?

Thanks!

Phil





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


From seamoby-admin@ietf.org  Fri Jan 11 08:13: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 IAA14097
	for ; Fri, 11 Jan 2002 08:13: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 HAA27986;
	Fri, 11 Jan 2002 07: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 HAA27957
	for ; Fri, 11 Jan 2002 07:34:35 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13647
	for ; Fri, 11 Jan 2002 07:34:29 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0BCYTJ01174
	for ; Fri, 11 Jan 2002 13:34:29 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jan 11 13:34:00 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 13:25:05 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1D8@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Trossen Dirk (NRC/Boston)'" ,
        "'ext Phillip Neumiller'" ,
        Govind Krishnamurthi , seamoby@ietf.org
Cc: "Krishnamurthi Govind (NRC/Boston)" 
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Fri, 11 Jan 2002 13:33:39 +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

  > > 
  > > 2).  It MUST provide a query (client server) and/or a post 
  > > (publish and
  > >      subscribe) method to allow other mobility protocols like 
  > > those being
  > >      worked on in the MIP and MANET WGs to cooperate with 
  > > this protocol.
  > 
  > Requirement 9 of the current list already states the 
  > independence of any
  > mobility management protocol. Why do you want to enforce specific
  > methods that have to be provided to ensure (from your point of view)
  > said independence? 
  > In conclusion, I think said requirement 9 is sufficient 
  > since it leave
  > more freedom for the actual solution.

=> I think it's important to be realistic, there is a 
difference between designing it _for_ MIP and MANET, 
and designing it to allow usage _with_ MIP and MANET. 
The latter is a minimum requirement IMO. Ignoring that
there are mobility protocols that should be used 
with the final solution, when the entire problem 
is mostly relevant to mobile devices, doesn't seem
realistic to me.

So I agree with Phil's comment.

Hesham
  > 
  > Regards,
  > 
  > 
  > 
  > 
  > Dirk
  > 
  > _______________________________________________
  > 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 Jan 11 10:51: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 KAA18670
	for ; Fri, 11 Jan 2002 10:51: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 KAA03095;
	Fri, 11 Jan 2002 10:35: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 KAA03067
	for ; Fri, 11 Jan 2002 10:35:14 -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 KAA18095
	for ; Fri, 11 Jan 2002 10:35:11 -0500 (EST)
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 g0BFagQ02982
	for ; Fri, 11 Jan 2002 09:36:42 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 11 Jan 2002 09:35:13 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 11 Jan 2002 09:35:13 -0600
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR Discovery Requirements
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 11 Jan 2002 10:35:12 -0500
Message-ID: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcGanFLk1ChfKgaMEdapbwBQi2kYTQAF3gxg
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Hesham Soliman (ERA)'" ,
        "ext Phillip Neumiller" ,
        "Govind Krishnamurthi" , 
Cc: "Krishnamurthi Govind (NRC/Boston)" 
X-OriginalArrivalTime: 11 Jan 2002 15:35:13.0506 (UTC) FILETIME=[8FC78420:01C19AB5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA03068
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 Hesham,

It's not quite clear to me what you propose. Do you want requirement 9,
i.e., the independence from the mobility mgt., to be removed or to be
changed
to a SHOULD requirement?
The said requirement 9 exactly states that the final solution should
be able to be used with ANY mobility mgt. protocol. It does not ignore
that CAR is used in the context of mobility.

My concern regarding Phil's comment was that he mentioned specific
methods to be mandatory in the final solution. I don't think it's a 
good idea to define specific methods as requirements since they
restrict the solution space. That was simply my comment. 

Regards,



Dirk
> -----Original Message-----
> From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
> Sent: Friday, January 11, 2002 7:34 AM
> To: Trossen Dirk (NRC/Boston); ext Phillip Neumiller; Govind
> Krishnamurthi; seamoby@ietf.org
> Cc: Krishnamurthi Govind (NRC/Boston)
> Subject: RE: [Seamoby] CAR Discovery Requirements
> 
> 
>   > > 
>   > > 2).  It MUST provide a query (client server) and/or a post 
>   > > (publish and
>   > >      subscribe) method to allow other mobility protocols like 
>   > > those being
>   > >      worked on in the MIP and MANET WGs to cooperate with 
>   > > this protocol.
>   > 
>   > Requirement 9 of the current list already states the 
>   > independence of any
>   > mobility management protocol. Why do you want to enforce specific
>   > methods that have to be provided to ensure (from your 
> point of view)
>   > said independence? 
>   > In conclusion, I think said requirement 9 is sufficient 
>   > since it leave
>   > more freedom for the actual solution.
> 
> => I think it's important to be realistic, there is a 
> difference between designing it _for_ MIP and MANET, 
> and designing it to allow usage _with_ MIP and MANET. 
> The latter is a minimum requirement IMO. Ignoring that
> there are mobility protocols that should be used 
> with the final solution, when the entire problem 
> is mostly relevant to mobile devices, doesn't seem
> realistic to me.
> 
> So I agree with Phil's comment.
> 
> Hesham
>   > 
>   > Regards,
>   > 
>   > 
>   > 
>   > 
>   > Dirk
>   > 
>   > _______________________________________________
>   > 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 Jan 11 11:03: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 LAA19242
	for ; Fri, 11 Jan 2002 11:03: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 KAA03348;
	Fri, 11 Jan 2002 10:49: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 KAA03318
	for ; Fri, 11 Jan 2002 10:48:59 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18533
	for ; Fri, 11 Jan 2002 10:48:56 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0BFmvJ16781
	for ; Fri, 11 Jan 2002 16:48:57 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Jan 11 16:48:40 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 16:40:01 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1DF@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Trossen Dirk (NRC/Boston)'" ,
        "Hesham Soliman (ERA)" ,
        ext Phillip Neumiller ,
        Govind Krishnamurthi
	 , seamoby@ietf.org
Cc: "Krishnamurthi Govind (NRC/Boston)" 
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Fri, 11 Jan 2002 16:48:29 +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

Dirk,

  > It's not quite clear to me what you propose. Do you want 
  > requirement 9,
  > i.e., the independence from the mobility mgt., to be 
  > removed or to be
  > changed
  > to a SHOULD requirement?

=> No, I was suggesting that the solution must 
   accomodate the existing mobility solutions. 
   This maybe as simple as having hooks in it, 
   but might also require more work. So simply stating
   that it MUST accomodate the existing mobility 
   solutions, to me, means that when used with MIP/MANET,
   everything should work without losing any of the
   existing features in MIP or MANET protocols. 

   I hope this is clearer, you might want to change
   'accomodate' to a better word, I don't mean 
   this to be taken literally.

  > 
  > My concern regarding Phil's comment was that he mentioned specific
  > methods to be mandatory in the final solution. I don't think it's a 
  > good idea to define specific methods as requirements since they
  > restrict the solution space. That was simply my comment. 
  > 

=> I agree that the requirements should not mandate a 
certain way of solving the problem. So when I said 
I agree with Phil, I meant the first part of his comment, 
without actually specifying 'how to do it'.
Sorry for not making this clear.

  > Regards,
  > 
  > 
  > 
  > Dirk
  > > -----Original Message-----
  > > From: ext Hesham Soliman (ERA) 
[mailto:hesham.soliman@era.ericsson.se]
> Sent: Friday, January 11, 2002 7:34 AM
> To: Trossen Dirk (NRC/Boston); ext Phillip Neumiller; Govind
> Krishnamurthi; seamoby@ietf.org
> Cc: Krishnamurthi Govind (NRC/Boston)
> Subject: RE: [Seamoby] CAR Discovery Requirements
> 
> 
>   > > 
>   > > 2).  It MUST provide a query (client server) and/or a post 
>   > > (publish and
>   > >      subscribe) method to allow other mobility protocols like 
>   > > those being
>   > >      worked on in the MIP and MANET WGs to cooperate with 
>   > > this protocol.
>   > 
>   > Requirement 9 of the current list already states the 
>   > independence of any
>   > mobility management protocol. Why do you want to enforce specific
>   > methods that have to be provided to ensure (from your 
> point of view)
>   > said independence? 
>   > In conclusion, I think said requirement 9 is sufficient 
>   > since it leave
>   > more freedom for the actual solution.
> 
> => I think it's important to be realistic, there is a 
> difference between designing it _for_ MIP and MANET, 
> and designing it to allow usage _with_ MIP and MANET. 
> The latter is a minimum requirement IMO. Ignoring that
> there are mobility protocols that should be used 
> with the final solution, when the entire problem 
> is mostly relevant to mobile devices, doesn't seem
> realistic to me.
> 
> So I agree with Phil's comment.
> 
> Hesham
>   > 
>   > Regards,
>   > 
>   > 
>   > 
>   > 
>   > Dirk
>   > 
>   > _______________________________________________
>   > 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 Jan 11 11:05: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 LAA19313
	for ; Fri, 11 Jan 2002 11:05: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 KAA03583;
	Fri, 11 Jan 2002 10:53: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 KAA03552
	for ; Fri, 11 Jan 2002 10:53:45 -0500 (EST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18778
	for ; Fri, 11 Jan 2002 10:53:42 -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 g0BFr2k18376
	for ; Fri, 11 Jan 2002 16:53:02 +0100 (MET)
Message-ID: <3C3F0AC6.C064979@inrialpes.fr>
Date: Fri, 11 Jan 2002 16:54:46 +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
To: seamoby@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] IP paging question
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,

I have a question concerning IP paging:

What will be the order of magnitude of the "dormant mode timer"
i.e. the time a host waits before making a dormant mode registration
(when it is not in active communication).

I'm not asking (of course) for an exact value. It will be in
milliseconds or seconds?

I would say in milliseconds, or "register as quickly as possible" but
I'm not sure.

Thanks in advance for your help.

Regards,
pars



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


From seamoby-admin@ietf.org  Fri Jan 11 11:09: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 LAA19497
	for ; Fri, 11 Jan 2002 11:09: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 KAA03659;
	Fri, 11 Jan 2002 10:55: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 KAA03628
	for ; Fri, 11 Jan 2002 10:55:34 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18831
	for ; Fri, 11 Jan 2002 10:55:31 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0BFtXJ20935
	for ; Fri, 11 Jan 2002 16:55:33 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Jan 11 16:54:51 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 16:46:12 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1E1@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Vijay Devarapalli'" ,
        "Trossen Dirk (NRC/Boston)" 
Cc: Govind Krishnamurthi , seamoby@ietf.org
Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...
Date: Fri, 11 Jan 2002 16:54:49 +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

[reply for a very old mail]


  > can you make IKE create an SA between two nodes (one having
  > a public address and another having a private address)?

=> Yes you can. There are IKE extensions for this.

I'm obviously not interested in anything involving
private addresses, but your point is incorrect.

Hesham

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


From seamoby-admin@ietf.org  Fri Jan 11 11:10: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 LAA19540
	for ; Fri, 11 Jan 2002 11:10: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 KAA03810;
	Fri, 11 Jan 2002 10:59: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 KAA03781
	for ; Fri, 11 Jan 2002 10:59:19 -0500 (EST)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19000
	for ; Fri, 11 Jan 2002 10:59:16 -0500 (EST)
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 10:59:14 -0500
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048616681@meshpdc.meshnetworks.com>
From: Phillip Neumiller 
To: "'Hesham Soliman (ERA)'" ,
        "'Trossen Dirk (NRC/Boston)'" ,
        Phillip Neumiller
	 ,
        Govind Krishnamurthi , seamoby@ietf.org
Cc: "Krishnamurthi Govind (NRC/Boston)" 
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Fri, 11 Jan 2002 10:59:12 -0500
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

Hi Hesham and Trossen,

We seem to dance around in abstract space a lot in this WG.  Isn't it time
to get down to brass tacks?  MIP has an implied architecture and it is not
going away.  Neither are many of the MANET protocols.  What ever happened
to the "running code" idea anyway?  I don't see why we have to be so
very vague (which is occuring strictly to be pedantic about requirement-
speak).  There is an old adage that states if its not "testable" its not
a requirement.  This WG seems to have adopted the opposite approach, i.e.
if its "testable" it can't be a requirement because it isn't vague enough.

Best regards,

Phil
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 

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


From seamoby-admin@ietf.org  Fri Jan 11 11:30: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 LAA20380
	for ; Fri, 11 Jan 2002 11:30: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 LAA04649;
	Fri, 11 Jan 2002 11:18: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 LAA04620
	for ; Fri, 11 Jan 2002 11:18:42 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19945
	for ; Fri, 11 Jan 2002 11:18:39 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0BGIfJ07138
	for ; Fri, 11 Jan 2002 17:18:41 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Jan 11 17:18:24 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 17:18:40 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1E2@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Phillip Neumiller'" ,
        "Hesham Soliman (ERA)" ,
        "'Trossen Dirk (NRC/Boston)'" ,
        Govind Krishnamurthi , seamoby@ietf.org
Cc: "Krishnamurthi Govind (NRC/Boston)" 
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Fri, 11 Jan 2002 17:18:18 +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

Phil,

  > We seem to dance around in abstract space a lot in this WG. 

=> Really ! :)

  >  Isn't it time
  > to get down to brass tacks?  MIP has an implied 
  > architecture and it is not
  > going away.  Neither are many of the MANET protocols.  What 
  > ever happened
  > to the "running code" idea anyway?  I don't see why we have to be so
  > very vague (which is occuring strictly to be pedantic about 
  > requirement-
  > speak).  There is an old adage that states if its not 
  > "testable" its not
  > a requirement.  

=> I agree, we should have clear and 'easy to test'
requirements. I was only explaining in generic terms
that requirements should not mandate solutions. In  this
particular case, all I care about is that no optimisations
or features of existing MIP/MANET stuff is lost.
I don't care how it's done.

Hesham


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


From seamoby-admin@ietf.org  Fri Jan 11 11:53: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 LAA21301
	for ; Fri, 11 Jan 2002 11:53: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 LAA05963;
	Fri, 11 Jan 2002 11:41: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 LAA05929
	for ; Fri, 11 Jan 2002 11:41:51 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20893
	for ; Fri, 11 Jan 2002 11:41:48 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g0BGfoJ18805
	for ; Fri, 11 Jan 2002 17:41:50 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jan 11 17:41:49 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 17:32:54 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1E4@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Govind Krishnamurthi'" , seamoby@ietf.org
Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...
Date: Fri, 11 Jan 2002 17:41:32 +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

Govind and all, 

Some comments below.

Generally I think it would be useful to identify
which protocol these requirements apply to. 
I.e. the protocol between the ARs or the one between
the MN and the AR?



  > >
  > >1. MUST translate L2 Ids (APs and ARs) to L3 Ids of ARs
  > >
  > >
  > >2. MUST support L2 devices of different technologies

=> What does this really mean ?

  > >
  > >6. Protocol applicability - SHOULD (show of hands 
  > indicated that a MUST
  > >is needed here) support inter-domain as well as Intra-domain scope
  > >

=> Definitely a MUST IMO. Also we should be clear on the 
meaning of 'domain'.

  > >8. SHOULD minimize involvement of ARs which are not GAARs in CAR
  > >discovery

=> Going to Phil's comment, how do we measure a SHOULD ?
What tradeoffs will be acceptable to exempt a solution
from following this requirement? 
I think it would be esaier to make it a MUST.

I'd like to also suggest that if the WG still wants to
keep section 4.1 of the problem statement draft, we 
should at least change the wording in the first
paragraph to reflect that the AR will _never_ 
guarantee to know _all_ neighbouring ARs. 
I think this is obvious. 

Also 'anticipation' is misleading, because it is seems
to imply that the MN does not signal. The MN can
certainly anticipate and that is explained in the 
low latency and FMIPv6 drafts referenced in the doc.

Regs,
Hesham 

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


From seamoby-admin@ietf.org  Fri Jan 11 11:56: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 LAA21385
	for ; Fri, 11 Jan 2002 11:56: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 LAA06128;
	Fri, 11 Jan 2002 11:45: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 LAA06090
	for ; Fri, 11 Jan 2002 11:45:26 -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 LAA21071
	for ; Fri, 11 Jan 2002 11:45:23 -0500 (EST)
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 g0BGktQ11758
	for ; Fri, 11 Jan 2002 10:46:55 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 11 Jan 2002 10:45:22 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 11 Jan 2002 10:45:22 -0600
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR Discovery Requirements
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 11 Jan 2002 11:45:21 -0500
Message-ID: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcGau63HRZH/ZwasEdaxMgAIx6TWeAAAvYrQ
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Hesham Soliman (ERA)'" ,
        "Phillip Neumiller" ,
        "Govind Krishnamurthi" , 
Cc: "Krishnamurthi Govind (NRC/Boston)" 
X-OriginalArrivalTime: 11 Jan 2002 16:45:22.0720 (UTC) FILETIME=[5CAA9A00:01C19ABF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA06091
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 Phil and Hesham,

some comments:
- requirements shouldn't mandate certain solutions. What Phil proposed
was to make certain solutions mandatory. This is not about being vague
or not. This is retricting the solutions (maybe for a certain reason).

- making the 'usage' or 'accomodation' of mobility management features
a MUST restricts the solution space, too. Is a solution prohibited, only

because it does not rely on certain mobility management features, even
if
the solution might be easier?

Regards,



Dirk

> -----Original Message-----
> From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
> Sent: Friday, January 11, 2002 11:18 AM
> To: Phillip Neumiller; Hesham Soliman (ERA); Trossen Dirk 
> (NRC/Boston);
> Govind Krishnamurthi; seamoby@ietf.org
> Cc: Krishnamurthi Govind (NRC/Boston)
> Subject: RE: [Seamoby] CAR Discovery Requirements
> 
> 
> Phil,
> 
>   > We seem to dance around in abstract space a lot in this WG. 
> 
> => Really ! :)
> 
>   >  Isn't it time
>   > to get down to brass tacks?  MIP has an implied 
>   > architecture and it is not
>   > going away.  Neither are many of the MANET protocols.  What 
>   > ever happened
>   > to the "running code" idea anyway?  I don't see why we 
> have to be so
>   > very vague (which is occuring strictly to be pedantic about 
>   > requirement-
>   > speak).  There is an old adage that states if its not 
>   > "testable" its not
>   > a requirement.  
> 
> => I agree, we should have clear and 'easy to test'
> requirements. I was only explaining in generic terms
> that requirements should not mandate solutions. In  this
> particular case, all I care about is that no optimisations
> or features of existing MIP/MANET stuff is lost.
> I don't care how it's done.
> 
> Hesham
> 
> 
> _______________________________________________
> 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 Jan 11 12:01: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 MAA21549
	for ; Fri, 11 Jan 2002 12:01: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 LAA06271;
	Fri, 11 Jan 2002 11:50: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 LAA06243
	for ; Fri, 11 Jan 2002 11:50:13 -0500 (EST)
Received: from hotmail.com (f15.law9.hotmail.com [64.4.9.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21228
	for ; Fri, 11 Jan 2002 11:50:09 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 11 Jan 2002 08:49:42 -0800
Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP;
	Fri, 11 Jan 2002 16:49:42 GMT
X-Originating-IP: [63.78.179.4]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Fri, 11 Jan 2002 11:49:42 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 11 Jan 2002 16:49:42.0687 (UTC) FILETIME=[F79E6AF0:01C19ABF]
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 Hesham,
Just for clarification. Is there an inherent assumption in your
statement that CAR discovery will need assistance from mobility management 
protocols. My understanding is that in Seamoby we don't
restrict only to MIP. Also by making it independent of mobility management 
protocols  we clearly don't affect any of the features of the underlying 
mobility management protocol is that not? Or am I missing something here.
-Govind.



>
>Phil,
>
>   > We seem to dance around in abstract space a lot in this WG.
>
>=> Really ! :)
>
>   >  Isn't it time
>   > to get down to brass tacks?  MIP has an implied
>   > architecture and it is not
>   > going away.  Neither are many of the MANET protocols.  What
   > ever happened
>   > to the "running code" idea anyway?  I don't see why we have to be so
>   > very vague (which is occuring strictly to be pedantic about
>   > requirement-
>   > speak).  There is an old adage that states if its not
>   > "testable" its not
>   > a requirement.
>
>=> I agree, we should have clear and 'easy to test'
>requirements. I was only explaining in generic terms
>that requirements should not mandate solutions. In  this
>particular case, all I care about is that no optimisations
>or features of existing MIP/MANET stuff is lost.
>I don't care how it's done.
>
>Hesham
>
>
>_______________________________________________
>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  Fri Jan 11 12:28: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 MAA22494
	for ; Fri, 11 Jan 2002 12:28: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 MAA07871;
	Fri, 11 Jan 2002 12:17: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 MAA07841
	for ; Fri, 11 Jan 2002 12:17:49 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22071
	for ; Fri, 11 Jan 2002 12:17:45 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0BHH9S07783;
	Fri, 11 Jan 2002 09:17:09 -0800 (PST)
Message-ID: <006401c19ac3$9425a5c0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Pars MUTAF" , 
References: <3C3F0AC6.C064979@inrialpes.fr>
Subject: Re: [Seamoby] IP paging question
Date: Fri, 11 Jan 2002 09:15: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

Pars,

This sounds like a policy issue to me. I think it should
be configurable but the spec should provide a
suggested default. 

As to what that default is, good question.

            jak

----- Original Message ----- 
From: "Pars MUTAF" 
To: 
Sent: Friday, January 11, 2002 7:54 AM
Subject: [Seamoby] IP paging question


> 
> 
> Hello,
> 
> I have a question concerning IP paging:
> 
> What will be the order of magnitude of the "dormant mode timer"
> i.e. the time a host waits before making a dormant mode registration
> (when it is not in active communication).
> 
> I'm not asking (of course) for an exact value. It will be in
> milliseconds or seconds?
> 
> I would say in milliseconds, or "register as quickly as possible" but
> I'm not sure.
> 
> Thanks in advance for your help.
> 
> 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  Fri Jan 11 12: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 MAA22815
	for ; Fri, 11 Jan 2002 12:35: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 MAA08106;
	Fri, 11 Jan 2002 12:24: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 MAA08080
	for ; Fri, 11 Jan 2002 12:24:53 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22348
	for ; Fri, 11 Jan 2002 12:24:49 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0BHOJS08026;
	Fri, 11 Jan 2002 09:24:19 -0800 (PST)
Message-ID: <009301c19ac4$9479ead0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Hesham Soliman \(ERA\)" ,
        "'Govind Krishnamurthi'" , 
References: <4DA6EA82906FD511BE2F00508BCF053801C4C1E4@Esealnt861.al.sw.ericsson.se>
Subject: Re: [Seamoby] CAR DiscoveryProtocol Requirements...
Date: Fri, 11 Jan 2002 09:22:43 -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,

The problem statement discusses a need for both, so we need requirements
for both.

I agree that it would be useful to distinguish if the requrirements
apply
to one or the other or both.

            jak

----- Original Message -----
From: "Hesham Soliman (ERA)" 
To: "'Govind Krishnamurthi'" ; 
Sent: Friday, January 11, 2002 8:41 AM
Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...


> Govind and all,
>
> Some comments below.
>
> Generally I think it would be useful to identify
> which protocol these requirements apply to.
> I.e. the protocol between the ARs or the one between
> the MN and the AR?
>
>
>
>   > >
>   > >1. MUST translate L2 Ids (APs and ARs) to L3 Ids of ARs
>   > >
>   > >
>   > >2. MUST support L2 devices of different technologies
>
> => What does this really mean ?
>
>   > >
>   > >6. Protocol applicability - SHOULD (show of hands
>   > indicated that a MUST
>   > >is needed here) support inter-domain as well as Intra-domain
scope
>   > >
>
> => Definitely a MUST IMO. Also we should be clear on the
> meaning of 'domain'.
>
>   > >8. SHOULD minimize involvement of ARs which are not GAARs in CAR
>   > >discovery
>
> => Going to Phil's comment, how do we measure a SHOULD ?
> What tradeoffs will be acceptable to exempt a solution
> from following this requirement?
> I think it would be esaier to make it a MUST.
>
> I'd like to also suggest that if the WG still wants to
> keep section 4.1 of the problem statement draft, we
> should at least change the wording in the first
> paragraph to reflect that the AR will _never_
> guarantee to know _all_ neighbouring ARs.
> I think this is obvious.
>
> Also 'anticipation' is misleading, because it is seems
> to imply that the MN does not signal. The MN can
> certainly anticipate and that is explained in the
> low latency and FMIPv6 drafts referenced in the doc.
>
> Regs,
> Hesham
>
> _______________________________________________
> 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 Jan 11 12:41: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 MAA23008
	for ; Fri, 11 Jan 2002 12:41: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 MAA08318;
	Fri, 11 Jan 2002 12:29: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 MAA08293
	for ; Fri, 11 Jan 2002 12:29:37 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22516
	for ; Fri, 11 Jan 2002 12:29:32 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0BHTZK08402
	for ; Fri, 11 Jan 2002 18:29:35 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jan 11 18:29:34 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 18:20:39 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1E5@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Trossen Dirk (NRC/Boston)'" ,
        "Hesham Soliman (ERA)" ,
        Phillip Neumiller ,
        Govind Krishnamurthi
	 , seamoby@ietf.org
Cc: "Krishnamurthi Govind (NRC/Boston)" 
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Fri, 11 Jan 2002 18:29:13 +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

  > some comments:
  > - requirements shouldn't mandate certain solutions. What 
  > Phil proposed
  > was to make certain solutions mandatory. This is not about 
  > being vague
  > or not. This is retricting the solutions (maybe for a 
  > certain reason).
  > 
  > - making the 'usage' or 'accomodation' of mobility 
  > management features
  > a MUST restricts the solution space, too. Is a solution 
  > prohibited, only
  > 
  > because it does not rely on certain mobility management 
  > features, even
  > if
  > the solution might be easier?

=> If we're designing things to be used, then yes
you have to be compatible with existing (very related)
protocols. What's the point of this work if it breaks
mobility management as we know it today ? 
This should not be seen as a pure research exercise
IMO, we need to design useable products. 

I'm not ruling out any new features or trying to make
it work with MIP only, I'm saying don't break the 
existing solutions. 

I think this is a pretty straight forward request
and we shouldn't dwell on it too much

Hesham




  > 
  > Regards,
  > 
  > 
  > 
  > Dirk
  > 
  > > -----Original Message-----
  > > From: ext Hesham Soliman (ERA) 
[mailto:hesham.soliman@era.ericsson.se]
> Sent: Friday, January 11, 2002 11:18 AM
> To: Phillip Neumiller; Hesham Soliman (ERA); Trossen Dirk 
> (NRC/Boston);
> Govind Krishnamurthi; seamoby@ietf.org
> Cc: Krishnamurthi Govind (NRC/Boston)
> Subject: RE: [Seamoby] CAR Discovery Requirements
> 
> 
> Phil,
> 
>   > We seem to dance around in abstract space a lot in this WG. 
> 
> => Really ! :)
> 
>   >  Isn't it time
>   > to get down to brass tacks?  MIP has an implied 
>   > architecture and it is not
>   > going away.  Neither are many of the MANET protocols.  What 
>   > ever happened
>   > to the "running code" idea anyway?  I don't see why we 
> have to be so
>   > very vague (which is occuring strictly to be pedantic about 
>   > requirement-
>   > speak).  There is an old adage that states if its not 
>   > "testable" its not
>   > a requirement.  
> 
> => I agree, we should have clear and 'easy to test'
> requirements. I was only explaining in generic terms
> that requirements should not mandate solutions. In  this
> particular case, all I care about is that no optimisations
> or features of existing MIP/MANET stuff is lost.
> I don't care how it's done.
> 
> Hesham
> 
> 
> _______________________________________________
> 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 Jan 11 12:53: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 MAA23389
	for ; Fri, 11 Jan 2002 12:53: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 MAA09046;
	Fri, 11 Jan 2002 12:42: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 MAA09015
	for ; Fri, 11 Jan 2002 12:42:38 -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 MAA23036
	for ; Fri, 11 Jan 2002 12:42:36 -0500 (EST)
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 g0BHglQ25075
	for ; Fri, 11 Jan 2002 11:42:47 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 11 Jan 2002 11:42:37 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 11 Jan 2002 11:42:36 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 11 Jan 2002 12:42:36 -0500
Message-ID: 
Thread-Topic: [Seamoby] CAR DiscoveryProtocol Requirements...
Thread-Index: AcGavuk055NOwAaxEdapbwBQi2kYTQAAHYVg
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Hesham Soliman (ERA)'" ,
        "Govind Krishnamurthi" , 
X-OriginalArrivalTime: 11 Jan 2002 17:42:36.0979 (UTC) FILETIME=[5BA4F030:01C19AC7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA09016
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 Hesham, 

some comments inline

> -----Original Message-----
> From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
> Sent: Friday, January 11, 2002 11:42 AM
> To: Govind Krishnamurthi; seamoby@ietf.org
> Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...
> 
> 
> Govind and all, 
> 
> Some comments below.
> 
> Generally I think it would be useful to identify
> which protocol these requirements apply to. 
> I.e. the protocol between the ARs or the one between
> the MN and the AR?
> 
> 
> 
>   > >
>   > >1. MUST translate L2 Ids (APs and ARs) to L3 Ids of ARs
>   > >
>   > >
>   > >2. MUST support L2 devices of different technologies
> 
> => What does this really mean ?

Having an AP in WLAN and Bluetooth and being able to discover
both.

> 
>   > >
>   > >6. Protocol applicability - SHOULD (show of hands 
>   > indicated that a MUST
>   > >is needed here) support inter-domain as well as 
> Intra-domain scope
>   > >
> 
> => Definitely a MUST IMO. Also we should be clear on the 
> meaning of 'domain'.

I agree with the MUST. Clarification of domain is certainly 
helpful.

> 
>   > >8. SHOULD minimize involvement of ARs which are not GAARs in CAR
>   > >discovery
> 
> => Going to Phil's comment, how do we measure a SHOULD ?
> What tradeoffs will be acceptable to exempt a solution
> from following this requirement? 
> I think it would be esaier to make it a MUST.

This minimization has to be seen compared to other protocols in
the first place. If there is a solution that does not at all involve
non-GAARs, the minimization is certainly optimized. The other
extreme would be a general flooding of the entire Internet to
resolve the L2 identifier. In between these extremes (including
them), the solutions will exist, and they have to be evaluated
against this requirement.

The SHOULD has been used since it wasn't clear if such kind of
evaluation for the selection of the final solution should be
mandatory or not. Personally, I prefer the MUST, too since I'd like
to see a final solution that minimizes involvement of non-GAARs.

> 
> I'd like to also suggest that if the WG still wants to
> keep section 4.1 of the problem statement draft, we 
> should at least change the wording in the first
> paragraph to reflect that the AR will _never_ 
> guarantee to know _all_ neighbouring ARs. 
> I think this is obvious. 

The wording in Section 4.1. doesn't imply that CAR guarantees
the knowledge of ALL GAARs. The wording has to be seen at the
point of TAR selection. For that, only the current status of 
knowledge regarding the GAARs is taken into account. 

It is obvious that CAR does not guarantee full knowledge, but it has 
at least to maximize the information regarding the GAARs with its
optimal
point of operation, i.e., the knowledge of all GAARs, though 
this optimal point might never be reached. But a solution that
at least enables to reach this point in a finite time is certainly
better than a mechanism that never reaches this point. Example
for the latter would be solution that were entirely be based on one
mobility management protocol. This solution could never 
discover GAARs that are using another mobility management protocol. 

> 
> Also 'anticipation' is misleading, because it is seems
> to imply that the MN does not signal. The MN can
> certainly anticipate and that is explained in the 
> low latency and FMIPv6 drafts referenced in the doc.

I don't see the problem of excluding MN signaling by using
the word 'anticipation'. Could you point out which wording
you don't like?

Regards,



Dirk

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


From seamoby-admin@ietf.org  Fri Jan 11 12:56: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 MAA23536
	for ; Fri, 11 Jan 2002 12:56: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 MAA09208;
	Fri, 11 Jan 2002 12: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 MAA09177
	for ; Fri, 11 Jan 2002 12:45:47 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23126
	for ; Fri, 11 Jan 2002 12:45:45 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0BHjkJ13488
	for ; Fri, 11 Jan 2002 18:45:46 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Jan 11 18:45:29 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 18:36:50 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1E6@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Govind Krishnamurthi'" 
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Fri, 11 Jan 2002 18:45:27 +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

Hi Govind, 

Sure you could use CAR without any mobility 
management, but I think that it is reasonable
to assume that CAR will also be very useful for 
MNs. If you agree with that, then it would sense
to make sure that it certainly works smoothly
with existing solutions, that will most likely
be around for a long time. 

Again, I' not suggesting we integrate CAR into
MIP, just make sure they work well together.

Hesham

  > -----Original Message-----
  > From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
  > Sent: Friday, January 11, 2002 5:49 PM
  > To: hesham.soliman@era.ericsson.se
  > Subject: RE: [Seamoby] CAR Discovery Requirements
  > 
  > 
  > Hello Hesham,
  > Just for clarification. Is there an inherent assumption in your
  > statement that CAR discovery will need assistance from 
  > mobility management 
  > protocols. My understanding is that in Seamoby we don't
  > restrict only to MIP. Also by making it independent of 
  > mobility management 
  > protocols  we clearly don't affect any of the features of 
  > the underlying 
  > mobility management protocol is that not? Or am I missing 
  > something here.
  > -Govind.
  > 
  > 
  > 
  > >
  > >Phil,
  > >
  > >   > We seem to dance around in abstract space a lot in this WG.
  > >
  > >=> Really ! :)
  > >
  > >   >  Isn't it time
  > >   > to get down to brass tacks?  MIP has an implied
  > >   > architecture and it is not
  > >   > going away.  Neither are many of the MANET protocols.  What
  >    > ever happened
  > >   > to the "running code" idea anyway?  I don't see why 
  > we have to be so
  > >   > very vague (which is occuring strictly to be pedantic about
  > >   > requirement-
  > >   > speak).  There is an old adage that states if its not
  > >   > "testable" its not
  > >   > a requirement.
  > >
  > >=> I agree, we should have clear and 'easy to test'
  > >requirements. I was only explaining in generic terms
  > >that requirements should not mandate solutions. In  this
  > >particular case, all I care about is that no optimisations
  > >or features of existing MIP/MANET stuff is lost.
  > >I don't care how it's done.
  > >
  > >Hesham
  > >
  > >
  > >_______________________________________________
  > >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  Fri Jan 11 12: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 MAA23630
	for ; Fri, 11 Jan 2002 12: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 MAA09326;
	Fri, 11 Jan 2002 12:47: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 MAA09295
	for ; Fri, 11 Jan 2002 12:47:27 -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 MAA23204
	for ; Fri, 11 Jan 2002 12:47:23 -0500 (EST)
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 g0BHmnQ19209
	for ; Fri, 11 Jan 2002 11:48:49 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 11 Jan 2002 11:47:20 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 11 Jan 2002 11:47:20 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR Discovery Requirements
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 11 Jan 2002 12:47:19 -0500
Message-ID: 
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcGaxZH9QqkHwQa4EdaJYAAIx6TWpQAAfS5g
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Hesham Soliman (ERA)'" ,
        "Phillip Neumiller" ,
        "Govind Krishnamurthi" , 
Cc: "Krishnamurthi Govind (NRC/Boston)" 
X-OriginalArrivalTime: 11 Jan 2002 17:47:20.0482 (UTC) FILETIME=[04A01020:01C19AC8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA09296
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 Hesham,

> => If we're designing things to be used, then yes
> you have to be compatible with existing (very related)
> protocols. What's the point of this work if it breaks
> mobility management as we know it today ? 

I don't quite understand your problem. Not accomodating 
existing features does not necessarily means to break mobility 
management features. It certainly has to be compatible to existing
protocols, noone ever questioned that. However, making the
accomodation of existing features mandatory restricts the solution
space.

> I think this is a pretty straight forward request
> and we shouldn't dwell on it too much

I agree with both.

Regards,



Dirk

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


From seamoby-admin@ietf.org  Fri Jan 11 13: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 NAA23718
	for ; Fri, 11 Jan 2002 13:00: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 MAA09156;
	Fri, 11 Jan 2002 12:45: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 MAA09126
	for ; Fri, 11 Jan 2002 12:45:20 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23095
	for ; Fri, 11 Jan 2002 12:45:18 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0BHinS08807
	for ; Fri, 11 Jan 2002 09:44:49 -0800 (PST)
Message-ID: <00eb01c19ac7$7185d450$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Date: Fri, 11 Jan 2002 09:43:13 -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] Status of WG Last Call
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

WG Last call has expired on the following drafts:

1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
2) draft-ietf-seamoby-ct-reqs-02.txt
3) draft-ietf-seamoby-car-discovery-issues-01.txt
4) draft-ietf-seamoby-paging-protocol-assessment-00.txt

No comments were received on 1) and 3), they will now be sent to the
IESG for review.

On 3), one comment was received to remove 4 requirements, but there were
two opinions expressed
that the document should remain unchanged, so this document will be sent
to the IESG as is for
review.

On 4), a desire was expressed for some additional text describing the
decision process. This text
is currently undergoing review by the WG chairs and ADs for inclusion in
the document. An updated
document will be issued when the text is incorporated and another WG
last call will be scheduled.

                    jak




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


From seamoby-admin@ietf.org  Fri Jan 11 13:10: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 NAA24033
	for ; Fri, 11 Jan 2002 13:10: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 MAA09645;
	Fri, 11 Jan 2002 12:59: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 MAA09614
	for ; Fri, 11 Jan 2002 12:59:51 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23686
	for ; Fri, 11 Jan 2002 12:59:49 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0BHxoJ17192
	for ; Fri, 11 Jan 2002 18:59:50 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Jan 11 18:59:33 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 18:59:49 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1E8@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'James Kempf'" , seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Fri, 11 Jan 2002 18:59:31 +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

  > 
  > WG Last call has expired on the following drafts:
  > 
  > 1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
  > 2) draft-ietf-seamoby-ct-reqs-02.txt
  > 3) draft-ietf-seamoby-car-discovery-issues-01.txt
  > 4) draft-ietf-seamoby-paging-protocol-assessment-00.txt
  > 
  > No comments were received on 1) and 3), they will now be sent to the
  > IESG for review.

=> Just a minute, we _are_ discussing comments on 3).
I've also made these comments in London.

Hesham

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


From seamoby-admin@ietf.org  Fri Jan 11 13:10: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 NAA24044
	for ; Fri, 11 Jan 2002 13:10: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 MAA09553;
	Fri, 11 Jan 2002 12:58: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 MAA09523
	for ; Fri, 11 Jan 2002 12:58:03 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23621
	for ; Fri, 11 Jan 2002 12:58:01 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0BHw2K15243
	for ; Fri, 11 Jan 2002 18:58:02 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jan 11 18:58:01 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 18:58:01 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1E7@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Trossen Dirk (NRC/Boston)'" ,
        "Hesham Soliman (ERA)" ,
        Govind Krishnamurthi , seamoby@ietf.org
Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...
Date: Fri, 11 Jan 2002 18:57:44 +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

  > >   > >1. MUST translate L2 Ids (APs and ARs) to L3 Ids of ARs
  > >   > >
  > >   > >
  > >   > >2. MUST support L2 devices of different technologies
  > > 
  > > => What does this really mean ?
  > 
  > Having an AP in WLAN and Bluetooth and being able to discover
  > both.
  > 

=> OK. 

  > > 
  > >   > >8. SHOULD minimize involvement of ARs which are not 
  > GAARs in CAR
  > >   > >discovery
  > > 
  > > => Going to Phil's comment, how do we measure a SHOULD ?
  > > What tradeoffs will be acceptable to exempt a solution
  > > from following this requirement? 
  > > I think it would be esaier to make it a MUST.
  > 
  > This minimization has to be seen compared to other protocols in
  > the first place. If there is a solution that does not at all involve
  > non-GAARs, the minimization is certainly optimized. The other
  > extreme would be a general flooding of the entire Internet to
  > resolve the L2 identifier. In between these extremes (including
  > them), the solutions will exist, and they have to be evaluated
  > against this requirement.
  > 
  > The SHOULD has been used since it wasn't clear if such kind of
  > evaluation for the selection of the final solution should be
  > mandatory or not. Personally, I prefer the MUST, too since I'd like
  > to see a final solution that minimizes involvement of non-GAARs.
  > 
  > > 
  > > I'd like to also suggest that if the WG still wants to
  > > keep section 4.1 of the problem statement draft, we 
  > > should at least change the wording in the first
  > > paragraph to reflect that the AR will _never_ 
  > > guarantee to know _all_ neighbouring ARs. 
  > > I think this is obvious. 
  > 
  > The wording in Section 4.1. doesn't imply that CAR guarantees
  > the knowledge of ALL GAARs. The wording has to be seen at the
  > point of TAR selection. For that, only the current status of 
  > knowledge regarding the GAARs is taken into account. 

=> To me the following text from the draft suggests
that the AR knows ALL GAARs. I think that's unrealistic.

  4.1 Anticipated CAR Discovery

   In this approach, an AR currently serving the MN identifies all CARs
   for the MN's handoff, at some point prior to handoff.


  > 
  > It is obvious that CAR does not guarantee full knowledge, 
  > but it has 

=> So we agree, then I suggest you reflect it in the text.

  > at least to maximize the information regarding the GAARs with its
  > optimal
  > point of operation, i.e., the knowledge of all GAARs, though 
  > this optimal point might never be reached.

=> Surely the MN would be able to know about all ARs in its
coverage area, that is if it can see their RAs.


 But a solution that
  > at least enables to reach this point in a finite time is certainly
  > better than a mechanism that never reaches this point. Example
  > for the latter would be solution that were entirely be based on one
  > mobility management protocol. This solution could never 
  > discover GAARs that are using another mobility management protocol. 

=> You\re making a lot of assumptions about the discovery
mechanism. If a MN can hear RAs from different
GAARs, it will discover them. If that is not 
possible due to l2 limitations, there are ways to go
around that, without depending on any mobility
management protocol, but keeping in line with
existing protocols. 
I didn\t want to start arguing about solutions but
I think it can be done.

  > 
  > > 
  > > Also 'anticipation' is misleading, because it is seems
  > > to imply that the MN does not signal. The MN can
  > > certainly anticipate and that is explained in the 
  > > low latency and FMIPv6 drafts referenced in the doc.
  > 
  > I don't see the problem of excluding MN signaling by using
  > the word 'anticipation'. Could you point out which wording
  > you don't like?

=> anticipation should not be associated with the 
case where the MN does not signal, you can have
anticipation when the MN signals also. Therefore
associating 'anticipation' with a certain model
where the MN does not signal, does not seem right.

I'm referring to the title of ch 4.1

Regards,
Hesham

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


From seamoby-admin@ietf.org  Fri Jan 11 13: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 NAA24261
	for ; Fri, 11 Jan 2002 13:15: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 NAA10119;
	Fri, 11 Jan 2002 13:04: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 NAA10089
	for ; Fri, 11 Jan 2002 13:03:58 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23843
	for ; Fri, 11 Jan 2002 13:03:55 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0BI3uK16723
	for ; Fri, 11 Jan 2002 19:03:56 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jan 11 19:03:55 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 18:55:00 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1E9@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Trossen Dirk (NRC/Boston)'" ,
        "Hesham Soliman (ERA)" ,
        Phillip Neumiller ,
        Govind Krishnamurthi
	 , seamoby@ietf.org
Cc: "Krishnamurthi Govind (NRC/Boston)" 
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Fri, 11 Jan 2002 19:03:38 +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

  > > => If we're designing things to be used, then yes
  > > you have to be compatible with existing (very related)
  > > protocols. What's the point of this work if it breaks
  > > mobility management as we know it today ? 
  > 
  > I don't quite understand your problem. 

=> I don't have a problem. the requirement does.

Not accomodating 
  > existing features does not necessarily means to break mobility 
  > management features. It certainly has to be compatible to existing
  > protocols, noone ever questioned that. However, making the
  > accomodation of existing features mandatory restricts the solution
  > space.
  > 

=> This is getting confusing, you've just said 

'It certainly has to be compatible to existing ..'

then

'However, making the
  > accomodation of existing features mandatory restricts the solution
  > space.'

=> What are you saying ?


  > > I think this is a pretty straight forward request
  > > and we shouldn't dwell on it too much
  > 
  > I agree with both.

=> Great !

Hesham

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


From seamoby-admin@ietf.org  Fri Jan 11 13: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 NAA24558
	for ; Fri, 11 Jan 2002 13: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 NAA10380;
	Fri, 11 Jan 2002 13:13: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 NAA10351
	for ; Fri, 11 Jan 2002 13:13:31 -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 NAA24196
	for ; Fri, 11 Jan 2002 13:13:29 -0500 (EST)
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 g0BIDeQ27169
	for ; Fri, 11 Jan 2002 12:13:40 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 11 Jan 2002 12:13:30 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 11 Jan 2002 12:13:30 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 11 Jan 2002 13:13:29 -0500
Message-ID: 
Thread-Topic: [Seamoby] CAR DiscoveryProtocol Requirements...
Thread-Index: AcGayYt+fiV+GAa6Edar0gAIx6S5QwAAKmxQ
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Hesham Soliman (ERA)'" ,
        "Govind Krishnamurthi" , 
X-OriginalArrivalTime: 11 Jan 2002 18:13:30.0678 (UTC) FILETIME=[AC88F560:01C19ACB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA10352
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 Hesham,

comments inline

> 
> => To me the following text from the draft suggests
> that the AR knows ALL GAARs. I think that's unrealistic.
> 
>   4.1 Anticipated CAR Discovery
> 
>    In this approach, an AR currently serving the MN 
> identifies all CARs
>    for the MN's handoff, at some point prior to handoff.
> 
> 
>   > 
>   > It is obvious that CAR does not guarantee full knowledge, 
>   > but it has 
> 
> => So we agree, then I suggest you reflect it in the text.

As I outlined in my mail, the identification of CARs at the AR
is bound the current knowledge of GAARs at the AR. Out of this
set of GAARs, all CARs are identified. The text does not imply that
all GAARs are known.

> => You\re making a lot of assumptions about the discovery
> mechanism. If a MN can hear RAs from different
> GAARs, it will discover them. If that is not 
> possible due to l2 limitations, there are ways to go
> around that, without depending on any mobility
> management protocol, but keeping in line with
> existing protocols. 
> I didn\t want to start arguing about solutions but
> I think it can be done.

I don't understand your point here since I don't see the 'many
assumptions'
that I make. I'm trying to address requirements to solve the
problem. This is to identify GAARs under the constraint to minimize
the ARs that are actually not GAARs of the considered AR. I don't care
about MN involvement or not. This is not prohibited by the current set
of requirements, and I agree, it shouldn't. You should look at the basic
text of the requirements.

> => anticipation should not be associated with the 
> case where the MN does not signal, you can have
> anticipation when the MN signals also. Therefore
> associating 'anticipation' with a certain model
> where the MN does not signal, does not seem right.
> 
> I'm referring to the title of ch 4.1

I would appreciate if you could point out WHICH wording does imply
that MN signalling is ruled out in the anticipated approach. It is 
certainly not the title. 

Regards,



Dirk

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


From seamoby-admin@ietf.org  Fri Jan 11 13:25: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 NAA24584
	for ; Fri, 11 Jan 2002 13:25: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 NAA10457;
	Fri, 11 Jan 2002 13:14: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 NAA10421
	for ; Fri, 11 Jan 2002 13:14:53 -0500 (EST)
Received: from hotmail.com (f160.law9.hotmail.com [64.4.9.160])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24257
	for ; Fri, 11 Jan 2002 13:14:51 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 11 Jan 2002 10:14:14 -0800
Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP;
	Fri, 11 Jan 2002 18:14:14 GMT
X-Originating-IP: [63.78.179.4]
From: "Govind Krishnamurthi" 
To: hesham.soliman@era.ericsson.se
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Fri, 11 Jan 2002 13:14:14 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 11 Jan 2002 18:14:14.0631 (UTC) FILETIME=[C6BBA770:01C19ACB]
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 Hesham,
>Hi Govind,
>
>Sure you could use CAR without any mobility
>management, but I think that it is reasonable
>to assume that CAR will also be very useful for
>MNs.
----> I believe CAR discovery is for mobility and
therefore for MNs. So we have no disagreement here :).
What I said was that it may be possible for CAR discovery
to happen without any help from underlying mobility management protocols.

If you agree with that, then it would sense
>to make sure that it certainly works smoothly
>with existing solutions, that will most likely
>be around for a long time.
>
----> Agreed again and I think we are saying the same thing,
except that there seems to be confusion about how we put
it into words. IMO, working independently implies that
it does not depend on or impede any mobility management protocols.

>Again, I' not suggesting we integrate CAR into
>MIP, just make sure they work well together.
>
>Hesham
Regards,
Govind.
>
>   > -----Original Message-----
>   > From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
>   > Sent: Friday, January 11, 2002 5:49 PM
>   > To: hesham.soliman@era.ericsson.se
>   > Subject: RE: [Seamoby] CAR Discovery Requirements
>   >
>   >
>   > Hello Hesham,
>   > Just for clarification. Is there an inherent assumption in your
>   > statement that CAR discovery will need assistance from
>   > mobility management
>   > protocols. My understanding is that in Seamoby we don't
>   > restrict only to MIP. Also by making it independent of
>   > mobility management
>   > protocols  we clearly don't affect any of the features of
>   > the underlying
>   > mobility management protocol is that not? Or am I missing
>   > something here.
>   > -Govind.
>   >
>   >
>   >
>   > >
>   > >Phil,
>   > >
>   > >   > We seem to dance around in abstract space a lot in this WG.
>   > >
>   > >=> Really ! :)
>   > >
>   > >   >  Isn't it time
>   > >   > to get down to brass tacks?  MIP has an implied
>   > >   > architecture and it is not
>   > >   > going away.  Neither are many of the MANET protocols.  What
>   >    > ever happened
>   > >   > to the "running code" idea anyway?  I don't see why
>   > we have to be so
>   > >   > very vague (which is occuring strictly to be pedantic about
>   > >   > requirement-
>   > >   > speak).  There is an old adage that states if its not
>   > >   > "testable" its not
>   > >   > a requirement.
>   > >
>   > >=> I agree, we should have clear and 'easy to test'
>   > >requirements. I was only explaining in generic terms
>   > >that requirements should not mandate solutions. In  this
>   > >particular case, all I care about is that no optimisations
>   > >or features of existing MIP/MANET stuff is lost.
>   > >I don't care how it's done.
>   > >
>   > >Hesham
>   > >
>   > >
>   > >_______________________________________________
>   > >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




_________________________________________________________________
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  Fri Jan 11 13:30: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 NAA24744
	for ; Fri, 11 Jan 2002 13:30: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 NAA10570;
	Fri, 11 Jan 2002 13:18: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 NAA10536
	for ; Fri, 11 Jan 2002 13:18:29 -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 NAA24347
	for ; Fri, 11 Jan 2002 13:18:26 -0500 (EST)
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 g0BIIcQ27441
	for ; Fri, 11 Jan 2002 12:18:38 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 11 Jan 2002 12:18:21 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 11 Jan 2002 12:18:21 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR Discovery Requirements
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 11 Jan 2002 13:18:20 -0500
Message-ID: 
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcGayl6wRCPKYQa9Edar0gAIx6S5QwAAWosA
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Hesham Soliman (ERA)'" ,
        "Phillip Neumiller" ,
        "Govind Krishnamurthi" , 
Cc: "Krishnamurthi Govind (NRC/Boston)" 
X-OriginalArrivalTime: 11 Jan 2002 18:18:21.0260 (UTC) FILETIME=[59BC40C0:01C19ACC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA10537
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 Hesham,

maybe you should outline what you mean by 'accomodating features'.

Being compatible to existing mobility management solution means to
me not to break mobility management when introducing a specific
solution.

Accomodating features means to me to use specific features whereever
possible. 

These are two different things. The first one should be clear, I simply
don't like the second one since it restricts the solution space. That's 
where the discussion started by Phil's proposal to make specific methods

mandatory in any solution.

Regards,



Dirk

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


From seamoby-admin@ietf.org  Fri Jan 11 13:32: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 NAA24782
	for ; Fri, 11 Jan 2002 13:31: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 NAA10651;
	Fri, 11 Jan 2002 13:21: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 NAA10620
	for ; Fri, 11 Jan 2002 13:21:14 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24469
	for ; Fri, 11 Jan 2002 13:21:11 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0BIKfS10450;
	Fri, 11 Jan 2002 10:20:41 -0800 (PST)
Message-ID: <012101c19acc$73f163d0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Hesham Soliman \(ERA\)" ,
        
References: <4DA6EA82906FD511BE2F00508BCF053801C4C1E8@Esealnt861.al.sw.ericsson.se>
Subject: Re: [Seamoby] Status of WG Last Call
Date: Fri, 11 Jan 2002 10:19: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

Hesham,

The usual procedure for comments is that they be sent to the list. Any
Last
Call comments must be sent to the list in order that there be a record
of them. I don't recall any email from you on
draft-ietf-seamoby-car-discovery-issues-01.txt
during the last call period, but perhaps I missed it. If you have any
comments,
please send them out within the next day.

Also note that we are talking here about the problem statement, not the
requirements.
I have noted a thread over the last couple days on requirements, and
your comments, will
naturally be taken into account when the requirements draft is done.

                jak

----- Original Message -----
From: "Hesham Soliman (ERA)" 
To: "'James Kempf'" ; 
Sent: Friday, January 11, 2002 9:59 AM
Subject: RE: [Seamoby] Status of WG Last Call


>   >
>   > WG Last call has expired on the following drafts:
>   >
>   > 1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
>   > 2) draft-ietf-seamoby-ct-reqs-02.txt
>   > 3) draft-ietf-seamoby-car-discovery-issues-01.txt
>   > 4) draft-ietf-seamoby-paging-protocol-assessment-00.txt
>   >
>   > No comments were received on 1) and 3), they will now be sent to
the
>   > IESG for review.
>
> => Just a minute, we _are_ discussing comments on 3).
> I've also made these comments in London.
>
> Hesham
>


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


From seamoby-admin@ietf.org  Fri Jan 11 13:34: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 NAA24873
	for ; Fri, 11 Jan 2002 13:34: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 NAA10734;
	Fri, 11 Jan 2002 13:23: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 NAA10703
	for ; Fri, 11 Jan 2002 13:23:22 -0500 (EST)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24531
	for ; Fri, 11 Jan 2002 13:23:19 -0500 (EST)
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 13:23:14 -0500
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048616682@meshpdc.meshnetworks.com>
From: Phillip Neumiller 
To: "'Trossen Dirk (NRC/Boston)'" ,
        "'ext Hesham Soliman (ERA)'" ,
        Phillip Neumiller ,
        Govind Krishnamurthi
	 , seamoby@ietf.org
Cc: "Krishnamurthi Govind (NRC/Boston)" 
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Fri, 11 Jan 2002 13:23:12 -0500
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

Hi Dirk,

Perhaps we can compromise here and say that some particular set of 
specific methods MUST be supported as a minimum and not restrict at
all what goes on beyond this.  Lets be honest with ourselves here,
this protocol will be used by MIP and MANET protocols as their 
primary customers.  If not, then what customer does this requirement
serve?  Maybe I am dense on this, but I just don't get why we can't
specify the existance of an interface here?

Thanks,

Phil
> 
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 

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


From seamoby-admin@ietf.org  Fri Jan 11 13:35: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 NAA24977
	for ; Fri, 11 Jan 2002 13:35: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 NAA10844;
	Fri, 11 Jan 2002 13:25: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 NAA10799
	for ; Fri, 11 Jan 2002 13:24:56 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24568
	for ; Fri, 11 Jan 2002 13:24:54 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0BIOPS10603
	for ; Fri, 11 Jan 2002 10:24:25 -0800 (PST)
Message-ID: <012f01c19acc$f9a635f0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Date: Fri, 11 Jan 2002 10:22:49 -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
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

Since there seems to be some differing opinions about requirements
for CAR discovery, it seems appropriate to have a WG discussion
and record the results in a draft. We've requested that Govind be
editor for a requirements draft, and he is currently preparing a
draft based on the initial set of requirements that he presented
at SLC.

I think we should run the requirements discussion until perhaps
the end of Feb., so we can conclude requirements collection by
Minneapolis.
*By no means*, should this discussion drag out for longer. We do not
want to bog down and spend a year discussing requirements, as
was the case for CT. The interesting part is the protocol, the
sooner we can agree on a suitable set of requirements, the
sooner we can start discussing that.

            jak



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


From seamoby-admin@ietf.org  Fri Jan 11 13:48: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 NAA25335
	for ; Fri, 11 Jan 2002 13:48: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 NAA11478;
	Fri, 11 Jan 2002 13:35: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 NAA11446
	for ; Fri, 11 Jan 2002 13:35: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 NAA24973
	for ; Fri, 11 Jan 2002 13:35:38 -0500 (EST)
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 g0BIb8Q24583
	for ; Fri, 11 Jan 2002 12:37:08 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 11 Jan 2002 12:35:39 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 11 Jan 2002 12:35:39 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR Discovery Requirements
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 11 Jan 2002 13:35:38 -0500
Message-ID: 
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcGazQsZ48zmlga7EdaxMgAIx6TWeAAABa2w
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Phillip Neumiller'" ,
        "ext Hesham Soliman (ERA)" ,
        "Govind Krishnamurthi" , 
Cc: "Krishnamurthi Govind (NRC/Boston)" 
X-OriginalArrivalTime: 11 Jan 2002 18:35:39.0289 (UTC) FILETIME=[C472E890:01C19ACE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA11447
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 Phil,

> Perhaps we can compromise here and say that some particular set of 
> specific methods MUST be supported as a minimum and not restrict at
> all what goes on beyond this.  Lets be honest with ourselves here,
> this protocol will be used by MIP and MANET protocols as their 
> primary customers.  If not, then what customer does this requirement
> serve?  Maybe I am dense on this, but I just don't get why we can't
> specify the existance of an interface here?
> 
Maybe, there is some misunderstanding on my side what this interface
is about. 

Let's assume a final CAR discovery solution (however it'll work)
that provides the current AR with a set of GAARs and its associated
capabilities. Do you want to make the necessity mandatory to define
an interface to access this information for any (maybe mobility
management
dependend) subsequent actions, such as a policy server-based TAR
selection 
for the fast handover case?

Regards,


Dirk

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


From seamoby-admin@ietf.org  Fri Jan 11 13:49: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 NAA25411
	for ; Fri, 11 Jan 2002 13:49: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 NAA11580;
	Fri, 11 Jan 2002 13:38: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 NAA11551
	for ; Fri, 11 Jan 2002 13:38:22 -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 NAA25053
	for ; Fri, 11 Jan 2002 13:38:19 -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 KAA12435;
	Fri, 11 Jan 2002 10:37:51 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0BIbo400737;
	Fri, 11 Jan 2002 10:37:50 -0800
X-mProtect:  Fri, 11 Jan 2002 10:37:50 -0800 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdnCW6G5; Fri, 11 Jan 2002 10:37:48 PST
Message-ID: <3C3F30FD.E7AE8703@iprg.nokia.com>
Date: Fri, 11 Jan 2002 10:37:49 -0800
From: Vijay Devarapalli 
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hesham Soliman (ERA)" 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] CAR DiscoveryProtocol Requirements...
References: <4DA6EA82906FD511BE2F00508BCF053801C4C1E1@Esealnt861.al.sw.ericsson.se>
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

"Hesham Soliman (ERA)" wrote:
> 
> [reply for a very old mail]
> 
>   > can you make IKE create an SA between two nodes (one having
>   > a public address and another having a private address)?
> 
> => Yes you can. There are IKE extensions for this.

which RFC?? 

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

from Aboba's draft draft-ietf-ipsec-nat-reqts-00.txt

c) Incompatibility between IKE address identifiers and NAT.
   Where IP addresses are used as identifiers in IKE MM [7]
   or QM, modification of the IP source or destination
   addresses by NATs or reverse NATs will result in a
   mismatch between the identifiers and the addresses in the
   IP header. As described in [7], IKE implementations are
   required to discard such packets.

   In order to avoid use of IP addresses as IKE MM and QM identifiers,
   userIDs and FQDNs can be used instead. Where user authentication
   is desired, an ID type of ID_USER_FQDN can be used, as described in
   [5]. Where machine authentication is desired, an ID type of ID_FQDN
   can be used. In either case it is necessary to verify that the
   proposed identity matches that enclosed in the certificate.
   However, while use of USER_FQDN or FQDN identity types is possible
   within IKE, there are usage scenarios (e.g. SPD entries
   describing subnets) that cannot be accommodated this way.

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

However there are a couple of internet drafts in the IPSec WG
dealing with this. Hopefully they will have a solution soon.

If I am missing something, let me know.

Vijay


> I'm obviously not interested in anything involving
> private addresses, but your point is incorrect.
> 
> Hesham

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


From seamoby-admin@ietf.org  Fri Jan 11 14:03: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 OAA25945
	for ; Fri, 11 Jan 2002 14:03: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 NAA11851;
	Fri, 11 Jan 2002 13:52: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 NAA11822
	for ; Fri, 11 Jan 2002 13:51:59 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25465
	for ; Fri, 11 Jan 2002 13:51:57 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0BIpNS11655;
	Fri, 11 Jan 2002 10:51:23 -0800 (PST)
Message-ID: <016f01c19ad0$bdd5e030$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Hesham Soliman \(ERA\)" ,
        "'Trossen Dirk \(NRC/Boston\)'" ,
        "Govind Krishnamurthi" , 
References: <4DA6EA82906FD511BE2F00508BCF053801C4C1E7@Esealnt861.al.sw.ericsson.se>
Date: Fri, 11 Jan 2002 10:49:46 -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 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

Hesham,

OK, this sounds like some comments on
draft-ietf-seamoby-cardiscovery-issues-01.txt.

It certainly would have been helpful if you had posted your comments
during the Last Call period.
Last Call expired Jan. 4 on this document. I don't believe comments sent
in after
Last Call necessarily need to be accommodated, but, if these are simple
editorial changes that can be
 resolved in the next day or two, then I think we can accommodate them.
However, I do not want to get into a
 long discussion about requirements prior to releasing the problem
statement. If we can't resolve these
editorial issues by Tuesday, the draft will go to the IESG as it
currently stands.

Here are some suggestions about changes in the wording.

> => To me the following text from the draft suggests
> that the AR knows ALL GAARs. I think that's unrealistic.
>
>   4.1 Anticipated CAR Discovery
>
>    In this approach, an AR currently serving the MN identifies all
CARs
>    for the MN's handoff, at some point prior to handoff.
>

How about:

    In this approach, an AR currently serving the MN identifies some set
of
    suitable CARs for the MN's handoff, at some point prior to handoff.

If this text is unsatisfactory, please feel free to propose an
alternative.

> => anticipation should not be associated with the
> case where the MN does not signal, you can have
> anticipation when the MN signals also. Therefore
> associating 'anticipation' with a certain model
> where the MN does not signal, does not seem right.
>
> I'm referring to the title of ch 4.1
>

One of the problems with not having a consistent set
of terminology for wireless networking in the IETF
is that it becomes difficult to find a word that describes
the concept you are trying to get at without impinging
on what somebody else thinks a particular word
means. I believe this is the case here. The "anticipated"
here has nothing to do with "anticipated handover."
Here, the AR is anticipating the need for CARs
by performing discovery prior to the MN needing
them. The anticipation is exactly the same anticipation
as occurs for distribution of routing information prior
to a packet arriving at a router that requires that
routing information.

Perhaps another word would be suitable? Please
feel free to suggest one. Perhaps "router based"?

            jak


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


From seamoby-admin@ietf.org  Fri Jan 11 15: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 PAA29079
	for ; Fri, 11 Jan 2002 15:44: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 PAA14396;
	Fri, 11 Jan 2002 15:26: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 PAA14367
	for ; Fri, 11 Jan 2002 15:26:02 -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 PAA28284
	for ; Fri, 11 Jan 2002 15:25:58 -0500 (EST)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA19186 for ; Fri, 11 Jan 2002 13:25:59 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA02747 for ; Fri, 11 Jan 2002 13:25:58 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52)
	id ; Fri, 11 Jan 2002 14:25:58 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FD47@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'James Kempf'" , seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Fri, 11 Jan 2002 14:25:50 -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



-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Friday, January 11, 2002 11:43 AM
To: seamoby@ietf.org
Subject: [Seamoby] Status of WG Last Call


WG Last call has expired on the following drafts:

1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
2) draft-ietf-seamoby-ct-reqs-02.txt
3) draft-ietf-seamoby-car-discovery-issues-01.txt
4) draft-ietf-seamoby-paging-protocol-assessment-00.txt

No comments were received on 1) and 3), they will now be sent to the
IESG for review.



Madjid>> You mean 1) and 2), right?





On 3), one comment was received to remove 4 requirements, but there were
two opinions expressed
that the document should remain unchanged, so this document will be sent
to the IESG as is for
review.

On 4), a desire was expressed for some additional text describing the
decision process. This text
is currently undergoing review by the WG chairs and ADs for inclusion in
the document. An updated
document will be issued when the text is incorporated and another WG
last call will be scheduled.

                    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 Jan 11 16:14: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 QAA29852
	for ; Fri, 11 Jan 2002 16:14: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 QAA15930;
	Fri, 11 Jan 2002 16:03: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 QAA15899
	for ; Fri, 11 Jan 2002 16:03:35 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29508
	for ; Fri, 11 Jan 2002 16:03:31 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0BL31S17087;
	Fri, 11 Jan 2002 13:03:01 -0800 (PST)
Message-ID: <01d001c19ae3$215c5f00$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Nakhjiri Madjid-MNAKHJI1" ,
        
References: <35DBB8B7AC89D4118E98009027B1009B0464FD47@IL27EXM10.cig.mot.com>
Subject: Re: [Seamoby] Status of WG Last Call
Date: Fri, 11 Jan 2002 13:01: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

>
> WG Last call has expired on the following drafts:
>
> 1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
> 2) draft-ietf-seamoby-ct-reqs-02.txt
> 3) draft-ietf-seamoby-car-discovery-issues-01.txt
> 4) draft-ietf-seamoby-paging-protocol-assessment-00.txt
>
> No comments were received on 1) and 3), they will now be sent to the
> IESG for review.
>
>
>
> Madjid>> You mean 1) and 2), right?
>

No, I mean 1 and 3. George, you and Gary all had comments on 2. That's
what
the next paragraph was about:

>
>
>
>
> On 3), one comment was received to remove 4 requirements, but there
were
> two opinions expressed
> that the document should remain unchanged, so this document will be
sent
> to the IESG as is for
> review.
>

OK, I see the confusion. This should say "On 2)..." Sorry.

            jak


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


From seamoby-admin@ietf.org  Fri Jan 11 16:53: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 QAA01027
	for ; Fri, 11 Jan 2002 16:53: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 QAA17436;
	Fri, 11 Jan 2002 16:41: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 QAA17407
	for ; Fri, 11 Jan 2002 16:41:46 -0500 (EST)
Received: from hotmail.com (f140.law7.hotmail.com [216.33.237.140])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00440
	for ; Fri, 11 Jan 2002 16:41:43 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 11 Jan 2002 13:41:15 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP;
	Fri, 11 Jan 2002 21:41:15 GMT
X-Originating-IP: [63.78.179.5]
From: "Hemant Chaskar" 
To: kempf@docomolabs-usa.com, hesham.soliman@era.ericsson.se, seamoby@ietf.org
Subject: Re: [Seamoby] Status of WG Last Call
Date: Fri, 11 Jan 2002 21:41:15 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 11 Jan 2002 21:41:15.0887 (UTC) FILETIME=[B260E7F0:01C19AE8]
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 Hesham,

I also did not see any comment from you on the NSIS list during the first 
last call that has not been attended to. What was the text of your email, is 
it there in list archives? If so, please point me to that and I will take 
care of your concern.

Also, note that this is the "second" WG last call for the same draft. When 
we make multiple last calls, we should try to build upon the text of the 
previous call. Hence, in the second WG calls we should restrict the comments 
to either the new text that is added after the first call or the relation 
between the new text and the previous text. Directly making major changes in 
the old text during second call without its any reletion to the new text 
will just keep us infinitely in the last calls phase. Nonetheless, we can 
"finetune" the old text for better clarity.

Also, please note the difference between the "issues" draft, the 
"requirements" draft and the "solutions" draft.

Hemant

>From: "James Kempf" 
>To: "Hesham Soliman \(ERA\)" ,        
>
>Subject: Re: [Seamoby] Status of WG Last Call
>Date: Fri, 11 Jan 2002 10:19:05 -0800
>
>Hesham,
>
>The usual procedure for comments is that they be sent to the list. Any
>Last
>Call comments must be sent to the list in order that there be a record
>of them. I don't recall any email from you on
>draft-ietf-seamoby-car-discovery-issues-01.txt
>during the last call period, but perhaps I missed it. If you have any
>comments,
>please send them out within the next day.
>
>Also note that we are talking here about the problem statement, not the
>requirements.
>I have noted a thread over the last couple days on requirements, and
>your comments, will
>naturally be taken into account when the requirements draft is done.
>
>                 jak
>
>----- Original Message -----
>From: "Hesham Soliman (ERA)" 
>To: "'James Kempf'" ; 
>Sent: Friday, January 11, 2002 9:59 AM
>Subject: RE: [Seamoby] Status of WG Last Call
>
>
> >   >
> >   > WG Last call has expired on the following drafts:
> >   >
> >   > 1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
> >   > 2) draft-ietf-seamoby-ct-reqs-02.txt
> >   > 3) draft-ietf-seamoby-car-discovery-issues-01.txt
> >   > 4) draft-ietf-seamoby-paging-protocol-assessment-00.txt
> >   >
> >   > No comments were received on 1) and 3), they will now be sent to
>the
> >   > IESG for review.
> >
> > => Just a minute, we _are_ discussing comments on 3).
> > I've also made these comments in London.
> >
> > Hesham
> >
>
>
>_______________________________________________
>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  Fri Jan 11 17:04: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 RAA01326
	for ; Fri, 11 Jan 2002 17:04: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 QAA17744;
	Fri, 11 Jan 2002 16:53: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 QAA17715
	for ; Fri, 11 Jan 2002 16:53:48 -0500 (EST)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01020
	for ; Fri, 11 Jan 2002 16:53:45 -0500 (EST)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 16:53:16 -0500
Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB939@ftmail>
From: George Tsirtsis 
To: "'James Kempf'" ,
        Nakhjiri Madjid-MNAKHJI1
	 ,
        seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Fri, 11 Jan 2002 16:53:14 -0500
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

From what I remember Gary said that he supports the removal of 3 out of the
4 points....so the 2 opinions against the removal do not constitute what I
would call....WG consensus do they? In fact only Madjid said that "we could
re-word but not remove"...who was the 2nd person against removal?

Maybe you should ask "who cares?"

Anyway...

George

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Friday, January 11, 2002 9:01 PM
To: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
Subject: Re: [Seamoby] Status of WG Last Call


>
> WG Last call has expired on the following drafts:
>
> 1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
> 2) draft-ietf-seamoby-ct-reqs-02.txt
> 3) draft-ietf-seamoby-car-discovery-issues-01.txt
> 4) draft-ietf-seamoby-paging-protocol-assessment-00.txt
>
> No comments were received on 1) and 3), they will now be sent to the
> IESG for review.
>
>
>
> Madjid>> You mean 1) and 2), right?
>

No, I mean 1 and 3. George, you and Gary all had comments on 2. That's
what
the next paragraph was about:

>
>
>
>
> On 3), one comment was received to remove 4 requirements, but there
were
> two opinions expressed
> that the document should remain unchanged, so this document will be
sent
> to the IESG as is for
> review.
>

OK, I see the confusion. This should say "On 2)..." Sorry.

            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 Jan 11 17:22: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 RAA01864
	for ; Fri, 11 Jan 2002 17:22: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 RAA18823;
	Fri, 11 Jan 2002 17:12: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 RAA18793
	for ; Fri, 11 Jan 2002 17:12:15 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01577
	for ; Fri, 11 Jan 2002 17:12:12 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0BMBhS19656;
	Fri, 11 Jan 2002 14:11:43 -0800 (PST)
Message-ID: <024301c19aec$ba3d1850$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "George Tsirtsis" ,
        "Nakhjiri Madjid-MNAKHJI1" ,
        
References: <8C92E23A3E87FB479988285F9E22BE465AB939@ftmail>
Subject: Re: [Seamoby] Status of WG Last Call
Date: Fri, 11 Jan 2002 14:10:07 -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



> >From what I remember Gary said that he supports the removal of 3 out
of the
> 4 points....so the 2 opinions against the removal do not constitute
what I
> would call....WG consensus do they? In fact only Madjid said that "we
could
> re-word but not remove"...who was the 2nd person against removal?
>
> Maybe you should ask "who cares?"
>

Alright, but this is *the very last time*. We do really need to get this
document on the way.
This is a concensus call. Is there any opposition to removing the
following requirements
from draft-ietf-seamoby-ct-reqs-02.txt:

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.

Speak until Monday 3 PM Pacific Standard time or forever hold your
peace.

            jak



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


From seamoby-admin@ietf.org  Fri Jan 11 17: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 RAA01992
	for ; Fri, 11 Jan 2002 17:26: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 RAA18670;
	Fri, 11 Jan 2002 17:06: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 RAA18643
	for ; Fri, 11 Jan 2002 17:06:55 -0500 (EST)
Received: from hotmail.com (f126.law7.hotmail.com [216.33.237.126])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01411
	for ; Fri, 11 Jan 2002 17:06:52 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 11 Jan 2002 14:06:25 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP;
	Fri, 11 Jan 2002 22:06:25 GMT
X-Originating-IP: [63.78.179.5]
From: "Hemant Chaskar" 
To: vijayd@iprg.nokia.com, hesham.soliman@era.ericsson.se
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] CAR DiscoveryProtocol Requirements...
Date: Fri, 11 Jan 2002 22:06:25 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 11 Jan 2002 22:06:25.0524 (UTC) FILETIME=[36313B40:01C19AEC]
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,

Be there RFC or not, this discussion is not based on the relevant issue in 
the first place. The issue raised is:

"can you make IKE create an SA between two nodes (one having a public 
address and another having a private address)?".

SA between public to private routers need not be done by direct IKE between 
public and private peers. In the case of public to private SA, SA can be 
created (say using IKE) between public router to border router of private 
router. Border router to private router SA can be taken for granted. There 
are various ways to do the latter including static configuration. Such a 
concatenation of two SAs will guarantee SA between public and private 
routers, which is what we want.

Hence, ability or otherwise of creating direct IKE between public and 
private is not at all the sumbling block behind the private address space 
requirement.

If there is any genuine stumbing block in this requirement, please let me 
know it.


Hemant


>From: Vijay Devarapalli 
>To: "Hesham Soliman (ERA)" 
>CC: seamoby@ietf.org
>Subject: Re: [Seamoby] CAR DiscoveryProtocol Requirements...
>Date: Fri, 11 Jan 2002 10:37:49 -0800
>
>"Hesham Soliman (ERA)" wrote:
> >
> > [reply for a very old mail]
> >
> >   > can you make IKE create an SA between two nodes (one having
> >   > a public address and another having a private address)?
> >
> > => Yes you can. There are IKE extensions for this.
>
>which RFC??
>
>---------------
>
>from Aboba's draft draft-ietf-ipsec-nat-reqts-00.txt
>
>c) Incompatibility between IKE address identifiers and NAT.
>    Where IP addresses are used as identifiers in IKE MM [7]
>    or QM, modification of the IP source or destination
>    addresses by NATs or reverse NATs will result in a
>    mismatch between the identifiers and the addresses in the
>    IP header. As described in [7], IKE implementations are
>    required to discard such packets.
>
>    In order to avoid use of IP addresses as IKE MM and QM identifiers,
>    userIDs and FQDNs can be used instead. Where user authentication
>    is desired, an ID type of ID_USER_FQDN can be used, as described in
>    [5]. Where machine authentication is desired, an ID type of ID_FQDN
>    can be used. In either case it is necessary to verify that the
>    proposed identity matches that enclosed in the certificate.
>    However, while use of USER_FQDN or FQDN identity types is possible
>    within IKE, there are usage scenarios (e.g. SPD entries
>    describing subnets) that cannot be accommodated this way.
>
>------------------
>
>However there are a couple of internet drafts in the IPSec WG
>dealing with this. Hopefully they will have a solution soon.
>
>If I am missing something, let me know.
>
>Vijay
>
>
> > I'm obviously not interested in anything involving
> > private addresses, but your point is incorrect.
> >
> > Hesham
>
>_______________________________________________
>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  Fri Jan 11 17:35: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 RAA02183
	for ; Fri, 11 Jan 2002 17:35: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 RAA18986;
	Fri, 11 Jan 2002 17:20: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 RAA18948
	for ; Fri, 11 Jan 2002 17:20:55 -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 RAA01799
	for ; Fri, 11 Jan 2002 17:20:52 -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 g0BMKOD14259;
	Fri, 11 Jan 2002 17:20:24 -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 g0BMKLG02810;
	Fri, 11 Jan 2002 17:20:21 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 11 Jan 2002 17:18:51 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4765@zcard031.ca.nortel.com>
From: "Gary Kenward"
To: "'James Kempf'" ,
        George Tsirtsis
	 ,
        Nakhjiri Madjid-MNAKHJI1
	 ,
        seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Fri, 11 Jan 2002 17:19:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19AED.FCBD36F0"
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_01C19AED.FCBD36F0
Content-Type: text/plain;
	charset="iso-8859-1"

Since I spoke up before and my name was mentioned in the recent
exchange....

I do not care about 4.12 or 4.15, one way or another. 

I do care about 5.5.2, but these requirements have revisited 
so many times that the rationale behind them are ethereal, 
so I will sit firmly on the fence.

How that for an explicit non-vote?

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: January 11, 2002 17:10
> To: George Tsirtsis; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> Subject: Re: [Seamoby] Status of WG Last Call
> 
> 
> 
> 
> > >From what I remember Gary said that he supports the 
> removal of 3 out
> of the
> > 4 points....so the 2 opinions against the removal do not constitute
> what I
> > would call....WG consensus do they? In fact only Madjid 
> said that "we
> could
> > re-word but not remove"...who was the 2nd person against removal?
> >
> > Maybe you should ask "who cares?"
> >
> 
> Alright, but this is *the very last time*. We do really need 
> to get this
> document on the way.
> This is a concensus call. Is there any opposition to removing the
> following requirements
> from draft-ietf-seamoby-ct-reqs-02.txt:
> 
> 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.
> 
> Speak until Monday 3 PM Pacific Standard time or forever hold your
> peace.
> 
>             jak
> 
> 
> 
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> 

------_=_NextPart_001_01C19AED.FCBD36F0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Seamoby] Status of WG Last Call




Since I spoke up before and my name was mentioned in the recent

exchange....




I do not care about 4.12 or 4.15, one way or another. 




I do care about 5.5.2, but these requirements have revisited 

so many times that the rationale behind them are ethereal, 

so I will sit firmly on the fence.




How that for an explicit non-vote?




Gary




> -----Original Message-----

> From: James Kempf [mailto:kempf@docomolabs-usa.com]

> Sent: January 11, 2002 17:10

> To: George Tsirtsis; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org

> Subject: Re: [Seamoby] Status of WG Last Call

> 

> 

> 

> 

> > >From what I remember Gary said that he supports the 

> removal of 3 out

> of the

> > 4 points....so the 2 opinions against the removal do not constitute

> what I

> > would call....WG consensus do they? In fact only Madjid 

> said that "we

> could

> > re-word but not remove"...who was the 2nd person against removal?

> >

> > Maybe you should ask "who cares?"

> >

> 

> Alright, but this is *the very last time*. We do really need 

> to get this

> document on the way.

> This is a concensus call. Is there any opposition to removing the

> following requirements

> from draft-ietf-seamoby-ct-reqs-02.txt:

> 

> 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.

> 

> Speak until Monday 3 PM Pacific Standard time or forever hold your

> peace.

> 

>             jak

> 

> 

> 

> _______________________________________________

> Seamoby mailing list

> Seamoby@ietf.org

> https://www1.ietf.org/mailman/listinfo/seamoby

> 





------_=_NextPart_001_01C19AED.FCBD36F0--

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


From seamoby-admin@ietf.org  Fri Jan 11 17:47: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 RAA02418
	for ; Fri, 11 Jan 2002 17:47: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 RAA19610;
	Fri, 11 Jan 2002 17:35: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 RAA19582
	for ; Fri, 11 Jan 2002 17:35:52 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02194
	for ; Fri, 11 Jan 2002 17:35:49 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0BMZDS20430;
	Fri, 11 Jan 2002 14:35:13 -0800 (PST)
Message-ID: <026e01c19af0$02635f60$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Gary Kenward" ,
        "George Tsirtsis" ,
        "Nakhjiri Madjid-MNAKHJI1" ,
        
References: <9FBD322B7824D511B36900508BF93C9C01AA4765@zcard031.ca.nortel.com>
Subject: Re: [Seamoby] Status of WG Last Call
Date: Fri, 11 Jan 2002 14:33: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

Sorry, Gary, it wasn't a nonvote.

That you don't care about 4.12 and 4.15 means that you don't care
whether we get rid of them. Since George
wants to get rid of them, unless somebody else complains, they will go.

As for 5.5.2, since you want to keep it, it stays.

Since you didn't say anything about 4.13, it goes unless somebody cares
that it stays.

            jak

----- Original Message -----
From: "Gary Kenward" 
To: "'James Kempf'" ; "George Tsirtsis"
; "Nakhjiri Madjid-MNAKHJI1"
; 
Sent: Friday, January 11, 2002 2:19 PM
Subject: RE: [Seamoby] Status of WG Last Call


> Since I spoke up before and my name was mentioned in the recent
> exchange....
>
> I do not care about 4.12 or 4.15, one way or another.
>
> I do care about 5.5.2, but these requirements have revisited
> so many times that the rationale behind them are ethereal,
> so I will sit firmly on the fence.
>
> How that for an explicit non-vote?
>
> Gary
>
> > -----Original Message-----
> > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > Sent: January 11, 2002 17:10
> > To: George Tsirtsis; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> > Subject: Re: [Seamoby] Status of WG Last Call
> >
> >
> >
> >
> > > >From what I remember Gary said that he supports the
> > removal of 3 out
> > of the
> > > 4 points....so the 2 opinions against the removal do not
constitute
> > what I
> > > would call....WG consensus do they? In fact only Madjid
> > said that "we
> > could
> > > re-word but not remove"...who was the 2nd person against removal?
> > >
> > > Maybe you should ask "who cares?"
> > >
> >
> > Alright, but this is *the very last time*. We do really need
> > to get this
> > document on the way.
> > This is a concensus call. Is there any opposition to removing the
> > following requirements
> > from draft-ietf-seamoby-ct-reqs-02.txt:
> >
> > 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.
> >
> > Speak until Monday 3 PM Pacific Standard time or forever hold your
> > peace.
> >
> >             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 Jan 11 17:49: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 RAA02457
	for ; Fri, 11 Jan 2002 17:49: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 RAA19746;
	Fri, 11 Jan 2002 17:39: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 RAA19717
	for ; Fri, 11 Jan 2002 17:39:11 -0500 (EST)
Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02299
	for ; Fri, 11 Jan 2002 17:39:08 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 11 Jan 2002 17:38:35 -0500
Message-ID: 
Thread-Topic: [Seamoby] CAR DiscoveryProtocol Requirements...
Thread-Index: AcGa7a9SfVfHUOBmQOq4iIiBc64j3AACeNEQ
From: "Qiang Zhang" 
To: "Hemant Chaskar" 
Cc: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA19718
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, 

This sounds more an IPsec issue. In reality, it does happen that a public IP needs to IKE to a private IP behind a perimeter gateway, the private IP is non-routable unless NAT mapping is performed. 

The solution for sake of saving headache can be to introduce additional tunneling beneath the IKE, such as UDP encapsulation.

2 SAs can probably achieve a similiar effect in a lot scenarios, but unfortunately it also somewhat defeats the peer2peer purpose for certain usages.

Sorry if am actually off topic...

Qiang


Be there RFC or not, this discussion is not based on the relevant issue in 
the first place. The issue raised is:

"can you make IKE create an SA between two nodes (one having a public 
address and another having a private address)?".

SA between public to private routers need not be done by direct IKE between 
public and private peers. In the case of public to private SA, SA can be 
created (say using IKE) between public router to border router of private 
router. Border router to private router SA can be taken for granted. There 
are various ways to do the latter including static configuration. Such a 
concatenation of two SAs will guarantee SA between public and private 
routers, which is what we want.

Hence, ability or otherwise of creating direct IKE between public and 
private is not at all the sumbling block behind the private address space 
requirement.

If there is any genuine stumbing block in this requirement, please let me 
know it.


Hemant


>From: Vijay Devarapalli 
>To: "Hesham Soliman (ERA)" 
>CC: seamoby@ietf.org
>Subject: Re: [Seamoby] CAR DiscoveryProtocol Requirements...
>Date: Fri, 11 Jan 2002 10:37:49 -0800
>
>"Hesham Soliman (ERA)" wrote:
> >
> > [reply for a very old mail]
> >
> >   > can you make IKE create an SA between two nodes (one having
> >   > a public address and another having a private address)?
> >
> > => Yes you can. There are IKE extensions for this.
>
>which RFC??
>
>---------------
>
>from Aboba's draft draft-ietf-ipsec-nat-reqts-00.txt
>
>c) Incompatibility between IKE address identifiers and NAT.
>    Where IP addresses are used as identifiers in IKE MM [7]
>    or QM, modification of the IP source or destination
>    addresses by NATs or reverse NATs will result in a
>    mismatch between the identifiers and the addresses in the
>    IP header. As described in [7], IKE implementations are
>    required to discard such packets.
>
>    In order to avoid use of IP addresses as IKE MM and QM identifiers,
>    userIDs and FQDNs can be used instead. Where user authentication
>    is desired, an ID type of ID_USER_FQDN can be used, as described in
>    [5]. Where machine authentication is desired, an ID type of ID_FQDN
>    can be used. In either case it is necessary to verify that the
>    proposed identity matches that enclosed in the certificate.
>    However, while use of USER_FQDN or FQDN identity types is possible
>    within IKE, there are usage scenarios (e.g. SPD entries
>    describing subnets) that cannot be accommodated this way.
>
>------------------
>
>However there are a couple of internet drafts in the IPSec WG
>dealing with this. Hopefully they will have a solution soon.
>
>If I am missing something, let me know.
>
>Vijay
>
>
> > I'm obviously not interested in anything involving
> > private addresses, but your point is incorrect.
> >
> > Hesham
>
>_______________________________________________
>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

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


From seamoby-admin@ietf.org  Fri Jan 11 19:20: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 TAA03502
	for ; Fri, 11 Jan 2002 19:20: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 TAA21767;
	Fri, 11 Jan 2002 19:03: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 TAA21738
	for ; Fri, 11 Jan 2002 19:02:56 -0500 (EST)
Received: from hotmail.com (f237.law9.hotmail.com [64.4.9.237])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03323
	for ; Fri, 11 Jan 2002 19:02:54 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 11 Jan 2002 16:02:25 -0800
Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP;
	Sat, 12 Jan 2002 00:02:25 GMT
X-Originating-IP: [63.78.179.4]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: Re: [Seamoby] Status of WG Last Call
Date: Fri, 11 Jan 2002 19:02:25 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 12 Jan 2002 00:02:25.0654 (UTC) FILETIME=[6AC0C960:01C19AFC]
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

Do we loose much by letting 4.12 stay? I don't see this such a big
problem as the transferring AR much get the context prior to transfer
anyways.. so the only point is how much prior.
Maybe I'm missing something.
-Govind.

>
>
> > Since I spoke up before and my name was mentioned in the recent
> > exchange....
> >
> > I do not care about 4.12 or 4.15, one way or another.
> >
> > I do care about 5.5.2, but these requirements have revisited
> > so many times that the rationale behind them are ethereal,
> > so I will sit firmly on the fence.
> >
> > How that for an explicit non-vote?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: January 11, 2002 17:10
> > > To: George Tsirtsis; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> > > Subject: Re: [Seamoby] Status of WG Last Call
> > >
> > >
> > >
> > >
> > > > >From what I remember Gary said that he supports the
> > > removal of 3 out
> > > of the
> > > > 4 points....so the 2 opinions against the removal do not
>constitute
> > > what I
> > > > would call....WG consensus do they? In fact only Madjid
> > > said that "we
> > > could
> > > > re-word but not remove"...who was the 2nd person against removal?
> > > >
> > > > Maybe you should ask "who cares?"
> > > >
> > >
> > > Alright, but this is *the very last time*. We do really need
> > > to get this
> > > document on the way.
> > > This is a concensus call. Is there any opposition to removing the
> > > following requirements
> > > from draft-ietf-seamoby-ct-reqs-02.txt:
> > >
> > > 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.
> > >
> > > Speak until Monday 3 PM Pacific Standard time or forever hold your
> > > peace.
> > >
> > >             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




_________________________________________________________________
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  Sun Jan 13 05:20: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 FAA09338
	for ; Sun, 13 Jan 2002 05:20: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 EAA21811;
	Sun, 13 Jan 2002 04:58: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 EAA21780
	for ; Sun, 13 Jan 2002 04:58:37 -0500 (EST)
Received: from samar.sasken.com (samar.sasken.com [164.164.56.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09221
	for ; Sun, 13 Jan 2002 04:58:29 -0500 (EST)
Received: from samar (localhost [127.0.0.1])
	by samar.sasken.com (8.11.3/8.11.3) with SMTP id g0D9wNc27919;
	Sun, 13 Jan 2002 15:28:23 +0530 (IST)
Received: from SATISHJ (pcz-satishj.sasken.com [10.1.48.152])
	by sunrnd2.sasken.com (8.9.3/8.9.3) with SMTP id PAA21059;
	Sun, 13 Jan 2002 15:28:20 +0530 (IST)
Message-ID: <000a01c19c1a$48991800$9830010a@SATISHJ>
From: "Satish Jamadagni" 
To: "Govind Krishnamurthi" , 
References: 
Subject: Re: [Seamoby] Status of WG Last Call
Date: Sun, 13 Jan 2002 15:38:44 +0530
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

Hi All,
The discussion here seems to have assumed that the nFA or the new AR CAN and
WILL ALWAYS accept the mobile terminal demands in terms of its usage
"context".

Is it appropriate for us to make such an assumption in the face of varied
load or QoS considerations. Should it not be the concern of the context
transfer WG to evolve some form of "negotiation mechanism" before a context
transfer can be effected.

This means that the notion of context integrity during context transfer
should be subject to such a negotiation mechanism or signaling.

This is my first attempt to participate in these discussions so please do
forgive me if such discussion has taken place or if it has been deligated to
some other body or working group.

Regards,
Satish Jamadagni
Research Scientist
Sasken Communiocation Technologies Ltd
www.sasken.com
Bangalore.



----- Original Message -----
From: "Govind Krishnamurthi" 
To: 
Sent: Saturday, January 12, 2002 5:32 AM
Subject: Re: [Seamoby] Status of WG Last Call


> Do we loose much by letting 4.12 stay? I don't see this such a big
> problem as the transferring AR much get the context prior to transfer
> anyways.. so the only point is how much prior.
> Maybe I'm missing something.
> -Govind.
>
> >
> >
> > > Since I spoke up before and my name was mentioned in the recent
> > > exchange....
> > >
> > > I do not care about 4.12 or 4.15, one way or another.
> > >
> > > I do care about 5.5.2, but these requirements have revisited
> > > so many times that the rationale behind them are ethereal,
> > > so I will sit firmly on the fence.
> > >
> > > How that for an explicit non-vote?
> > >
> > > Gary
> > >
> > > > -----Original Message-----
> > > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > > Sent: January 11, 2002 17:10
> > > > To: George Tsirtsis; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> > > > Subject: Re: [Seamoby] Status of WG Last Call
> > > >
> > > >
> > > >
> > > >
> > > > > >From what I remember Gary said that he supports the
> > > > removal of 3 out
> > > > of the
> > > > > 4 points....so the 2 opinions against the removal do not
> >constitute
> > > > what I
> > > > > would call....WG consensus do they? In fact only Madjid
> > > > said that "we
> > > > could
> > > > > re-word but not remove"...who was the 2nd person against removal?
> > > > >
> > > > > Maybe you should ask "who cares?"
> > > > >
> > > >
> > > > Alright, but this is *the very last time*. We do really need
> > > > to get this
> > > > document on the way.
> > > > This is a concensus call. Is there any opposition to removing the
> > > > following requirements
> > > > from draft-ietf-seamoby-ct-reqs-02.txt:
> > > >
> > > > 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.
> > > >
> > > > Speak until Monday 3 PM Pacific Standard time or forever hold your
> > > > peace.
> > > >
> > > >             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
>
>
>
>
> _________________________________________________________________
> 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


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


From seamoby-admin@ietf.org  Mon Jan 14 07:47: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 HAA01895
	for ; Mon, 14 Jan 2002 07:47: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 HAA04421;
	Mon, 14 Jan 2002 07:28: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 HAA04393
	for ; Mon, 14 Jan 2002 07:28:30 -0500 (EST)
Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01730
	for ; Mon, 14 Jan 2002 07:28:26 -0500 (EST)
Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0)
	with SMTP id jmf3c42f978; Mon, 14 Jan 2002 12:28:23 -0000
Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0)
	with SMTP id jm203c3e29cc; Thu, 10 Jan 2002 17:46:38 -0000
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id SAA29017
	for ietf-123-outbound.01@ietf.org; Wed, 9 Jan 2002 18:15:00 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id QAA28017
	for ; Wed, 9 Jan 2002 16:03:40 -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 QAA15361;
	Wed, 9 Jan 2002 16:03:37 -0500 (EST)
Message-Id: <200201092103.QAA15361@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, 09 Jan 2002 16:03:36 -0500
Subject: [Seamoby] I-D ACTION:draft-jung-seamoby-paging-buffload-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		: Reducing the Buffering Load of Paging Agent in IP 
                          Paging
	Author(s)	: H. Jung, S. Koh
	Filename	: draft-jung-seamoby-paging-buffload-00.txt
	Pages		: 6
	Date		: 08-Jan-02
	
This draft defines two procedures to distribute buffering load in IP
paging using PA.  A couple of documents using the PA, which includes
all functions defined RFC 3154 in an entity, have beee submitted for
cadidate protocol for IP paging. In this PA paging approach, the
centralized buffering in PA can be a bottleneck point if a PA has to
manage large paging area and a number of idle mobile hosts.  To
address the problem, it can be good solution to distribute buffering
load among ARs in the paging area

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jung-seamoby-paging-buffload-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-jung-seamoby-paging-buffload-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-jung-seamoby-paging-buffload-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:	<20020108150738.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-jung-seamoby-paging-buffload-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-jung-seamoby-paging-buffload-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



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


From seamoby-admin@ietf.org  Mon Jan 14 08:10: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 IAA02159
	for ; Mon, 14 Jan 2002 08:10: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 HAA05447;
	Mon, 14 Jan 2002 07:56: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 HAA05418
	for ; Mon, 14 Jan 2002 07:56:39 -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 HAA01987
	for ; Mon, 14 Jan 2002 07:56:36 -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 g0ECuUH39157
	for ; Mon, 14 Jan 2002 13:56:30 +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 NAA03494
	for ; Mon, 14 Jan 2002 13:56:03 +0100
Message-ID: <3C42D563.BE04F6F5@ccrle.nec.de>
Date: Mon, 14 Jan 2002 13:56: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: Seamoby 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] DMHA framework draft architecture
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,

referring to the functional architecture for DMHA in RFC 3154, currently
the protocol base line draft describes a composite architecture.
Appendix C of draft-renker-paging-ipv6-01.txt illustrates a mapping
between the described architecture and the functional elements given in
RFC 3154. In order to come up with a first cut of a framework draft, I
would like to request a WG consensus of taking over the proposed
architecture, having a composite Paging Agent node (PA node) addressing
paging related attendant functional entities within ARs. Actually,
taking the description of the Paging Agent Functional Entity (FE) as it
is described in RFC 3154, this functional entity could be split into a
master FE, currently assigned to the PA node, and multiple attendant
FEs, located in ARs, responsible for local paging function and mapping
L3 paging requests to lower layer specifics.

Comments are welcome.

marco




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


From seamoby-admin@ietf.org  Mon Jan 14 08:38: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 IAA02415
	for ; Mon, 14 Jan 2002 08:38: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 IAA06198;
	Mon, 14 Jan 2002 08:25: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 IAA06167
	for ; Mon, 14 Jan 2002 08:25:29 -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 IAA02294
	for ; Mon, 14 Jan 2002 08:25:25 -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 g0EDPNH39530
	for ; Mon, 14 Jan 2002 14:25:23 +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 OAA03931
	for ; Mon, 14 Jan 2002 14:24:56 +0100
Message-ID: <3C42DC28.F8220F2C@ccrle.nec.de>
Date: Mon, 14 Jan 2002 14:24:56 +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: Seamoby 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] openness for advanced paging strategies in DMHA
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,

the architecture of the Paging Agent node in the current base line draft
for the WG's DMHA protocol intends to be open for several paging
strategies. As James proposed, maybe it is appropriate to take detailed
sections addressing different paging strategies and characteristics out
for the WG's protocol framework draft. In my opinion, deployment of
different paging strategies is an important area, therefore, the future
WG architecture and the protocol for DMHA should allow deployment of
several paging strategies. Therefore, I propose the following: Taking
out the details on paging strategies and having later a reference on a
possibly stand-alone document describing the paging strategy specifics.
We could have a very brief comment in the draft addressing the 'role of
a paging strategy' (sec. 1.1.4 in draft-renker) and the concept's
openness.

Comments are appreciated.

marco




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


From seamoby-admin@ietf.org  Mon Jan 14 09:09: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 JAA02798
	for ; Mon, 14 Jan 2002 09:09: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 IAA07103;
	Mon, 14 Jan 2002 08:54: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 IAA07074
	for ; Mon, 14 Jan 2002 08:54:37 -0500 (EST)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02546
	for ; Mon, 14 Jan 2002 08:54:33 -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 g0EDrtk03062;
	Mon, 14 Jan 2002 14:53:55 +0100 (MET)
Message-ID: <3C42E35B.42E440B9@inrialpes.fr>
Date: Mon, 14 Jan 2002 14:55:39 +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
To: Marco Liebsch 
CC: Seamoby 
Subject: Re: [Seamoby] openness for advanced paging strategies in DMHA
References: <3C42DC28.F8220F2C@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,


Marco Liebsch wrote:

> Hi all,
>
> the architecture of the Paging Agent node in the current base line draft
> for the WG's DMHA protocol intends to be open for several paging
> strategies. As James proposed, maybe it is appropriate to take detailed
> sections addressing different paging strategies and characteristics out
> for the WG's protocol framework draft. In my opinion, deployment of
> different paging strategies is an important area, therefore, the future
> WG architecture and the protocol for DMHA should allow deployment of
> several paging strategies. Therefore, I propose the following: Taking
> out the details on paging strategies and having later a reference on a
> possibly stand-alone document describing the paging strategy specifics.
> We could have a very brief comment in the draft addressing the 'role of
> a paging strategy' (sec. 1.1.4 in draft-renker) and the concept's
> openness.
>
> Comments are appreciated.
>

IMHO this would be a very efficient design choice (I mean,
supporting multiple paging policies). For two reasons (at least):
1- Seems like no paging policy suits well all mobility scenarios
2- Paging policy research is not finished (especially in IP area).

regards,
pars


>
> marco
>
> _______________________________________________
> 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 Jan 14 09:25: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 JAA02974
	for ; Mon, 14 Jan 2002 09:25: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 JAA07843;
	Mon, 14 Jan 2002 09:11: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 JAA07811
	for ; Mon, 14 Jan 2002 09:11:23 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02833
	for ; Mon, 14 Jan 2002 09:11:19 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g0EEBKJ12872
	for ; Mon, 14 Jan 2002 15:11:20 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Jan 14 15:11:19 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 14 Jan 2002 15:02:21 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1F0@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Trossen Dirk (NRC/Boston)'" ,
        "Hesham Soliman (ERA)" ,
        Govind Krishnamurthi , seamoby@ietf.org
Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...
Date: Mon, 14 Jan 2002 15:11:01 +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'm referring to the title of ch 4.1
  > 
  > I would appreciate if you could point out WHICH wording does imply
  > that MN signalling is ruled out in the anticipated approach. It is 
  > certainly not the title. 

=> I already copied that part in the draft and put it in one
of my emails. 
If you missed it, it's the title (as I say above), and 
the first sentence.

Hesham

  > 
  > Regards,
  > 
  > 
  > 
  > Dirk
  > 

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


From seamoby-admin@ietf.org  Mon Jan 14 09:26: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 JAA02987
	for ; Mon, 14 Jan 2002 09:26: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 JAA07727;
	Mon, 14 Jan 2002 09:06: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 JAA07694
	for ; Mon, 14 Jan 2002 09:06:48 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02776
	for ; Mon, 14 Jan 2002 09:06:44 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0EE6gK12761
	for ; Mon, 14 Jan 2002 15:06:42 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jan 14 15:06:41 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Mon, 14 Jan 2002 15:06:25 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1EF@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'James Kempf'" ,
        "Hesham Soliman (ERA)"
	 ,
        seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Mon, 14 Jan 2002 15:06:23 +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

James, 

  > The usual procedure for comments is that they be sent to 
  > the list. Any
  > Last
  > Call comments must be sent to the list in order that there 
  > be a record
  > of them. I don't recall any email from you on
  > draft-ietf-seamoby-car-discovery-issues-01.txt
  > during the last call period, but perhaps I missed it. 

=> No you didn't miss it, but I think the last call 
period was a very strange time, that goes over the 
christmas break where a lot of people (especially on
this side of the world) take some holidays. 

If 
  > you have any
  > comments,
  > please send them out within the next day.

=> I've already sent my comments on the draft 
(in this thread), specifically on the assumptions
in chapter 4.1. 

  > Also note that we are talking here about the problem 
  > statement, not the
  > requirements.

=> I commented on both in my email.

Hesham


  > ----- Original Message -----
  > From: "Hesham Soliman (ERA)" 
  > To: "'James Kempf'" ; 
  > Sent: Friday, January 11, 2002 9:59 AM
  > Subject: RE: [Seamoby] Status of WG Last Call
  > 
  > 
  > >   >
  > >   > WG Last call has expired on the following drafts:
  > >   >
  > >   > 1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
  > >   > 2) draft-ietf-seamoby-ct-reqs-02.txt
  > >   > 3) draft-ietf-seamoby-car-discovery-issues-01.txt
  > >   > 4) draft-ietf-seamoby-paging-protocol-assessment-00.txt
  > >   >
  > >   > No comments were received on 1) and 3), they will now 
  > be sent to
  > the
  > >   > IESG for review.
  > >
  > > => Just a minute, we _are_ discussing comments on 3).
  > > I've also made these comments in London.
  > >
  > > Hesham
  > >
  > 

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


From seamoby-admin@ietf.org  Mon Jan 14 09:29: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 JAA03067
	for ; Mon, 14 Jan 2002 09:29: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 JAA07973;
	Mon, 14 Jan 2002 09:16: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 JAA07949
	for ; Mon, 14 Jan 2002 09:16:19 -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 JAA02886
	for ; Mon, 14 Jan 2002 09:16:17 -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 g0EEGFH39949;
	Mon, 14 Jan 2002 15:16:15 +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 PAA04716;
	Mon, 14 Jan 2002 15:15:48 +0100
Message-ID: <3C42E814.FDDAEAD1@ccrle.nec.de>
Date: Mon, 14 Jan 2002 15:15: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: Pars MUTAF 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] IP paging question
References: <3C3F0AC6.C064979@inrialpes.fr>
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 Pars,
of course, from power saving point of view, the MN intends to enter
dormant mode as early as possible. But I think more parameters have to be
considered for this issue. This is, as an example, the systems
characteristics (e.g. mobility management) as well as network protocol
characteristics. For IPv6, characteristics of Neighbour Cache maintenance
should be considered in order to avoid 'black hole' behaviour of the
system (packet addresses a MN's link address, taken from cache, although
the MN has entered dormant mode already). In case of IPv6, the
RachableTime value is 30 sec. Of course, more system characteristics
affect the degree of sensitivity for black holes. This is for example
having Mobile IPv6 with Route Optimization, allowing direct addressing of
MNs from CN point of view (if a valid binding cache entry is available).
If the oAR would have a valid cache entry in its table, the packet could
be lost. In my opinion, the timer you referred to should be configurable,
dependent on the platform's characteristics.

Regards,

marco

Pars MUTAF wrote:

> Hello,
>
> I have a question concerning IP paging:
>
> What will be the order of magnitude of the "dormant mode timer"
> i.e. the time a host waits before making a dormant mode registration
> (when it is not in active communication).
>
> I'm not asking (of course) for an exact value. It will be in
> milliseconds or seconds?
>
> I would say in milliseconds, or "register as quickly as possible" but
> I'm not sure.
>
> Thanks in advance for your help.
>
> 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  Mon Jan 14 11:15: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 LAA05510
	for ; Mon, 14 Jan 2002 11:15: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 KAA11458;
	Mon, 14 Jan 2002 10:56: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 KAA11430
	for ; Mon, 14 Jan 2002 10:56:05 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04903
	for ; Mon, 14 Jan 2002 10:56:02 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0EFu3K16704
	for ; Mon, 14 Jan 2002 16:56:03 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Jan 14 16:56:02 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Mon, 14 Jan 2002 16:55:46 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1F1@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'James Kempf'" ,
        "Hesham Soliman (ERA)"
	 ,
        "'Trossen Dirk (NRC/Boston)'"
	 ,
        Govind Krishnamurthi , seamoby@ietf.org
Date: Mon, 14 Jan 2002 16:55:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Seamoby] RE: CAR Discovery 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

James,

  > It certainly would have been helpful if you had posted your comments
  > during the Last Call period.
  > Last Call expired Jan. 4 on this document. I don't believe 
  > comments sent
  > in after
  > Last Call necessarily need to be accommodated, but, if 
  > these are simple
  > editorial changes that can be
  >  resolved in the next day or two, then I think we can 
  > accommodate them.
  > However, I do not want to get into a
  >  long discussion about requirements prior to releasing the problem
  > statement. 

=> The requirements discussion is seaprate from my 
comments on the problem statement. I would have liked
to send them earlier too, but as I said it's a very 
common holiday period. Perhaps something to think about
with future last calls.

  > 
  > > => To me the following text from the draft suggests
  > > that the AR knows ALL GAARs. I think that's unrealistic.
  > >
  > >   4.1 Anticipated CAR Discovery
  > >
  > >    In this approach, an AR currently serving the MN identifies all
  > CARs
  > >    for the MN's handoff, at some point prior to handoff.
  > >
  > 
  > How about:
  > 
  >     In this approach, an AR currently serving the MN 
  > identifies some set
  > of
  >     suitable CARs for the MN's handoff, at some point prior 
  > to handoff.

=> Fine with me
  > 
  > If this text is unsatisfactory, please feel free to propose an
  > alternative.
  > 
  > > => anticipation should not be associated with the
  > > case where the MN does not signal, you can have
  > > anticipation when the MN signals also. Therefore
  > > associating 'anticipation' with a certain model
  > > where the MN does not signal, does not seem right.
  > >
  > > I'm referring to the title of ch 4.1
  > >
  > 
  > One of the problems with not having a consistent set
  > of terminology for wireless networking in the IETF
  > is that it becomes difficult to find a word that describes
  > the concept you are trying to get at without impinging
  > on what somebody else thinks a particular word
  > means. I believe this is the case here. The "anticipated"
  > here has nothing to do with "anticipated handover."
  > Here, the AR is anticipating the need for CARs
  > by performing discovery prior to the MN needing
  > them. 

=> Then it should be explicitly stated that the 
anticipation is 'AR-based'. Simply saying 
'anticipation' in isolation and not mentioning
this term in ch 4.2 is misleading because it associates
'anticipation' with a certain mechanism.

  > Perhaps another word would be suitable? Please
  > feel free to suggest one. Perhaps "router based"?

=> Exactly, I think 'access router- based' is more
appropriate. 

Hesham

  > 
  >             jak
  > 

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


From seamoby-admin@ietf.org  Mon Jan 14 12:11: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 MAA07456
	for ; Mon, 14 Jan 2002 12:11: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 LAA13334;
	Mon, 14 Jan 2002 11:48: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 LAA13302
	for ; Mon, 14 Jan 2002 11:48:31 -0500 (EST)
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06383
	for ; Mon, 14 Jan 2002 11:48:28 -0500 (EST)
Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn2-595.cisco.com [10.82.242.83]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA04519; Mon, 14 Jan 2002 08:47:59 -0800 (PST)
Message-Id: <4.3.2.7.2.20020114113728.03782008@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 14 Jan 2002 11:46:55 -0500
To: "Govind Krishnamurthi" 
From: John Schnizlein 
Subject: Re: [Seamoby] CAR Discovery Requirements
Cc: seamoby@ietf.org
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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

At 12:50 PM 1/10/2002, Govind Krishnamurthi wrote:
>...
>6. Protocol applicability ? SHOULD (?) 
>(show of hands indicated that this item should be changed to a MUST) 
>support inter-domain as well as Intra-domain scope

Inter-domain discovery of access routers (which seems implied by what
might otherwise seem an innocuous protocol design feature) is problematic.

It would require resolving which users are subscribers of which domains,
or complex inter-domain roaming and billing reciprocity. 

While it seems reasonable to avoid locking mobile stations into a single
domain, the policy interactions of requiring multiple-domain discovery
would make the task much more difficult at the start.

Please reconsider even the SHOULD for this item, much less moving toward
MUST.

John


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


From seamoby-admin@ietf.org  Mon Jan 14 12:14: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 LAA05514
	for ; Mon, 14 Jan 2002 11:15: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 KAA11561;
	Mon, 14 Jan 2002 10:58: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 KAA11530
	for ; Mon, 14 Jan 2002 10:58:55 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04965
	for ; Mon, 14 Jan 2002 10:58:52 -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 g0EFwsK19054
	for ; Mon, 14 Jan 2002 16:58:54 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Jan 14 16:58:37 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Mon, 14 Jan 2002 16:58:37 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1F2@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Hemant Chaskar'" , kempf@docomolabs-usa.com,
        "Hesham Soliman (ERA)" ,
        seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Mon, 14 Jan 2002 16:58:32 +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

Hi Hemant, 

  > I also did not see any comment from you on the NSIS list 
  > during the first 
  > last call that has not been attended to. 

=> I'm not on the NSIS list. This is a seamoby doc.

  > Also, please note the difference between the "issues" draft, the 
  > "requirements" draft and the "solutions" draft.

=> I made comments on both. I realise they are 2 different
things.

Hesham


  > 
  > Hemant
  > 
  > >From: "James Kempf" 
  > >To: "Hesham Soliman \(ERA\)" 
  > ,        
  > >
  > >Subject: Re: [Seamoby] Status of WG Last Call
  > >Date: Fri, 11 Jan 2002 10:19:05 -0800
  > >
  > >Hesham,
  > >
  > >The usual procedure for comments is that they be sent to 
  > the list. Any
  > >Last
  > >Call comments must be sent to the list in order that there 
  > be a record
  > >of them. I don't recall any email from you on
  > >draft-ietf-seamoby-car-discovery-issues-01.txt
  > >during the last call period, but perhaps I missed it. If 
  > you have any
  > >comments,
  > >please send them out within the next day.
  > >
  > >Also note that we are talking here about the problem 
  > statement, not the
  > >requirements.
  > >I have noted a thread over the last couple days on 
  > requirements, and
  > >your comments, will
  > >naturally be taken into account when the requirements 
  > draft is done.
  > >
  > >                 jak
  > >
  > >----- Original Message -----
  > >From: "Hesham Soliman (ERA)" 
  > >To: "'James Kempf'" ; 
  > >Sent: Friday, January 11, 2002 9:59 AM
  > >Subject: RE: [Seamoby] Status of WG Last Call
  > >
  > >
  > > >   >
  > > >   > WG Last call has expired on the following drafts:
  > > >   >
  > > >   > 1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
  > > >   > 2) draft-ietf-seamoby-ct-reqs-02.txt
  > > >   > 3) draft-ietf-seamoby-car-discovery-issues-01.txt
  > > >   > 4) draft-ietf-seamoby-paging-protocol-assessment-00.txt
  > > >   >
  > > >   > No comments were received on 1) and 3), they will 
  > now be sent to
  > >the
  > > >   > IESG for review.
  > > >
  > > > => Just a minute, we _are_ discussing comments on 3).
  > > > I've also made these comments in London.
  > > >
  > > > Hesham
  > > >
  > >
  > >
  > >_______________________________________________
  > >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  Mon Jan 14 12:20: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 MAA07880
	for ; Mon, 14 Jan 2002 12:20: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 LAA13630;
	Mon, 14 Jan 2002 11:58: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 LAA13599
	for ; Mon, 14 Jan 2002 11:58:29 -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 LAA06713
	for ; Mon, 14 Jan 2002 11:58:25 -0500 (EST)
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 g0EGwdQ17873
	for ; Mon, 14 Jan 2002 10:58:39 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 14 Jan 2002 10:58:27 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 14 Jan 2002 10:57:42 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR Discovery Requirements
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 14 Jan 2002 11:57:41 -0500
Message-ID: 
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcGdG8ZiwAzO4gkNEdaJYAAIx6TWpQAADOWg
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext John Schnizlein'" ,
        "Govind Krishnamurthi" 
Cc: 
X-OriginalArrivalTime: 14 Jan 2002 16:57:42.0270 (UTC) FILETIME=[94B639E0:01C19D1C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA13600
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 John,

I'm kind of confused by your comment. Are you questioning
the inter-domain handoff or the discovery? Why do I have to
resolve which users are subscribers of which domains if I want
to discover ARs in my proximity?

We're discussing CAR discovery. I don't see your policy
interactions, inter-domain roaming, and billing problems in this
context. However, it is certainly an issue for the actual selection of
the
target AR, but TAR selection is not within the scope of the
CAR discovery protocol.

Regards,



Dirk
> -----Original Message-----
> From: ext John Schnizlein [mailto:jschnizl@cisco.com]
> Sent: Monday, January 14, 2002 11:47 AM
> To: Govind Krishnamurthi
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CAR Discovery Requirements
> 
> 
> At 12:50 PM 1/10/2002, Govind Krishnamurthi wrote:
> >...
> >6. Protocol applicability ? SHOULD (?) 
> >(show of hands indicated that this item should be changed to a MUST) 
> >support inter-domain as well as Intra-domain scope
> 
> Inter-domain discovery of access routers (which seems implied by what
> might otherwise seem an innocuous protocol design feature) is 
> problematic.
> 
> It would require resolving which users are subscribers of 
> which domains,
> or complex inter-domain roaming and billing reciprocity. 
> 
> While it seems reasonable to avoid locking mobile stations 
> into a single
> domain, the policy interactions of requiring multiple-domain discovery
> would make the task much more difficult at the start.
> 
> Please reconsider even the SHOULD for this item, much less 
> moving toward
> MUST.
> 
> John
> 
> 
> _______________________________________________
> 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 Jan 14 12:24: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 MAA08105
	for ; Mon, 14 Jan 2002 12:24: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 MAA14364;
	Mon, 14 Jan 2002 12:00: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 MAA14322
	for ; Mon, 14 Jan 2002 12:00:35 -0500 (EST)
Received: from clarinet.u-strasbg.fr (IDENT:root@clarinet.u-strasbg.fr [130.79.90.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06855
	for ; Mon, 14 Jan 2002 12:00:31 -0500 (EST)
Received: from PATINET (patinet.u-strasbg.fr [130.79.90.172])
	by clarinet.u-strasbg.fr (8.9.3/8.9.3) with SMTP id SAA03272
	for ; Mon, 14 Jan 2002 18:00:32 +0100
Message-ID: <027201c19d1c$fe949500$ac5a4f82@ustrasbg.fr>
From: "Christophe Jelger" 
To: 
Date: Mon, 14 Jan 2002 18:00:39 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 8bit
Subject: [Seamoby] Problem Statement
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 am new to the list so please forgive me if my points are out of the main
discussion subject. I also apologise if this has been discussed before.

In the draft context-transfer-problem-stat-04.txt in section 5.3, it is
stated that context transfer should be used when it establishes a service
faster than from scratch. While this is certainly good sense, it is also
mentioned that for certain types of services, e.g. multicast, context
transfer may not be suitable.

As I told you before I am new to the list so I don't know if this has been
discussed before. I believe that this statement makes little sense for two
main reasons:

1) First, there has been almost no studies at all about the join latency of
multicast communications and I find it inadequate to say that something is
better or worse than something that has not been evaluated (even if it may
intuitively be the case)

2) Second, the term "faster" or "quicker" has to be carefully defined to
have a strict sense. What I mean is that with context transfer, the process
of joining a multicast group (with respect to the nAR) can be anticipated
and therefore after the handoff completes the multicast traffic may already
be delivered in the new network and in that case the service disruption is
almost null. The whole process of context tranfer may be longer than a
native multicast join process from the new network but the service
disruption time may be shorter with context transfer.

Any comments/suggestions are welcome. Please also understand that my
intention is not to critisise the draft when I did not take part of any
prior discussions. I simply think that this point should be clarified.

Regards,

Christophe


-------------------------------------------------------------------------
Christophe Jelger - LSIIT                   jelger@dpt-info.u-strasbg.fr
Université Louis Pasteur
Strasbourg - France                           Tel: +33 (0)3 90 24 45 90

http://www-r2.u-strasbg.fr/~jelger
-------------------------------------------------------------------------


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


From seamoby-admin@ietf.org  Mon Jan 14 12:24: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 MAA08143
	for ; Mon, 14 Jan 2002 12:24: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 MAA14498;
	Mon, 14 Jan 2002 12:00: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 MAA14462
	for ; Mon, 14 Jan 2002 12:00:51 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06860
	for ; Mon, 14 Jan 2002 12:00:47 -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 g0EH0nK26526
	for ; Mon, 14 Jan 2002 18:00:49 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Jan 14 18:00:32 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 14 Jan 2002 17:51:50 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1F6@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'John Schnizlein'" ,
        Govind Krishnamurthi
	 
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Mon, 14 Jan 2002 18:00:28 +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

>...
  > >6. Protocol applicability ? SHOULD (?) 
  > >(show of hands indicated that this item should be changed 
  > to a MUST) 
  > >support inter-domain as well as Intra-domain scope
  > 
  > Inter-domain discovery of access routers (which seems 
  > implied by what
  > might otherwise seem an innocuous protocol design feature) 
  > is problematic.
  > 
  > It would require resolving which users are subscribers of 
  > which domains,
  > or complex inter-domain roaming and billing reciprocity. 

=> This is exactly why I urge you (this wg) to clearly 
explain which protocol you are talking about. AR - AR or
AR MN ???
Clearly AR - MN lis an obvious way to discover all routers 
that the MN can hear. Inter/intra domain issues are 
not relevant. 

So please make it clear which part of the protocol
you're referring to. We should not always assume 
that we're discussing the AR - AR case. 

  > While it seems reasonable to avoid locking mobile stations 
  > into a single
  > domain, the policy interactions of requiring 
  > multiple-domain discovery
  > would make the task much more difficult at the start.

=> Certainly. But there is an easy way of doing that:
Let the MN decide.

Hesham

  > _______________________________________________
  > 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 Jan 14 12:49: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 MAA09269
	for ; Mon, 14 Jan 2002 12:49: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 MAA15760;
	Mon, 14 Jan 2002 12:30: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 MAA15711
	for ; Mon, 14 Jan 2002 12:30:25 -0500 (EST)
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08425
	for ; Mon, 14 Jan 2002 12:30:21 -0500 (EST)
Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn2-595.cisco.com [10.82.242.83]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA19420; Mon, 14 Jan 2002 09:29:46 -0800 (PST)
Message-Id: <4.3.2.7.2.20020114120320.037d6358@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 14 Jan 2002 12:28:42 -0500
To: "Hesham Soliman (ERA)" 
From: John Schnizlein 
Subject: RE: [Seamoby] CAR Discovery Requirements
Cc: Govind Krishnamurthi , seamoby@ietf.org
In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C1F6@Esealnt861.al.sw.
 ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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

At 12:00 PM 1/14/2002, Hesham Soliman (ERA) wrote:
>>...
>  > >6. Protocol applicability ? SHOULD (?)
>  > 
>  > Inter-domain discovery of access routers is problematic.
>
>AR - AR or AR MN ???

This is a good question.

>Clearly AR - MN lis an obvious way to discover all routers that 
>the MN can hear. Inter/intra domain issues are not relevant. 

If the WG goes that way, the resulting protocol would be usable
only by operators who allow access to any mobile node (MN). But 
normal business arrangements might require a pre-existing 
relationship between the subscriber (MN) before service providers 
are willing to be discovered. Remember the implication that the
AR would be willing to accept an operating context for the MN from
some other provider.

The issue is potentially even more problematic for AR - AR. Would the
operator of an access service willingly include another operator's
routers to be neighbors, encouraging the possibility that the MN
would switch into/out-of service from a different provider?
We know that telephone companies try to avoid this.

>So please make it clear which part of the protocol
>you're referring to. We should not always assume 
>that we're discussing the AR - AR case. 
>
>...
>Let the MN decide.

This is a good answer. But then the MN would need to get the sort of
information it needs to make a reasonable decision. This might include
pricing information, or information regarding the which providers
share access reciprocity agreements. Are we ready for all this?

John


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


From seamoby-admin@ietf.org  Mon Jan 14 12:50: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 MAA09350
	for ; Mon, 14 Jan 2002 12:50: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 MAA16069;
	Mon, 14 Jan 2002 12:32: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 MAA16028
	for ; Mon, 14 Jan 2002 12:32:10 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08502
	for ; Mon, 14 Jan 2002 12:31:51 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0EHVJS00846;
	Mon, 14 Jan 2002 09:31:19 -0800 (PST)
Message-ID: <003201c19d21$0d68d420$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Satish Jamadagni" ,
        "Govind Krishnamurthi" , 
References:  <000a01c19c1a$48991800$9830010a@SATISHJ>
Subject: Re: [Seamoby] Status of WG Last Call
Date: Mon, 14 Jan 2002 09:29: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

Satish,

Thanx for the thoughts, but the concensus call is limited to whether
requirements 4.12, 4.13, 4.15 and 5.5.2 should
be kept or dropped. We have been working on these requirements for the
better part of a year, and we must
advance this draft. If you care to express an opinion on whether the
requirements should be kept or dropped, you
have until 3:00 PM Pacific Time today.

            jak

----- Original Message -----
From: "Satish Jamadagni" 
To: "Govind Krishnamurthi" ; 
Sent: Sunday, January 13, 2002 2:08 AM
Subject: Re: [Seamoby] Status of WG Last Call


> Hi All,
> The discussion here seems to have assumed that the nFA or the new AR
CAN and
> WILL ALWAYS accept the mobile terminal demands in terms of its usage
> "context".
>
> Is it appropriate for us to make such an assumption in the face of
varied
> load or QoS considerations. Should it not be the concern of the
context
> transfer WG to evolve some form of "negotiation mechanism" before a
context
> transfer can be effected.
>
> This means that the notion of context integrity during context
transfer
> should be subject to such a negotiation mechanism or signaling.
>
> This is my first attempt to participate in these discussions so please
do
> forgive me if such discussion has taken place or if it has been
deligated to
> some other body or working group.
>
> Regards,
> Satish Jamadagni
> Research Scientist
> Sasken Communiocation Technologies Ltd
> www.sasken.com
> Bangalore.
>
>
>
> ----- Original Message -----
> From: "Govind Krishnamurthi" 
> To: 
> Sent: Saturday, January 12, 2002 5:32 AM
> Subject: Re: [Seamoby] Status of WG Last Call
>
>
> > Do we loose much by letting 4.12 stay? I don't see this such a big
> > problem as the transferring AR much get the context prior to
transfer
> > anyways.. so the only point is how much prior.
> > Maybe I'm missing something.
> > -Govind.
> >
> > >
> > >
> > > > Since I spoke up before and my name was mentioned in the recent
> > > > exchange....
> > > >
> > > > I do not care about 4.12 or 4.15, one way or another.
> > > >
> > > > I do care about 5.5.2, but these requirements have revisited
> > > > so many times that the rationale behind them are ethereal,
> > > > so I will sit firmly on the fence.
> > > >
> > > > How that for an explicit non-vote?
> > > >
> > > > Gary
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > > > Sent: January 11, 2002 17:10
> > > > > To: George Tsirtsis; Nakhjiri Madjid-MNAKHJI1;
seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] Status of WG Last Call
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > >From what I remember Gary said that he supports the
> > > > > removal of 3 out
> > > > > of the
> > > > > > 4 points....so the 2 opinions against the removal do not
> > >constitute
> > > > > what I
> > > > > > would call....WG consensus do they? In fact only Madjid
> > > > > said that "we
> > > > > could
> > > > > > re-word but not remove"...who was the 2nd person against
removal?
> > > > > >
> > > > > > Maybe you should ask "who cares?"
> > > > > >
> > > > >
> > > > > Alright, but this is *the very last time*. We do really need
> > > > > to get this
> > > > > document on the way.
> > > > > This is a concensus call. Is there any opposition to removing
the
> > > > > following requirements
> > > > > from draft-ietf-seamoby-ct-reqs-02.txt:
> > > > >
> > > > > 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.
> > > > >
> > > > > Speak until Monday 3 PM Pacific Standard time or forever hold
your
> > > > > peace.
> > > > >
> > > > >             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
> >
> >
> >
> >
> > _________________________________________________________________
> > 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
>
>
> _______________________________________________
> 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 Jan 14 12:59: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 MAA09867
	for ; Mon, 14 Jan 2002 12:59: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 MAA16336;
	Mon, 14 Jan 2002 12:43: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 MAA16306
	for ; Mon, 14 Jan 2002 12:43:09 -0500 (EST)
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08995
	for ; Mon, 14 Jan 2002 12:43:07 -0500 (EST)
Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn2-595.cisco.com [10.82.242.83]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA04151; Mon, 14 Jan 2002 09:42:25 -0800 (PST)
Message-Id: <4.3.2.7.2.20020114123121.0377bf90@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 14 Jan 2002 12:41:19 -0500
To: "Trossen Dirk (NRC/Boston)" 
From: John Schnizlein 
Subject: RE: [Seamoby] CAR Discovery Requirements
Cc: "Govind Krishnamurthi" , 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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

At 11:57 AM 1/14/2002, Trossen Dirk (NRC/Boston) wrote:

>I'm kind of confused by your comment. 
>Are you questioning the inter-domain handoff or the discovery? 
>Why do I have to resolve which users are subscribers of which 
>domains if I want to discover ARs in my proximity?

I will admit the possibility that I simply don't understand.
My impression is that the discovery is for the purpose of finding
neighbors for potential context hand-off. One way to limit getting
or giving hand-offs to/from domains with which the provider has no
business relationship is to limit forming the neighborhood.

In non-cyber-space, there are sometimes houses closer to mine that
are considered a different neighborhood because their $/sq.ft. are
so different. On just the other side of a street, the children often
attend a different school (with sometimes dramatically different
$/student expenditure).

Is it necessary to preclude this method of operation for mobility?

>We're discussing CAR discovery. I don't see your policy
>interactions, inter-domain roaming, and billing problems in this
>context. However, it is certainly an issue for the actual selection 
>of the target AR, but TAR selection is not within the scope of the
>CAR discovery protocol.

If you operated a network that supported mobility, would you want the
protocol to imply that other operators could discover your routers for
the purpose of handing off subscriber context to you or getting context
from you? Possibly one or the other, depending on who pays whom, but
you might not want to treat other domain's routers according to the
same policy. You might not even want your competitors to know how well
you cover particular regions.

John


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


From seamoby-admin@ietf.org  Mon Jan 14 13:06: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 NAA10216
	for ; Mon, 14 Jan 2002 13:06: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 MAA16814;
	Mon, 14 Jan 2002 12:50: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 MAA16785
	for ; Mon, 14 Jan 2002 12:50:16 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09335
	for ; Mon, 14 Jan 2002 12:50:14 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0EHnXS01636;
	Mon, 14 Jan 2002 09:49:33 -0800 (PST)
Message-ID: <00b801c19d23$99a750e0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Govind Krishnamurthi" ,
        "John Schnizlein" 
Cc: 
References: <4.3.2.7.2.20020114113728.03782008@diablo.cisco.com>
Subject: Re: [Seamoby] CAR Discovery Requirements
Date: Mon, 14 Jan 2002 09:47: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

John,

> It would require resolving which users are subscribers of which
domains,
> or complex inter-domain roaming and billing reciprocity.
>
> While it seems reasonable to avoid locking mobile stations into a
single
> domain, the policy interactions of requiring multiple-domain discovery
> would make the task much more difficult at the start.
>

I'm not quite sure I understand the reasoning behind this statement. How
does
inter-domain CAR discovery complicate roaming and billing reciprocity
any
more than simply statically configuring the inter-domain CAR routers?

            jak


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


From seamoby-admin@ietf.org  Mon Jan 14 13:10: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 NAA10370
	for ; Mon, 14 Jan 2002 13:10: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 MAA16580;
	Mon, 14 Jan 2002 12:47: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 MAA16551
	for ; Mon, 14 Jan 2002 12:47:12 -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 MAA09149
	for ; Mon, 14 Jan 2002 12:47:10 -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 g0EHkd308316;
	Mon, 14 Jan 2002 12:46:39 -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 g0EHkb126045;
	Mon, 14 Jan 2002 12:46:37 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 14 Jan 2002 12:46:37 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA476E@zcard031.ca.nortel.com>
From: "Gary Kenward"
To: "'John Schnizlein'" 
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Mon, 14 Jan 2002 12:46:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19D23.66AC7940"
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_01C19D23.66AC7940
Content-Type: text/plain;
	charset="ISO-8859-1"



> -----Original Message-----
> From: John Schnizlein [mailto:jschnizl@cisco.com]
> Sent: January 14, 2002 12:29
> To: Hesham Soliman (ERA)
> Cc: Govind Krishnamurthi; seamoby@ietf.org
> Subject: RE: [Seamoby] CAR Discovery Requirements
> 
> 
*snip*
> 
> The issue is potentially even more problematic for AR - AR. Would the
> operator of an access service willingly include another operator's
> routers to be neighbors, encouraging the possibility that the MN
> would switch into/out-of service from a different provider?
> We know that telephone companies try to avoid this.

Inter-domain roaming of this type is common in cellular networks. 
In the US inter-domain handover is specified in IS-41. The operators 
may prefer to keep a customer in their network, but they recognize that 
mobility has greater value to the customer if it is not limited artificially

by administrative domains, and most operators cannot provide contiguous, 
continent wide coverage.

Gary

*snip*

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

------_=_NextPart_001_01C19D23.66AC7940
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] CAR Discovery Requirements








> -----Original Message-----

> From: John Schnizlein [mailto:jschnizl@cisco.com]=


> Sent: January 14, 2002 12:29

> To: Hesham Soliman (ERA)

> Cc: Govind Krishnamurthi; =
seamoby@ietf.org

> Subject: RE: [Seamoby] CAR Discovery =
Requirements

> 

> 

*snip*

> 

> The issue is potentially even more problematic =
for AR - AR. Would the

> operator of an access service willingly include =
another operator's

> routers to be neighbors, encouraging the =
possibility that the MN

> would switch into/out-of service from a =
different provider?

> We know that telephone companies try to avoid =
this.




Inter-domain roaming of this type is common in =
cellular networks. 

In the US inter-domain handover is specified in =
IS-41. The operators 

may prefer to keep a customer in their network, but =
they recognize that 

mobility has greater value to the customer if it is =
not limited artificially 

by administrative domains, and most operators cannot =
provide contiguous, 

continent wide coverage.




Gary




*snip*




> 

> John

> 

> 

> =
_______________________________________________

> Seamoby mailing list

> Seamoby@ietf.org

> https://www1.ietf.org/mailman/listinfo/seamoby

> 





------_=_NextPart_001_01C19D23.66AC7940--

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


From seamoby-admin@ietf.org  Mon Jan 14 13:15: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 NAA10555
	for ; Mon, 14 Jan 2002 13:15: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 MAA17027;
	Mon, 14 Jan 2002 12:53: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 MAA16998
	for ; Mon, 14 Jan 2002 12:53:31 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09538
	for ; Mon, 14 Jan 2002 12:53:29 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0EHqqS01822;
	Mon, 14 Jan 2002 09:52:52 -0800 (PST)
Message-ID: <00c001c19d24$101c05e0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Christophe Jelger" , 
References: <027201c19d1c$fe949500$ac5a4f82@ustrasbg.fr>
Subject: Re: [Seamoby] Problem Statement
Date: Mon, 14 Jan 2002 09:51:15 -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


> 1) First, there has been almost no studies at all about the join
latency of
> multicast communications and I find it inadequate to say that
something is
> better or worse than something that has not been evaluated (even if it
may
> intuitively be the case)
>

The draft doesn't say that it will be, it just says that it might. If
you have
evidence to the contrary, then please feel free to write a draft on it.

> 2) Second, the term "faster" or "quicker" has to be carefully defined
to
> have a strict sense. What I mean is that with context transfer, the
process
> of joining a multicast group (with respect to the nAR) can be
anticipated
> and therefore after the handoff completes the multicast traffic may
already
> be delivered in the new network and in that case the service
disruption is
> almost null. The whole process of context tranfer may be longer than a
> native multicast join process from the new network but the service
> disruption time may be shorter with context transfer.
>

If joining the service from scratch is faster than context transfer,
then
the join should be used by all means. Context transfer is not being
proposed as a replacement for everything, just those services (for
want of a better word) that would require a long transient to
restart from scratch.

            jak


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


From seamoby-admin@ietf.org  Mon Jan 14 13:22: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 NAA10999
	for ; Mon, 14 Jan 2002 13:22: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 MAA16495;
	Mon, 14 Jan 2002 12:45: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 MAA16463
	for ; Mon, 14 Jan 2002 12:45:17 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09078
	for ; Mon, 14 Jan 2002 12:45:15 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0EHiaS01379;
	Mon, 14 Jan 2002 09:44:36 -0800 (PST)
Message-ID: <008f01c19d22$e8998a70$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Hesham Soliman \(ERA\)" ,
        "'Trossen Dirk \(NRC/Boston\)'" ,
        "Govind Krishnamurthi" , 
References: <4DA6EA82906FD511BE2F00508BCF053801C4C1F1@Esealnt861.al.sw.ericsson.se>
Date: Mon, 14 Jan 2002 09:42:59 -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] Re: CAR Discovery 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

Hesham,

Thanx for your comments. I will request that Govind make the appropriate
changes to the draft, and we will
submit an update prior sending it to the IESG.

            jak

----- Original Message -----
From: "Hesham Soliman (ERA)" 
To: "'James Kempf'" ; "Hesham Soliman (ERA)"
; "'Trossen Dirk (NRC/Boston)'"
; "Govind Krishnamurthi" ;

Sent: Monday, January 14, 2002 7:55 AM
Subject: RE: CAR Discovery Draft


> James,
>
>   > It certainly would have been helpful if you had posted your
comments
>   > during the Last Call period.
>   > Last Call expired Jan. 4 on this document. I don't believe
>   > comments sent
>   > in after
>   > Last Call necessarily need to be accommodated, but, if
>   > these are simple
>   > editorial changes that can be
>   >  resolved in the next day or two, then I think we can
>   > accommodate them.
>   > However, I do not want to get into a
>   >  long discussion about requirements prior to releasing the problem
>   > statement.
>
> => The requirements discussion is seaprate from my
> comments on the problem statement. I would have liked
> to send them earlier too, but as I said it's a very
> common holiday period. Perhaps something to think about
> with future last calls.
>
>   >
>   > > => To me the following text from the draft suggests
>   > > that the AR knows ALL GAARs. I think that's unrealistic.
>   > >
>   > >   4.1 Anticipated CAR Discovery
>   > >
>   > >    In this approach, an AR currently serving the MN identifies
all
>   > CARs
>   > >    for the MN's handoff, at some point prior to handoff.
>   > >
>   >
>   > How about:
>   >
>   >     In this approach, an AR currently serving the MN
>   > identifies some set
>   > of
>   >     suitable CARs for the MN's handoff, at some point prior
>   > to handoff.
>
> => Fine with me
>   >
>   > If this text is unsatisfactory, please feel free to propose an
>   > alternative.
>   >
>   > > => anticipation should not be associated with the
>   > > case where the MN does not signal, you can have
>   > > anticipation when the MN signals also. Therefore
>   > > associating 'anticipation' with a certain model
>   > > where the MN does not signal, does not seem right.
>   > >
>   > > I'm referring to the title of ch 4.1
>   > >
>   >
>   > One of the problems with not having a consistent set
>   > of terminology for wireless networking in the IETF
>   > is that it becomes difficult to find a word that describes
>   > the concept you are trying to get at without impinging
>   > on what somebody else thinks a particular word
>   > means. I believe this is the case here. The "anticipated"
>   > here has nothing to do with "anticipated handover."
>   > Here, the AR is anticipating the need for CARs
>   > by performing discovery prior to the MN needing
>   > them.
>
> => Then it should be explicitly stated that the
> anticipation is 'AR-based'. Simply saying
> 'anticipation' in isolation and not mentioning
> this term in ch 4.2 is misleading because it associates
> 'anticipation' with a certain mechanism.
>
>   > Perhaps another word would be suitable? Please
>   > feel free to suggest one. Perhaps "router based"?
>
> => Exactly, I think 'access router- based' is more
> appropriate.
>
> Hesham
>
>   >
>   >             jak
>   >
>


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


From seamoby-admin@ietf.org  Mon Jan 14 13:22: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 NAA11001
	for ; Mon, 14 Jan 2002 13:22: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 NAA17927;
	Mon, 14 Jan 2002 13:01: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 NAA17896
	for ; Mon, 14 Jan 2002 13:01:17 -0500 (EST)
Received: from clarinet.u-strasbg.fr (IDENT:root@clarinet.u-strasbg.fr [130.79.90.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09999
	for ; Mon, 14 Jan 2002 13:01:15 -0500 (EST)
Received: from PATINET (patinet.u-strasbg.fr [130.79.90.172])
	by clarinet.u-strasbg.fr (8.9.3/8.9.3) with SMTP id TAA03871
	for ; Mon, 14 Jan 2002 19:01:16 +0100
Message-ID: <02d001c19d25$7aa837c0$ac5a4f82@ustrasbg.fr>
From: "Christophe Jelger" 
To: 
References: <027201c19d1c$fe949500$ac5a4f82@ustrasbg.fr> <00c001c19d24$101c05e0$7e6015ac@T23KEMPF>
Subject: Re: [Seamoby] Problem Statement
Date: Mon, 14 Jan 2002 19:01:23 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
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

Yep but that's exactly what I want to point out ... it may be faster to join
a multicast group in the traditional way but the service disruption should
be smaller with context transfer before the multicast delivery at the new
network can be anticipated. What I mainly want to say is that it's not a
matter of quick establishment or not, the main point is to minimize the
service disruption (in the case of multicast for example).

Christophe

>
> If joining the service from scratch is faster than context transfer,
> then
> the join should be used by all means. Context transfer is not being
> proposed as a replacement for everything, just those services (for
> want of a better word) that would require a long transient to
> restart from scratch.
>
>             jak
>


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


From seamoby-admin@ietf.org  Mon Jan 14 13:22: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 NAA11002
	for ; Mon, 14 Jan 2002 13:22: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 MAA17384;
	Mon, 14 Jan 2002 12:57: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 MAA17343
	for ; Mon, 14 Jan 2002 12:57:46 -0500 (EST)
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09806
	for ; Mon, 14 Jan 2002 12:57:44 -0500 (EST)
Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn2-595.cisco.com [10.82.242.83]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA21368; Mon, 14 Jan 2002 09:57:14 -0800 (PST)
Message-Id: <4.3.2.7.2.20020114125144.00bab0b8@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 14 Jan 2002 12:56:10 -0500
To: "James Kempf" 
From: John Schnizlein 
Subject: Re: [Seamoby] CAR Discovery Requirements
Cc: 
In-Reply-To: <00b801c19d23$99a750e0$7e6015ac@T23KEMPF>
References: <4.3.2.7.2.20020114113728.03782008@diablo.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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

At 12:47 PM 1/14/2002, James Kempf wrote:

>> It would require resolving which users are subscribers of which
>> domains or complex inter-domain roaming and billing reciprocity.
>>
>> While it seems reasonable to avoid locking mobile stations into a
>> single domain, the policy interactions of requiring multiple-domain 
>> discovery would make the task much more difficult at the start.
>
>I'm not quite sure I understand the reasoning behind this statement. 
>How does inter-domain CAR discovery complicate roaming and billing
>reciprocity any more than simply statically configuring the 
>inter-domain CAR routers?

It is not increasing the complexity of roaming and reciprocity that 
worries me, it is the potential that requiring discovery be inter-domain 
would complicate the discovery (by drawing in these difficult issues).

John


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


From seamoby-admin@ietf.org  Mon Jan 14 13:25:21 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 NAA11107
	for ; Mon, 14 Jan 2002 13:25:21 -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 NAA18149;
	Mon, 14 Jan 2002 13:07: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 NAA18109
	for ; Mon, 14 Jan 2002 13:07:45 -0500 (EST)
Received: from hotmail.com (f159.law9.hotmail.com [64.4.9.159])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10280
	for ; Mon, 14 Jan 2002 13:07:42 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 14 Jan 2002 10:07:13 -0800
Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP;
	Mon, 14 Jan 2002 18:07:13 GMT
X-Originating-IP: [63.78.179.4]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: Re: [Seamoby] CAR Discovery Requirements
Date: Mon, 14 Jan 2002 13:07:13 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 14 Jan 2002 18:07:13.0892 (UTC) FILETIME=[4B313A40:01C19D26]
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

John,
What you ask is here is clearly an implementation issue. Whether
the protocol becomes complicated by including inter-domain discovery
is debatable. What we are looking into right now is whether there
SHOULD or MUST be support for inter-domain domain discovery. Many of
us feel it is necessary given that the Internet is  a bunch of domains
put together.

-Govind.


>At 12:47 PM 1/14/2002, James Kempf wrote:
>
> >> It would require resolving which users are subscribers of which
> >> domains or complex inter-domain roaming and billing reciprocity.
> >>
> >> While it seems reasonable to avoid locking mobile stations into a
> >> single domain, the policy interactions of requiring multiple-domain
> >> discovery would make the task much more difficult at the start.
> >
> >I'm not quite sure I understand the reasoning behind this statement.
> >How does inter-domain CAR discovery complicate roaming and billing
> >reciprocity any more than simply statically configuring the
> >inter-domain CAR routers?
>
>It is not increasing the complexity of roaming and reciprocity that
>worries me, it is the potential that requiring discovery be inter-domain
>would complicate the discovery (by drawing in these difficult issues).
>
>John
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby




_________________________________________________________________
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  Mon Jan 14 13:31: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 NAA11341
	for ; Mon, 14 Jan 2002 13:31: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 NAA18306;
	Mon, 14 Jan 2002 13:12: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 NAA18278
	for ; Mon, 14 Jan 2002 13:12:42 -0500 (EST)
Received: from hotmail.com (f100.law9.hotmail.com [64.4.9.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10436
	for ; Mon, 14 Jan 2002 13:12:39 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 14 Jan 2002 10:12:11 -0800
Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP;
	Mon, 14 Jan 2002 18:12:10 GMT
X-Originating-IP: [63.78.179.4]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Mon, 14 Jan 2002 13:12:10 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 14 Jan 2002 18:12:11.0194 (UTC) FILETIME=[FC65E9A0:01C19D26]
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


Hesham,
Where does the current set of requirements preclude any sort of mobile node 
involvement. I think
whether an MN is involved or not is implementation specific.. and
not a requirements issue. I don't think the requirements for CAR discovery 
change whether a MN is involved or not. Also letting the MN or AR decide 
where actually to handover is out of scope of CAR discovery.
Just letting the MN also hear does not complete CAR discovery.. CARs 
comprise of GAARS + their capabilities.. What you say is just GAARs.

-Govind.
> >...
>   > >6. Protocol applicability ? SHOULD (?)
>   > >(show of hands indicated that this item should be changed
>   > to a MUST)
>   > >support inter-domain as well as Intra-domain scope
>   >
>   > Inter-domain discovery of access routers (which seems
>   > implied by what
>   > might otherwise seem an innocuous protocol design feature)
>   > is problematic.
>   >
>   > It would require resolving which users are subscribers of
>   > which domains,
>   > or complex inter-domain roaming and billing reciprocity.
>
>=> This is exactly why I urge you (this wg) to clearly
>explain which protocol you are talking about. AR - AR or
>AR MN ???
>Clearly AR - MN lis an obvious way to discover all routers
>that the MN can hear. Inter/intra domain issues are
>not relevant.
>
>So please make it clear which part of the protocol
>you're referring to. We should not always assume
>that we're discussing the AR - AR case.
>
>   > While it seems reasonable to avoid locking mobile stations
>   > into a single
>   > domain, the policy interactions of requiring
>   > multiple-domain discovery
>   > would make the task much more difficult at the start.
>
>=> Certainly. But there is an easy way of doing that:
>Let the MN decide.
>
>Hesham
>
>   > _______________________________________________
>   > 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




_________________________________________________________________
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  Mon Jan 14 13:31: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 NAA11350
	for ; Mon, 14 Jan 2002 13:31: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 MAA17185;
	Mon, 14 Jan 2002 12:55: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 MAA17154
	for ; Mon, 14 Jan 2002 12:55:39 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09668
	for ; Mon, 14 Jan 2002 12:55:34 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0EHstS01912;
	Mon, 14 Jan 2002 09:54:55 -0800 (PST)
Message-ID: <00c601c19d24$599699b0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Hesham Soliman \(ERA\)" ,
        "'John Schnizlein'" ,
        "Govind Krishnamurthi" 
Cc: 
References: <4DA6EA82906FD511BE2F00508BCF053801C4C1F6@Esealnt861.al.sw.ericsson.se>
Subject: Re: [Seamoby] CAR Discovery Requirements
Date: Mon, 14 Jan 2002 09:53: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
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,



> => This is exactly why I urge you (this wg) to clearly 
> explain which protocol you are talking about. AR - AR or
> AR MN ???
> Clearly AR - MN lis an obvious way to discover all routers 
> that the MN can hear. Inter/intra domain issues are 
> not relevant. 
> 
> So please make it clear which part of the protocol
> you're referring to. We should not always assume 
> that we're discussing the AR - AR case. 
> 
You are correct, the protocol must apply to both cases,
and the requirements should reflect that.

Perhaps it would make sense to divide the requirements
document into three sections: a) common requirements,
b) requirements for AR-AR case, c) requirements
for AR-MN case.


            jak


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


From seamoby-admin@ietf.org  Mon Jan 14 13:31: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 NAA11381
	for ; Mon, 14 Jan 2002 13:31: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 NAA18403;
	Mon, 14 Jan 2002 13:14: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 NAA18371
	for ; Mon, 14 Jan 2002 13:14:30 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10506
	for ; Mon, 14 Jan 2002 13:14:27 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0EIDqS02816;
	Mon, 14 Jan 2002 10:13:52 -0800 (PST)
Message-ID: <00ec01c19d26$ff0880f0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "John Schnizlein" 
Cc: 
References: <4.3.2.7.2.20020114113728.03782008@diablo.cisco.com> <4.3.2.7.2.20020114125144.00bab0b8@diablo.cisco.com>
Subject: Re: [Seamoby] CAR Discovery Requirements
Date: Mon, 14 Jan 2002 10:12:15 -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

John,

> >> It would require resolving which users are subscribers of which
> >> domains or complex inter-domain roaming and billing reciprocity.
> >>
> >> While it seems reasonable to avoid locking mobile stations into a
> >> single domain, the policy interactions of requiring multiple-domain
> >> discovery would make the task much more difficult at the start.
> >
> >I'm not quite sure I understand the reasoning behind this statement.
> >How does inter-domain CAR discovery complicate roaming and billing
> >reciprocity any more than simply statically configuring the
> >inter-domain CAR routers?
>
> It is not increasing the complexity of roaming and reciprocity that
> worries me, it is the potential that requiring discovery be
inter-domain
> would complicate the discovery (by drawing in these difficult issues).
>

I believe that your intuition here is correct, that inter-domain
discovery
will compilicate discovery in general. However, I don't necessarily see
there being only one way to do discovery. Just as their are inter-
and intra-domain routing protocols, I think there could be inter-
and intra-domain discovery protocols, with the intra-domain
protocol being simpler. One could argue that
routers on the border of a domain which could participate
in an inter-domain handover are actually border routers, though
to my limited understanding, the current border router protocol
does not envision a host sitting between border routers, much
less moving between them.

As a practical matter, I think that we will in fact need some way
of doing inter-domain discovery, particularly for inter-technology
handover. Consider a dual interface device, with one interface
on 802.11 and the other on cdma2K. The current situation is
that there is one collection of wireless ISPs that are supplying
802.11 hotspot service and another that are supplying
cdma2K wide area service. Unless the MN and/or
ARs have the capability to do inter-domain discovery, the
service providers will end up statically configuring their
routers with the addresses of the other routers, which could
lead to problems if the network topologies change unexpectedly.

Alternatively, without any information about ARs in the other domain,
the MNs will be forced back to standard MIP handover to
move from one provider's network to the other's. While this might
not seem so bad in the end, it will certainly preclude doing fast
handover of voice calls from one network to the other.
Since the current IS-41 protocol on SS7 allows intersystem
handovers for ongoing calls (though I do not know
in the end what percentage of these handovers actually
are fast enough that the user doesn't notice), this will be a limitation
of VoIP networks that is not there in the current cellular
networks, and thus an argument against deploying VoIP
for cellular.

It would be interesting to have some data on the
actual time involved in an intersystem handover
on IS-41. If the amount of time is on the order
of seconds, then maybe we don't have to worry
about this problem.

            jak


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


From seamoby-admin@ietf.org  Mon Jan 14 13: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 NAA11624
	for ; Mon, 14 Jan 2002 13: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 NAA18535;
	Mon, 14 Jan 2002 13:17: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 NAA18505
	for ; Mon, 14 Jan 2002 13:16:59 -0500 (EST)
Received: from hotmail.com (f238.law9.hotmail.com [64.4.9.238])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10655
	for ; Mon, 14 Jan 2002 13:16:56 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 14 Jan 2002 10:16:28 -0800
Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP;
	Mon, 14 Jan 2002 18:16:27 GMT
X-Originating-IP: [63.78.179.4]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Mon, 14 Jan 2002 13:16:27 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 14 Jan 2002 18:16:28.0122 (UTC) FILETIME=[958A03A0:01C19D27]
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


Good point,
and as pointed out in the Issues draft the CAR discovery may not be used
just in the case of mobility. It could be used for example, to even out
the load on the ARs in a hotspot.
-Govind.
> >
> >
>*snip*
> >
> > The issue is potentially even more problematic for AR - AR. Would the
> > operator of an access service willingly include another operator's
> > routers to be neighbors, encouraging the possibility that the MN
> > would switch into/out-of service from a different provider?
> > We know that telephone companies try to avoid this.
>
>Inter-domain roaming of this type is common in cellular networks.
>In the US inter-domain handover is specified in IS-41. The operators
>may prefer to keep a customer in their network, but they recognize that
>mobility has greater value to the customer if it is not limited 
>artificially
>
>by administrative domains, and most operators cannot provide contiguous,
>continent wide coverage.
>
>Gary
>
>*snip*
>
> >
> > John
> >
> >
> > _______________________________________________
> > 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  Mon Jan 14 13:56: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 NAA12666
	for ; Mon, 14 Jan 2002 13:56: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 NAA19300;
	Mon, 14 Jan 2002 13:38: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 NAA19272
	for ; Mon, 14 Jan 2002 13:38:26 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11642
	for ; Mon, 14 Jan 2002 13:38:22 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0EIbLS04006;
	Mon, 14 Jan 2002 10:37:36 -0800 (PST)
Message-ID: <013901c19d2a$4fbf9f30$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Marco Liebsch" , "Seamoby" 
References: <3C42D563.BE04F6F5@ccrle.nec.de>
Subject: Re: [Seamoby] DMHA framework draft architecture
Date: Mon, 14 Jan 2002 10:35: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

Marco,

I had been thinking about this change myself.
So the basic idea is that the composite paging
agent contains that part of the tracking agent
that does IP paging area tracking, dormant
mode monitoring agent, and that part of
the paging agent which initiates IP paging.
Another part of the paging agent and
tracking agent sits in the access routers.
The part in the access router is responsible for
taking the L3 paging and tracking protocol
and converting it into an L2 paging and tracking
protocol, or, if the L2 does not support such
a protocol, translating into a last hop L3 protocol
to the MN (which actually might be the same
as the incoming L3 tracking and paging protocol).

I think this architecture would facilitate failover
if the composite paging agent for an IP
paging area fails. Consider
the following scenario. The composite agent
keeps track of the subnets it is currently covering.
Periodically, it propagates that information
to other, neighboring paging agents, just like
routing protocols do. Now suppose a paging
agent fails and the neighboring agents notice
due to an update failing to arrive. The neighboring
agents could use a dynamic paging area protocol
to arrange for the hosts under the control of the
failed paging agent to receive new paging
area location informing them that their
paging area changed. This would allow
the hosts to continue receiving service even though
their paging agent failed, without having to use
a server duplication protocol for the composite
agent. So paging area resiliency would work
somewhat like routing resilency, which is
a proven benefit of Internet routing.

            jak

----- Original Message -----
From: "Marco Liebsch" 
To: "Seamoby" 
Sent: Monday, January 14, 2002 4:56 AM
Subject: [Seamoby] DMHA framework draft architecture


> Hi all,
>
> referring to the functional architecture for DMHA in RFC 3154,
currently
> the protocol base line draft describes a composite architecture.
> Appendix C of draft-renker-paging-ipv6-01.txt illustrates a mapping
> between the described architecture and the functional elements given
in
> RFC 3154. In order to come up with a first cut of a framework draft, I
> would like to request a WG consensus of taking over the proposed
> architecture, having a composite Paging Agent node (PA node)
addressing
> paging related attendant functional entities within ARs. Actually,
> taking the description of the Paging Agent Functional Entity (FE) as
it
> is described in RFC 3154, this functional entity could be split into a
> master FE, currently assigned to the PA node, and multiple attendant
> FEs, located in ARs, responsible for local paging function and mapping
> L3 paging requests to lower layer specifics.
>
> Comments are welcome.
>
> marco
>
>
>
>
> _______________________________________________
> 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 Jan 14 13:57: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 NAA12735
	for ; Mon, 14 Jan 2002 13:57: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 NAA19392;
	Mon, 14 Jan 2002 13:42: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 NAA19365
	for ; Mon, 14 Jan 2002 13:42:09 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11883
	for ; Mon, 14 Jan 2002 13:42:06 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0EIfES04213;
	Mon, 14 Jan 2002 10:41:24 -0800 (PST)
Message-ID: <014101c19d2a$d7e87e90$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Marco Liebsch" , "Seamoby" 
References: <3C42DC28.F8220F2C@ccrle.nec.de>
Subject: Re: [Seamoby] openness for advanced paging strategies in DMHA
Date: Mon, 14 Jan 2002 10:39:37 -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 that the Seamoby DMHA protocol must provide
the mechanism for implemeting a variety of paging policies.
However, I don't believe the DMHA protocol should
specify a particular policy or policies. The protocol spec
might use one or two example policies to show how
the paging mechanism can be used, but that could also
be done in another document which is more comprehensive
and illustrates how to deploy a variety of paging policies.
So I support separating out the discussion of implementing
particular paging policies in a separate document.

            jak

----- Original Message -----
From: "Marco Liebsch" 
To: "Seamoby" 
Sent: Monday, January 14, 2002 5:24 AM
Subject: [Seamoby] openness for advanced paging strategies in DMHA


> Hi all,
>
> the architecture of the Paging Agent node in the current base line
draft
> for the WG's DMHA protocol intends to be open for several paging
> strategies. As James proposed, maybe it is appropriate to take
detailed
> sections addressing different paging strategies and characteristics
out
> for the WG's protocol framework draft. In my opinion, deployment of
> different paging strategies is an important area, therefore, the
future
> WG architecture and the protocol for DMHA should allow deployment of
> several paging strategies. Therefore, I propose the following: Taking
> out the details on paging strategies and having later a reference on a
> possibly stand-alone document describing the paging strategy
specifics.
> We could have a very brief comment in the draft addressing the 'role
of
> a paging strategy' (sec. 1.1.4 in draft-renker) and the concept's
> openness.
>
> Comments are appreciated.
>
> marco
>
>
>
>
> _______________________________________________
> 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 Jan 14 14:35: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 OAA14847
	for ; Mon, 14 Jan 2002 14:35: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 OAA20492;
	Mon, 14 Jan 2002 14:08: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 OAA20461
	for ; Mon, 14 Jan 2002 14:08:11 -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 OAA13407
	for ; Mon, 14 Jan 2002 14:08:08 -0500 (EST)
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 g0EJ9dQ01334
	for ; Mon, 14 Jan 2002 13:09:39 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 14 Jan 2002 13:08:08 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 14 Jan 2002 13:08:08 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR Discovery Requirements
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 14 Jan 2002 14:08:07 -0500
Message-ID: 
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcGdJLxc5swy4QkUEdaJYAAIx6TWpQABlfDw
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext James Kempf'" ,
        "Hesham Soliman (ERA)" ,
        "John Schnizlein" ,
        "Govind Krishnamurthi" 
Cc: 
X-OriginalArrivalTime: 14 Jan 2002 19:08:08.0462 (UTC) FILETIME=[CD7C5AE0:01C19D2E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA20462
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,

Can anybody make clear to me why this separation of requirements is
really necessary? In the issues draft, we have identified three cases 
(anticipated, dynamic, and hybrid) to address the problem of CAR
discovery, 
and to my understanding the requirements cover all three. I would urge 
not only to suggest a separation but really to outline a proper
definition of
(separate) requirements so that everybody can see that this separation
makes sense. 

But just as a reminder (please look into the issue draft). This, i.e.,
CAR discovery, is merely about identifying GAARs including their
capabilities,
whereby the the spectrum and exact definition of the latter are not
within
the scope of the protocol, to enable either the AR (anticipated case) or
the MN (dynamic case) to determine a set of ARs, namely the CARs, that
meet 
MN's requirements.

HOW (and by what parties) to determine this set, e.g., by signalling the
MN's requirements to the AR for the anticipated case, and how to select
a 
TAR, i.e., the final candidate for handover, are out of scope of this 
protocol.

Hence, I don't understand how billing and accounting comes in here and
why anything should be considered separately for AR-AR or AR-MN. The
problems
to be addressed are similar for all three cases, namely anticipated,
dynamic, and hybrid. I admit that the decision as to how to select the
TAR 
would probably heavily depend on operator's policies. But this is
(again) not in
the scope of what we are discussing here. 

For instance, if you want to keep other ARs out of the decision of TAR
selection,
then implement your TAR selection algorithm appropriately. It does not 
at all influence the CAR discovery. It is rather a local (adminstrative)
implementation issue. And that's how it is defined in the issues
draft. 

In conclusion, John's comments are already considered by taking these
problems out of the scope of CAR discovery. How they still affect CAR 
discovery and its requirements, is unclear to me.

Regards,


Dirk

> -----Original Message-----
> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Monday, January 14, 2002 12:53 PM
> To: Hesham Soliman (ERA); John Schnizlein; Govind Krishnamurthi
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CAR Discovery Requirements
> 
> 
> Hesham,
> 
> 
> 
> > => This is exactly why I urge you (this wg) to clearly 
> > explain which protocol you are talking about. AR - AR or
> > AR MN ???
> > Clearly AR - MN lis an obvious way to discover all routers 
> > that the MN can hear. Inter/intra domain issues are 
> > not relevant. 
> > 
> > So please make it clear which part of the protocol
> > you're referring to. We should not always assume 
> > that we're discussing the AR - AR case. 
> > 
> You are correct, the protocol must apply to both cases,
> and the requirements should reflect that.
> 
> Perhaps it would make sense to divide the requirements
> document into three sections: a) common requirements,
> b) requirements for AR-AR case, c) requirements
> for AR-MN case.
> 
> 
>             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 Jan 14 15:26: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 PAA17461
	for ; Mon, 14 Jan 2002 15:26: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 PAA22507;
	Mon, 14 Jan 2002 15:04: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 PAA22480
	for ; Mon, 14 Jan 2002 15:04:29 -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 PAA16363
	for ; Mon, 14 Jan 2002 15:04:26 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA08965
	for ; Mon, 14 Jan 2002 14:03:57 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g0EK3vr20018
	for ; Mon, 14 Jan 2002 14:03:57 -0600 (CST)
Message-ID: <3C433991.2090906@alcatel.com>
Date: Mon, 14 Jan 2002 14:03: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
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Re: IP Paging Protocol
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 James,

  There has been a new development (Pls see the email that was forwarded 
to you).
 It seems now clear that there is no longer a consensus on draft-renker. 
I think that this draft can not be taken as WG document, and therefore 
serve as base.
  The assessment draft drafy-seamoby-paging-protocol-assessment-00.txt 
did not identify a clear winner but it seems that it has identified a 
clear loser (the renker draft)  in terms the marks given (72 marks 
versus 89, 90, etc).
 
  Here is the way out:

>We believe that the process of creating an IP paging protocol can be
>> substantially improved, and that the establishment in Seamoby of a
>> design team comprising the authors of the current proposal and few
>> other relevant parties is the only realistic solution (as it has
>> already happened in other IETF WGs). 
>


Regards,


-- 
Behcet 




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


From seamoby-admin@ietf.org  Mon Jan 14 15:33: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 PAA17823
	for ; Mon, 14 Jan 2002 15:33: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 PAA22655;
	Mon, 14 Jan 2002 15:13: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 PAA22628
	for ; Mon, 14 Jan 2002 15:13:18 -0500 (EST)
Received: from hotmail.com (f5.law7.hotmail.com [216.33.237.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16788
	for ; Mon, 14 Jan 2002 15:13:15 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 14 Jan 2002 12:12:46 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP;
	Mon, 14 Jan 2002 20:12:46 GMT
X-Originating-IP: [63.78.179.5]
From: "Hemant Chaskar" 
To: hesham.soliman@era.ericsson.se, kempf@docomolabs-usa.com, seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Mon, 14 Jan 2002 20:12:46 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 14 Jan 2002 20:12:46.0872 (UTC) FILETIME=[D532C180:01C19D37]
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 Hesham:

Opps, that was a slip of pen, of course. I meant Seamoby, and not NSIS. So, 
was the concern raised on SEAMOBY list, and what exactly was it?

Also, note that the term anticipated has been there since the first draft 
and before the first last call. Also, the period of first last call did 
_not_ overlap with the holiday season of any sort.

I do not know if it is good to change the name "anticipated" now as, for 
one, it has references at other places in document, as well as there is no 
other better alternative name. I do not think that AR-based better suited 
than anticipated. Anticipated discovery means discovery before actual 
handoff event. It could be AR-based on anyting else based.

However, we can certainly finetune the text to state that _a set_ of CARs 
(_not all_ CARs) are discovered. With that, can we close this tread now and 
conclude on the issues draft? Please let us know. Thanks.

Hemant


>From: "Hesham Soliman (ERA)" 
>To: "'Hemant Chaskar'" , kempf@docomolabs-usa.com,    
>     "Hesham Soliman (ERA)" ,        
>seamoby@ietf.org
>Subject: RE: [Seamoby] Status of WG Last Call
>Date: Mon, 14 Jan 2002 16:58:32 +0100
>
>Hi Hemant,
>
>   > I also did not see any comment from you on the NSIS list
>   > during the first
>   > last call that has not been attended to.
>
>=> I'm not on the NSIS list. This is a seamoby doc.
>
>   > Also, please note the difference between the "issues" draft, the
>   > "requirements" draft and the "solutions" draft.
>
>=> I made comments on both. I realise they are 2 different
>things.
>
>Hesham
>
>
>   >
>   > Hemant
>   >
>   > >From: "James Kempf" 
>   > >To: "Hesham Soliman \(ERA\)"
>   > ,
>   > >
>   > >Subject: Re: [Seamoby] Status of WG Last Call
>   > >Date: Fri, 11 Jan 2002 10:19:05 -0800
>   > >
>   > >Hesham,
>   > >
>   > >The usual procedure for comments is that they be sent to
>   > the list. Any
>   > >Last
>   > >Call comments must be sent to the list in order that there
>   > be a record
>   > >of them. I don't recall any email from you on
>   > >draft-ietf-seamoby-car-discovery-issues-01.txt
>   > >during the last call period, but perhaps I missed it. If
>   > you have any
>   > >comments,
>   > >please send them out within the next day.
>   > >
>   > >Also note that we are talking here about the problem
>   > statement, not the
>   > >requirements.
>   > >I have noted a thread over the last couple days on
>   > requirements, and
>   > >your comments, will
>   > >naturally be taken into account when the requirements
>   > draft is done.
>   > >
>   > >                 jak
>   > >
>   > >----- Original Message -----
>   > >From: "Hesham Soliman (ERA)" 
>   > >To: "'James Kempf'" ; 
>   > >Sent: Friday, January 11, 2002 9:59 AM
>   > >Subject: RE: [Seamoby] Status of WG Last Call
>   > >
>   > >
>   > > >   >
>   > > >   > WG Last call has expired on the following drafts:
>   > > >   >
>   > > >   > 1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
>   > > >   > 2) draft-ietf-seamoby-ct-reqs-02.txt
>   > > >   > 3) draft-ietf-seamoby-car-discovery-issues-01.txt
>   > > >   > 4) draft-ietf-seamoby-paging-protocol-assessment-00.txt
>   > > >   >
>   > > >   > No comments were received on 1) and 3), they will
>   > now be sent to
>   > >the
>   > > >   > IESG for review.
>   > > >
>   > > > => Just a minute, we _are_ discussing comments on 3).
>   > > > I've also made these comments in London.
>   > > >
>   > > > Hesham
>   > > >
>   > >
>   > >
>   > >_______________________________________________
>   > >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


_________________________________________________________________
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  Mon Jan 14 15:55: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 PAA18679
	for ; Mon, 14 Jan 2002 15:55: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 PAA23524;
	Mon, 14 Jan 2002 15:33: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 PAA23484
	for ; Mon, 14 Jan 2002 15:33:48 -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 PAA17869
	for ; Mon, 14 Jan 2002 15:33:44 -0500 (EST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA25885 for ; Mon, 14 Jan 2002 13:33:45 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA22957 for ; Mon, 14 Jan 2002 13:22:58 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52)
	id ; Mon, 14 Jan 2002 14:33:44 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FD4F@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'James Kempf'" ,
        Gary Kenward
	 ,
        George Tsirtsis ,
        Nakhjiri Madjid-MNAKHJI1 ,
        seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Mon, 14 Jan 2002 14:33:43 -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

I don't want 4.12 removed, because I don't want to put
the burden of context management (collection and dump)
on the context transfer protocol. Removing 4.12 would
add that extra requirement on CTP. CTP was supposed
to be a mere transport protocol. and that is why
I said you could reword it, if you want to, but not remove.
However, rewording it is up to people that are not happy with
it IMHO :)

I don't care about 4.15, since a MAY is not a requirement
anyway :)

and yes 5.5.2 is a 1000:1 condensation of a lot of reliability discussions,
it should stay. Nobody likes to get garbage instead of actual
context

Madjid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Friday, January 11, 2002 4:34 PM
To: Gary Kenward; George Tsirtsis; Nakhjiri Madjid-MNAKHJI1;
seamoby@ietf.org
Subject: Re: [Seamoby] Status of WG Last Call


Sorry, Gary, it wasn't a nonvote.

That you don't care about 4.12 and 4.15 means that you don't care
whether we get rid of them. Since George
wants to get rid of them, unless somebody else complains, they will go.

As for 5.5.2, since you want to keep it, it stays.

Since you didn't say anything about 4.13, it goes unless somebody cares
that it stays.

            jak

----- Original Message -----
From: "Gary Kenward" 
To: "'James Kempf'" ; "George Tsirtsis"
; "Nakhjiri Madjid-MNAKHJI1"
; 
Sent: Friday, January 11, 2002 2:19 PM
Subject: RE: [Seamoby] Status of WG Last Call


> Since I spoke up before and my name was mentioned in the recent
> exchange....
>
> I do not care about 4.12 or 4.15, one way or another.
>
> I do care about 5.5.2, but these requirements have revisited
> so many times that the rationale behind them are ethereal,
> so I will sit firmly on the fence.
>
> How that for an explicit non-vote?
>
> Gary
>
> > -----Original Message-----
> > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > Sent: January 11, 2002 17:10
> > To: George Tsirtsis; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> > Subject: Re: [Seamoby] Status of WG Last Call
> >
> >
> >
> >
> > > >From what I remember Gary said that he supports the
> > removal of 3 out
> > of the
> > > 4 points....so the 2 opinions against the removal do not
constitute
> > what I
> > > would call....WG consensus do they? In fact only Madjid
> > said that "we
> > could
> > > re-word but not remove"...who was the 2nd person against removal?
> > >
> > > Maybe you should ask "who cares?"
> > >
> >
> > Alright, but this is *the very last time*. We do really need
> > to get this
> > document on the way.
> > This is a concensus call. Is there any opposition to removing the
> > following requirements
> > from draft-ietf-seamoby-ct-reqs-02.txt:
> >
> > 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.
> >
> > Speak until Monday 3 PM Pacific Standard time or forever hold your
> > peace.
> >
> >             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 Jan 14 15:55: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 PAA18690
	for ; Mon, 14 Jan 2002 15:55: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 PAA22969;
	Mon, 14 Jan 2002 15:28: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 PAA22940
	for ; Mon, 14 Jan 2002 15:28:25 -0500 (EST)
Received: from hotmail.com (f214.law7.hotmail.com [216.33.237.214])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17560
	for ; Mon, 14 Jan 2002 15:28:21 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 14 Jan 2002 12:27:53 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP;
	Mon, 14 Jan 2002 20:27:53 GMT
X-Originating-IP: [63.78.179.5]
From: "Hemant Chaskar" 
To: jschnizl@cisco.com
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Mon, 14 Jan 2002 20:27:53 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 14 Jan 2002 20:27:53.0325 (UTC) FILETIME=[F17C81D0:01C19D39]
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 John:

Some comments inline:

>From: John Schnizlein 
>To: "Trossen Dirk (NRC/Boston)" 
>CC: "Govind Krishnamurthi" , 
>Subject: RE: [Seamoby] CAR Discovery Requirements
>Date: Mon, 14 Jan 2002 12:41:19 -0500
>
>At 11:57 AM 1/14/2002, Trossen Dirk (NRC/Boston) wrote:
>
> >I'm kind of confused by your comment.
> >Are you questioning the inter-domain handoff or the discovery?
> >Why do I have to resolve which users are subscribers of which
> >domains if I want to discover ARs in my proximity?
>
>I will admit the possibility that I simply don't understand.
>My impression is that the discovery is for the purpose of finding
>neighbors for potential context hand-off. One way to limit getting
>or giving hand-offs to/from domains with which the provider has no
>business relationship is to limit forming the neighborhood.

Whenever that is indeed the case, CAR discovery protocol will discover it. 
Either by getting explicit policy from the other router that it does not 
allow handoffs from the former or by not getting any answer to capability 
query. Policy information is an important piece of information that will be 
exchanged during capability exchange.

>
>In non-cyber-space, there are sometimes houses closer to mine that
>are considered a different neighborhood because their $/sq.ft. are
>so different. On just the other side of a street, the children often
>attend a different school (with sometimes dramatically different
>$/student expenditure).
>
>Is it necessary to preclude this method of operation for mobility?

We are not precluding this at all. Again dollar cost can be exchanged as a 
part of capability exchange.

>
> >We're discussing CAR discovery. I don't see your policy
> >interactions, inter-domain roaming, and billing problems in this
> >context. However, it is certainly an issue for the actual selection
> >of the target AR, but TAR selection is not within the scope of the
> >CAR discovery protocol.
>
>If you operated a network that supported mobility, would you want the
>protocol to imply that other operators could discover your routers for
>the purpose of handing off subscriber context to you or getting context
>from you? Possibly one or the other, depending on who pays whom, but
>you might not want to treat other domain's routers according to the
>same policy. You might not even want your competitors to know how well
>you cover particular regions.
>

If you bother to co-operate with other operators to provide seamless 
handoffs to MN, you should talk to them. You need not disclose AR's 
identities (IP addresses) for security reasons. That is why the requirement 
of private address space is important. Also, it is entirely upto the 
operator as to which capabilities it wants to disclose and which he does 
not.

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


_________________________________________________________________
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  Mon Jan 14 15:58: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 PAA18791
	for ; Mon, 14 Jan 2002 15:58: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 PAA23674;
	Mon, 14 Jan 2002 15:37: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 PAA23647
	for ; Mon, 14 Jan 2002 15:37:17 -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 PAA17971
	for ; Mon, 14 Jan 2002 15:37:13 -0500 (EST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA29334 for ; Mon, 14 Jan 2002 13:37:16 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA20235 for ; Mon, 14 Jan 2002 13:37:15 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52)
	id ; Mon, 14 Jan 2002 14:37:15 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FD50@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'Govind Krishnamurthi'" , seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Mon, 14 Jan 2002 14:37:15 -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, 
 you got it. But lets not get into "how much prior" right now :)

Madjid

-----Original Message-----
From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
Sent: Friday, January 11, 2002 6:02 PM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Status of WG Last Call


Do we loose much by letting 4.12 stay? I don't see this such a big
problem as the transferring AR much get the context prior to transfer
anyways.. so the only point is how much prior.
Maybe I'm missing something.
-Govind.

>
>
> > Since I spoke up before and my name was mentioned in the recent
> > exchange....
> >
> > I do not care about 4.12 or 4.15, one way or another.
> >
> > I do care about 5.5.2, but these requirements have revisited
> > so many times that the rationale behind them are ethereal,
> > so I will sit firmly on the fence.
> >
> > How that for an explicit non-vote?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: January 11, 2002 17:10
> > > To: George Tsirtsis; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> > > Subject: Re: [Seamoby] Status of WG Last Call
> > >
> > >
> > >
> > >
> > > > >From what I remember Gary said that he supports the
> > > removal of 3 out
> > > of the
> > > > 4 points....so the 2 opinions against the removal do not
>constitute
> > > what I
> > > > would call....WG consensus do they? In fact only Madjid
> > > said that "we
> > > could
> > > > re-word but not remove"...who was the 2nd person against removal?
> > > >
> > > > Maybe you should ask "who cares?"
> > > >
> > >
> > > Alright, but this is *the very last time*. We do really need
> > > to get this
> > > document on the way.
> > > This is a concensus call. Is there any opposition to removing the
> > > following requirements
> > > from draft-ietf-seamoby-ct-reqs-02.txt:
> > >
> > > 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.
> > >
> > > Speak until Monday 3 PM Pacific Standard time or forever hold your
> > > peace.
> > >
> > >             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




_________________________________________________________________
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

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


From seamoby-admin@ietf.org  Mon Jan 14 15:59: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 PAA18830
	for ; Mon, 14 Jan 2002 15:59: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 PAA23724;
	Mon, 14 Jan 2002 15:38: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 PAA23697
	for ; Mon, 14 Jan 2002 15:38:13 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18002
	for ; Mon, 14 Jan 2002 15:38:09 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0EKbWS09726;
	Mon, 14 Jan 2002 12:37:32 -0800 (PST)
Message-ID: <01f401c19d3b$110a3f00$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Hemant Chaskar" , ,
        
References: 
Subject: Re: [Seamoby] Status of WG Last Call
Date: Mon, 14 Jan 2002 12:35:55 -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

Hemant,

I believe Hesham has agreed to the editorial changes I suggested, and
I think they are minor enough that we won't have to go through
another last call. So I've suggested to Govind to make them
and rerelease the draft, then we will send it to the IESG.

As to what is or what isn't a holiday, I suppose that depends on
one's cultural perspective, but for many cultures, the end of
the year does include a few holidays. The last call period
on the draft did overlap with that period, but there was
a substantial amount of time before and after as well.

            jak

----- Original Message -----
From: "Hemant Chaskar" 
To: ; ;

Sent: Monday, January 14, 2002 8:12 PM
Subject: RE: [Seamoby] Status of WG Last Call


> Hi Hesham:
>
> Opps, that was a slip of pen, of course. I meant Seamoby, and not
NSIS. So,
> was the concern raised on SEAMOBY list, and what exactly was it?
>
> Also, note that the term anticipated has been there since the first
draft
> and before the first last call. Also, the period of first last call
did
> _not_ overlap with the holiday season of any sort.
>
> I do not know if it is good to change the name "anticipated" now as,
for
> one, it has references at other places in document, as well as there
is no
> other better alternative name. I do not think that AR-based better
suited
> than anticipated. Anticipated discovery means discovery before actual
> handoff event. It could be AR-based on anyting else based.
>
> However, we can certainly finetune the text to state that _a set_ of
CARs
> (_not all_ CARs) are discovered. With that, can we close this tread
now and
> conclude on the issues draft? Please let us know. Thanks.
>
> Hemant
>
>
> >From: "Hesham Soliman (ERA)" 
> >To: "'Hemant Chaskar'" ,
kempf@docomolabs-usa.com,
> >     "Hesham Soliman (ERA)" ,
> >seamoby@ietf.org
> >Subject: RE: [Seamoby] Status of WG Last Call
> >Date: Mon, 14 Jan 2002 16:58:32 +0100
> >
> >Hi Hemant,
> >
> >   > I also did not see any comment from you on the NSIS list
> >   > during the first
> >   > last call that has not been attended to.
> >
> >=> I'm not on the NSIS list. This is a seamoby doc.
> >
> >   > Also, please note the difference between the "issues" draft, the
> >   > "requirements" draft and the "solutions" draft.
> >
> >=> I made comments on both. I realise they are 2 different
> >things.
> >
> >Hesham
> >
> >
> >   >
> >   > Hemant
> >   >
> >   > >From: "James Kempf" 
> >   > >To: "Hesham Soliman \(ERA\)"
> >   > ,
> >   > >
> >   > >Subject: Re: [Seamoby] Status of WG Last Call
> >   > >Date: Fri, 11 Jan 2002 10:19:05 -0800
> >   > >
> >   > >Hesham,
> >   > >
> >   > >The usual procedure for comments is that they be sent to
> >   > the list. Any
> >   > >Last
> >   > >Call comments must be sent to the list in order that there
> >   > be a record
> >   > >of them. I don't recall any email from you on
> >   > >draft-ietf-seamoby-car-discovery-issues-01.txt
> >   > >during the last call period, but perhaps I missed it. If
> >   > you have any
> >   > >comments,
> >   > >please send them out within the next day.
> >   > >
> >   > >Also note that we are talking here about the problem
> >   > statement, not the
> >   > >requirements.
> >   > >I have noted a thread over the last couple days on
> >   > requirements, and
> >   > >your comments, will
> >   > >naturally be taken into account when the requirements
> >   > draft is done.
> >   > >
> >   > >                 jak
> >   > >
> >   > >----- Original Message -----
> >   > >From: "Hesham Soliman (ERA)" 
> >   > >To: "'James Kempf'" ;

> >   > >Sent: Friday, January 11, 2002 9:59 AM
> >   > >Subject: RE: [Seamoby] Status of WG Last Call
> >   > >
> >   > >
> >   > > >   >
> >   > > >   > WG Last call has expired on the following drafts:
> >   > > >   >
> >   > > >   > 1)
draft-ietf-seamoby-context-transfer-problem-stat-04.txt
> >   > > >   > 2) draft-ietf-seamoby-ct-reqs-02.txt
> >   > > >   > 3) draft-ietf-seamoby-car-discovery-issues-01.txt
> >   > > >   > 4) draft-ietf-seamoby-paging-protocol-assessment-00.txt
> >   > > >   >
> >   > > >   > No comments were received on 1) and 3), they will
> >   > now be sent to
> >   > >the
> >   > > >   > IESG for review.
> >   > > >
> >   > > > => Just a minute, we _are_ discussing comments on 3).
> >   > > > I've also made these comments in London.
> >   > > >
> >   > > > Hesham
> >   > > >
> >   > >
> >   > >
> >   > >_______________________________________________
> >   > >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
>
>
> _________________________________________________________________
> 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  Mon Jan 14 16:13: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 QAA19488
	for ; Mon, 14 Jan 2002 16:13: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 PAA24241;
	Mon, 14 Jan 2002 15:53: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 PAA24212
	for ; Mon, 14 Jan 2002 15:53:20 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18568
	for ; Mon, 14 Jan 2002 15:53:16 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0EKqlS10318;
	Mon, 14 Jan 2002 12:52:47 -0800 (PST)
Message-ID: <01fe01c19d3d$32563180$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" , 
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com> <3C433991.2090906@alcatel.com>
Subject: Re: [Seamoby] Re: IP Paging Protocol
Date: Mon, 14 Jan 2002 12:51:10 -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 saw the mail you forwarded. Since it was
sent to me privately by you and I was not on the
cc list, I do not know whether the sender
intended it to be made public, but the
sentiment expressed in the paragraph
you cite below sums up the gist of
the message.

The mail was sent by one person who was not an author of
one of the proposed protocols, and had on the cc list another
person who was not an author. Other than that, all
the people who were on the cc list were authors of proposed
protocols that were not selected.

Up until now, the only people who have expressed
an opinion about the paging protocol decision were authors of protocols
that
were not selected. One could, quite frankly, view this as "sour grapes"
on their part for not having been selected. However,
the fact that one person who is not an author has
stepped forward and expressed this opinion now indicates
that at least one other member of the working group would prefer
a different course. It does not indicate to me, by any
stretch of the imagination,  that there is working group
concensus for a different course.

Given this, Allison, Pat, and I will discuss the matter
and post an email to the working group in the
near future.

            jak

----- Original Message -----
From: "Behcet Sarikaya" 
To: 
Sent: Monday, January 14, 2002 12:03 PM
Subject: [Seamoby] Re: IP Paging Protocol


> Hi James,
>
>   There has been a new development (Pls see the email that was
forwarded
> to you).
>  It seems now clear that there is no longer a consensus on
draft-renker.
> I think that this draft can not be taken as WG document, and therefore
> serve as base.
>   The assessment draft drafy-seamoby-paging-protocol-assessment-00.txt
> did not identify a clear winner but it seems that it has identified a
> clear loser (the renker draft)  in terms the marks given (72 marks
> versus 89, 90, etc).
>
>   Here is the way out:
>
> >We believe that the process of creating an IP paging protocol can be
> >> substantially improved, and that the establishment in Seamoby of a
> >> design team comprising the authors of the current proposal and few
> >> other relevant parties is the only realistic solution (as it has
> >> already happened in other IETF WGs).
> >
>
>
> 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  Mon Jan 14 19:45: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 TAA27532
	for ; Mon, 14 Jan 2002 19:45: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 TAA02147;
	Mon, 14 Jan 2002 19:23: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 TAA02119
	for ; Mon, 14 Jan 2002 19:23:49 -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 TAA27001
	for ; Mon, 14 Jan 2002 19:23:47 -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 QAA17107;
	Mon, 14 Jan 2002 16:23:18 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0F0NHZ22554;
	Mon, 14 Jan 2002 16:23:17 -0800
X-mProtect:  Mon, 14 Jan 2002 16:23:17 -0800 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdz8z7G0; Mon, 14 Jan 2002 16:23:15 PST
Message-ID: <3C437674.F7603259@iprg.nokia.com>
Date: Mon, 14 Jan 2002 16:23:16 -0800
From: Vijay Devarapalli 
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: Behcet Sarikaya , seamoby@ietf.org
Subject: Re: [Seamoby] Re: IP Paging Protocol
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com> <3C433991.2090906@alcatel.com> <01fe01c19d3d$32563180$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

Hi Jim,

just one comment.

James Kempf wrote:
> 
>  Behcet,
> 
> Up until now, the only people who have expressed
> an opinion about the paging protocol decision were authors of protocols
> that
> were not selected. One could, quite frankly, view this as "sour grapes"
> on their part for not having been selected. However,

People spend a lot of their time to come up with proposals.
and they also hope that their proposal goes somewhere in the
WG. and when the protocol assessment turns out to be murky
and they complain, I dont think it is right to call them 
"sour grapes".

Vijay

> the fact that one person who is not an author has
> stepped forward and expressed this opinion now indicates
> that at least one other member of the working group would prefer
> a different course. It does not indicate to me, by any
> stretch of the imagination,  that there is working group
> concensus for a different course.
> 
> Given this, Allison, Pat, and I will discuss the matter
> and post an email to the working group in the
> near future.
> 
>             jak
> 
> ----- Original Message -----
> From: "Behcet Sarikaya" 
> To: 
> Sent: Monday, January 14, 2002 12:03 PM
> Subject: [Seamoby] Re: IP Paging Protocol
> 
> > Hi James,
> >
> >   There has been a new development (Pls see the email that was
> forwarded
> > to you).
> >  It seems now clear that there is no longer a consensus on
> draft-renker.
> > I think that this draft can not be taken as WG document, and therefore
> > serve as base.
> >   The assessment draft drafy-seamoby-paging-protocol-assessment-00.txt
> > did not identify a clear winner but it seems that it has identified a
> > clear loser (the renker draft)  in terms the marks given (72 marks
> > versus 89, 90, etc).
> >
> >   Here is the way out:
> >
> > >We believe that the process of creating an IP paging protocol can be
> > >> substantially improved, and that the establishment in Seamoby of a
> > >> design team comprising the authors of the current proposal and few
> > >> other relevant parties is the only realistic solution (as it has
> > >> already happened in other IETF WGs).
> > >
> >
> >
> > 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

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


From seamoby-admin@ietf.org  Tue Jan 15 05:49: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 FAA17089
	for ; Tue, 15 Jan 2002 05:49: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 FAA29258;
	Tue, 15 Jan 2002 05:26: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 FAA29229
	for ; Tue, 15 Jan 2002 05:26:12 -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 FAA16805
	for ; Tue, 15 Jan 2002 05:26:07 -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 g0FAQ6H44489;
	Tue, 15 Jan 2002 11:26:06 +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 LAA15728;
	Tue, 15 Jan 2002 11:25:39 +0100
Message-ID: <3C4403A2.93C257EA@ccrle.nec.de>
Date: Tue, 15 Jan 2002 11:25:38 +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: Pars MUTAF 
CC: Seamoby 
Subject: Re: [Seamoby] openness for advanced paging strategies in DMHA
References: <3C42DC28.F8220F2C@ccrle.nec.de> <3C42E35B.42E440B9@inrialpes.fr>
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

Pars,

thanks for your feedback. Another big issue is paging related signaling cost.
In order to optimize the paging process, an architecture and design should
allow several paging strategies, reducing signaling cost, but performing under
a given delay constraint. So, I will keep a brief comment on the support of
different paging strategies in a first farmework cut, but take out the
details, as recommended by James. There has been done some work on paging
strategies already (see references list in draft-renker), so we should
consider respective openness.

Regards,

Marco

Pars MUTAF wrote:

> Hello,
>
> Marco Liebsch wrote:
>
> > Hi all,
> >
> > the architecture of the Paging Agent node in the current base line draft
> > for the WG's DMHA protocol intends to be open for several paging
> > strategies. As James proposed, maybe it is appropriate to take detailed
> > sections addressing different paging strategies and characteristics out
> > for the WG's protocol framework draft. In my opinion, deployment of
> > different paging strategies is an important area, therefore, the future
> > WG architecture and the protocol for DMHA should allow deployment of
> > several paging strategies. Therefore, I propose the following: Taking
> > out the details on paging strategies and having later a reference on a
> > possibly stand-alone document describing the paging strategy specifics.
> > We could have a very brief comment in the draft addressing the 'role of
> > a paging strategy' (sec. 1.1.4 in draft-renker) and the concept's
> > openness.
> >
> > Comments are appreciated.
> >
>
> IMHO this would be a very efficient design choice (I mean,
> supporting multiple paging policies). For two reasons (at least):
> 1- Seems like no paging policy suits well all mobility scenarios
> 2- Paging policy research is not finished (especially in IP area).
>
> regards,
> pars
>
> >
> > marco
> >
> > _______________________________________________
> > 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 Jan 15 05:55: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 FAA17212
	for ; Tue, 15 Jan 2002 05:55: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 FAA29811;
	Tue, 15 Jan 2002 05:37: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 FAA29784
	for ; Tue, 15 Jan 2002 05:37:57 -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 FAA16957
	for ; Tue, 15 Jan 2002 05:37:52 -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 g0FAbqH44615;
	Tue, 15 Jan 2002 11:37:52 +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 LAA15946;
	Tue, 15 Jan 2002 11:37:24 +0100
Message-ID: <3C440663.B68C6B31@ccrle.nec.de>
Date: Tue, 15 Jan 2002 11:37: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: Seamoby 
Subject: Re: [Seamoby] openness for advanced paging strategies in DMHA
References: <3C42DC28.F8220F2C@ccrle.nec.de> <014101c19d2a$d7e87e90$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:

> Marco,
>
> I agree that the Seamoby DMHA protocol must provide
> the mechanism for implemeting a variety of paging policies.
> However, I don't believe the DMHA protocol should
> specify a particular policy or policies. The protocol spec
> might use one or two example policies to show how
> the paging mechanism can be used, but that could also
> be done in another document which is more comprehensive
> and illustrates how to deploy a variety of paging policies.
> So I support separating out the discussion of implementing
> particular paging policies in a separate document.
>

Of course no discussion or detailed explanation should be in, but a few
sentences on the designs openness and maybe a reference to an extra document
(which could refer to some work done already in this area).

marco



>
>             jak
>
> ----- Original Message -----
> From: "Marco Liebsch" 
> To: "Seamoby" 
> Sent: Monday, January 14, 2002 5:24 AM
> Subject: [Seamoby] openness for advanced paging strategies in DMHA
>
> > Hi all,
> >
> > the architecture of the Paging Agent node in the current base line
> draft
> > for the WG's DMHA protocol intends to be open for several paging
> > strategies. As James proposed, maybe it is appropriate to take
> detailed
> > sections addressing different paging strategies and characteristics
> out
> > for the WG's protocol framework draft. In my opinion, deployment of
> > different paging strategies is an important area, therefore, the
> future
> > WG architecture and the protocol for DMHA should allow deployment of
> > several paging strategies. Therefore, I propose the following: Taking
> > out the details on paging strategies and having later a reference on a
> > possibly stand-alone document describing the paging strategy
> specifics.
> > We could have a very brief comment in the draft addressing the 'role
> of
> > a paging strategy' (sec. 1.1.4 in draft-renker) and the concept's
> > openness.
> >
> > Comments are appreciated.
> >
> > marco
> >
> >
> >
> >
> > _______________________________________________
> > 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 Jan 15 07:31: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 HAA19961
	for ; Tue, 15 Jan 2002 07:31: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 HAA02677;
	Tue, 15 Jan 2002 07:16: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 HAA02648
	for ; Tue, 15 Jan 2002 07:16:30 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19514
	for ; Tue, 15 Jan 2002 07:16:27 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0FCGRJ18978
	for ; Tue, 15 Jan 2002 13:16:27 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jan 15 13:16:11 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 15 Jan 2002 13:16:11 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1F8@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Hemant Chaskar'" ,
        "Hesham Soliman (ERA)"
	 ,
        kempf@docomolabs-usa.com, seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Tue, 15 Jan 2002 13:16:06 +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

Hi Hemant

  > Opps, that was a slip of pen, of course. I meant Seamoby, 
  > and not NSIS. So, 
  > was the concern raised on SEAMOBY list, and what exactly was it?

=> I don't know where the spanish inquisition is going :) but
we've already agreed to the change. Btw, i never claimed to
have sent this comment during last call, I always said
I made the comment in London. London IETF _meeting_

  > 
  > I do not know if it is good to change the name 
  > "anticipated" now as, for 
  > one, it has references at other places in document, as well 
  > as there is no 
  > other better alternative name. I do not think that AR-based 
  > better suited 
  > than anticipated. Anticipated discovery means discovery 
  > before actual 
  > handoff event. It could be AR-based on anyting else based.

=> I don't care what it's called as long as it is meaningful
and consistent. If people want to go with anticipated 
then be it, call them AR-based and MN-based anticipation. 
If this WG has some kind of allergic reaction towards MIP
terminology then replace MN with something else. 
But simply attaching anticipation to AR-based discovery
only is not correct.


  > 
  > However, we can certainly finetune the text to state that 
  > _a set_ of CARs 
  > (_not all_ CARs) are discovered. 

=> Yes this should be done too.


With that, can we close 
  > this tread now and 
  > conclude on the issues draft? Please let us know. Thanks.

=> I was under the impression that we concluded already as per
James' email. My comment is to change both the anticipated 
terminology and the first sentence under 4.1.

Thanks, 
Hesham

  > 
  > Hemant
  > 
  > 
  > >From: "Hesham Soliman (ERA)" 
  > >To: "'Hemant Chaskar'" , 
  > kempf@docomolabs-usa.com,    
  > >     "Hesham Soliman (ERA)" 
  > ,        
  > >seamoby@ietf.org
  > >Subject: RE: [Seamoby] Status of WG Last Call
  > >Date: Mon, 14 Jan 2002 16:58:32 +0100
  > >
  > >Hi Hemant,
  > >
  > >   > I also did not see any comment from you on the NSIS list
  > >   > during the first
  > >   > last call that has not been attended to.
  > >
  > >=> I'm not on the NSIS list. This is a seamoby doc.
  > >
  > >   > Also, please note the difference between the "issues" 
  > draft, the
  > >   > "requirements" draft and the "solutions" draft.
  > >
  > >=> I made comments on both. I realise they are 2 different
  > >things.
  > >
  > >Hesham
  > >
  > >
  > >   >
  > >   > Hemant
  > >   >
  > >   > >From: "James Kempf" 
  > >   > >To: "Hesham Soliman \(ERA\)"
  > >   > ,
  > >   > >
  > >   > >Subject: Re: [Seamoby] Status of WG Last Call
  > >   > >Date: Fri, 11 Jan 2002 10:19:05 -0800
  > >   > >
  > >   > >Hesham,
  > >   > >
  > >   > >The usual procedure for comments is that they be sent to
  > >   > the list. Any
  > >   > >Last
  > >   > >Call comments must be sent to the list in order that there
  > >   > be a record
  > >   > >of them. I don't recall any email from you on
  > >   > >draft-ietf-seamoby-car-discovery-issues-01.txt
  > >   > >during the last call period, but perhaps I missed it. If
  > >   > you have any
  > >   > >comments,
  > >   > >please send them out within the next day.
  > >   > >
  > >   > >Also note that we are talking here about the problem
  > >   > statement, not the
  > >   > >requirements.
  > >   > >I have noted a thread over the last couple days on
  > >   > requirements, and
  > >   > >your comments, will
  > >   > >naturally be taken into account when the requirements
  > >   > draft is done.
  > >   > >
  > >   > >                 jak
  > >   > >
  > >   > >----- Original Message -----
  > >   > >From: "Hesham Soliman (ERA)" 
  > >   > >To: "'James Kempf'" ; 
  > 
  > >   > >Sent: Friday, January 11, 2002 9:59 AM
  > >   > >Subject: RE: [Seamoby] Status of WG Last Call
  > >   > >
  > >   > >
  > >   > > >   >
  > >   > > >   > WG Last call has expired on the following drafts:
  > >   > > >   >
  > >   > > >   > 1) 
  > draft-ietf-seamoby-context-transfer-problem-stat-04.txt
  > >   > > >   > 2) draft-ietf-seamoby-ct-reqs-02.txt
  > >   > > >   > 3) draft-ietf-seamoby-car-discovery-issues-01.txt
  > >   > > >   > 4) 
  > draft-ietf-seamoby-paging-protocol-assessment-00.txt
  > >   > > >   >
  > >   > > >   > No comments were received on 1) and 3), they will
  > >   > now be sent to
  > >   > >the
  > >   > > >   > IESG for review.
  > >   > > >
  > >   > > > => Just a minute, we _are_ discussing comments on 3).
  > >   > > > I've also made these comments in London.
  > >   > > >
  > >   > > > Hesham
  > >   > > >
  > >   > >
  > >   > >
  > >   > >_______________________________________________
  > >   > >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
  > 
  > 
  > _________________________________________________________________
  > 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  Tue Jan 15 07:56: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 HAA20782
	for ; Tue, 15 Jan 2002 07:56: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 HAA03626;
	Tue, 15 Jan 2002 07: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 HAA03594
	for ; Tue, 15 Jan 2002 07:43:49 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20386
	for ; Tue, 15 Jan 2002 07:43:46 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0FChkJ13166
	for ; Tue, 15 Jan 2002 13:43:46 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Jan 15 13:43:46 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 15 Jan 2002 13:34:47 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1FC@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'John Schnizlein'" 
Cc: Govind Krishnamurthi , seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Tue, 15 Jan 2002 13:43:26 +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


  > 
  > If the WG goes that way, the resulting protocol would be usable
  > only by operators who allow access to any mobile node (MN). 

=> I don't think so, this is not related to access control.
If some authentication is required to hear RAs from a router 
then this step will be done first.


  > The issue is potentially even more problematic for AR - AR. 
  > Would the
  > operator of an access service willingly include another operator's
  > routers to be neighbors, encouraging the possibility that the MN
  > would switch into/out-of service from a different provider?
  > We know that telephone companies try to avoid this.

=> Sure, but the WG doesn't have to address this problem.

  > 
  > >So please make it clear which part of the protocol
  > >you're referring to. We should not always assume 
  > >that we're discussing the AR - AR case. 
  > >
  > >...
  > >Let the MN decide.
  > 
  > This is a good answer. But then the MN would need to get the sort of
  > information it needs to make a reasonable decision. This 
  > might include
  > pricing information, or information regarding the which providers
  > share access reciprocity agreements. Are we ready for all this?

=> Well, why not ? I don't know how much detail we should 
put in the protocol, but something along those lines
will be necessary. Do you see problems with this ?

Hesham
  > 
  > John
  > 

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


From seamoby-admin@ietf.org  Tue Jan 15 09:11: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 JAA23958
	for ; Tue, 15 Jan 2002 09:11: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 IAA05805;
	Tue, 15 Jan 2002 08:58: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 IAA05765
	for ; Tue, 15 Jan 2002 08:58:03 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23592
	for ; Tue, 15 Jan 2002 08:57:59 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g0FDw0J25363
	for ; Tue, 15 Jan 2002 14:58:00 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jan 15 14:58:00 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 15 Jan 2002 14:57:44 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C200@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Govind Krishnamurthi'" , seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Tue, 15 Jan 2002 14:57:40 +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

Govind, 

  > Where does the current set of requirements preclude any 
  > sort of mobile node 
  > involvement. I think
  > whether an MN is involved or not is implementation specific.. and
  > not a requirements issue. I don't think the requirements 
  > for CAR discovery 
  > change whether a MN is involved or not. 

=> What is this in response to exactly ? I didn't claim
the opposite of what you said, I said 'separate' the 
requirements so we know what you refer to when you 
say 'support inter-domain discovery' 'support mapping 
from L2 to L3'. 

Also letting the MN 
  > or AR decide 
  > where actually to handover is out of scope of CAR discovery.
  > Just letting the MN also hear does not complete CAR 
  > discovery.. CARs 
  > comprise of GAARS + their capabilities.. What you say is just GAARs.

=> Ok, please respond to the statements I made, just so
I can understand which parts you are referring to. 

Hesham

  > 
  > -Govind.
  > > >...
  > >   > >6. Protocol applicability ? SHOULD (?)
  > >   > >(show of hands indicated that this item should be changed
  > >   > to a MUST)
  > >   > >support inter-domain as well as Intra-domain scope
  > >   >
  > >   > Inter-domain discovery of access routers (which seems
  > >   > implied by what
  > >   > might otherwise seem an innocuous protocol design feature)
  > >   > is problematic.
  > >   >
  > >   > It would require resolving which users are subscribers of
  > >   > which domains,
  > >   > or complex inter-domain roaming and billing reciprocity.
  > >
  > >=> This is exactly why I urge you (this wg) to clearly
  > >explain which protocol you are talking about. AR - AR or
  > >AR MN ???
  > >Clearly AR - MN lis an obvious way to discover all routers
  > >that the MN can hear. Inter/intra domain issues are
  > >not relevant.
  > >
  > >So please make it clear which part of the protocol
  > >you're referring to. We should not always assume
  > >that we're discussing the AR - AR case.
  > >
  > >   > While it seems reasonable to avoid locking mobile stations
  > >   > into a single
  > >   > domain, the policy interactions of requiring
  > >   > multiple-domain discovery
  > >   > would make the task much more difficult at the start.
  > >
  > >=> Certainly. But there is an easy way of doing that:
  > >Let the MN decide.
  > >
  > >Hesham
  > >
  > >   > _______________________________________________
  > >   > 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
  > 
  > 
  > 
  > 
  > _________________________________________________________________
  > 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

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


From seamoby-admin@ietf.org  Tue Jan 15 09:26: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 JAA24430
	for ; Tue, 15 Jan 2002 09:26: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 JAA06804;
	Tue, 15 Jan 2002 09:15: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 JAA06773
	for ; Tue, 15 Jan 2002 09:15:13 -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 JAA24064
	for ; Tue, 15 Jan 2002 09:15:08 -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 g0FEEDH45896;
	Tue, 15 Jan 2002 15:14:13 +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 PAA18861;
	Tue, 15 Jan 2002 15:13:45 +0100
Message-ID: <3C443918.7616E5BB@ccrle.nec.de>
Date: Tue, 15 Jan 2002 15:13:44 +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 
Subject: Re: [Seamoby] DMHA framework draft architecture
References: <3C42D563.BE04F6F5@ccrle.nec.de> <013901c19d2a$4fbf9f30$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:

> Marco,
>
> I had been thinking about this change myself.
> So the basic idea is that the composite paging
> agent contains that part of the tracking agent
> that does IP paging area tracking, dormant
> mode monitoring agent, and that part of
> the paging agent which initiates IP paging.
> Another part of the paging agent and
> tracking agent sits in the access routers.
> The part in the access router is responsible for
> taking the L3 paging and tracking protocol
> and converting it into an L2 paging and tracking
> protocol, or, if the L2 does not support such
> a protocol, translating into a last hop L3 protocol
> to the MN (which actually might be the same
> as the incoming L3 tracking and paging protocol).
>

The only difference I see, compared to the architecture described in the
base-line document,  is that you propose to have a further attendant for the
TA located within ARs. Is this correct?
What you propose next is to have periodic updating of redundant composite
Paging Agents, allowing to intervene in case of a composite Paging Agent
failure. Only to understand correctly, this refers more to a lightweight
mechanisms for keeping redundant composite Paging Agents updated, rather
than introducing a complex protocol for PA mirroring and maintenance of
reliability, and has nothing to do with your proposal above, which is
introducing a TA attendant in ARs. Correct?

In case of a failure, the paging area, made up by one or more ARs, should be
the same as before, but the composite Paging Agent, addressing the
respective attendants within a paging area's ARs, is different. Information
on which ARs are assigned to which paging area could be included in the
periodic update information or beeing configured making use of the dynamic
paging area protocol you addressed. Is this understanding correct?

marco


>
> I think this architecture would facilitate failover
> if the composite paging agent for an IP
> paging area fails. Consider
> the following scenario. The composite agent
> keeps track of the subnets it is currently covering.
> Periodically, it propagates that information
> to other, neighboring paging agents, just like
> routing protocols do. Now suppose a paging
> agent fails and the neighboring agents notice
> due to an update failing to arrive. The neighboring
> agents could use a dynamic paging area protocol
> to arrange for the hosts under the control of the
> failed paging agent to receive new paging
> area location informing them that their
> paging area changed. This would allow
> the hosts to continue receiving service even though
> their paging agent failed, without having to use
> a server duplication protocol for the composite
> agent. So paging area resiliency would work
> somewhat like routing resilency, which is
> a proven benefit of Internet routing.
>
>             jak
>
> ----- Original Message -----
> From: "Marco Liebsch" 
> To: "Seamoby" 
> Sent: Monday, January 14, 2002 4:56 AM
> Subject: [Seamoby] DMHA framework draft architecture
>
> > Hi all,
> >
> > referring to the functional architecture for DMHA in RFC 3154,
> currently
> > the protocol base line draft describes a composite architecture.
> > Appendix C of draft-renker-paging-ipv6-01.txt illustrates a mapping
> > between the described architecture and the functional elements given
> in
> > RFC 3154. In order to come up with a first cut of a framework draft, I
> > would like to request a WG consensus of taking over the proposed
> > architecture, having a composite Paging Agent node (PA node)
> addressing
> > paging related attendant functional entities within ARs. Actually,
> > taking the description of the Paging Agent Functional Entity (FE) as
> it
> > is described in RFC 3154, this functional entity could be split into a
> > master FE, currently assigned to the PA node, and multiple attendant
> > FEs, located in ARs, responsible for local paging function and mapping
> > L3 paging requests to lower layer specifics.
> >
> > Comments are welcome.
> >
> > marco
> >
> >
> >
> >
> > _______________________________________________
> > 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 Jan 15 09:36: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 JAA24802
	for ; Tue, 15 Jan 2002 09:36: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 JAA07056;
	Tue, 15 Jan 2002 09:25:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07025
	for ; Tue, 15 Jan 2002 09:25:06 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24357
	for ; Tue, 15 Jan 2002 09:24:55 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 15 Jan 2002 06:24:06 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Hesham Soliman (ERA)'" ,
        "'James Kempf'" , seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Tue, 15 Jan 2002 06:24:04 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19DD0.48F3F330"
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_01C19DD0.48F3F330
Content-Type: text/plain

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

Hesham, because of the holidays, we provided much more than the
necessary two weeks.

PatC

- -----Original Message-----
From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] 
Sent: Monday, January 14, 2002 6:06 AM
To: 'James Kempf'; Hesham Soliman (ERA); seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call


James, 

  > The usual procedure for comments is that they be sent to 
  > the list. Any
  > Last
  > Call comments must be sent to the list in order that there 
  > be a record
  > of them. I don't recall any email from you on
  > draft-ietf-seamoby-car-discovery-issues-01.txt
  > during the last call period, but perhaps I missed it. 

=> No you didn't miss it, but I think the last call 
period was a very strange time, that goes over the 
christmas break where a lot of people (especially on
this side of the world) take some holidays. 

If 
  > you have any
  > comments,
  > please send them out within the next day.

=> I've already sent my comments on the draft 
(in this thread), specifically on the assumptions
in chapter 4.1. 

  > Also note that we are talking here about the problem 
  > statement, not the
  > requirements.

=> I commented on both in my email.

Hesham


  > ----- Original Message -----
  > From: "Hesham Soliman (ERA)" 
  > To: "'James Kempf'" ;

  > Sent: Friday, January 11, 2002 9:59 AM
  > Subject: RE: [Seamoby] Status of WG Last Call
  > 
  > 
  > >   >
  > >   > WG Last call has expired on the following drafts:
  > >   >
  > >   > 1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
  > >   > 2) draft-ietf-seamoby-ct-reqs-02.txt
  > >   > 3) draft-ietf-seamoby-car-discovery-issues-01.txt
  > >   > 4) draft-ietf-seamoby-paging-protocol-assessment-00.txt
  > >   >
  > >   > No comments were received on 1) and 3), they will now 
  > be sent to
  > the
  > >   > IESG for review.
  > >
  > > => Just a minute, we _are_ discussing comments on 3).
  > > I've also made these comments in London.
  > >
  > > Hesham
  > >
  > 

_______________________________________________
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/AwUBPEQ7hDN1fXKoxmisEQIOxACeOk4rvhDB1fG1luga0/jBLQw6FD0An3Ux
WOfajSp1miyFJTKQNnNOyAlk
=TvfG
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C19DD0.48F3F330
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Status of WG Last Call




 

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

Hash: SHA1




Hesham, because of the holidays, we provided much =
more than the

necessary two weeks.




PatC




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

From: Hesham Soliman (ERA) [mailto:hesham.soliman@era=
.ericsson.se] 

Sent: Monday, January 14, 2002 6:06 AM

To: 'James Kempf'; Hesham Soliman (ERA); =
seamoby@ietf.org

Subject: RE: [Seamoby] Status of WG Last Call






James, 




  > The usual procedure for comments is that =
they be sent to 

  > the list. Any

  > Last

  > Call comments must be sent to the list =
in order that there 

  > be a record

  > of them. I don't recall any email from =
you on

  > =
draft-ietf-seamoby-car-discovery-issues-01.txt

  > during the last call period, but perhaps =
I missed it. 




=3D> No you didn't miss it, but I think the last =
call 

period was a very strange time, that goes over the =


christmas break where a lot of people (especially =
on

this side of the world) take some holidays. 




If 

  > you have any

  > comments,

  > please send them out within the next =
day.




=3D> I've already sent my comments on the draft =


(in this thread), specifically on the =
assumptions

in chapter 4.1. 




  > Also note that we are talking here about =
the problem 

  > statement, not the

  > requirements.




=3D> I commented on both in my email.




Hesham






  > ----- Original Message -----

  > From: "Hesham Soliman (ERA)" =
<hesham.soliman@era.ericsson.se>

  > To: "'James Kempf'" =
<kempf@docomolabs-usa.com>;

<seamoby@ietf.org>

  > Sent: Friday, January 11, 2002 9:59 =
AM

  > Subject: RE: [Seamoby] Status of WG Last =
Call

  > 

  > 

  > >   >

  > >   > WG Last call has =
expired on the following drafts:

  > >   >

  > >   > 1) =
draft-ietf-seamoby-context-transfer-problem-stat-04.txt

  > >   > 2) =
draft-ietf-seamoby-ct-reqs-02.txt

  > >   > 3) =
draft-ietf-seamoby-car-discovery-issues-01.txt

  > >   > 4) =
draft-ietf-seamoby-paging-protocol-assessment-00.txt

  > >   >

  > >   > No comments were =
received on 1) and 3), they will now 

  > be sent to

  > the

  > >   > IESG for =
review.

  > >

  > > =3D> Just a minute, we _are_ =
discussing comments on 3).

  > > I've also made these comments in =
London.

  > >

  > > Hesham

  > >

  > 




_______________________________________________

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/AwUBPEQ7hDN1fXKoxmisEQIOxACeOk4rvhDB1fG1luga0/jBLQw6FD0An3U=
x

WOfajSp1miyFJTKQNnNOyAlk

=3DTvfG

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





------_=_NextPart_001_01C19DD0.48F3F330--

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


From seamoby-admin@ietf.org  Tue Jan 15 09:40: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 JAA24972
	for ; Tue, 15 Jan 2002 09:40: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 JAA07195;
	Tue, 15 Jan 2002 09:29:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07164
	for ; Tue, 15 Jan 2002 09:29:06 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24517
	for ; Tue, 15 Jan 2002 09:28:56 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 15 Jan 2002 06:28:21 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Hesham Soliman (ERA)'" ,
        "'Hemant Chaskar'" , kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Tue, 15 Jan 2002 06:27:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19DD0.C59CCAB0"
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_01C19DD0.C59CCAB0
Content-Type: text/plain

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

=> I don't know where the spanish inquisition is going :) but we've
already agreed to the change. Btw, i never claimed to have sent this
comment during last call, I always said I made the comment in London.
London IETF _meeting_

Hesham, it is necessary to actually send your comments on the mailing
list during the last call period. Otherwise, folks like me forget,
and we have no record of the comment.

PatC

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

iQA/AwUBPEQ8VTN1fXKoxmisEQJ4hwCcCfeHq486uENYYZ+UxJ9rw3tON5YAnjcc
QnLZJG6ZzNoWfit71TWCMMh8
=vVeS
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C19DD0.C59CCAB0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Status of WG Last Call




 

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

Hash: SHA1




=3D> I don't know where the spanish inquisition is =
going :) but we've

already agreed to the change. Btw, i never claimed =
to have sent this

comment during last call, I always said I made the =
comment in London.

London IETF _meeting_




Hesham, it is necessary to actually send your =
comments on the mailing

list during the last call period. Otherwise, folks =
like me forget,

and we have no record of the comment.




PatC




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

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




iQA/AwUBPEQ8VTN1fXKoxmisEQJ4hwCcCfeHq486uENYYZ+UxJ9rw3tON5YAnjc=
c

QnLZJG6ZzNoWfit71TWCMMh8

=3DvVeS

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





------_=_NextPart_001_01C19DD0.C59CCAB0--

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


From seamoby-admin@ietf.org  Tue Jan 15 09:46: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 JAA25266
	for ; Tue, 15 Jan 2002 09:46: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 JAA07836;
	Tue, 15 Jan 2002 09:35: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 JAA07805
	for ; Tue, 15 Jan 2002 09:35:27 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24753
	for ; Tue, 15 Jan 2002 09:35:22 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g0FEZNJ06398
	for ; Tue, 15 Jan 2002 15:35:23 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jan 15 15:35:22 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 15 Jan 2002 15:26:23 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C201@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Pat R. Calhoun'" ,
        "Hesham Soliman (ERA)" ,
        "'Hemant Chaskar'"
	 , kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Tue, 15 Jan 2002 15:35:00 +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 don't know where the spanish inquisition is going :) but we've 
already agreed to the change. Btw, i never claimed to have sent this 
comment during last call, I always said I made the comment in London. 
London IETF _meeting_ 

Hesham, it is necessary to actually send your comments on the mailing 
list during the last call period. Otherwise, folks like me forget, 
and we have no record of the comment.  

=> Got it, but there should be some record in the meeting
minutes.

Hesham
 
PatC 
-----BEGIN PGP SIGNATURE----- 
Version: PGPfreeware 7.0.3 for non-commercial use  
iQA/AwUBPEQ8VTN1fXKoxmisEQJ4hwCcCfeHq486uENYYZ+UxJ9rw3tON5YAnjcc 
QnLZJG6ZzNoWfit71TWCMMh8 
=vVeS 
-----END PGP SIGNATURE----- 

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


From seamoby-admin@ietf.org  Tue Jan 15 09:52: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 JAA25520
	for ; Tue, 15 Jan 2002 09:52: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 JAA08248;
	Tue, 15 Jan 2002 09:39: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 JAA08215
	for ; Tue, 15 Jan 2002 09:39:51 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24958
	for ; Tue, 15 Jan 2002 09:39:42 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 15 Jan 2002 06:39:06 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Hesham Soliman (ERA)'" ,
        "'Hemant Chaskar'" , kempf@docomolabs-usa.com,
        seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Tue, 15 Jan 2002 06:38:23 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19DD2.49034A90"
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_01C19DD2.49034A90
Content-Type: text/plain

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

I hope you don't seriously expect the document editors to have to
interpret a third party's interpretation of a WG last call comment,
that may, or may not be, in the meeting minutes, right? :)

Anyways... For future reference, it would be best to send the comment
to the list as well.

PatC

- -----Original Message-----
From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] 
Sent: Tuesday, January 15, 2002 6:35 AM
To: Pat R. Calhoun; Hesham Soliman (ERA); 'Hemant Chaskar';
kempf@docomolabs-usa.com; seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call


=> I don't know where the spanish inquisition is going :) but we've 
already agreed to the change. Btw, i never claimed to have sent this 
comment during last call, I always said I made the comment in London.
London IETF _meeting_ 

Hesham, it is necessary to actually send your comments on the mailing
list during the last call period. Otherwise, folks like me forget, 
and we have no record of the comment.  

=> Got it, but there should be some record in the meeting minutes.

Hesham
 
PatC 
- -----BEGIN PGP SIGNATURE----- 
Version: PGPfreeware 7.0.3 for non-commercial use
 
iQA/AwUBPEQ8VTN1fXKoxmisEQJ4hwCcCfeHq486uENYYZ+UxJ9rw3tON5YAnjcc 
QnLZJG6ZzNoWfit71TWCMMh8 
=vVeS 
- -----END PGP SIGNATURE----- 

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

iQA/AwUBPEQ+3zN1fXKoxmisEQJBJACg7dENtpG20BtPwkrq/yTE2m3BMOEAoI2s
5D0AGnyaGFSRJY5q/MblDor+
=OLfJ
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C19DD2.49034A90
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Status of WG Last Call




 

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

Hash: SHA1




I hope you don't seriously expect the document =
editors to have to

interpret a third party's interpretation of a WG =
last call comment,

that may, or may not be, in the meeting minutes, =
right? :)




Anyways... For future reference, it would be best to =
send the comment

to the list as well.




PatC




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

From: Hesham Soliman (ERA) [mailto:hesham.soliman@era=
.ericsson.se] 

Sent: Tuesday, January 15, 2002 6:35 AM

To: Pat R. Calhoun; Hesham Soliman (ERA); 'Hemant =
Chaskar';

kempf@docomolabs-usa.com; seamoby@ietf.org

Subject: RE: [Seamoby] Status of WG Last Call






=3D> I don't know where the spanish inquisition is =
going :) but we've 

already agreed to the change. Btw, i never claimed =
to have sent this 

comment during last call, I always said I made the =
comment in London.

London IETF _meeting_ 




Hesham, it is necessary to actually send your =
comments on the mailing

list during the last call period. Otherwise, folks =
like me forget, 

and we have no record of the comment.  




=3D> Got it, but there should be some record in =
the meeting minutes.




Hesham

 

PatC 

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

Version: PGPfreeware 7.0.3 for non-commercial =
use

<http://www.pgp.com> 

iQA/AwUBPEQ8VTN1fXKoxmisEQJ4hwCcCfeHq486uENYYZ+UxJ9rw3tON5YAnjc=
c 

QnLZJG6ZzNoWfit71TWCMMh8 

=3DvVeS 

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




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

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




iQA/AwUBPEQ+3zN1fXKoxmisEQJBJACg7dENtpG20BtPwkrq/yTE2m3BMOEAoI2=
s

5D0AGnyaGFSRJY5q/MblDor+

=3DOLfJ

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





------_=_NextPart_001_01C19DD2.49034A90--

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


From seamoby-admin@ietf.org  Tue Jan 15 09:59: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 JAA25890
	for ; Tue, 15 Jan 2002 09:59: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 JAA08618;
	Tue, 15 Jan 2002 09:48: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 JAA08580
	for ; Tue, 15 Jan 2002 09:48:03 -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 JAA25321
	for ; Tue, 15 Jan 2002 09:48:00 -0500 (EST)
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 g0FEmDQ00905
	for ; Tue, 15 Jan 2002 08:48:13 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 15 Jan 2002 08:48:00 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 15 Jan 2002 08:47:56 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [Seamoby] CAR Discovery Requirements
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 15 Jan 2002 09:47:55 -0500
Message-ID: 
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcGdzLKd6VayyQm+EdaJYgAIx6TWpQABfarw
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Hesham Soliman (ERA)'" ,
        "Govind Krishnamurthi" , 
X-OriginalArrivalTime: 15 Jan 2002 14:47:56.0807 (UTC) FILETIME=[9EA09970:01C19DD3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA08583
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 Hesham,

I guess Govind's point was (as I also outlined in my mail regarding
separation of requirements) that we don't see how the requirements
will change for an MN-based or AR-based scheme.

This is true in particular for the requirements you mentioned. Isn't
it the fundamental task of CAR discovery to resolve L2Ids to L3Ids?
Why would this be different for an MN-based or AR-based scheme?
And why is there a difference in the inter-domain support? Either
we agree that GAARs are discovered even if they are in different
administrative domains or not. Whether the MN is doing (most of) the
job or the AR, doesn't really matter.

So as I said in my previous email, please outline exactly WHAT
requirements you have in mind that justify this separation. Right now,
we are only discussing about the procedure without having the
meat to fill.

Regards,



Dirk

> -----Original Message-----
> From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
> Sent: Tuesday, January 15, 2002 8:58 AM
> To: Govind Krishnamurthi; seamoby@ietf.org
> Subject: RE: [Seamoby] CAR Discovery Requirements
> 
> 
> Govind, 
> 
>   > Where does the current set of requirements preclude any 
>   > sort of mobile node 
>   > involvement. I think
>   > whether an MN is involved or not is implementation specific.. and
>   > not a requirements issue. I don't think the requirements 
>   > for CAR discovery 
>   > change whether a MN is involved or not. 
> 
> => What is this in response to exactly ? I didn't claim
> the opposite of what you said, I said 'separate' the 
> requirements so we know what you refer to when you 
> say 'support inter-domain discovery' 'support mapping 
> from L2 to L3'. 
> 
> Also letting the MN 
>   > or AR decide 
>   > where actually to handover is out of scope of CAR discovery.
>   > Just letting the MN also hear does not complete CAR 
>   > discovery.. CARs 
>   > comprise of GAARS + their capabilities.. What you say is 
> just GAARs.
> 
> => Ok, please respond to the statements I made, just so
> I can understand which parts you are referring to. 
> 
> Hesham
> 
>   > 
>   > -Govind.
>   > > >...
>   > >   > >6. Protocol applicability ? SHOULD (?)
>   > >   > >(show of hands indicated that this item should be changed
>   > >   > to a MUST)
>   > >   > >support inter-domain as well as Intra-domain scope
>   > >   >
>   > >   > Inter-domain discovery of access routers (which seems
>   > >   > implied by what
>   > >   > might otherwise seem an innocuous protocol design feature)
>   > >   > is problematic.
>   > >   >
>   > >   > It would require resolving which users are subscribers of
>   > >   > which domains,
>   > >   > or complex inter-domain roaming and billing reciprocity.
>   > >
>   > >=> This is exactly why I urge you (this wg) to clearly
>   > >explain which protocol you are talking about. AR - AR or
>   > >AR MN ???
>   > >Clearly AR - MN lis an obvious way to discover all routers
>   > >that the MN can hear. Inter/intra domain issues are
>   > >not relevant.
>   > >
>   > >So please make it clear which part of the protocol
>   > >you're referring to. We should not always assume
>   > >that we're discussing the AR - AR case.
>   > >
>   > >   > While it seems reasonable to avoid locking mobile stations
>   > >   > into a single
>   > >   > domain, the policy interactions of requiring
>   > >   > multiple-domain discovery
>   > >   > would make the task much more difficult at the start.
>   > >
>   > >=> Certainly. But there is an easy way of doing that:
>   > >Let the MN decide.
>   > >
>   > >Hesham
>   > >
>   > >   > _______________________________________________
>   > >   > 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
>   > 
>   > 
>   > 
>   > 
>   > _________________________________________________________________
>   > 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
> 
> _______________________________________________
> 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 Jan 15 10:01: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 KAA26014
	for ; Tue, 15 Jan 2002 10:01: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 JAA08803;
	Tue, 15 Jan 2002 09:50: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 JAA08778
	for ; Tue, 15 Jan 2002 09:50:35 -0500 (EST)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25440
	for ; Tue, 15 Jan 2002 09:50:33 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.10.2/8.10.2) id g0FEoBp10686;
	Tue, 15 Jan 2002 09:50:11 -0500 (EST)
Date: Tue, 15 Jan 2002 09:50:11 -0500 (EST)
From: Scott  Bradner 
Message-Id: <200201151450.g0FEoBp10686@newdev.harvard.edu>
To: hesham.soliman@era.ericsson.se, kempf@docomolabs-usa.com,
        pcalhoun@bstormnetworks.com, seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
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

> Hesham, because of the holidays, we provided much more than the
> necessary two weeks.

note that the IETF always wants to know about real problems in specifications
but it is helpful if people who have problems be very clear as to what they
are - so, Hesham, can you please send your comments to the list now -
please be very careful to say 
	1/ exactly what you think is wrong
	2/ exactly what you think should be done to fix it

I understand that you have already sent or said them but please do so again
so that there is no misunderstanding on what you are talking about

note that not all comments may pass working group consensus muster

Scott

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


From seamoby-admin@ietf.org  Tue Jan 15 10:20: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 KAA28613
	for ; Tue, 15 Jan 2002 10:20: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 KAA09806;
	Tue, 15 Jan 2002 10:08: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 KAA09770
	for ; Tue, 15 Jan 2002 10:08:31 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28133
	for ; Tue, 15 Jan 2002 10:08:28 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0FF8UJ08599
	for ; Tue, 15 Jan 2002 16:08:30 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jan 15 16:08:13 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 15 Jan 2002 16:08:13 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C202@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Scott  Bradner'" ,
        "Hesham Soliman (ERA)"
	 ,
        kempf@docomolabs-usa.com, pcalhoun@bstormnetworks.com,
        seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Tue, 15 Jan 2002 16:08:06 +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

Hi Scott and all,

  > note that the IETF always wants to know about real problems 
  > in specifications
  > but it is helpful if people who have problems be very clear 
  > as to what they
  > are - so, Hesham, can you please send your comments to the 
  > list now -
  > please be very careful to say 
  > 	1/ exactly what you think is wrong
  > 	2/ exactly what you think should be done to fix it

=> I have 2 minor comments really but I thought they were
important enough to make sure we understand the different
ways of solving the problems outlined in the draft. 

1. The title of chapter 4.1 is confusing. It associates
'anticipation' with the case where the AR discovers 
other GAARs. This need not be the case. If anticipation
is in relation to handover, the MN can also discover
GAARs in advance. If anticipation is in relation to some
other event, then I think this 'other event' should be
stated. 

Chapter 4.2, on the other hand, explains the case where 
the MN discovers GAARs and is given a different. 

2. The first sentence of the same chapter (4.1) states
that the AR can discover a set of all GAARs for a 
certain MN. I think this assertion is false and I 
don't see why it should be stated at all. 

I hope this is clear enough. I really thought these 
are quite straight forward comments and we can fix
them quickly. Overall the draft is well written.

  > 
  > note that not all comments may pass working group consensus muster

=> Sure.

Hesham

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


From seamoby-admin@ietf.org  Tue Jan 15 10:31:21 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 KAA29074
	for ; Tue, 15 Jan 2002 10:31: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 KAA10074;
	Tue, 15 Jan 2002 10:18: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 KAA10044
	for ; Tue, 15 Jan 2002 10:18:28 -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 KAA28569
	for ; Tue, 15 Jan 2002 10:18:26 -0500 (EST)
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 g0FFJxQ01155
	for ; Tue, 15 Jan 2002 09:19:59 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 15 Jan 2002 09:18:26 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 15 Jan 2002 09:17:24 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [Seamoby] Status of WG Last Call
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 15 Jan 2002 10:17:23 -0500
Message-ID: 
Thread-Topic: [Seamoby] Status of WG Last Call
Thread-Index: AcGd1omENxI1VQnJEdaJYgAIx6TWpQAADrRQ
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Hesham Soliman (ERA)'" ,
        "Scott  Bradner" , ,
        , 
X-OriginalArrivalTime: 15 Jan 2002 15:17:24.0783 (UTC) FILETIME=[BC6C53F0:01C19DD7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA10045
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 Hesham,

As I tried to explain, the terms anticipated as well as dynamic are 
meant as timing-based differentiation criterias regarding the knowledge 
of the CARs in the case of a handoff event. So I don't quite understand 
why the title as such is confusing since what you mentioned is our
example 
in the text that, in your opinion, precludes MN-based anticipated CAR 
discovery.

So why don't we agree on explicit statements that the descriptions
(for both cases) merely outlines examples how (and where) the
anticipation
(or the dynamic request for the second case) could happen so that we
eliminate the impression to preclude other solutions.

The second comment is no problem.

BTW, the focus in Section 4.2 is not on the fact that the MN discovers,
it is the again the TIME when the GAARs are discovered, namely at the
time of handoff in contrast to the example in Section 4.1 !

Regards,



Dirk

> -----Original Message-----
> From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
> Sent: Tuesday, January 15, 2002 10:08 AM
> To: Scott Bradner; Hesham Soliman (ERA); kempf@docomolabs-usa.com;
> pcalhoun@bstormnetworks.com; seamoby@ietf.org
> Subject: RE: [Seamoby] Status of WG Last Call
> 
> 
> Hi Scott and all,
> 
>   > note that the IETF always wants to know about real problems 
>   > in specifications
>   > but it is helpful if people who have problems be very clear 
>   > as to what they
>   > are - so, Hesham, can you please send your comments to the 
>   > list now -
>   > please be very careful to say 
>   > 	1/ exactly what you think is wrong
>   > 	2/ exactly what you think should be done to fix it
> 
> => I have 2 minor comments really but I thought they were
> important enough to make sure we understand the different
> ways of solving the problems outlined in the draft. 
> 
> 1. The title of chapter 4.1 is confusing. It associates
> 'anticipation' with the case where the AR discovers 
> other GAARs. This need not be the case. If anticipation
> is in relation to handover, the MN can also discover
> GAARs in advance. If anticipation is in relation to some
> other event, then I think this 'other event' should be
> stated. 
> 
> Chapter 4.2, on the other hand, explains the case where 
> the MN discovers GAARs and is given a different. 
> 
> 2. The first sentence of the same chapter (4.1) states
> that the AR can discover a set of all GAARs for a 
> certain MN. I think this assertion is false and I 
> don't see why it should be stated at all. 
> 
> I hope this is clear enough. I really thought these 
> are quite straight forward comments and we can fix
> them quickly. Overall the draft is well written.
> 
>   > 
>   > note that not all comments may pass working group consensus muster
> 
> => Sure.
> 
> Hesham
> 
> _______________________________________________
> 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 Jan 15 12:19: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 MAA05902
	for ; Tue, 15 Jan 2002 12:19: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 LAA13217;
	Tue, 15 Jan 2002 11:56: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 LAA13186
	for ; Tue, 15 Jan 2002 11:56:55 -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 LAA04910
	for ; Tue, 15 Jan 2002 11:56:52 -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 IAA23921;
	Tue, 15 Jan 2002 08:56:21 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0FGuKH08184;
	Tue, 15 Jan 2002 08:56:20 -0800
X-mProtect:  Tue, 15 Jan 2002 08:56:20 -0800 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdyZ0QXi; Tue, 15 Jan 2002 08:56:18 PST
Message-ID: <3C445F33.480C86F@iprg.nokia.com>
Date: Tue, 15 Jan 2002 08:56:19 -0800
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "'James Kempf'" ,
        "Pat R. Calhoun" 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] RE: CAR Discovery Draft
References: <4DA6EA82906FD511BE2F00508BCF053801C4C1F1@Esealnt861.al.sw.ericsson.se>
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,

It was written to the [seamoby] mailing list:

>> One of the problems with not having a consistent set
>> of terminology for wireless networking in the IETF
>> is that it becomes difficult to find a word that describes
>> the concept you are trying to get at without impinging
>> on what somebody else thinks a particular word
>> means.

I would like again to propose that the terminology draft
be accepted as a working group document in [seamoby], and
that we update it as needed whenever the working group
decides on a definition.

Regards,
Charlie P.

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


From seamoby-admin@ietf.org  Tue Jan 15 12:37: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 MAA06482
	for ; Tue, 15 Jan 2002 12:37: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 MAA14522;
	Tue, 15 Jan 2002 12:25: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 MAA14493
	for ; Tue, 15 Jan 2002 12:25:36 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06119
	for ; Tue, 15 Jan 2002 12:25:32 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0FHOwS23097;
	Tue, 15 Jan 2002 09:24:58 -0800 (PST)
Message-ID: <003801c19de9$551e6280$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Vijay Devarapalli" 
Cc: "Behcet Sarikaya" , 
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com> <3C433991.2090906@alcatel.com> <01fe01c19d3d$32563180$7e6015ac@T23KEMPF> <3C437674.F7603259@iprg.nokia.com>
Subject: Re: [Seamoby] Re: IP Paging Protocol
Date: Tue, 15 Jan 2002 09:23:22 -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

Vijay,

> People spend a lot of their time to come up with proposals.
> and they also hope that their proposal goes somewhere in the
> WG. and when the protocol assessment turns out to be murky
> and they complain, I dont think it is right to call them 
> "sour grapes".
> 

I fully appreciate the amount of time people spend putting
into their proposals and I was not trying to denigate that.
A soccer team works hard to win a tournament, but after
the game has been decided, they don't go around
complaining about the result, at least, not if
they are good sportsmen. It seems to me more than passing strange that
the only people who have so far complained about the
decision publically are people whose proposals weren't
selected. Furthermore, authors of two of the
drafts that were not selected have publically declared
themselves ready to continue working with the working
group, and it is really just the author of the third who
continues to agitate against the decision. 

If there was an outcry on the list from others, I would be more
inclined to view the complaints seriously. In the past,
the Seamoby list has not been short of people who
were ready to jump out at the first sign of a technical
controversy and express their opinions. I have not
seen a single one of those people, either in SLC
or on the list, stand up publically and say that they did
not agree with the decision.

I've already agreed that the the decision process
by which the selection was made was not
transparent. I have some text that I have
written which I hope will render more
transparency to the process,  but I have
not yet been able to get a time to
talk with Pat and Allision about it.
If you can just be patient, I will
post the text as soon as we have
had a chance to review it. Let's see if there
are any complaints from neutral
sources about the decision after
I've posted that text.

            jak



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


From seamoby-admin@ietf.org  Tue Jan 15 12:48: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 MAA07008
	for ; Tue, 15 Jan 2002 12:48: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 MAA15118;
	Tue, 15 Jan 2002 12:35: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 MAA15090
	for ; Tue, 15 Jan 2002 12:34:57 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06371
	for ; Tue, 15 Jan 2002 12:34:53 -0500 (EST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0FHYuK07956
	for ; Tue, 15 Jan 2002 18:34:56 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jan 15 18:34:55 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 15 Jan 2002 18:25:56 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C204@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Trossen Dirk (NRC/Boston)'" ,
        "Hesham Soliman (ERA)" ,
        Scott  Bradner
	 , kempf@docomolabs-usa.com,
        pcalhoun@bstormnetworks.com, seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Tue, 15 Jan 2002 18:34:36 +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

  > As I tried to explain, the terms anticipated as well as dynamic are 
  > meant as timing-based differentiation criterias regarding 
  > the knowledge 
  > of the CARs in the case of a handoff event. 

=> And I already tried to explain that this is not reflecting
the text in the draft. I don't think we're making any 
progress, but I suggest you read the draft without 
your author's hat because I get the impression that the 
authors meant somethings that are not obvious to me
in the text. But of course I could also be wrong.

  > 
  > So why don't we agree on explicit statements that the descriptions
  > (for both cases) merely outlines examples how (and where) the
  > anticipation
  > (or the dynamic request for the second case) could happen so that we
  > eliminate the impression to preclude other solutions.

=> You mean we state that the chapter (e.g. 4.1) only
states one example of achieving anticipation ?
Do you think that this is easier than changing the 
title to reflect the real concepts behind the chapter ? 

  > 
  > The second comment is no problem.

=> OK.

  > 
  > BTW, the focus in Section 4.2 is not on the fact that the 
  > MN discovers,
  > it is the again the TIME when the GAARs are discovered, 
  > namely at the
  > time of handoff in contrast to the example in Section 4.1 !

=> I might be confused or unable to comprehend your explanation
in the draft, but what you're explaining on email 
does not (entirely) reflect the draft. I'm not saying time 
is not relevant here (although you insist on repeating this), 
I am saying that the differences between 4.1 and 4.2
are TIMING and ENTITIES involved in the discovery. 
If you agree with that, then the text in the draft
does not reflect this. 

I have expressed my opinion several times now and I 
can see we're revisiting the same places, so it's
up to the WG to decide on this. 

Hesham


  > 
  > Regards,
  > 
  > 
  > 
  > Dirk
  > 
  > > -----Original Message-----
  > > From: ext Hesham Soliman (ERA) 
[mailto:hesham.soliman@era.ericsson.se]
> Sent: Tuesday, January 15, 2002 10:08 AM
> To: Scott Bradner; Hesham Soliman (ERA); kempf@docomolabs-usa.com;
> pcalhoun@bstormnetworks.com; seamoby@ietf.org
> Subject: RE: [Seamoby] Status of WG Last Call
> 
> 
> Hi Scott and all,
> 
>   > note that the IETF always wants to know about real problems 
>   > in specifications
>   > but it is helpful if people who have problems be very clear 
>   > as to what they
>   > are - so, Hesham, can you please send your comments to the 
>   > list now -
>   > please be very careful to say 
>   > 	1/ exactly what you think is wrong
>   > 	2/ exactly what you think should be done to fix it
> 
> => I have 2 minor comments really but I thought they were
> important enough to make sure we understand the different
> ways of solving the problems outlined in the draft. 
> 
> 1. The title of chapter 4.1 is confusing. It associates
> 'anticipation' with the case where the AR discovers 
> other GAARs. This need not be the case. If anticipation
> is in relation to handover, the MN can also discover
> GAARs in advance. If anticipation is in relation to some
> other event, then I think this 'other event' should be
> stated. 
> 
> Chapter 4.2, on the other hand, explains the case where 
> the MN discovers GAARs and is given a different. 
> 
> 2. The first sentence of the same chapter (4.1) states
> that the AR can discover a set of all GAARs for a 
> certain MN. I think this assertion is false and I 
> don't see why it should be stated at all. 
> 
> I hope this is clear enough. I really thought these 
> are quite straight forward comments and we can fix
> them quickly. Overall the draft is well written.
> 
>   > 
>   > note that not all comments may pass working group consensus muster
> 
> => Sure.
> 
> Hesham
> 
> _______________________________________________
> 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 Jan 15 13: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 NAA07645
	for ; Tue, 15 Jan 2002 13:10: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 MAA15672;
	Tue, 15 Jan 2002 12:58: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 MAA15641
	for ; Tue, 15 Jan 2002 12:58:32 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07219
	for ; Tue, 15 Jan 2002 12:58:30 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0FHvtS24523;
	Tue, 15 Jan 2002 09:57:55 -0800 (PST)
Message-ID: <00f501c19ded$ef9c9170$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Trossen Dirk \(NRC/Boston\)" ,
        "'ext Hesham Soliman \(ERA\)'" ,
        "Govind Krishnamurthi" , 
References: 
Date: Tue, 15 Jan 2002 09:56: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
Subject: [Seamoby] Differences in Requirements between AR and MN CAR discovery
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,

I understand, but I believe that Hesham, and perhaps some others, do
think that
there will be different requirements based on whether the MN or
the ARs are doing the discovery.

I agree that we need to have a clearer understanding of what the
differences in requirements are. Perhaps those who think
that there should be a difference can post specific requirements
that they believe do differ (and please post under the above
subject, so I can keep track of the thread). If we don't get a well
articulated list of such requirements by the end of the requirements
development
period, then I think we can be justified in not separating them.

            jak

----- Original Message -----
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Hesham Soliman (ERA)'" ;
"Govind Krishnamurthi" ; 
Sent: Tuesday, January 15, 2002 6:47 AM
Subject: RE: [Seamoby] CAR Discovery Requirements


> Hi Hesham,
>
> I guess Govind's point was (as I also outlined in my mail regarding
> separation of requirements) that we don't see how the requirements
> will change for an MN-based or AR-based scheme.
>
> This is true in particular for the requirements you mentioned. Isn't
> it the fundamental task of CAR discovery to resolve L2Ids to L3Ids?
> Why would this be different for an MN-based or AR-based scheme?
> And why is there a difference in the inter-domain support? Either
> we agree that GAARs are discovered even if they are in different
> administrative domains or not. Whether the MN is doing (most of) the
> job or the AR, doesn't really matter.
>
> So as I said in my previous email, please outline exactly WHAT
> requirements you have in mind that justify this separation. Right now,
> we are only discussing about the procedure without having the
> meat to fill.
>
> Regards,
>
>
>
> Dirk
>
> > -----Original Message-----
> > From: ext Hesham Soliman (ERA)
[mailto:hesham.soliman@era.ericsson.se]
> > Sent: Tuesday, January 15, 2002 8:58 AM
> > To: Govind Krishnamurthi; seamoby@ietf.org
> > Subject: RE: [Seamoby] CAR Discovery Requirements
> >
> >
> > Govind,
> >
> >   > Where does the current set of requirements preclude any
> >   > sort of mobile node
> >   > involvement. I think
> >   > whether an MN is involved or not is implementation specific..
and
> >   > not a requirements issue. I don't think the requirements
> >   > for CAR discovery
> >   > change whether a MN is involved or not.
> >
> > => What is this in response to exactly ? I didn't claim
> > the opposite of what you said, I said 'separate' the
> > requirements so we know what you refer to when you
> > say 'support inter-domain discovery' 'support mapping
> > from L2 to L3'.
> >
> > Also letting the MN
> >   > or AR decide
> >   > where actually to handover is out of scope of CAR discovery.
> >   > Just letting the MN also hear does not complete CAR
> >   > discovery.. CARs
> >   > comprise of GAARS + their capabilities.. What you say is
> > just GAARs.
> >
> > => Ok, please respond to the statements I made, just so
> > I can understand which parts you are referring to.
> >
> > Hesham
> >
> >   >
> >   > -Govind.
> >   > > >...
> >   > >   > >6. Protocol applicability ? SHOULD (?)
> >   > >   > >(show of hands indicated that this item should be changed
> >   > >   > to a MUST)
> >   > >   > >support inter-domain as well as Intra-domain scope
> >   > >   >
> >   > >   > Inter-domain discovery of access routers (which seems
> >   > >   > implied by what
> >   > >   > might otherwise seem an innocuous protocol design feature)
> >   > >   > is problematic.
> >   > >   >
> >   > >   > It would require resolving which users are subscribers of
> >   > >   > which domains,
> >   > >   > or complex inter-domain roaming and billing reciprocity.
> >   > >
> >   > >=> This is exactly why I urge you (this wg) to clearly
> >   > >explain which protocol you are talking about. AR - AR or
> >   > >AR MN ???
> >   > >Clearly AR - MN lis an obvious way to discover all routers
> >   > >that the MN can hear. Inter/intra domain issues are
> >   > >not relevant.
> >   > >
> >   > >So please make it clear which part of the protocol
> >   > >you're referring to. We should not always assume
> >   > >that we're discussing the AR - AR case.
> >   > >
> >   > >   > While it seems reasonable to avoid locking mobile stations
> >   > >   > into a single
> >   > >   > domain, the policy interactions of requiring
> >   > >   > multiple-domain discovery
> >   > >   > would make the task much more difficult at the start.
> >   > >
> >   > >=> Certainly. But there is an easy way of doing that:
> >   > >Let the MN decide.
> >   > >
> >   > >Hesham
> >   > >
> >   > >   > _______________________________________________
> >   > >   > 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
> >   >
> >   >
> >   >
> >   >
> >   >
_________________________________________________________________
> >   > 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
> >
> > _______________________________________________
> > 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 Jan 15 13: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 NAA07967
	for ; Tue, 15 Jan 2002 13:17: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 NAA16387;
	Tue, 15 Jan 2002 13:05: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 NAA16358
	for ; Tue, 15 Jan 2002 13:05:39 -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 NAA07466
	for ; Tue, 15 Jan 2002 13:05:37 -0500 (EST)
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 g0FI76Q21612
	for ; Tue, 15 Jan 2002 12:07:06 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 15 Jan 2002 12:05:31 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 15 Jan 2002 12:04:59 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [Seamoby] Status of WG Last Call
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 15 Jan 2002 13:04:58 -0500
Message-ID: 
Thread-Topic: [Seamoby] Status of WG Last Call
Thread-Index: AcGd6vu6sDOfMgndEdar0gAIx6S5QwAApPdA
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext Hesham Soliman (ERA)'" ,
        "Scott  Bradner" , ,
        , 
X-OriginalArrivalTime: 15 Jan 2002 18:04:59.0927 (UTC) FILETIME=[25C18A70:01C19DEF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA16359
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 Hesham,

see comments inline.
>   > 
>   > So why don't we agree on explicit statements that the descriptions
>   > (for both cases) merely outlines examples how (and where) the
>   > anticipation
>   > (or the dynamic request for the second case) could happen 
> so that we
>   > eliminate the impression to preclude other solutions.
> 
> => You mean we state that the chapter (e.g. 4.1) only
> states one example of achieving anticipation ?
> Do you think that this is easier than changing the 
> title to reflect the real concepts behind the chapter ? 

Yes, it is. The timing issue is the differentiation, reflected by
the title alone. A title 'AR- or router-based' introduces another
concept of differentiation, and the entire text has to reflect that
and has therefore to be changed appropriately. It is simply not done 
with just changing the title. As I suggested in my mail, let's explictly

state that the text only reflects examples to not preclude other 
solutions. 

Let's face it, this is an issue draft that is not intended to reflect 
all possible 'modes' of  operations since the basis issues of CAR
discovery 
is the same for all these 'modes'.

>   > 
>   > BTW, the focus in Section 4.2 is not on the fact that the 
>   > MN discovers,
>   > it is the again the TIME when the GAARs are discovered, 
>   > namely at the
>   > time of handoff in contrast to the example in Section 4.1 !
> 
> => I might be confused or unable to comprehend your explanation
> in the draft, but what you're explaining on email 
> does not (entirely) reflect the draft. I'm not saying time 
> is not relevant here (although you insist on repeating this), 
> I am saying that the differences between 4.1 and 4.2
> are TIMING and ENTITIES involved in the discovery. 
> If you agree with that, then the text in the draft
> does not reflect this. 

The differentiation is made based on time, the text are examples
for this mode. These examples indeed involve different entities
but we could have also used an AR-based example for Section 4.2.

> 
> I have expressed my opinion several times now and I 
> can see we're revisiting the same places, so it's
> up to the WG to decide on this. 

My problem is that exactly noone else participated in this
discussion. The specific text has been out now for six months
with two WG last calls, and noone came up with that discussion.
This means (maybe I understand the procedures wrong), that
the WG has already decided that this is ok. You are the only
one coming with this issue, and this after the second last call.

If we introduce procedure like this, we will certainly never come
to an end.

Regards,



Dirk

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


From seamoby-admin@ietf.org  Tue Jan 15 13:25: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 NAA08238
	for ; Tue, 15 Jan 2002 13:25: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 NAA16536;
	Tue, 15 Jan 2002 13:12: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 NAA16507
	for ; Tue, 15 Jan 2002 13:12:39 -0500 (EST)
Received: from hotmail.com (f3.law9.hotmail.com [64.4.9.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07733
	for ; Tue, 15 Jan 2002 13:12:37 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 15 Jan 2002 10:12:08 -0800
Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP;
	Tue, 15 Jan 2002 18:12:07 GMT
X-Originating-IP: [63.78.179.5]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Tue, 15 Jan 2002 13:12:07 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 15 Jan 2002 18:12:08.0079 (UTC) FILETIME=[24F459F0:01C19DF0]
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 Hesham,
I guess Dirk answered your questions in an earlier mail, explaining
my mail.
-Govind.
>Govind,
>
>   > Where does the current set of requirements preclude any
>   > sort of mobile node
>   > involvement. I think
>   > whether an MN is involved or not is implementation specific.. and
>   > not a requirements issue. I don't think the requirements
>   > for CAR discovery
>   > change whether a MN is involved or not.
>
>=> What is this in response to exactly ? I didn't claim
>the opposite of what you said, I said 'separate' the
>requirements so we know what you refer to when you
>say 'support inter-domain discovery' 'support mapping
>from L2 to L3'.
>
>Also letting the MN
>   > or AR decide
>   > where actually to handover is out of scope of CAR discovery.
>   > Just letting the MN also hear does not complete CAR
>   > discovery.. CARs
>   > comprise of GAARS + their capabilities.. What you say is just GAARs.
>
>=> Ok, please respond to the statements I made, just so
>I can understand which parts you are referring to.
>
>Hesham
>
>   >
>   > -Govind.
>   > > >...
>   > >   > >6. Protocol applicability ? SHOULD (?)
>   > >   > >(show of hands indicated that this item should be changed
>   > >   > to a MUST)
>   > >   > >support inter-domain as well as Intra-domain scope
>   > >   >
>   > >   > Inter-domain discovery of access routers (which seems
>   > >   > implied by what
>   > >   > might otherwise seem an innocuous protocol design feature)
>   > >   > is problematic.
>   > >   >
>   > >   > It would require resolving which users are subscribers of
>   > >   > which domains,
>   > >   > or complex inter-domain roaming and billing reciprocity.
>   > >
>   > >=> This is exactly why I urge you (this wg) to clearly
>   > >explain which protocol you are talking about. AR - AR or
>   > >AR MN ???
>   > >Clearly AR - MN lis an obvious way to discover all routers
>   > >that the MN can hear. Inter/intra domain issues are
>   > >not relevant.
>   > >
>   > >So please make it clear which part of the protocol
>   > >you're referring to. We should not always assume
>   > >that we're discussing the AR - AR case.
>   > >
>   > >   > While it seems reasonable to avoid locking mobile stations
>   > >   > into a single
>   > >   > domain, the policy interactions of requiring
>   > >   > multiple-domain discovery
>   > >   > would make the task much more difficult at the start.
>   > >
>   > >=> Certainly. But there is an easy way of doing that:
>   > >Let the MN decide.


>   > >
>   > >Hesham
>   > >
>   > >   > _______________________________________________
>   > >   > 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
>   >
>   >
>   >
>   >
>   > _________________________________________________________________
>   > 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




_________________________________________________________________
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 Jan 15 13:25: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 NAA08250
	for ; Tue, 15 Jan 2002 13:25: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 NAA16585;
	Tue, 15 Jan 2002 13:13: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 NAA16554
	for ; Tue, 15 Jan 2002 13:13: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 NAA07751
	for ; Tue, 15 Jan 2002 13:13: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 g0FICIjh001686;
	Tue, 15 Jan 2002 13:12: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 NAA27602;
	Tue, 15 Jan 2002 13:12:11 -0500 (EST)
Date: Tue, 15 Jan 2002 13:12:17 -0500
To: James Kempf 
Cc: Vijay Devarapalli ,
        Behcet Sarikaya , seamoby@ietf.org
Subject: Re: [Seamoby] Re: IP Paging Protocoly
Message-ID: <20020115181217.GC637@catfish>
Mail-Followup-To: James Kempf ,
	Vijay Devarapalli ,
	Behcet Sarikaya , seamoby@ietf.org
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com> <3C433991.2090906@alcatel.com> <01fe01c19d3d$32563180$7e6015ac@T23KEMPF> <3C437674.F7603259@iprg.nokia.com> <003801c19de9$551e6280$7e6015ac@T23KEMPF>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: <003801c19de9$551e6280$7e6015ac@T23KEMPF>
User-Agent: Mutt/1.3.25i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 63
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, Jan 15, 2002 at 09:23:22AM -0800, James Kempf wrote:
> Vijay,
> 
> > People spend a lot of their time to come up with proposals.
> > and they also hope that their proposal goes somewhere in the
> > WG. and when the protocol assessment turns out to be murky
> > and they complain, I dont think it is right to call them 
> > "sour grapes".
> > 
> 
> I fully appreciate the amount of time people spend putting
> into their proposals and I was not trying to denigate that.
> A soccer team works hard to win a tournament, but after
> the game has been decided, they don't go around
> complaining about the result, at least, not if
> they are good sportsmen. It seems to me more than passing strange that
> the only people who have so far complained about the
> decision publically are people whose proposals weren't
> selected. Furthermore, authors of two of the
> drafts that were not selected have publically declared
> themselves ready to continue working with the working
> group, and it is really just the author of the third who
> continues to agitate against the decision. 

No authors would complain about the result if the winner selection 
process was as clear as succer game which is based on the total score.

Yoshihiro Ohba


> 
> If there was an outcry on the list from others, I would be more
> inclined to view the complaints seriously. In the past,
> the Seamoby list has not been short of people who
> were ready to jump out at the first sign of a technical
> controversy and express their opinions. I have not
> seen a single one of those people, either in SLC
> or on the list, stand up publically and say that they did
> not agree with the decision.
> 
> I've already agreed that the the decision process
> by which the selection was made was not
> transparent. I have some text that I have
> written which I hope will render more
> transparency to the process,  but I have
> not yet been able to get a time to
> talk with Pat and Allision about it.
> If you can just be patient, I will
> post the text as soon as we have
> had a chance to review it. Let's see if there
> are any complaints from neutral
> sources about the decision after
> I've posted that text.
> 
>             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 Jan 15 13: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 NAA08296
	for ; Tue, 15 Jan 2002 13: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 NAA16646;
	Tue, 15 Jan 2002 13:14: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 NAA16615
	for ; Tue, 15 Jan 2002 13:14:48 -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 NAA07820
	for ; Tue, 15 Jan 2002 13:14:45 -0500 (EST)
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0FIEl905630
	for ; Tue, 15 Jan 2002 20:14:48 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 15 Jan 2002 20:14:46 +0200
Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 15 Jan 2002 20:14:45 +0200
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 15 Jan 2002 12:14:19 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 15 Jan 2002 13:14:18 -0500
Message-ID: 
Thread-Topic: Differences in Requirements between AR and MN CAR discovery
Thread-Index: AcGd7is5K3fRMAnhEdar0gAIx6S5QwAARQVQ
From: "Trossen Dirk (NRC/Boston)" 
To: "'ext James Kempf'" ,
        "ext Hesham Soliman (ERA)" ,
        "Govind Krishnamurthi" , 
X-OriginalArrivalTime: 15 Jan 2002 18:14:19.0075 (UTC) FILETIME=[7308C130:01C19DF0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA16616
Subject: [Seamoby] RE: Differences in Requirements between AR and MN CAR discovery
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,

> I understand, but I believe that Hesham, and perhaps some others, do
> think that
> there will be different requirements based on whether the MN or
> the ARs are doing the discovery.

With all due respect, James, but believing in differences won't
lead to any definition of requirements. I'm not saying that there
is no difference but I want to see it.

> 
> I agree that we need to have a clearer understanding of what the
> differences in requirements are. Perhaps those who think
> that there should be a difference can post specific requirements
> that they believe do differ (and please post under the above
> subject, so I can keep track of the thread). If we don't get a well
> articulated list of such requirements by the end of the requirements
> development
> period, then I think we can be justified in not separating them.

Thanks, that's exactly my point. All comments regarding separation
merely asked for separation without giving ANY concrete example.
But that's what I asked for. If we get a list of requirements that
indeed contains items that demand for a separation, we have to do 
this. But for that, we first need these items. I'm simply kind
of confused why we discuss first the grouping of information, i.e.,
requirements, before we actually have the information that justify
this specific grouping. Maybe, another grouping would make much
more sense actually. I'd like to discuss this at the end not before.

So please, everybody who 'believes' that this separation makes
sense, send the specific requirement(s) to the list. We'll keep
track of them and present (hopefully) an appropriate ordered/
separated/grouped list of them at the end of the discussion. 
Right now, we're still at the list that was presented in SLC 
(with some proposals to change MUSTs and SHOULDs).

Regards,



Dirk

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


From seamoby-admin@ietf.org  Tue Jan 15 13:34: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 NAA08665
	for ; Tue, 15 Jan 2002 13:34: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 NAA16941;
	Tue, 15 Jan 2002 13:23: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 NAA16916
	for ; Tue, 15 Jan 2002 13:23:49 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08213
	for ; Tue, 15 Jan 2002 13:23:47 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0FIMjS25798;
	Tue, 15 Jan 2002 10:22:46 -0800 (PST)
Message-ID: <018c01c19df1$67cfdf00$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Yoshihiro Ohba" 
Cc: "Vijay Devarapalli" ,
        "Behcet Sarikaya" , 
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com> <3C433991.2090906@alcatel.com> <01fe01c19d3d$32563180$7e6015ac@T23KEMPF> <3C437674.F7603259@iprg.nokia.com> <003801c19de9$551e6280$7e6015ac@T23KEMPF> <20020115181217.GC637@catfish>
Subject: Re: [Seamoby] Re: IP Paging Protocoly
Date: Tue, 15 Jan 2002 10:21:09 -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

Hi Yoshi,

> No authors would complain about the result if the winner selection
> process was as clear as succer game which is based on the total score.
>

I agree 100%, and that is why I am going to post the text that describes
how the decision was made. If it is not clear after that, then
we can discuss it further.

            jak




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


From seamoby-admin@ietf.org  Tue Jan 15 13:51: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 NAA09333
	for ; Tue, 15 Jan 2002 13:51: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 NAA17788;
	Tue, 15 Jan 2002 13:38: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 NAA17759
	for ; Tue, 15 Jan 2002 13:38:03 -0500 (EST)
Received: from hotmail.com (f69.law7.hotmail.com [216.33.237.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08753
	for ; Tue, 15 Jan 2002 13:38:00 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 15 Jan 2002 10:37:32 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP;
	Tue, 15 Jan 2002 18:37:31 GMT
X-Originating-IP: [63.78.179.5]
From: "Hemant Chaskar" 
To: seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Tue, 15 Jan 2002 18:37:31 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 15 Jan 2002 18:37:32.0172 (UTC) FILETIME=[B1627CC0:01C19DF3]
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 Hesham,

---Snip------

>=> I might be confused or unable to comprehend your explanation
>in the draft, but what you're explaining on email
>does not (entirely) reflect the draft. I'm not saying time
>is not relevant here (although you insist on repeating this),
>I am saying that the differences between 4.1 and 4.2
>are TIMING and ENTITIES involved in the discovery.
>If you agree with that, then the text in the draft
>does not reflect this.

We do not agree with this, and hence, the text does not reflect it either. 
It is only the TIMING that we are proposing for classification as it causes 
first order differentiation among the approaches. The second order 
differentiation based on who takes lead (I do not know how lead will be 
defined) in doing this is solution specific, and it is left as a free 
parameter in the problem statement. If we had to classify using (Timing, 
Entities) tuple, there would have been at least 4 combinations, as each of 
these parameters can take 2 distinct values. Or there would have been 9 
different classifications if each parameter can take "hybrid" as valid value 
as well.

Hemant

_________________________________________________________________
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  Tue Jan 15 13:58: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 NAA09621
	for ; Tue, 15 Jan 2002 13:58: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 NAA17939;
	Tue, 15 Jan 2002 13:47: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 NAA17910
	for ; Tue, 15 Jan 2002 13:47:11 -0500 (EST)
Received: from hotmail.com (f264.law9.hotmail.com [64.4.8.139])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09165
	for ; Tue, 15 Jan 2002 13:47:09 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 15 Jan 2002 10:46:41 -0800
Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP;
	Tue, 15 Jan 2002 18:46:40 GMT
X-Originating-IP: [63.78.179.5]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Tue, 15 Jan 2002 13:46:40 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 15 Jan 2002 18:46:41.0020 (UTC) FILETIME=[F8860BC0:01C19DF4]
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 Hesham,
We are working on text which
will detail a temporal classification of CAR discovery protocols.
We will post it on the WG mailing list. We look forward
to your comments then.
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  Tue Jan 15 16:38: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 QAA14038
	for ; Tue, 15 Jan 2002 16:38: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 QAA22942;
	Tue, 15 Jan 2002 16:27: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 QAA22908
	for ; Tue, 15 Jan 2002 16:27:23 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13797
	for ; Tue, 15 Jan 2002 16:27:19 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0FLQmS04535
	for ; Tue, 15 Jan 2002 13:26:48 -0800 (PST)
Message-ID: <026901c19e0b$1d102230$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Date: Tue, 15 Jan 2002 13:25:10 -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] Paging Protocol Implementation Plans Survey
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,

I'm interested in finding out who is planning on implementing the
Seamoby IP Paging protocol for *products*. Research prototypes
don't count, so don't bother answering this survey if
you are planning on doing a research prototype. If your product plans
require interoperable IP paging over the next couple years, or if you
are
working with an outside standardization body that requires IP paging,
please either send email to me or to the list. For those people who
are in startups and don't want to say, I realize that you need
to keep your product plans quiet, but we need to know
how much real, near-term interest there is in
standardizing IP paging.

Thanx.

            jak


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


From seamoby-admin@ietf.org  Tue Jan 15 16:57: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 QAA14536
	for ; Tue, 15 Jan 2002 16:57: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 QAA23795;
	Tue, 15 Jan 2002 16:47:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23764
	for ; Tue, 15 Jan 2002 16:47:07 -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 QAA14238
	for ; Tue, 15 Jan 2002 16:47:03 -0500 (EST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA10009 for ; Tue, 15 Jan 2002 14:47:05 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA08367 for ; Tue, 15 Jan 2002 14:36:17 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52)
	id ; Tue, 15 Jan 2002 15:47:04 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FD60@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'James Kempf'" , seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Implementation Plans Survey
Date: Tue, 15 Jan 2002 15:47:03 -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

just curious, what are we hoping to acheive from
this survey? This is already a Work item isn't it?


Madjid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Tuesday, January 15, 2002 3:25 PM
To: seamoby@ietf.org
Subject: [Seamoby] Paging Protocol Implementation Plans Survey


Folks,

I'm interested in finding out who is planning on implementing the
Seamoby IP Paging protocol for *products*. Research prototypes
don't count, so don't bother answering this survey if
you are planning on doing a research prototype. If your product plans
require interoperable IP paging over the next couple years, or if you
are
working with an outside standardization body that requires IP paging,
please either send email to me or to the list. For those people who
are in startups and don't want to say, I realize that you need
to keep your product plans quiet, but we need to know
how much real, near-term interest there is in
standardizing IP paging.

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  Tue Jan 15 18:42: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 SAA16379
	for ; Tue, 15 Jan 2002 18:42: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 SAA26680;
	Tue, 15 Jan 2002 18:27: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 SAA26651
	for ; Tue, 15 Jan 2002 18:27:31 -0500 (EST)
Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16109
	for ; Tue, 15 Jan 2002 18:27:28 -0500 (EST)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 15 Jan 2002 18:25:45 -0500
Message-ID: 
From: "Chitrapu, Prabhakar R" 
To: "'James Kempf'" , seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Implementation Plans Survey
Date: Tue, 15 Jan 2002 18:25:44 -0500
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

Hi Jak:

Clearly IP-Paging is useful when networks with differing underlying (below
IP) protocols need to interwork. Examples would be WLAN - UMTS and
WLAN-GSM/GPRS. As you know, the relevant standardization bodies are 3GPP/SA1
(for WLAN-UMTS interworking, where WLAN might include 802.11 family as well
as HiperLAN family) and ETSI/BRAN (for HiperLan/2 - UMTS interworking).
There are also other non-standardization groups that are interested in
determining technical requirements for such interworking. Most of such work
is in its early stages, so that specific interworking protocols are not
addressed yet. Certainly, IP-Paging could be used, but it remains to be seen
whether it (and its relatives such as IP-level Handovers, IP-level Context
Transfers etc etc)  would find usage. 

Hope this answers the question you were asking!

Regards
Prabhakar

--------------------
Prabhakar Chitrapu
InterDigital Communications Corp.

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Tuesday, January 15, 2002 4:25 PM
To: seamoby@ietf.org
Subject: [Seamoby] Paging Protocol Implementation Plans Survey

Folks,

I'm interested in finding out who is planning on implementing the
Seamoby IP Paging protocol for *products*. Research prototypes
don't count, so don't bother answering this survey if
you are planning on doing a research prototype. If your product plans
require interoperable IP paging over the next couple years, or if you
are
working with an outside standardization body that requires IP paging,
please either send email to me or to the list. For those people who
are in startups and don't want to say, I realize that you need
to keep your product plans quiet, but we need to know
how much real, near-term interest there is in
standardizing IP paging.

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  Tue Jan 15 19: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 TAA16899
	for ; Tue, 15 Jan 2002 19:13: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 SAA27500;
	Tue, 15 Jan 2002 18:56: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 SAA27471
	for ; Tue, 15 Jan 2002 18:56: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 SAA16690
	for ; Tue, 15 Jan 2002 18:56:30 -0500 (EST)
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 g0FNw4Q29138
	for ; Tue, 15 Jan 2002 17:58:04 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 15 Jan 2002 17:56:33 -0600
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 15 Jan 2002 17:56:33 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [Seamoby] Paging Protocol Implementation Plans Survey
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 15 Jan 2002 17:56:32 -0600
Message-ID: <748E8123D183394982E32A511DB3E73610B0BF@daebe005.NOE.Nokia.com>
Thread-Topic: [Seamoby] Paging Protocol Implementation Plans Survey
Thread-Index: AcGeC4l/MvEKCwn7Edar0gAIx6S5QwAEeC+A
From: "Purnadi Rene (NRC/Dallas)" 
To: "'ext James Kempf'" , 
X-OriginalArrivalTime: 15 Jan 2002 23:56:33.0151 (UTC) FILETIME=[424C18F0:01C19E20]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA27472
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,

I agree with Prabhakar that IP Paging is required. The IP based mobile
network is still in the early stage as well, so that the product may not
be relevant yet. The IP paging provides more efficient use of battery
and spectrum since in the IP dormant mode, the IP mobility procedures
can be reduced. 

Best Regards,
Rene Purnadi
Phone: +1 972.894.4897
Mobile: +1 972.342.3503
e-mail: rene.purnadi@nokia.com


-----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Tuesday, January 15, 2002 3:25 PM
To: seamoby@ietf.org
Subject: [Seamoby] Paging Protocol Implementation Plans Survey


Folks,

I'm interested in finding out who is planning on implementing the
Seamoby IP Paging protocol for *products*. Research prototypes
don't count, so don't bother answering this survey if
you are planning on doing a research prototype. If your product plans
require interoperable IP paging over the next couple years, or if you
are
working with an outside standardization body that requires IP paging,
please either send email to me or to the list. For those people who
are in startups and don't want to say, I realize that you need
to keep your product plans quiet, but we need to know
how much real, near-term interest there is in
standardizing IP paging.

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  Tue Jan 15 19:47: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 TAA17242
	for ; Tue, 15 Jan 2002 19:47: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 TAA28583;
	Tue, 15 Jan 2002 19:30: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 TAA28550
	for ; Tue, 15 Jan 2002 19:30:31 -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 TAA17048
	for ; Tue, 15 Jan 2002 19:30:29 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id SAA22317
	for ; Tue, 15 Jan 2002 18:30:00 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g0G0Txr12002
	for ; Tue, 15 Jan 2002 18:29:59 -0600 (CST)
Message-ID: <3C44CABD.4949D8D2@alcatel.com>
Date: Tue, 15 Jan 2002 18:35:10 -0600
From: Behcet Sarikaya 
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Re: IP Paging Protocol
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com> <3C433991.2090906@alcatel.com> <01fe01c19d3d$32563180$7e6015ac@T23KEMPF> <3C437674.F7603259@iprg.nokia.com> <003801c19de9$551e6280$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

I think that WG chairs should not expect WG members to react more than
what we observed so far. I reacted and pointed to one important problem
during the meeting and continued to argue on the mailing list. The other
WG members also have spoken out.
  WG members are kind people, we do not shout and leave the meeting room
slamming the door.
  WG members prefer to kindly indicate the peaceful solution which is two
fold, never again make such assessment irregularities and
>We believe that the process of creating an IP paging protocol can be
>> substantially improved, and that the establishment in Seamoby of a
>> design team comprising the authors of the current proposal and few
>> other relevant parties is the only realistic solution (as it has
>> already happened in other IETF WGs).

Regards,

James Kempf wrote:

>
>
>
> If there was an outcry on the list from others, I would be more
> inclined to view the complaints seriously. In the past,
> the Seamoby list has not been short of people who
> were ready to jump out at the first sign of a technical
> controversy and express their opinions. I have not
> seen a single one of those people, either in SLC
> or on the list, stand up publically and say that they did
> not agree with the decision.
>
> I've already agreed that the the decision process
> by which the selection was made was not
> transparent. I have some text that I have
> written which I hope will render more
> transparency to the process,  but I have
> not yet been able to get a time to
> talk with Pat and Allision about it.
> If you can just be patient, I will
> post the text as soon as we have
> had a chance to review it. Let's see if there
> are any complaints from neutral
> sources about the decision after
> I've posted that text.
>
>             jak
>
> _______________________________________________
> --

Behcet


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


From seamoby-admin@ietf.org  Tue Jan 15 22:17:21 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 WAA19729
	for ; Tue, 15 Jan 2002 22:17:21 -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 VAA03645;
	Tue, 15 Jan 2002 21:58: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 VAA03612
	for ; Tue, 15 Jan 2002 21:58:00 -0500 (EST)
Received: from hotmail.com (f264.law7.hotmail.com [216.33.236.142])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19542
	for ; Tue, 15 Jan 2002 21:57:57 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 15 Jan 2002 18:57:29 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP;
	Wed, 16 Jan 2002 02:57:28 GMT
X-Originating-IP: [63.78.179.5]
From: "Hemant Chaskar" 
To: seamoby@ietf.org
Date: Wed, 16 Jan 2002 02:57:28 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 16 Jan 2002 02:57:29.0372 (UTC) FILETIME=[891BF5C0:01C19E39]
Subject: [Seamoby] Revised Section 4 of CAR issues 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

Hi,

Here is the revised text for Section 4 of CAR discovery issues draft. The 
text has been finetuned. I hope that it is now clear enough. If there are no 
more concerns on Section 4, we can submit the problem statement draft with 
this text for Section 4, to IESG.

Hemant

-------------------------------snip----------------------------------

4. APPROACHES TO CANDIDATE ACCESS ROUTER DISCOVERY

In this section, we describe three approaches to CAR discovery,
namely the Anticipated CAR Discovery (discovery prior to handoff), Dynamic 
CAR
Discovery (discovery at the time of handoff) and Hybrid CAR Discovery.

4.1 Anticipated CAR Discovery

In Anticpated CAR Discovery, CAR discovery is performed at some
point prior to the MN performing a handoff. This can be performed in
a number of ways and with various entities particpating in the process.
One illustrative method for Anticipated CAR Discovery is given below.

In this method, an AR currently serving an MN can identify a set of CARs for
the MN's handoff, at some point prior to handoff. This information is then
available at the time of handoff as input to the TAR Selection Algorithm. 
Another
input to the TAR Selection Algorithm may be the preferences expressed by the 
MN
prior to the handoff, or preferences enforced by the administrative control. 
At
the time of handoff, it may only be required to provide input to the TAR 
Selection
Algorithm about the reachability of neighboring ARs from the MN. This 
reachability
information is usually in the form of the identity of the AP to which the MN
can listen to, and the current AR has to resolve this AP identity to the
GAAR's IP address.

The advantage of Anticipated CAR Discovery is that the handoff can be 
executed
quickly because much of the information needed by the TAR Selection 
Algorithm
is collected in advance of handoff.

Anticipated CAR Discovery is depicted in Figure 1.


    -----------------------------------------------------------------
   |                     All routers                                 |
   |                          |  Discovery of ARs whose coverage     |
   |                          |  areas overlap (GAARs) with that of  |
   |                          v  the current AR                      |
   |           Local map of GAARs at current AR                      |
   |                          |                                      |
   |                          |   Capability identification          |
   |                          v                                      |
   |      CARs for MN's handoff identified at current AR             |
   |                          |                                      |
    --------------------------|--------------------------------------
                              |
                              |   Predefined preferences of the MN
         AR Reachability      |   and administrative preferences
           for the MN         |
                |             |             |
                v             v             v
             TAR Selection Algorithm executed at the time of
             handoff to determine unique TAR for MN's handoff

              Figure 1: Anticipated CAR Discovery


4.2 Dynamic CAR Discovery

In Dyanmic CAR discovery, CAR discovery is performed at the time the MN is
about to undergo handoff. Again, this can be performed in a number of ways
and with various entities particpating in the process. One illustrative 
method
for Dynamic CAR Discovery is given below.

According to this method, an MN dynamically obtains information about the 
available
ARs for handoff, along with their capabilities. This is done after the 
handoff trigger
is generated. When the MN detects an AR that has capabilities matching its 
preferences,
the MN may notify the currently serving AR to perform a handoff to this AR 
using one or
more of the seamless handoff protocols. The advantage of this method is that 
the MN
has fine-grained control over the TAR selection. However, this method 
generates more
radio traffic during the CAR discovery step. This is because capability 
information is
sent to the MN over the air. Also, it is required that the MN can receive 
IP-level
capability information from the GAARs and negotiate requirements with the 
GAARs, while
still being connected to the current AR.


Dynamic CAR Discovery is shown in Figure 2.


       --------------------------------------------------------------
      |                                                              |
      |                 GAARs identified at handoff time             |
      |                           |                                  |
      |                           | Capability identification        |
      |                           |                                  |
      |                           v                                  |
      |            CARs for MN's handoff identified                  |
      |                           |                                  |
       ---------------------------|----------------------------------
                                  |
                                  | TAR selection at the
                                  |    time of handoff
                                  v
                        Unique TAR identity

                  Figure 2: Dynamic CAR Discovery


4.3 Hybrid CAR Discovery

In practice, a hybrid of the Anticipated and Dynamic CAR discovery 
approaches
may be used. For example, in the hybrid approach, the GAAR discovery and 
much
of the capability identification may be performed prior to handover, while 
the
remaining capability identification may happen during the handover process. 
But,
there are other alternatives too.

_________________________________________________________________
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  Wed Jan 16 05:47: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 FAA03876
	for ; Wed, 16 Jan 2002 05:47: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 FAA25648;
	Wed, 16 Jan 2002 05:33: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 FAA25621
	for ; Wed, 16 Jan 2002 05:33:27 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03790
	for ; Wed, 16 Jan 2002 05:33:23 -0500 (EST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0GAXOK24659
	for ; Wed, 16 Jan 2002 11:33:24 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jan 16 11:33:23 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 16 Jan 2002 11:33:23 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C205@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Govind Krishnamurthi'" , seamoby@ietf.org
Subject: RE: [Seamoby] Status of WG Last Call
Date: Wed, 16 Jan 2002 11:32:58 +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

Thanks, 
Hesham

  > -----Original Message-----
  > From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
  > Sent: Tuesday, January 15, 2002 7:47 PM
  > To: seamoby@ietf.org
  > Subject: RE: [Seamoby] Status of WG Last Call
  > 
  > 
  > Hello Hesham,
  > We are working on text which
  > will detail a temporal classification of CAR discovery protocols.
  > We will post it on the WG mailing list. We look forward
  > to your comments then.
  > 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  Wed Jan 16 08:30: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 IAA06544
	for ; Wed, 16 Jan 2002 08:30: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 IAA00096;
	Wed, 16 Jan 2002 08:14: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 IAA00065
	for ; Wed, 16 Jan 2002 08:14:09 -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 IAA06160
	for ; Wed, 16 Jan 2002 08:14:05 -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 g0GDE5H51302
	for ; Wed, 16 Jan 2002 14:14:05 +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 OAA32092
	for ; Wed, 16 Jan 2002 14:13:37 +0100
Message-ID: <3C457C80.59CBA8B6@ccrle.nec.de>
Date: Wed, 16 Jan 2002 14:13: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: Seamoby 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Technical issues of protocol assessment
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,

in order to address the issues of the paging protocol assessment, I send
the following comments to you. I already sent a list of comments on the
assessment on Dec, 4th, 2001. Some of the statements are taken over, but
I think it is reasonable to address the issues step by step. This is
open for discussion in order to move on and improve the current
architecture and protocol.

marco

----------------------------------
Issues addressed in 4.2:

4.2 Scalability:
The concept describes explicit idle state registration, which
requires one handshake with the composite Paging Agent. Additional
mechansims, like implicit/explicit dormancy as described in
draft-koodly, could be added. In case of not registering the
composite Paging Agent with the system in order to be able to
receive paging trigger packets, no additional signaling is
required (could be realized for example by integrating DMA
functionality in border routers). Since there will be multiple
composite Paging Agents in a domain, load will be shared between
them. Multiple Paging Agents furthermore will introduce redundancy
in order to support failover handling.

4.4 Efficient signaling while inactive
Please correct me if I misinterpreted this point.
The MN is either registered as IDLE or ACTIVE. When a MN is INACTIVE,
this is not an explicit state transition, which is to be signaled,
but could happen due to entering a location, where no wireless link
connection is available for any reason (e.g. due to obstacles) or
when the MN switches off due to unexpectied reasons (MN crashes).
Therefore, a MN never notifies the system of entering an inactive
state. It's up to the system to discover, that the MN is currently
not reachable. This is to be done only in case of an incoming paging
trigger packet. When the MN does not respond to paging request
messages, it's marked as 'not reachable' or 'inactive'.
This behaviour is described in D.4 of draft-renker-paging-ipv6-01.
From signaling point of view, at least a search within the
registered paging area is to be done before the MN can be marked as
'not reachable' [exponential backoff behaviour]. For this process,
even enhanced paging strategies (for example sequential polling)
introduce no gain in signaling avoidance. Tracking the idle MN by
e.g. polling periodically or expecting the MN to send 'heartbeat
massages' in order to proof that the MN is able to answer a
possible Paging Request, is somehow against the concepts of
paging and idle mode support.

4.6 Multiple Dormant Modes
Early requirements of the paging protocol referred to a paging
protocol, which should be independent of link interface specifics.
What the Paging Agent in draft-renker-paging-ipv6-01.txt supports
is a L3 protocol, that is independent of link interface specifics
'up to the Access Routers'. An appropriate paging functional entity
in each Access Router can map the L3 Paging Requests to link specifics
(L2 wake up mechanisms, ...) in order to support hardware power saving
modes. If there are more modes possible per interface and the MN
should select one and store this mode with the system, then some more
message options would be required (which could be easily conveyed as
TLV-encoded (sub-)options. Specifics on access technology should not
(yet) be part of the paging architecture/protocol specification.
First We should focus on having a generic functional architecure,
which allows easily extensions like the one discussed in this section
(and others).

4.7 Independence of Mobility Protocol
As already clarified, the explicit rehistration described in the
base-line draft should be taken for the generic case. As some already
suggested, the implicit case description could be part of
optimizations in the annex, if entirely de-coupled from the generic
protocol specified in the main part of the WG document.


To be continued...



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


From seamoby-admin@ietf.org  Wed Jan 16 09:57: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 JAA09875
	for ; Wed, 16 Jan 2002 09:57: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 JAA03101;
	Wed, 16 Jan 2002 09:39: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 JAA03070
	for ; Wed, 16 Jan 2002 09:39:34 -0500 (EST)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09080
	for ; Wed, 16 Jan 2002 09:39:28 -0500 (EST)
Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id C7800XQZ; Wed, 16 Jan 2002 09:39:14 -0500
Message-ID: <003f01c19e9b$91d4b3c0$6200000a@meshnetworks.com>
From: "Phil Neumiller" 
To: , 
Date: Wed, 16 Jan 2002 09:39:14 -0500
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Terminology Draft Needed
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,

I have seen Charlie pull out the terminology draft at least a few times! :-)  Why can't 
some WG chair in SeaMoby or MANET adopt it as WG draft?

http://people.nokia.net/~charliep/txt/seamoby/term.txt

It seems that many times arguments are over terminology.  IMO, I would like to 
the SeaMoby WG become a bridge between MANET and MIP technologies, 
especially with respect to AR discovery and CT.  This terminology draft would make
a very nice addition to the SeaMoby WG draft list.  

Best regards,

Phil


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


From seamoby-admin@ietf.org  Wed Jan 16 10:49: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 KAA11903
	for ; Wed, 16 Jan 2002 10:49: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 KAA05776;
	Wed, 16 Jan 2002 10:34: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 KAA05743
	for ; Wed, 16 Jan 2002 10:34:02 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11362
	for ; Wed, 16 Jan 2002 10:33:43 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g0GFXhJ28688
	for ; Wed, 16 Jan 2002 16:33:43 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Jan 16 16:33:26 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 16 Jan 2002 16:33:42 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C20D@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Hemant Chaskar'" , seamoby@ietf.org
Subject: RE: [Seamoby] Revised Section 4 of CAR issues draft
Date: Wed, 16 Jan 2002 16:33:21 +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'm happy with the new modifications.

Hesham

  > -----Original Message-----
  > From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
  > Sent: Wednesday, January 16, 2002 3:57 AM
  > To: seamoby@ietf.org
  > Subject: [Seamoby] Revised Section 4 of CAR issues draft
  > 
  > 
  > Hi,
  > 
  > Here is the revised text for Section 4 of CAR discovery 
  > issues draft. The 
  > text has been finetuned. I hope that it is now clear 
  > enough. If there are no 
  > more concerns on Section 4, we can submit the problem 
  > statement draft with 
  > this text for Section 4, to IESG.
  > 
  > Hemant
  > 
  > -------------------------------snip-------------------------
  > ---------
  > 
  > 4. APPROACHES TO CANDIDATE ACCESS ROUTER DISCOVERY
  > 
  > In this section, we describe three approaches to CAR discovery,
  > namely the Anticipated CAR Discovery (discovery prior to 
  > handoff), Dynamic 
  > CAR
  > Discovery (discovery at the time of handoff) and Hybrid CAR 
  > Discovery.
  > 
  > 4.1 Anticipated CAR Discovery
  > 
  > In Anticpated CAR Discovery, CAR discovery is performed at some
  > point prior to the MN performing a handoff. This can be performed in
  > a number of ways and with various entities particpating in 
  > the process.
  > One illustrative method for Anticipated CAR Discovery is 
  > given below.
  > 
  > In this method, an AR currently serving an MN can identify 
  > a set of CARs for
  > the MN's handoff, at some point prior to handoff. This 
  > information is then
  > available at the time of handoff as input to the TAR 
  > Selection Algorithm. 
  > Another
  > input to the TAR Selection Algorithm may be the preferences 
  > expressed by the 
  > MN
  > prior to the handoff, or preferences enforced by the 
  > administrative control. 
  > At
  > the time of handoff, it may only be required to provide 
  > input to the TAR 
  > Selection
  > Algorithm about the reachability of neighboring ARs from 
  > the MN. This 
  > reachability
  > information is usually in the form of the identity of the 
  > AP to which the MN
  > can listen to, and the current AR has to resolve this AP 
  > identity to the
  > GAAR's IP address.
  > 
  > The advantage of Anticipated CAR Discovery is that the 
  > handoff can be 
  > executed
  > quickly because much of the information needed by the TAR Selection 
  > Algorithm
  > is collected in advance of handoff.
  > 
  > Anticipated CAR Discovery is depicted in Figure 1.
  > 
  > 
  >     
  > -----------------------------------------------------------------
  >    |                     All routers                        
  >          |
  >    |                          |  Discovery of ARs whose 
  > coverage     |
  >    |                          |  areas overlap (GAARs) with 
  > that of  |
  >    |                          v  the current AR             
  >          |
  >    |           Local map of GAARs at current AR             
  >          |
  >    |                          |                             
  >          |
  >    |                          |   Capability identification 
  >          |
  >    |                          v                             
  >          |
  >    |      CARs for MN's handoff identified at current AR    
  >          |
  >    |                          |                             
  >          |
  >     
  > --------------------------|--------------------------------------
  >                               |
  >                               |   Predefined preferences of the MN
  >          AR Reachability      |   and administrative preferences
  >            for the MN         |
  >                 |             |             |
  >                 v             v             v
  >              TAR Selection Algorithm executed at the time of
  >              handoff to determine unique TAR for MN's handoff
  > 
  >               Figure 1: Anticipated CAR Discovery
  > 
  > 
  > 4.2 Dynamic CAR Discovery
  > 
  > In Dyanmic CAR discovery, CAR discovery is performed at the 
  > time the MN is
  > about to undergo handoff. Again, this can be performed in a 
  > number of ways
  > and with various entities particpating in the process. One 
  > illustrative 
  > method
  > for Dynamic CAR Discovery is given below.
  > 
  > According to this method, an MN dynamically obtains 
  > information about the 
  > available
  > ARs for handoff, along with their capabilities. This is 
  > done after the 
  > handoff trigger
  > is generated. When the MN detects an AR that has 
  > capabilities matching its 
  > preferences,
  > the MN may notify the currently serving AR to perform a 
  > handoff to this AR 
  > using one or
  > more of the seamless handoff protocols. The advantage of 
  > this method is that 
  > the MN
  > has fine-grained control over the TAR selection. However, 
  > this method 
  > generates more
  > radio traffic during the CAR discovery step. This is 
  > because capability 
  > information is
  > sent to the MN over the air. Also, it is required that the 
  > MN can receive 
  > IP-level
  > capability information from the GAARs and negotiate 
  > requirements with the 
  > GAARs, while
  > still being connected to the current AR.
  > 
  > 
  > Dynamic CAR Discovery is shown in Figure 2.
  > 
  > 
  >        
  > --------------------------------------------------------------
  >       |                                                     
  >          |
  >       |                 GAARs identified at handoff time    
  >          |
  >       |                           |                         
  >          |
  >       |                           | Capability 
  > identification        |
  >       |                           |                         
  >          |
  >       |                           v                         
  >          |
  >       |            CARs for MN's handoff identified         
  >          |
  >       |                           |                         
  >          |
  >        
  > ---------------------------|----------------------------------
  >                                   |
  >                                   | TAR selection at the
  >                                   |    time of handoff
  >                                   v
  >                         Unique TAR identity
  > 
  >                   Figure 2: Dynamic CAR Discovery
  > 
  > 
  > 4.3 Hybrid CAR Discovery
  > 
  > In practice, a hybrid of the Anticipated and Dynamic CAR discovery 
  > approaches
  > may be used. For example, in the hybrid approach, the GAAR 
  > discovery and 
  > much
  > of the capability identification may be performed prior to 
  > handover, while 
  > the
  > remaining capability identification may happen during the 
  > handover process. 
  > But,
  > there are other alternatives too.
  > 
  > _________________________________________________________________
  > Chat with friends online, try MSN Messenger: 
http://messenger.msn.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  Wed Jan 16 11:15: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 LAA12705
	for ; Wed, 16 Jan 2002 11:15: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 KAA06356;
	Wed, 16 Jan 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 KAA06316
	for ; Wed, 16 Jan 2002 10:51:56 -0500 (EST)
Received: from hotmail.com (f197.law9.hotmail.com [64.4.9.197])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11959
	for ; Wed, 16 Jan 2002 10:51:52 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 16 Jan 2002 07:51:13 -0800
Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP;
	Wed, 16 Jan 2002 15:51:13 GMT
X-Originating-IP: [63.78.179.4]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: RE: [Seamoby] Revised Section 4 of CAR issues draft
Date: Wed, 16 Jan 2002 10:51:13 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 16 Jan 2002 15:51:13.0428 (UTC) FILETIME=[A000BD40:01C19EA5]
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 Hesham,
Thanks for your comments.

Govind.
>
>
>I'm happy with the new modifications.
>
>Hesham
>
>   > -----Original Message-----
>   > From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
>   > Sent: Wednesday, January 16, 2002 3:57 AM
>   > To: seamoby@ietf.org
>   > Subject: [Seamoby] Revised Section 4 of CAR issues draft
>   >
>   >
>   > Hi,
>   >
>   > Here is the revised text for Section 4 of CAR discovery
>   > issues draft. The
>   > text has been finetuned. I hope that it is now clear
>   > enough. If there are no
>   > more concerns on Section 4, we can submit the problem
>   > statement draft with
>   > this text for Section 4, to IESG.
>   >
>   > Hemant
>   >
>   > -------------------------------snip-------------------------
>   > ---------
>   >
>   > 4. APPROACHES TO CANDIDATE ACCESS ROUTER DISCOVERY
>   >
>   > In this section, we describe three approaches to CAR discovery,
>   > namely the Anticipated CAR Discovery (discovery prior to
>   > handoff), Dynamic
>   > CAR
>   > Discovery (discovery at the time of handoff) and Hybrid CAR
>   > Discovery.
>   >
>   > 4.1 Anticipated CAR Discovery
>   >
>   > In Anticpated CAR Discovery, CAR discovery is performed at some
>   > point prior to the MN performing a handoff. This can be performed in
>   > a number of ways and with various entities particpating in
>   > the process.
>   > One illustrative method for Anticipated CAR Discovery is
>   > given below.
>   >
>   > In this method, an AR currently serving an MN can identify
>   > a set of CARs for
>   > the MN's handoff, at some point prior to handoff. This
>   > information is then
>   > available at the time of handoff as input to the TAR
>   > Selection Algorithm.
>   > Another
>   > input to the TAR Selection Algorithm may be the preferences
>   > expressed by the
>   > MN
>   > prior to the handoff, or preferences enforced by the
>   > administrative control.
>   > At
>   > the time of handoff, it may only be required to provide
>   > input to the TAR
>   > Selection
>   > Algorithm about the reachability of neighboring ARs from
>   > the MN. This
>   > reachability
>   > information is usually in the form of the identity of the
>   > AP to which the MN
>   > can listen to, and the current AR has to resolve this AP
>   > identity to the
>   > GAAR's IP address.
>   >
>   > The advantage of Anticipated CAR Discovery is that the
>   > handoff can be
>   > executed
>   > quickly because much of the information needed by the TAR Selection
>   > Algorithm
>   > is collected in advance of handoff.
>   >
>   > Anticipated CAR Discovery is depicted in Figure 1.
>   >
>   >
>   >
>   > -----------------------------------------------------------------
>   >    |                     All routers
>   >          |
>   >    |                          |  Discovery of ARs whose
>   > coverage     |
>   >    |                          |  areas overlap (GAARs) with
>   > that of  |
>   >    |                          v  the current AR
>   >          |
>   >    |           Local map of GAARs at current AR
>   >          |
>   >    |                          |
>   >          |
>   >    |                          |   Capability identification
>   >          |
>   >    |                          v
>   >          |
>   >    |      CARs for MN's handoff identified at current AR
>   >          |
>   >    |                          |
>   >          |
>   >
>   > --------------------------|--------------------------------------
>   >                               |
>   >                               |   Predefined preferences of the MN
>   >          AR Reachability      |   and administrative preferences
>   >            for the MN         |
>   >                 |             |             |
>   >                 v             v             v
>   >              TAR Selection Algorithm executed at the time of
>   >              handoff to determine unique TAR for MN's handoff
>   >
>   >               Figure 1: Anticipated CAR Discovery
>   >
>   >
>   > 4.2 Dynamic CAR Discovery
>   >
>   > In Dyanmic CAR discovery, CAR discovery is performed at the
>   > time the MN is
>   > about to undergo handoff. Again, this can be performed in a
>   > number of ways
>   > and with various entities particpating in the process. One
>   > illustrative
>   > method
>   > for Dynamic CAR Discovery is given below.
>   >
>   > According to this method, an MN dynamically obtains
>   > information about the
>   > available
>   > ARs for handoff, along with their capabilities. This is
>   > done after the
>   > handoff trigger
>   > is generated. When the MN detects an AR that has
>   > capabilities matching its
>   > preferences,
>   > the MN may notify the currently serving AR to perform a
>   > handoff to this AR
>   > using one or
>   > more of the seamless handoff protocols. The advantage of
>   > this method is that
>   > the MN
>   > has fine-grained control over the TAR selection. However,
>   > this method
>   > generates more
>   > radio traffic during the CAR discovery step. This is
>   > because capability
>   > information is
>   > sent to the MN over the air. Also, it is required that the
>   > MN can receive
>   > IP-level
>   > capability information from the GAARs and negotiate
>   > requirements with the
>   > GAARs, while
>   > still being connected to the current AR.
>   >
>   >
>   > Dynamic CAR Discovery is shown in Figure 2.
>   >
>   >
>   >
>   > --------------------------------------------------------------
>   >       |
>   >          |
>   >       |                 GAARs identified at handoff time
>   >          |
>   >       |                           |
>   >          |
>   >       |                           | Capability
>   > identification        |
>   >       |                           |
>   >          |
>   >       |                           v
>   >          |
>   >       |            CARs for MN's handoff identified
>   >          |
>   >       |                           |
>   >          |
>   >
>   > ---------------------------|----------------------------------
>   >                                   |
>   >                                   | TAR selection at the
>   >                                   |    time of handoff
>   >                                   v
>   >                         Unique TAR identity
>   >
>   >                   Figure 2: Dynamic CAR Discovery
>   >
>   >
>   > 4.3 Hybrid CAR Discovery
>   >
>   > In practice, a hybrid of the Anticipated and Dynamic CAR discovery
>   > approaches
>   > may be used. For example, in the hybrid approach, the GAAR
>   > discovery and
>   > much
>   > of the capability identification may be performed prior to
>   > handover, while
>   > the
>   > remaining capability identification may happen during the
>   > handover process.
>   > But,
>   > there are other alternatives too.
>   >
>   > _________________________________________________________________
>   > Chat with friends online, try MSN Messenger:
>http://messenger.msn.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




_________________________________________________________________
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  Wed Jan 16 11:46: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 LAA13699
	for ; Wed, 16 Jan 2002 11:46: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 LAA07825;
	Wed, 16 Jan 2002 11:28: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 LAA07794
	for ; Wed, 16 Jan 2002 11:28:12 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13132
	for ; Wed, 16 Jan 2002 11:28:08 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 16 Jan 2002 08:27:41 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Phil Neumiller'" , manet@itd.nrl.navy.mil,
        seamoby@ietf.org
Subject: RE: [Seamoby] Terminology Draft Needed
Date: Wed, 16 Jan 2002 08:27:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19EAA.B5757FD0"
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_01C19EAA.B5757FD0
Content-Type: text/plain

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

I brought this topic up with the ADs again yesterday, and there seems
to be agreement that such a document is necessary. However, it would
be useful if this document also included the security terminology
that we use, since it conflicts with some of the terms used WGs in
other areas (e.g. IPSec).

PatC

- -----Original Message-----
From: Phil Neumiller [mailto:pneumiller@meshnetworks.com] 
Sent: Wednesday, January 16, 2002 6:39 AM
To: manet@itd.nrl.navy.mil; seamoby@ietf.org
Subject: [Seamoby] Terminology Draft Needed


Hi,

I have seen Charlie pull out the terminology draft at least a few
times! :-)  Why can't 
some WG chair in SeaMoby or MANET adopt it as WG draft?

http://people.nokia.net/~charliep/txt/seamoby/term.txt

It seems that many times arguments are over terminology.  IMO, I
would like to 
the SeaMoby WG become a bridge between MANET and MIP technologies, 
especially with respect to AR discovery and CT.  This terminology
draft would make a very nice addition to the SeaMoby WG draft list.  

Best regards,

Phil


_______________________________________________
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/AwUBPEWp+DN1fXKoxmisEQKpKwCgsuQlnVlOxREcl5hKPmD76ZrjI74AoLNh
bL1hxFHUR1waVYM8pGeJbZW/
=JrHd
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C19EAA.B5757FD0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Terminology Draft Needed




 

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

Hash: SHA1




I brought this topic up with the ADs again yesterday, =
and there seems

to be agreement that such a document is necessary. =
However, it would

be useful if this document also included the =
security terminology

that we use, since it conflicts with some of the =
terms used WGs in

other areas (e.g. IPSec).




PatC




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

From: Phil Neumiller [mailto:pneumiller@meshnetwor=
ks.com] 

Sent: Wednesday, January 16, 2002 6:39 AM

To: manet@itd.nrl.navy.mil; seamoby@ietf.org

Subject: [Seamoby] Terminology Draft Needed






Hi,




I have seen Charlie pull out the terminology draft at =
least a few

times! :-)  Why can't 

some WG chair in SeaMoby or MANET adopt it as WG =
draft?




http://people.nokia.net/~charliep/txt/seamoby/term.txt=





It seems that many times arguments are over =
terminology.  IMO, I

would like to 

the SeaMoby WG become a bridge between MANET and MIP =
technologies, 

especially with respect to AR discovery and =
CT.  This terminology

draft would make a very nice addition to the SeaMoby =
WG draft list.  




Best regards,




Phil






_______________________________________________

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/AwUBPEWp+DN1fXKoxmisEQKpKwCgsuQlnVlOxREcl5hKPmD76ZrjI74AoLN=
h

bL1hxFHUR1waVYM8pGeJbZW/

=3DJrHd

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





------_=_NextPart_001_01C19EAA.B5757FD0--

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


From seamoby-admin@ietf.org  Wed Jan 16 12:28: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 MAA14961
	for ; Wed, 16 Jan 2002 12:28: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 MAA10416;
	Wed, 16 Jan 2002 12:07: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 MAA10385
	for ; Wed, 16 Jan 2002 12:07:31 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14240
	for ; Wed, 16 Jan 2002 12:07:27 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0GH6wS08355;
	Wed, 16 Jan 2002 09:06:58 -0800 (PST)
Message-ID: <000d01c19eaf$fbe04950$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" , 
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com> <3C433991.2090906@alcatel.com> <01fe01c19d3d$32563180$7e6015ac@T23KEMPF> <3C437674.F7603259@iprg.nokia.com> <003801c19de9$551e6280$7e6015ac@T23KEMPF> <3C44CABD.4949D8D2@alcatel.com>
Subject: Re: [Seamoby] Re: IP Paging Protocol
Date: Wed, 16 Jan 2002 09:05:22 -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

So, what is the difference between:

a)  Forming an open design team and anyone in the working group
having the right to participate with Marco as the editor of the
document,

and:

b) The situation we are in now?

Why should the design team be restricted to authors of the
existing protocols?

            jak

----- Original Message -----
From: "Behcet Sarikaya" 
To: 
Sent: Tuesday, January 15, 2002 4:35 PM
Subject: Re: [Seamoby] Re: IP Paging Protocol


> I think that WG chairs should not expect WG members to react more than
> what we observed so far. I reacted and pointed to one important
problem
> during the meeting and continued to argue on the mailing list. The
other
> WG members also have spoken out.
>   WG members are kind people, we do not shout and leave the meeting
room
> slamming the door.
>   WG members prefer to kindly indicate the peaceful solution which is
two
> fold, never again make such assessment irregularities and
> >We believe that the process of creating an IP paging protocol can be
> >> substantially improved, and that the establishment in Seamoby of a
> >> design team comprising the authors of the current proposal and few
> >> other relevant parties is the only realistic solution (as it has
> >> already happened in other IETF WGs).
>
> Regards,
>
> James Kempf wrote:
>
> >
> >
> >
> > If there was an outcry on the list from others, I would be more
> > inclined to view the complaints seriously. In the past,
> > the Seamoby list has not been short of people who
> > were ready to jump out at the first sign of a technical
> > controversy and express their opinions. I have not
> > seen a single one of those people, either in SLC
> > or on the list, stand up publically and say that they did
> > not agree with the decision.
> >
> > I've already agreed that the the decision process
> > by which the selection was made was not
> > transparent. I have some text that I have
> > written which I hope will render more
> > transparency to the process,  but I have
> > not yet been able to get a time to
> > talk with Pat and Allision about it.
> > If you can just be patient, I will
> > post the text as soon as we have
> > had a chance to review it. Let's see if there
> > are any complaints from neutral
> > sources about the decision after
> > I've posted that text.
> >
> >             jak
> >
> > _______________________________________________
> > --
>
> 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  Wed Jan 16 12:38: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 MAA15254
	for ; Wed, 16 Jan 2002 12:38: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 MAA10844;
	Wed, 16 Jan 2002 12: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 MAA10806
	for ; Wed, 16 Jan 2002 12:21:01 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14660
	for ; Wed, 16 Jan 2002 12:20:57 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0GHKTS08818;
	Wed, 16 Jan 2002 09:20:29 -0800 (PST)
Message-ID: <005d01c19eb1$df1cc850$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Phil Neumiller" , 
References: <003f01c19e9b$91d4b3c0$6200000a@meshnetworks.com>
Subject: Re: [Seamoby] Terminology Draft Needed
Date: Wed, 16 Jan 2002 09:18:53 -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

Phil,

Pat and I were planning on sending a message out about this. I had asked
Charlie for a pointer to
the draft, you have helpfully supplied it (see below). Thanx.

So we have one strong endorsement of adopting the Charlie's terminology
draft as a WG item.
Anyone else have strong feelings one way or the other on the issue?

            jak

----- Original Message -----
From: "Phil Neumiller" 
To: ; 
Sent: Wednesday, January 16, 2002 6:39 AM
Subject: [Seamoby] Terminology Draft Needed


> Hi,
>
> I have seen Charlie pull out the terminology draft at least a few
times! :-)  Why can't
> some WG chair in SeaMoby or MANET adopt it as WG draft?
>
> http://people.nokia.net/~charliep/txt/seamoby/term.txt
>
> It seems that many times arguments are over terminology.  IMO, I would
like to
> the SeaMoby WG become a bridge between MANET and MIP technologies,
> especially with respect to AR discovery and CT.  This terminology
draft would make
> a very nice addition to the SeaMoby WG draft list.
>
> Best regards,
>
> Phil
>
>
> _______________________________________________
> 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 Jan 16 13:04: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 NAA16088
	for ; Wed, 16 Jan 2002 13:04: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 MAA12096;
	Wed, 16 Jan 2002 12:48: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 MAA12065
	for ; Wed, 16 Jan 2002 12:48:04 -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 MAA15549
	for ; Wed, 16 Jan 2002 12:48:01 -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 LAA09466
	for ; Wed, 16 Jan 2002 11:47:32 -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 g0GHlWs19521
	for ; Wed, 16 Jan 2002 11:47:32 -0600 (CST)
Message-ID: <3C45BCA9.5030702@alcatel.com>
Date: Wed, 16 Jan 2002 11:47:21 -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
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Re: IP Paging Protocol
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com> <3C433991.2090906@alcatel.com> <01fe01c19d3d$32563180$7e6015ac@T23KEMPF> <3C437674.F7603259@iprg.nokia.com> <003801c19de9$551e6280$7e6015ac@T23KEMPF> <3C44CABD.4949D8D2@alcatel.com> <000d01c19eaf$fbe04950$7e6015ac@T23KEMPF>
Content-Type: multipart/alternative;
 boundary="------------060106010807090209070006"
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


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

First of all can you please announce that there is no WG draft?
Then maybe we can discuss how the design team should be structured and 
who leads it.

Regards,

James Kempf wrote:

>So, what is the difference between:
>
>a)  Forming an open design team and anyone in the working group
>having the right to participate with Marco as the editor of the
>document,
>
>and:
>
>b) The situation we are in now?
>
>Why should the design team be restricted to authors of the
>existing protocols?
>
>            jak
>
>----- Original Message -----
>From: "Behcet Sarikaya" 
>To: 
>Sent: Tuesday, January 15, 2002 4:35 PM
>Subject: Re: [Seamoby] Re: IP Paging Protocol
>
>
>>I think that WG chairs should not expect WG members to react more than
>>what we observed so far. I reacted and pointed to one important
>>
>problem
>
>>during the meeting and continued to argue on the mailing list. The
>>
>other
>
>>WG members also have spoken out.
>>  WG members are kind people, we do not shout and leave the meeting
>>
>room
>
>>slamming the door.
>>  WG members prefer to kindly indicate the peaceful solution which is
>>
>two
>
>>fold, never again make such assessment irregularities and
>>
>>>We believe that the process of creating an IP paging protocol can be
>>>
>>>>substantially improved, and that the establishment in Seamoby of a
>>>>design team comprising the authors of the current proposal and few
>>>>other relevant parties is the only realistic solution (as it has
>>>>already happened in other IETF WGs).
>>>>
>>Regards,
>>
>>James Kempf wrote:
>>
>>>
>>>
>>>If there was an outcry on the list from others, I would be more
>>>inclined to view the complaints seriously. In the past,
>>>the Seamoby list has not been short of people who
>>>were ready to jump out at the first sign of a technical
>>>controversy and express their opinions. I have not
>>>seen a single one of those people, either in SLC
>>>or on the list, stand up publically and say that they did
>>>not agree with the decision.
>>>
>>>I've already agreed that the the decision process
>>>by which the selection was made was not
>>>transparent. I have some text that I have
>>>written which I hope will render more
>>>transparency to the process,  but I have
>>>not yet been able to get a time to
>>>talk with Pat and Allision about it.
>>>If you can just be patient, I will
>>>post the text as soon as we have
>>>had a chance to review it. Let's see if there
>>>are any complaints from neutral
>>>sources about the decision after
>>>I've posted that text.
>>>
>>>            jak
>>>
>>>_______________________________________________
>>>--
>>>
>>Behcet
>>
>>
>>_______________________________________________
>>Seamoby mailing list
>>Seamoby@ietf.org
>>https://www1.ietf.org/mailman/listinfo/seamoby
>>
>

-- 
Behcet 



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





First of all can you please announce that there is no WG draft? 

Then maybe we can discuss how the design team should be structured and who
leads it. 



Regards,



James Kempf wrote:



  
So, what is the difference between:

a)  Forming an open design team and anyone in the working group
having the right to participate with Marco as the editor of the
document,

and:

b) The situation we are in now?

Why should the design team be restricted to authors of the
existing protocols?

            jak

----- Original Message -----
From: "Behcet Sarikaya" <behcet.sarikaya@alcatel.com>
To: <seamoby@ietf.org>
Sent: Tuesday, January 15, 2002 4:35 PM
Subject: Re: [Seamoby] Re: IP Paging Protocol



  

    
I think that WG chairs should not expect WG members to react more than
what we observed so far. I reacted and pointed to one important

    

    
problem

    

      
during the meeting and continued to argue on the mailing list. The

      

      
other

      

        
WG members also have spoken out.
  WG members are kind people, we do not shout and leave the meeting

        

        
room

        

          
slamming the door.
  WG members prefer to kindly indicate the peaceful solution which is

          

          
two

          

            
fold, never again make such assessment irregularities and

            

              
We believe that the process of creating an IP paging protocol can be

              

                
substantially improved, and that the establishment in Seamoby of a
design team comprising the authors of the current proposal and few
other relevant parties is the only realistic solution (as it has
already happened in other IETF WGs).

                

                

                
Regards,

James Kempf wrote:


                

                  


If there was an outcry on the list from others, I would be more
inclined to view the complaints seriously. In the past,
the Seamoby list has not been short of people who
were ready to jump out at the first sign of a technical
controversy and express their opinions. I have not
seen a single one of those people, either in SLC
or on the list, stand up publically and say that they did
not agree with the decision.

I've already agreed that the the decision process
by which the selection was made was not
transparent. I have some text that I have
written which I hope will render more
transparency to the process,  but I have
not yet been able to get a time to
talk with Pat and Allision about it.
If you can just be patient, I will
post the text as soon as we have
had a chance to review it. Let's see if there
are any complaints from neutral
sources about the decision after
I've posted
 that text.

            jak

_______________________________________________
--

                  

                  
Behcet


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


                  

                  


                  

                  

                  
-- 
Behcet 

                  

                  
                  

--------------060106010807090209070006--


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


From seamoby-admin@ietf.org  Wed Jan 16 13: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 NAA16308
	for ; Wed, 16 Jan 2002 13: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 MAA12257;
	Wed, 16 Jan 2002 12: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 MAA12229
	for ; Wed, 16 Jan 2002 12:59:25 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15884
	for ; Wed, 16 Jan 2002 12:59:22 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0GHwqS10335;
	Wed, 16 Jan 2002 09:58:52 -0800 (PST)
Message-ID: <00b901c19eb7$3bf091b0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "James Kempf" ,
        "Phil Neumiller" , 
References: <003f01c19e9b$91d4b3c0$6200000a@meshnetworks.com> <005d01c19eb1$df1cc850$7e6015ac@T23KEMPF>
Subject: Re: [Seamoby] Terminology Draft Needed
Date: Wed, 16 Jan 2002 09:57: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

OK, taking off my WG chair hat...

I strongly support this. There have been two cases recently
in which mobility related terminology has been responsible for:

1) Delaying the release of a draft to the IESG after
it passed WG last call,

2) Delaying the movement of a draft to RFC.

I believe we need a consistent set of terminology for
mobility, and, as Pat has noted in another message,
I think the terminology draft should pay special attention
to security. In particular, it should contain a map of
security terms in general use by the mobile networks
community (i.e. cellular) to standard IETF terminology.

            jak

----- Original Message -----
From: "James Kempf" 
To: "Phil Neumiller" ; 
Sent: Wednesday, January 16, 2002 9:18 AM
Subject: Re: [Seamoby] Terminology Draft Needed


> Phil,
>
> Pat and I were planning on sending a message out about this. I had
asked
> Charlie for a pointer to
> the draft, you have helpfully supplied it (see below). Thanx.
>
> So we have one strong endorsement of adopting the Charlie's
terminology
> draft as a WG item.
> Anyone else have strong feelings one way or the other on the issue?
>
>             jak
>
> ----- Original Message -----
> From: "Phil Neumiller" 
> To: ; 
> Sent: Wednesday, January 16, 2002 6:39 AM
> Subject: [Seamoby] Terminology Draft Needed
>
>
> > Hi,
> >
> > I have seen Charlie pull out the terminology draft at least a few
> times! :-)  Why can't
> > some WG chair in SeaMoby or MANET adopt it as WG draft?
> >
> > http://people.nokia.net/~charliep/txt/seamoby/term.txt
> >
> > It seems that many times arguments are over terminology.  IMO, I
would
> like to
> > the SeaMoby WG become a bridge between MANET and MIP technologies,
> > especially with respect to AR discovery and CT.  This terminology
> draft would make
> > a very nice addition to the SeaMoby WG draft list.
> >
> > Best regards,
> >
> > Phil
> >
> >
> > _______________________________________________
> > 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 Jan 16 13:32: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 NAA17024
	for ; Wed, 16 Jan 2002 13:32: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 NAA13346;
	Wed, 16 Jan 2002 13:18: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 NAA13317
	for ; Wed, 16 Jan 2002 13:18:26 -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 NAA16503
	for ; Wed, 16 Jan 2002 13:18:23 -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 KAA13372;
	Wed, 16 Jan 2002 10:17:54 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0GIHr917005;
	Wed, 16 Jan 2002 10:17:53 -0800
X-mProtect:  Wed, 16 Jan 2002 10:17:53 -0800 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdyEUf6s; Wed, 16 Jan 2002 10:17:51 PST
Message-ID: <3C45C3D0.8D24D969@iprg.nokia.com>
Date: Wed, 16 Jan 2002 10:17:52 -0800
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Pat R. Calhoun" 
CC: "'Phil Neumiller'" , manet@itd.nrl.navy.mil,
        seamoby@ietf.org
Subject: Re: [Seamoby] Terminology Draft Needed
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


Hello folks,

This is a good idea.  Where can we find a list of the acceptable
security terminology to incorporate into the terminology draft?

Regards,
Charlie P.


> "Pat R. Calhoun" wrote:
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I brought this topic up with the ADs again yesterday, and there seems
> to be agreement that such a document is necessary. However, it would
> be useful if this document also included the security terminology
> that we use, since it conflicts with some of the terms used WGs in
> other areas (e.g. IPSec).
> 
> PatC
> 
> - -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@meshnetworks.com]
> Sent: Wednesday, January 16, 2002 6:39 AM
> To: manet@itd.nrl.navy.mil; seamoby@ietf.org
> Subject: [Seamoby] Terminology Draft Needed
> 
> Hi,
> 
> I have seen Charlie pull out the terminology draft at least a few
> times! :-)  Why can't
> some WG chair in SeaMoby or MANET adopt it as WG draft?
> 
> http://people.nokia.net/~charliep/txt/seamoby/term.txt
> 
> It seems that many times arguments are over terminology.  IMO, I
> would like to
> the SeaMoby WG become a bridge between MANET and MIP technologies,
> especially with respect to AR discovery and CT.  This terminology
> draft would make a very nice addition to the SeaMoby WG draft list.
> 
> Best regards,
> 
> Phil
> 
> _______________________________________________
> 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/AwUBPEWp+DN1fXKoxmisEQKpKwCgsuQlnVlOxREcl5hKPmD76ZrjI74AoLNh
> bL1hxFHUR1waVYM8pGeJbZW/
> =JrHd
> -----END PGP SIGNATURE-----

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


From seamoby-admin@ietf.org  Wed Jan 16 13:32: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 NAA17036
	for ; Wed, 16 Jan 2002 13:32: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 NAA13230;
	Wed, 16 Jan 2002 13:15: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 NAA13198
	for ; Wed, 16 Jan 2002 13:15:30 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16375
	for ; Wed, 16 Jan 2002 13:15:27 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0GIEvS11105;
	Wed, 16 Jan 2002 10:14:57 -0800 (PST)
Message-ID: <00da01c19eb9$7b1c86d0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" 
Cc: 
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com> <3C433991.2090906@alcatel.com> <01fe01c19d3d$32563180$7e6015ac@T23KEMPF> <3C437674.F7603259@iprg.nokia.com> <003801c19de9$551e6280$7e6015ac@T23KEMPF> <3C44CABD.4949D8D2@alcatel.com> <000d01c19eaf$fbe04950$7e6015ac@T23KEMPF> <3C45BCA9.5030702@alcatel.com>
Subject: Re: [Seamoby] Re: IP Paging Protocol
Date: Wed, 16 Jan 2002 10:13:21 -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 will do no such thing.

Please answer my question.

            jak

----- Original Message -----
From: "Behcet Sarikaya" 
Cc: 
Sent: Wednesday, January 16, 2002 9:47 AM
Subject: Re: [Seamoby] Re: IP Paging Protocol


> First of all can you please announce that there is no WG draft?
> Then maybe we can discuss how the design team should be structured and
> who leads it.
>
> Regards,
>
> James Kempf wrote:
>
> >So, what is the difference between:
> >
> >a)  Forming an open design team and anyone in the working group
> >having the right to participate with Marco as the editor of the
> >document,
> >
> >and:
> >
> >b) The situation we are in now?
> >
> >Why should the design team be restricted to authors of the
> >existing protocols?
> >
> >            jak
> >
> >----- Original Message -----
> >From: "Behcet Sarikaya" 
> >To: 
> >Sent: Tuesday, January 15, 2002 4:35 PM
> >Subject: Re: [Seamoby] Re: IP Paging Protocol
> >
> >
> >>I think that WG chairs should not expect WG members to react more
than
> >>what we observed so far. I reacted and pointed to one important
> >>
> >problem
> >
> >>during the meeting and continued to argue on the mailing list. The
> >>
> >other
> >
> >>WG members also have spoken out.
> >>  WG members are kind people, we do not shout and leave the meeting
> >>
> >room
> >
> >>slamming the door.
> >>  WG members prefer to kindly indicate the peaceful solution which
is
> >>
> >two
> >
> >>fold, never again make such assessment irregularities and
> >>
> >>>We believe that the process of creating an IP paging protocol can
be
> >>>
> >>>>substantially improved, and that the establishment in Seamoby of a
> >>>>design team comprising the authors of the current proposal and few
> >>>>other relevant parties is the only realistic solution (as it has
> >>>>already happened in other IETF WGs).
> >>>>
> >>Regards,
> >>
> >>James Kempf wrote:
> >>
> >>>
> >>>
> >>>If there was an outcry on the list from others, I would be more
> >>>inclined to view the complaints seriously. In the past,
> >>>the Seamoby list has not been short of people who
> >>>were ready to jump out at the first sign of a technical
> >>>controversy and express their opinions. I have not
> >>>seen a single one of those people, either in SLC
> >>>or on the list, stand up publically and say that they did
> >>>not agree with the decision.
> >>>
> >>>I've already agreed that the the decision process
> >>>by which the selection was made was not
> >>>transparent. I have some text that I have
> >>>written which I hope will render more
> >>>transparency to the process,  but I have
> >>>not yet been able to get a time to
> >>>talk with Pat and Allision about it.
> >>>If you can just be patient, I will
> >>>post the text as soon as we have
> >>>had a chance to review it. Let's see if there
> >>>are any complaints from neutral
> >>>sources about the decision after
> >>>I've posted that text.
> >>>
> >>>            jak
> >>>
> >>>_______________________________________________
> >>>--
> >>>
> >>Behcet
> >>
> >>
> >>_______________________________________________
> >>Seamoby mailing list
> >>Seamoby@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/seamoby
> >>
> >
>
> --
> Behcet
>
>
>


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


From seamoby-admin@ietf.org  Wed Jan 16 14:21: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 OAA18246
	for ; Wed, 16 Jan 2002 14:21: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 NAA14964;
	Wed, 16 Jan 2002 13:57: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 NAA14934
	for ; Wed, 16 Jan 2002 13:57:57 -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 NAA17614
	for ; Wed, 16 Jan 2002 13:57:53 -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 g0GIvrH53368;
	Wed, 16 Jan 2002 19:57: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 TAA03817;
	Wed, 16 Jan 2002 19:57:25 +0100
Message-ID: <3C45CD15.9332BE81@ccrle.nec.de>
Date: Wed, 16 Jan 2002 19:57:25 +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] Paging Protocol Implementation Plans Survey
References: <026901c19e0b$1d102230$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,

clearly we will start with a research prototype first,
decision on a product will be done after the spec reaches
RFC status.

Marco

James Kempf wrote:

> Folks,
>
> I'm interested in finding out who is planning on implementing the
> Seamoby IP Paging protocol for *products*. Research prototypes
> don't count, so don't bother answering this survey if
> you are planning on doing a research prototype. If your product plans
> require interoperable IP paging over the next couple years, or if you
> are
> working with an outside standardization body that requires IP paging,
> please either send email to me or to the list. For those people who
> are in startups and don't want to say, I realize that you need
> to keep your product plans quiet, but we need to know
> how much real, near-term interest there is in
> standardizing IP paging.
>
> 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 Jan 16 15: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 PAA20069
	for ; Wed, 16 Jan 2002 15: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 OAA17352;
	Wed, 16 Jan 2002 14:57: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 OAA17324
	for ; Wed, 16 Jan 2002 14:57:09 -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 OAA19284
	for ; Wed, 16 Jan 2002 14:57:05 -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 NAA03504
	for ; Wed, 16 Jan 2002 13:56:37 -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 g0GJuam18692
	for ; Wed, 16 Jan 2002 13:56:36 -0600 (CST)
Message-ID: <3C45DAE9.4080504@alcatel.com>
Date: Wed, 16 Jan 2002 13:56:25 -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] Re: IP Paging Protocol
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com> <3C433991.2090906@alcatel.com> <01fe01c19d3d$32563180$7e6015ac@T23KEMPF> <3C437674.F7603259@iprg.nokia.com> <003801c19de9$551e6280$7e6015ac@T23KEMPF> <3C44CABD.4949D8D2@alcatel.co <00da01c19eb9$7b1c86d0$7e6015ac@T23KEMPF>
Content-Type: multipart/alternative;
 boundary="------------080800010501020308090509"
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


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


It is totally unacceptable that WG cochair first said only one person is 
stating his concerns saying that others have accepted so there is 
consensus. When other people also stated then WG cochair said all those 
non accepted draft people are stating their concerns calling them sour 
grapes.

If draft-renker  is the WG draft then there is no point for us to 
discuss any further.
WG cochair is yet to post the slides.

Regards,

James Kempf wrote:

>Behcet,
>
>I will do no such thing.
>
>Please answer my question.
>
>            jak
>
>----- Original Message -----
>From: "Behcet Sarikaya" 
>Cc: 
>Sent: Wednesday, January 16, 2002 9:47 AM
>Subject: Re: [Seamoby] Re: IP Paging Protocol
>
>
>>First of all can you please announce that there is no WG draft?
>>Then maybe we can discuss how the design team should be structured and
>>who leads it.
>>
>>Regards,
>>
>>James Kempf wrote:
>>
>>>So, what is the difference between:
>>>
>>>a)  Forming an open design team and anyone in the working group
>>>having the right to participate with Marco as the editor of the
>>>document,
>>>
>>>and:
>>>
>>>b) The situation we are in now?
>>>
>>>Why should the design team be restricted to authors of the
>>>existing protocols?
>>>
>>>           jak
>>>
>>>----- Original Message -----
>>>From: "Behcet Sarikaya" 
>>>To: 
>>>Sent: Tuesday, January 15, 2002 4:35 PM
>>>Subject: Re: [Seamoby] Re: IP Paging Protocol
>>>
>>>
>>>>I think that WG chairs should not expect WG members to react more
>>>>
>than
>
>>>>what we observed so far. I reacted and pointed to one important
>>>>
>>>problem
>>>
>>>>during the meeting and continued to argue on the mailing list. The
>>>>
>>>other
>>>
>>>>WG members also have spoken out.
>>>> WG members are kind people, we do not shout and leave the meeting
>>>>
>>>room
>>>
>>>>slamming the door.
>>>> WG members prefer to kindly indicate the peaceful solution which
>>>>
>is
>
>>>two
>>>
>>>>fold, never again make such assessment irregularities and
>>>>
>>>>>We believe that the process of creating an IP paging protocol can
>>>>>
>be
>
>>>>>>substantially improved, and that the establishment in Seamoby of a
>>>>>>design team comprising the authors of the current proposal and few
>>>>>>other relevant parties is the only realistic solution (as it has
>>>>>>already happened in other IETF WGs).
>>>>>>
>>>>Regards,
>>>>
>>>>James Kempf wrote:
>>>>
>>>>>
>>>>>If there was an outcry on the list from others, I would be more
>>>>>inclined to view the complaints seriously. In the past,
>>>>>the Seamoby list has not been short of people who
>>>>>were ready to jump out at the first sign of a technical
>>>>>controversy and express their opinions. I have not
>>>>>seen a single one of those people, either in SLC
>>>>>or on the list, stand up publically and say that they did
>>>>>not agree with the decision.
>>>>>
>>>>>I've already agreed that the the decision process
>>>>>by which the selection was made was not
>>>>>transparent. I have some text that I have
>>>>>written which I hope will render more
>>>>>transparency to the process,  but I have
>>>>>not yet been able to get a time to
>>>>>talk with Pat and Allision about it.
>>>>>If you can just be patient, I will
>>>>>post the text as soon as we have
>>>>>had a chance to review it. Let's see if there
>>>>>are any complaints from neutral
>>>>>sources about the decision after
>>>>>I've posted that text.
>>>>>
>>>>>           jak
>>>>>
>>>>>_______________________________________________
>>>>>--
>>>>>
>>>>Behcet
>>>>
>>>>
>>>>_______________________________________________
>>>>Seamoby mailing list
>>>>Seamoby@ietf.org
>>>>https://www1.ietf.org/mailman/listinfo/seamoby
>>>>
>>--
>>Behcet
>>
>>
>>
>

-- 
Behcet 



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







It is totally unacceptable that WG cochair first said only one person is
stating his concerns saying that others have accepted so there is consensus.
When other people also stated then WG cochair said all those non accepted
draft people are stating their concerns calling them sour grapes.



If draft-renker  is the WG draft then there is no point for us to discuss
any further. 

WG cochair is yet to post the slides.



Regards,



James Kempf wrote:



  
Behcet,

I will do no such thing.

Please answer my question.

            jak

----- Original Message -----
From: "Behcet Sarikaya" <behcet.sarikaya@alcatel.com>
Cc: <seamoby@ietf.org>
Sent: Wednesday, January 16, 2002 9:47 AM
Subject: Re: [Seamoby] Re: IP Paging Protocol



  

    
First of all can you please announce that there is no WG draft?
Then maybe we can discuss how the design team should be structured and
who leads it.

Regards,

James Kempf wrote:


    

      
So, what is the difference between:

a)  Forming an open design team and anyone in the working group
having the right to participate with Marco as the editor of the
document,

and:

b) The situation we are in now?

Why should the design team be restricted to authors of the
existing protocols?

           jak

----- Original Message -----
From: "Behcet Sarikaya" <behcet.sarikaya@alcatel.com>
To: <seamoby@ietf.org>
Sent: Tuesday, January 15, 2002 4:35 PM
Subject: Re: [Seamoby] Re: IP Paging Protocol



      

        
I think that WG chairs should not expect WG members to react more

        

        

        

        
than

        

          

            

              
what we observed so far. I reacted and pointed to one important


              

              
problem


              

                
during the meeting and continued to argue on the mailing list. The


                

                
other


                

                  
WG members also have spoken out.
 WG members are kind people, we do not shout and leave the meeting


                  

                  
room


                  

                    
slamming the door.
 WG members prefer to kindly indicate the peaceful solution which

                    

                    

                    

                    
is

                    

                      

                        
two


                        

                          
fold, never again make such assessment irregularities and


                          

                            
We believe that the process of creating an IP paging protocol can

                            

                            

                            

                            

                            
be

                            

                              

                                

                                  

                                    

                                      
substantially improved, and that the establishment in Seamoby of a
design team comprising the authors of the current proposal and few
other relevant parties is the only realistic solution (as it has
already happened in other IETF WGs).


                                      

                                      

                                      
Regards,

James Kempf wrote:


                                      

                                        

If there was an outcry on the list from others, I would be more
inclined to view the complaints seriously. In the past,
the Seamoby list has not been short of people who
were ready to jump out at the first sign of a technical
controversy and express their opinions. I have not
seen a single one of those people, either in SLC
or on the list, stand up publically and say that they did
not agree with the decision.

I've already agreed that the the decision process
by which the selection was made was not
transparent. I have some text that I have
written which I hope will render more
transparency to the process,  but I have
not yet been able to get a time to
talk with Pat and Allision about it.
If you can just be patient, I will
post the text as soon as we have
had a chance to review it. Let's see if there
are any complaints from neutral
sources about the decision af
ter
I've posted that text.

           jak

_______________________________________________
--


                                        

                                        
Behcet


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


                                        

                                        

                                        
--
Behcet




                                        

                                        


                                        

                                        

                                        
-- 
Behcet 

                                        

                                        
                                        

--------------080800010501020308090509--


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


From seamoby-admin@ietf.org  Wed Jan 16 15:42: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 PAA20523
	for ; Wed, 16 Jan 2002 15:42: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 OAA17294;
	Wed, 16 Jan 2002 14:55: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 OAA17257
	for ; Wed, 16 Jan 2002 14:55:25 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19237
	for ; Wed, 16 Jan 2002 14:55:19 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0GJsmS15753
	for ; Wed, 16 Jan 2002 11:54:48 -0800 (PST)
Message-ID: <018c01c19ec7$6d761420$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Date: Wed, 16 Jan 2002 11:53:11 -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] Paging Protocol Decision Description
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

As promised, here is a description of the decision process used to
select the Seamoby paging protocol. After discussion and
editing based on WG feedback, this will be incorporated into
draft-ietf-seamoby-paging-protocol-assessment-00.txt.

Comments please.

            jak

------------------------------------------------------------------------
------------------------------------------
Assessment and Decision Process

The assessment team spent three weeks reading through the protocol
proposals.
Each team member was assigned a proposal for assessment, with the
exception
of draft-sarikaya and draft-guri, which were both assigned to
one team member because not enough people volunteered. Each team member
wrote up the results of their assessment, and submitted it to
the assessment draft editor for assembly into this draft. A
teleconference
was held to discuss the assessments and normalize assessments between
different team members. The assessment team did not make a
recommendation
about which draft to pick; however, the team did recommend that the next
step should be to either go through another round of design in which the
authors would attempt to refine their proposals, or to immediately begin
the
process of harmonizing the protocols to come up with a working group
draft.

Given that the assessment team's recommendation about which draft to
accept
was indeterminate, a decision team was formed by the two Working Group
co-chairs, with the Area Director providing advice. The decision team
decided
to proceed toward selecting a draft as the basis of a harmonized
protocol, in
order to avoid further delay in starting on the process of desiging the
Seamoby paging protocol.

The decision about which draft to select was difficult, because each
draft
had particular aspects that were well thought out and recommended
themselves for inclusion in the final result, but none of the drafts
exhibited
the maturity of implementation and design that immediately suggested it
as
the only possible candidate for selection. Some drafts had particular
aspects
that mitigated strongly against selection. A good example of this
difficulty
is Requirement 4.6, Multiple Dormant Modes. This requirement was
intended to
foster support for hosts that have no explicit L2 paging support,
basically
time-slotted paging. Draft-sarikaya has an excellent discussion of
time-slotted paging mode, but the basis of that draft is a protocol
(HMIPv6)
that has been proposed in another working group for a problem that is
still
in the requirements phase. The other proposals had varying degrees
of support for time-slotted paging, but none was sufficient to recommend
itself on this particular requirement.

The assessment team's work allowed the decision team to reduce the
number of drafts under consideration from five to two. The decision team
quickly decided to rule out draft-koodli because the draft is lacking in
specifics and is vague on many requirements, as mentioned in the
assessment
team's report. 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. Also, draft-sarikaya exclusively supports
Mobile IPv6, and a primary requirement of all Seamoby work is that the
protocols be independent of mobility protocol. 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. However, the ideas expressed in draft-guri were
felt
to be valuable and necessary for including in the final Seamoby paging
protocol for those cases where Layer 2 paging support is available.

The decision between the remaining two drafts, draft-renker and
draft-ohba,
was especially difficult because they were judged to be about of equal
quality. The decision team decided to focus on three primary
requirements
that were thought to be crucial to the successful acceptance of IP
paging:
independence of mobility protocol, support for existing mobility
protocols,
and independence of paging area from subnet topology.

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. Draft-renker was judged by the assessment team to
be overspecific in these areas, in the sense that it contained two
modes,
explicit mode and implicit mode, depending on whether Mobile IP was
supported
or not. However, considering the relatively immature state of the paging
protocol design, the decision team felt that providing the working group
with choices, where the benefits and drawbacks of each choice could be
clearly weighed, was preferable to providing a fixed decision, so
draft-renker was judged to be better in this regard.

On the requirement for independence of paging area from subnet topology,
the
support described in draft-ohba was very sketchy and did not provide
the decision team with a clear idea about how this could be achieved,
particularly with regard to the movement of a mobile host while the host
is
in dormant mode. Draft-renker has a much clearer description of how this
could
be achieved, and was judged to be better in this regard.

Additional aspects of draft-renker that recommended it as the selection
were attention to details of interaction with existing IP
routing, and a survey of paging strategies. While probably not essential
to
the final protocol design, the material on paging strategies showed
that the authors had given some thought to separating policy from
mechanism,
and were familiar with the somewhat extensive academic
literature on paging, and IP paging in particular.

While draft-renker was selected by the decision team as the basis for
continued Seamoby paging protocol work, the decision team feels that it
is
important to incorporate the outstanding contributions of the other
authors
into the final protocol design, in particular, the time-slotted paging
discussion in draft-sarikaya, the Layer 2 interface work in draft-guri,
the
paging state machine discussion in draft-koodli, and the security
protocol
work in draft-ohba. Additional aspects of the other drafts that address
issues which were weakly addressed or not addressed at all in
draft-renker
should also be incorporated, as well as ideas from other working group
members that address requirement which none of the draft addressed
particularly
well.







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


From seamoby-admin@ietf.org  Wed Jan 16 15:52: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 PAA20662
	for ; Wed, 16 Jan 2002 15:52: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 PAA18779;
	Wed, 16 Jan 2002 15:38: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 PAA18750
	for ; Wed, 16 Jan 2002 15:38:14 -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 PAA20470
	for ; Wed, 16 Jan 2002 15:38:09 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA10741;
	Wed, 16 Jan 2002 14:37:38 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g0GKbbr14122;
	Wed, 16 Jan 2002 14:37:37 -0600 (CST)
Message-ID: <3C45E485.2010400@alcatel.com>
Date: Wed, 16 Jan 2002 14:37:25 -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: James Kempf 
Subject: Re: [Seamoby] Paging Protocol Decision Description
References: <018c01c19ec7$6d761420$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

James,
 Following comments:
1. This text is not consistent with the minutes and the slides on which 
your presentation was based at WG meeting in IETF 52.
2. Regarding newly introduced comments on draft-guri, how come an aspect 
that is good to have in the final draft becomes the reason for rejection 
to select it?
  Since you made no comments on draft-guri at SLC I could not raise this 
question there, sorry about that :)
3. The comments on hmipv6 belong to you personally, please check the 
slides on WG document status of MIP WG, you should be able to see the 
official opinion of WG chairs of MIP WG. I think that it is a serious 
problem to state strong opinions on the business of other WGs especially 
if they are flawed.
 
4. The text does not mention the simple sum of the marks given to each 
draft?

  In short this text adds to the controversy failing to resolve 
anything.Regardless of what people say the conclusion is not going to 
change, right? Then why ask opinion of WG members? Is this normal? I do 
not think such a system can be maintained.


Regards,

--behcet


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


From seamoby-admin@ietf.org  Wed Jan 16 16:20: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 QAA21189
	for ; Wed, 16 Jan 2002 16:20: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 QAA19555;
	Wed, 16 Jan 2002 16:01: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 QAA19524
	for ; Wed, 16 Jan 2002 16:01:17 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20880
	for ; Wed, 16 Jan 2002 16:01:12 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0GL0iS18755;
	Wed, 16 Jan 2002 13:00:44 -0800 (PST)
Message-ID: <01d301c19ed0$a3254740$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" , 
References: <748E8123D183394982E32A511DB3E73610B0B9@daebe005.NOE.Nokia.com> <3C433991.2090906@alcatel.com> <01fe01c19d3d$32563180$7e6015ac@T23KEMPF> <3C437674.F7603259@iprg.nokia.com> <003801c19de9$551e6280$7e6015ac@T23KEMPF> <3C44CABD.4949D8D2@alcatel.co <00da01c19eb9$7b1c86d0$7e6015ac@T23KEMPF> <3C45DAE9.4080504@alcatel.com>
Subject: Re: [Seamoby] Re: IP Paging Protocol
Date: Wed, 16 Jan 2002 12:59:07 -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

> WG cochair is yet to post the slides.
> 

The minutes and slides will be available at  
www.ietf.org/proceedings/01dec as soon as
the Secretariat has time to process them. I sent
them in on Monday.

            jak


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


From seamoby-admin@ietf.org  Wed Jan 16 17:24: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 RAA22307
	for ; Wed, 16 Jan 2002 17:24: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 QAA20819;
	Wed, 16 Jan 2002 16:45: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 QAA20788
	for ; Wed, 16 Jan 2002 16:45:14 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21605
	for ; Wed, 16 Jan 2002 16:45:04 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0GLfxS20763;
	Wed, 16 Jan 2002 13:41:59 -0800 (PST)
Message-ID: <022701c19ed6$6646a3e0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" , 
References: <018c01c19ec7$6d761420$7e6015ac@T23KEMPF> <3C45E485.2010400@alcatel.com>
Subject: Re: [Seamoby] Paging Protocol Decision Description
Date: Wed, 16 Jan 2002 13:40:21 -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,

> 1. This text is not consistent with the minutes and the slides on
which
> your presentation was based at WG meeting in IETF 52.

The text I posted was my recollection, confirmed by Pat and
Allison, about the process we went through to make the decision.
There was a lot more detail than in my slides, because I wanted
to make sure that the authors of the proposals that were not
selected understood the decision process thoroughly. To the extent
that material from the slides was covered, I believe it is consistent.
For
example, the last paragraph cites a few examples of good
features in the various drafts that we would like to see in
the final result.Of those, only the security features from
draft-ohba were not on the slides, and that was an oversight
on my part, for which I apologize.

> 2. Regarding newly introduced comments on draft-guri, how come an
aspect
> that is good to have in the final draft becomes the reason for
rejection
> to select it?
>   Since you made no comments on draft-guri at SLC I could not raise
this
> question there, sorry about that :)

As I have told you before on this list, and as was stated in the
text I posted, draft-guri deals only with supporting L2 paging.
This is too limited to be the basis for the Seamoby IP paging protocol.
The text states that we want to see the ideas in draft-guri incorporated
into the final Seamoby protocol, and, as I have also told you before
on this list, we are working on
trying to organize a L2 Triggers BOF in Minneapolis so we can
discuss the kind of L2 triggers that are discussed on page 6 of
draft-guri. Seamoby is not the right place for this kind of work,
but we are trying to get one set up, and the L2 triggers work
for paging in draft-guri could be an important contribution. If, of
course,
you decide to participate.

> 3. The comments on hmipv6 belong to you personally, please check the
> slides on WG document status of MIP WG, you should be able to see the
> official opinion of WG chairs of MIP WG. I think that it is a serious
> problem to state strong opinions on the business of other WGs
especially
> if they are flawed.
>

I don't understand this comment. There is currently a draft,
draft-ietf-mobileip-lmm-requirements-00.txt, in the MIP
WG that outline requirements for an LMM solution. This
draft has not yet gone through WG Last Call, nor through
IETF Last Call, and so it does not yet have an RFC number.
That means that LMM is not yet out of the requirements phase.
This is what I said. We can't base the Seamoby paging
protocol on a protocol in another WG that isn't yet out
of requirements phase. The other WG might go through
the same kind of requirements assessment process for
competing protocols we've gone through
and come up with another protocol instead of HMIPv6
as the selected LMM protocol. Where would that leave
us?


> 4. The text does not mention the simple sum of the marks given to each
> draft?
>

A simple sum shows nothing. How should one rate under- versus
over-specification? In some cases, underspecification can be
a good thing, in other cases not. Same with overspecification.

In retrospect, I see now that putting numbers on these was a mistake.
It led people to believe that one could simply sum the numbers
and come up with a decision. Unfortunately, it was not so easy.
You can be assured that I will never use that technique again.

>   In short this text adds to the controversy failing to resolve
> anything.Regardless of what people say the conclusion is not going to
> change, right? Then why ask opinion of WG members? Is this normal? I
do
> not think such a system can be maintained.
>
>

Any such decision is always subject to WG concensus.
Unfortunately, the only voice we are hearing on the mailing list
right now is yours. One voice isn't enough for concensus, nor
is text from a private email forwarded and posted apparently without the
author's permission. Goodness knows, we have enough vocal
people on this list. It took us a year to get CT requirements
done (and we still don't have them in IESG Last Call!) because
everybody had an opinion. If I were seeing some of these people, who
were not authors of competing proposals coming forward and
saying that we should change the decison, it would be another
matter.

                    jak


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


From seamoby-admin@ietf.org  Wed Jan 16 18:41: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 SAA23718
	for ; Wed, 16 Jan 2002 18:41: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 SAA24421;
	Wed, 16 Jan 2002 18:27: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 SAA24390
	for ; Wed, 16 Jan 2002 18:27:00 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23527
	for ; Wed, 16 Jan 2002 18:26:55 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0GNQSi25799
	for ; Wed, 16 Jan 2002 15:26:28 -0800 (PST)
Message-ID: <02da01c19ee4$ff49c000$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Date: Wed, 16 Jan 2002 15:24:51 -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] Advancing draft-ietf-seamoby-ct-reqs-02.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,

I believe we have concluded the discussion about George's request to
remove requirements 4.12, 4.13, 4.15, and 5.5.2 from
the CT requirements draft.

My reading of opinions expressed on the list is as follows:

4.12 - Govind, Madjid keep

4.13 - A few opinions indicating indifference if it was removed

4.15 - same as 4.13

5.5.2 - Gary, Madjid strong keep

So, I think the concensus is to keep 4.12 and 5.5.2 and remove 4.13 and
4.15.

Unless there is any other comment, Gary, could you please remove the
4.13 and 4.15 and resubmit the document to the Internet Drafts
editor? When that is done, we will notify the IESG to advance
the draft.

Thanx to those who participated in the discussion and to
the rest of the WG for your patience.

                jak


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


From seamoby-admin@ietf.org  Wed Jan 16 19:26: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 TAA24465
	for ; Wed, 16 Jan 2002 19:26: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 TAA25844;
	Wed, 16 Jan 2002 19:13: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 TAA25813
	for ; Wed, 16 Jan 2002 19:13:03 -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 TAA24215
	for ; Wed, 16 Jan 2002 19:13:00 -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 SAA14201
	for ; Wed, 16 Jan 2002 18:12:32 -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 g0H0CWs24755
	for ; Wed, 16 Jan 2002 18:12:32 -0600 (CST)
Message-ID: <3C4616E3.6060407@alcatel.com>
Date: Wed, 16 Jan 2002 18:12: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] Paging Protocol Decision Description
References: <018c01c19ec7$6d761420$7e6015ac@T23KEMPF> <3C45E485.2010400@alcatel.com> <022701c19ed6$6646a3e0$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

Several people not authors of proposals (Vijay, Rene) voiced their 
concern on the murky assessment, or am I wrong, or are you waiting for  
the sky to fall down?

To be on the positive side, we can offer Majordomo based mailing list 
support for the design team, if only with no WG draft.

Take it or leave it.

James Kempf wrote:

>
>Any such decision is always subject to WG concensus.
>Unfortunately, the only voice we are hearing on the mailing list
>right now is yours. One voice isn't enough for concensus, nor
>is text from a private email forwarded and posted apparently without the
>author's permission. Goodness knows, we have enough vocal
>people on this list. It took us a year to get CT requirements
>done (and we still don't have them in IESG Last Call!) because
>everybody had an opinion. If I were seeing some of these people, who
>were not authors of competing proposals coming forward and
>saying that we should change the decison, it would be another
>matter.
>
>                    jak
>

-- 
Behcet 




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


From seamoby-admin@ietf.org  Wed Jan 16 20:04: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 UAA24998
	for ; Wed, 16 Jan 2002 20:04: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 TAA26692;
	Wed, 16 Jan 2002 19:48: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 TAA26665
	for ; Wed, 16 Jan 2002 19:47:59 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24777
	for ; Wed, 16 Jan 2002 19:47:56 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0H0lPv00643;
	Wed, 16 Jan 2002 16:47:25 -0800 (PST)
Message-ID: <031001c19ef0$4e3f1060$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" , 
References: <018c01c19ec7$6d761420$7e6015ac@T23KEMPF> <3C45E485.2010400@alcatel.com> <022701c19ed6$6646a3e0$7e6015ac@T23KEMPF> <3C4616E3.6060407@alcatel.com>
Subject: Re: [Seamoby] Paging Protocol Decision Description
Date: Wed, 16 Jan 2002 16:45:48 -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,

> Several people not authors of proposals (Vijay, Rene) voiced their
> concern on the murky assessment, or am I wrong, or are you waiting for
> the sky to fall down?
>

The text I've posted was intended to clarify how the decision
was made. If there are any further concerns expressed, then
we can discuss them.

> To be on the positive side, we can offer Majordomo based mailing list
> support for the design team, if only with no WG draft.
>

Thanx for the offer, but I believe we will stick with current WG
draft.


            jak


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


From seamoby-admin@ietf.org  Thu Jan 17 03: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 DAA10116
	for ; Thu, 17 Jan 2002 03: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 CAA19026;
	Thu, 17 Jan 2002 02:47: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 CAA18997
	for ; Thu, 17 Jan 2002 02:47:21 -0500 (EST)
Received: from mail.rz.uni-ulm.de (sirius-giga.rz.uni-ulm.de [134.60.246.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09745
	for ; Thu, 17 Jan 2002 02:47:18 -0500 (EST)
Received: from informatik.uni-ulm.de (seychelles.informatik.uni-ulm.de [134.60.70.20])
	by mail.rz.uni-ulm.de (8.12.1/8.12.1) with ESMTP id g0H7lHMF003392
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Thu, 17 Jan 2002 08:47:17 +0100 (MET)
Message-ID: <3C46817A.16871520@informatik.uni-ulm.de>
Date: Thu, 17 Jan 2002 08:47:06 +0100
From: Frank Kargl 
Organization: University of Ulm, Germany
X-Mailer: Mozilla 4.77 [en] (Win98; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: manet@itd.nrl.navy.mil, seamoby@ietf.org
Subject: Re: [Seamoby] Terminology Draft Needed
References:  <3C45C3D0.8D24D969@iprg.nokia.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

Hi Charlie,

"Charles E. Perkins" wrote: 
> This is a good idea.  Where can we find a list of the acceptable
> security terminology to incorporate into the terminology draft?

There are many such compilations in the web, e.g.:
http://www.securitypanel.org/glossary.html
http://www.certmag.com/issues/jul01/securityterms.cfm
http://www.setsolutions.com/security.htm

As MANET and Security is one of my focal points of interest, I would
gladly volunteer to compile such a security glossary. The important
point is how extensive such a glossary should be. Either we focus on
terms that are directly related to MANETs/Mobility or we try to compile
a glossary on everything that relates to security in general. I think
that only the first approach makes sense.

Ciao ... Frank

-- 
-----------------------------------------------------------------------
 Frank Kargl          Multimedia Computing, University of Ulm, Germany
 Mail:frank.kargl@informatik.uni-ulm.de http://www.uni-ulm.de/~fkargl/
-----------------------------------------------------------------------
   Use the SOURCE, Luke !  I feel a great disturbance in the SOURCE.
            But beware of the Microsoft side of the SOURCE !

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


From seamoby-admin@ietf.org  Thu Jan 17 06:44: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 GAA12126
	for ; Thu, 17 Jan 2002 06:44: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 GAA27038;
	Thu, 17 Jan 2002 06:28: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 GAA27012
	for ; Thu, 17 Jan 2002 06:28:21 -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 GAA11912
	for ; Thu, 17 Jan 2002 06:28:19 -0500 (EST)
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 g0HBSRk08684
	for ; Thu, 17 Jan 2002 13:28:27 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 17 Jan 2002 13:28:18 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 13:28:17 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Terminology Draft Needed
Date: Thu, 17 Jan 2002 13:28:17 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D937A@esebe004.NOE.Nokia.com>
Thread-Topic: [Seamoby] Terminology Draft Needed
Thread-Index: AcGfKz+y7OCDV777SVKC2vG5NX139wAHq9cA
From: "Loughney John (NRC/Helsinki)" 
To: "'ext Frank Kargl'" ,
        , 
X-OriginalArrivalTime: 17 Jan 2002 11:28:17.0770 (UTC) FILETIME=[0F641CA0:01C19F4A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA27013
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 Frank,

> As MANET and Security is one of my focal points of interest, I would
> gladly volunteer to compile such a security glossary. The important
> point is how extensive such a glossary should be. Either we focus on
> terms that are directly related to MANETs/Mobility or we try 
> to compile a glossary on everything that relates to security in
general. 
> I think that only the first approach makes sense.

Feel free to draw-up a security glossary as it relates to mobility
(seamoby,
mip, manet).  I, for one, would like to see it.

thanks,
John

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


From seamoby-admin@ietf.org  Thu Jan 17 10:49: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 KAA19472
	for ; Thu, 17 Jan 2002 10:49: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 KAA06797;
	Thu, 17 Jan 2002 10:33: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 KAA06759
	for ; Thu, 17 Jan 2002 10:33:14 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18956
	for ; Thu, 17 Jan 2002 10:33:12 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 17 Jan 2002 07:32:40 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 07:30:54 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F6B.F3E80230"
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_01C19F6B.F3E80230
Content-Type: text/plain

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

Behcet,

The process, to which I provided you a pointer a few days ago,
clearly states that folks express their opinion on the list. Jim and
I will not read other mailing list archives to determine roush
consensus. The seamoby list is the only one we can use to gauge
consensus.

Again, as Jim clearly stated, the only objection we are seeing right
now is yours (although you claim two other people did, and 3 is still
short of rough consensus for a list that has 499 members). If we
guaged there was rough consensus on this issue, then we would most
certainly act. 

Our primary concern at this time is to get the work completed and
achieve our milestones. So how about we get to work and put this
behind us.

PatC

- -----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] 
Sent: Wednesday, January 16, 2002 4:12 PM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description


Several people not authors of proposals (Vijay, Rene) voiced their 
concern on the murky assessment, or am I wrong, or are you waiting
for  
the sky to fall down?

To be on the positive side, we can offer Majordomo based mailing list
support for the design team, if only with no WG draft.

Take it or leave it.

James Kempf wrote:

>
>Any such decision is always subject to WG concensus. Unfortunately,
>the  only voice we are hearing on the mailing list right now is
>yours. One  voice isn't enough for concensus, nor is text from a
>private email 
>forwarded and posted apparently without the author's permission. 
>Goodness knows, we have enough vocal people on this list. It took us
>a  year to get CT requirements done (and we still don't have them in
>IESG  Last Call!) because everybody had an opinion. If I were seeing
>some of  these people, who were not authors of competing proposals
>coming 
>forward and saying that we should change the decison, it would be 
>another matter.
>
>                    jak
>

- -- 
Behcet 




_______________________________________________
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/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNkr
5WxMNRzg0Qv02oder+oZzLGR
=GIVv
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C19F6B.F3E80230
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Paging Protocol Decision Description




 

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

Hash: SHA1




Behcet,




The process, to which I provided you a pointer a few =
days ago,

clearly states that folks express their opinion on =
the list. Jim and

I will not read other mailing list archives to =
determine roush

consensus. The seamoby list is the only one we can =
use to gauge

consensus.




Again, as Jim clearly stated, the only objection we =
are seeing right

now is yours (although you claim two other people =
did, and 3 is still

short of rough consensus for a list that has 499 =
members). If we

guaged there was rough consensus on this issue, then =
we would most

certainly act. 




Our primary concern at this time is to get the work =
completed and

achieve our milestones. So how about we get to work =
and put this

behind us.




PatC




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

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

Sent: Wednesday, January 16, 2002 4:12 PM

To: seamoby@ietf.org

Subject: Re: [Seamoby] Paging Protocol Decision =
Description






Several people not authors of proposals (Vijay, Rene) =
voiced their 

concern on the murky assessment, or am I wrong, or =
are you waiting

for  

the sky to fall down?




To be on the positive side, we can offer Majordomo =
based mailing list

support for the design team, if only with no WG =
draft.




Take it or leave it.




James Kempf wrote:




>

>Any such decision is always subject to WG =
concensus. Unfortunately,

>the  only voice we are hearing on the =
mailing list right now is

>yours. One  voice isn't enough for =
concensus, nor is text from a

>private email 

>forwarded and posted apparently without the =
author's permission. 

>Goodness knows, we have enough vocal people on =
this list. It took us

>a  year to get CT requirements done (and we =
still don't have them in

>IESG  Last Call!) because everybody had an =
opinion. If I were seeing

>some of  these people, who were not authors =
of competing proposals

>coming 

>forward and saying that we should change the =
decison, it would be 

>another matter.

>

>          =
;          jak

>




- -- 

Behcet 










_______________________________________________

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/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNk=
r

5WxMNRzg0Qv02oder+oZzLGR

=3DGIVv

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





------_=_NextPart_001_01C19F6B.F3E80230--

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


From seamoby-admin@ietf.org  Thu Jan 17 11:14: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 LAA20279
	for ; Thu, 17 Jan 2002 11:14: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 LAA08082;
	Thu, 17 Jan 2002 11:01: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 LAA08050
	for ; Thu, 17 Jan 2002 11:01:34 -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 LAA19887
	for ; Thu, 17 Jan 2002 11:01:31 -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 g0HG1WH58766
	for ; Thu, 17 Jan 2002 17:01:32 +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 RAA16010
	for ; Thu, 17 Jan 2002 17:01:02 +0100
Message-ID: <3C46F53E.1D07E4C4@ccrle.nec.de>
Date: Thu, 17 Jan 2002 17:01:02 +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: Seamoby 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] technical issues on 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
Content-Transfer-Encoding: 7bit

Hi all,

now, after details of the selection process have been clarified, let's
start working on the incorporation of proposals.

I am currently re-structuring/separating the content of the base-line
draft in order to get a generic framework document for the WG draft
ready. I see the following issues as very important to be addressed in
order to allow folding appropriate solutions into a first draft.

#1 Security mechanisms (with respect to transport mechanisms)
#2 Signaling transport mechanism for IPv4/v6
#3 Improvements on support of hosts having no explicit L2 paging
mechanism (-> time slotted paging)
#4 Appropriate mechanism for failover handling/support of robustness

Of course there are more issues to be addressed, but let's start with
the ones above.
I will send separate e-mails addressing the individual issues.

Marco




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


From seamoby-admin@ietf.org  Thu Jan 17 11: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 LAA20458
	for ; Thu, 17 Jan 2002 11:17: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 LAA08218;
	Thu, 17 Jan 2002 11:05: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 LAA08187
	for ; Thu, 17 Jan 2002 11:05:18 -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 LAA20049
	for ; Thu, 17 Jan 2002 11:05:15 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA04824;
	Thu, 17 Jan 2002 10:04:47 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g0HG4kr00197;
	Thu, 17 Jan 2002 10:04:46 -0600 (CST)
Message-ID: <3C46F60F.5050005@alcatel.com>
Date: Thu, 17 Jan 2002 10:04:31 -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] Paging Protocol Decision Description
References: 
Content-Type: multipart/alternative;
 boundary="------------040700080305060802000804"
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


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

Hi Pat,
  So you are backing your cochair's decision to select the draft that 
received 72 marks while all other drafts received 90 or so marks. This 
means that the criteria was to select the worst draft as the WG draft. 
Since this was the case of course the worst draft  people would need 
other drafts in order to get something that makes sense.
   The catch here is how to get the other draft people to agree on this 
impossible task. This is the dilemma we are facing presently. That's why 
the pleas are being written, and even some people are being forced.
  My simple logic says this is impossible. If it is the WG chairship to 
try to achieve the impossible, please continue to try it, you won't get 
anywhere!
 

Regards,


 
Pat R. Calhoun wrote:

>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Behcet,
>
> The process, to which I provided you a pointer a few days ago,
> clearly states that folks express their opinion on the list. Jim and
> I will not read other mailing list archives to determine roush
> consensus. The seamoby list is the only one we can use to gauge
> consensus.
>
> Again, as Jim clearly stated, the only objection we are seeing right
> now is yours (although you claim two other people did, and 3 is still
> short of rough consensus for a list that has 499 members). If we
> guaged there was rough consensus on this issue, then we would most
> certainly act.
>
> Our primary concern at this time is to get the work completed and
> achieve our milestones. So how about we get to work and put this
> behind us.
>
> PatC
>
> - -----Original Message-----
> From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ]
> Sent: Wednesday, January 16, 2002 4:12 PM
> To: seamoby@ietf.org
> Subject: Re: [Seamoby] Paging Protocol Decision Description
>
>
> Several people not authors of proposals (Vijay, Rene) voiced their
> concern on the murky assessment, or am I wrong, or are you waiting
> for 
> the sky to fall down?
>
> To be on the positive side, we can offer Majordomo based mailing list
> support for the design team, if only with no WG draft.
>
> Take it or leave it.
>
> James Kempf wrote:
>
> >
> >Any such decision is always subject to WG concensus. Unfortunately,
> >the  only voice we are hearing on the mailing list right now is
> >yours. One  voice isn't enough for concensus, nor is text from a
> >private email
> >forwarded and posted apparently without the author's permission.
> >Goodness knows, we have enough vocal people on this list. It took us
> >a  year to get CT requirements done (and we still don't have them in
> >IESG  Last Call!) because everybody had an opinion. If I were seeing
> >some of  these people, who were not authors of competing proposals
> >coming
> >forward and saying that we should change the decison, it would be
> >another matter.
> >
> >                    jak
> >
>
> - --
> Behcet
>
>
>
>
> _______________________________________________
> 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/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNkr
> 5WxMNRzg0Qv02oder+oZzLGR
> =GIVv
> -----END PGP SIGNATURE-----
>

-- 
Behcet 



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





Hi Pat,

  So you are backing your cochair's decision to select the draft that received
72 marks while all other drafts received 90 or so marks. This means that
the criteria was to select the worst draft as the WG draft. Since this was
the case of course the worst draft  people would need other drafts in order
to get something that makes sense. 

   The catch here is how to get the other draft people to agree on this impossible
task. This is the dilemma we are facing presently. That's why the pleas are
being written, and even some people are being forced.

  My simple logic says this is impossible. If it is the WG chairship to try
to achieve the impossible, please continue to try it, you won't get anywhere!

  



Regards,





  

Pat R. Calhoun wrote:



  
  RE: [Seamoby] Paging Protocol Decision Description
  
 

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

  Hash: SHA1

  
Behcet,

  
The process, to which I provided you a pointer a few
days ago,

  clearly states that folks express their opinion on the list.
Jim and

  I will not read other mailing list archives to determine
roush

  consensus. The seamoby list is the only one we can use to
gauge

  consensus.

  
Again, as Jim clearly stated, the only objection we are
seeing right

  now is yours (although you claim two other people did, and
3 is still

  short of rough consensus for a list that has 499 members).
If we

  guaged there was rough consensus on this issue, then we
would most

  certainly act. 

  
Our primary concern at this time is to get the work completed
and

  achieve our milestones. So how about we get to work and
put this

  behind us.

  
PatC

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

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

  Sent: Wednesday, January 16, 2002 4:12 PM

  To: seamoby@ietf.org

  Subject: Re: [Seamoby] Paging Protocol Decision Description

  

  
Several people not authors of proposals (Vijay, Rene)
voiced their 

  concern on the murky assessment, or am I wrong, or are you
waiting

  for  

  the sky to fall down?

  
To be on the positive side, we can offer Majordomo based
mailing list

  support for the design team, if only with no WG draft.

  
Take it or leave it.

  
James Kempf wrote:

  
>

  >Any such decision is always subject to WG concensus.
Unfortunately,

  >the  only voice we are hearing on the mailing list right
now is

  >yours. One  voice isn't enough for concensus, nor is
text from a

  >private email 

  >forwarded and posted apparently without the author's
permission. 

  >Goodness knows, we have enough vocal people on this
list. It took us

  >a  year to get CT requirements done (and we still don't
have them in

  >IESG  Last Call!) because everybody had an opinion.
If I were seeing

  >some of  these people, who were not authors of competing
proposals

  >coming 

  >forward and saying that we should change the decison,
it would be 

  >another matter.

  >

  >                    jak

  >

  
- -- 

  Behcet 

  

  

  

  
_______________________________________________

  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/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNkr

  5WxMNRzg0Qv02oder+oZzLGR

  =GIVv

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

  

  

  
-- 
Behcet 

  

  
  

--------------040700080305060802000804--


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


From seamoby-admin@ietf.org  Thu Jan 17 11:44: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 LAA23643
	for ; Thu, 17 Jan 2002 11:44: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 LAA09092;
	Thu, 17 Jan 2002 11:30: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 LAA09059
	for ; Thu, 17 Jan 2002 11:29:58 -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 LAA21473
	for ; Thu, 17 Jan 2002 11:29:55 -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 g0HGTuH58872
	for ; Thu, 17 Jan 2002 17:29:56 +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 RAA16328
	for ; Thu, 17 Jan 2002 17:29:27 +0100
Message-ID: <3C46FBE6.441E69BF@ccrle.nec.de>
Date: Thu, 17 Jan 2002 17: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: Seamoby 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] paging issue#1: security mechanisms
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,

on security support, the submitted proposals refer to IPSec and TLS
based mechanisms in order to make paging related signaling secure.
Beside others, the base-line document makes use of IPSec to have
appropriate mechanisms for authentication and possibly encryption.
draft-ohba specifies a TLS mechansims in order to provide authentication
and refers to IPSec in order to provide encryption.

As addressed already a bit earlier on the list, both mechansims have
pros and cons. We should clarify in which direction the paging protocol
should go to, considering the transport mechanisms for paging related
signaling. Signaling transport as described in the base-line draft makes
use of Destination Options for IPv6, but allows carrying messages over
UDP as well. draft-ohba relies on UDP transport. The following is my
current view on the two mechanisms:

IPSec:
*Needs to be open for mobility support
*Would be the same mechanism for IPv6/Dest-Opt as well as for UDP
transport
*Allows a gateway mode (but this is not yet part of any IP paging
protocol proposal, as far as I know)

TLS:
*Independence of lower layer specifics
*Proprietary mechanism
*Requires reliable transport

Also SSL- /PBK-like mechanisms have been addressed, but we have to
compare in order to go into one direction with the paging protocol.

Marco




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


From seamoby-admin@ietf.org  Thu Jan 17 11:45: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 LAA23738
	for ; Thu, 17 Jan 2002 11:45: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 LAA09602;
	Thu, 17 Jan 2002 11:34: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 LAA09572
	for ; Thu, 17 Jan 2002 11:33:58 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22224
	for ; Thu, 17 Jan 2002 11:33:55 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 17 Jan 2002 08:33:27 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Behcet Sarikaya'" 
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 08:33:22 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F74.AE017B80"
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_01C19F74.AE017B80
Content-Type: text/plain

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

To be honest, I don't see how this numbering scheme came into play.
It is the first time that I've ever heard of it within the IETF. If I
would have known that the evaluation team was doing this, I would
have stopped it.
 
The reason for the evaluation is to find the candidate protocol that
most closely matches the requirements, which the WG agreed upon. This
would ensure that there is less work involved in getting the protocol
up to par.
 
That was the process (and the same process has been used in many
other WGs)
 
PatC

- -----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] 
Sent: Thursday, January 17, 2002 8:05 AM
To: Pat R. Calhoun
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description


Hi Pat,
  So you are backing your cochair's decision to select the draft that
received 72 marks while all other drafts received 90 or so marks.
This means that the criteria was to select the worst draft as the WG
draft. Since this was the case of course the worst draft  people
would need other drafts in order to get something that makes sense. 
   The catch here is how to get the other draft people to agree on
this impossible task. This is the dilemma we are facing presently.
That's why the pleas are being written, and even some people are
being forced.
  My simple logic says this is impossible. If it is the WG chairship
to try to achieve the impossible, please continue to try it, you
won't get anywhere!
  

Regards,


  
Pat R. Calhoun wrote:



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

Behcet,

The process, to which I provided you a pointer a few days ago,
clearly states that folks express their opinion on the list. Jim and
I will not read other mailing list archives to determine roush
consensus. The seamoby list is the only one we can use to gauge
consensus.

Again, as Jim clearly stated, the only objection we are seeing right
now is yours (although you claim two other people did, and 3 is still
short of rough consensus for a list that has 499 members). If we
guaged there was rough consensus on this issue, then we would most
certainly act. 

Our primary concern at this time is to get the work completed and
achieve our milestones. So how about we get to work and put this
behind us.

PatC

- - -----Original Message-----
From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ] 
Sent: Wednesday, January 16, 2002 4:12 PM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description


Several people not authors of proposals (Vijay, Rene) voiced their 
concern on the murky assessment, or am I wrong, or are you waiting
for  
the sky to fall down?

To be on the positive side, we can offer Majordomo based mailing list
support for the design team, if only with no WG draft.

Take it or leave it.

James Kempf wrote:

>
>Any such decision is always subject to WG concensus. Unfortunately,
>the  only voice we are hearing on the mailing list right now is
>yours. One  voice isn't enough for concensus, nor is text from a
>private email 
>forwarded and posted apparently without the author's permission. 
>Goodness knows, we have enough vocal people on this list. It took us
>a  year to get CT requirements done (and we still don't have them in
>IESG  Last Call!) because everybody had an opinion. If I were seeing
>some of  these people, who were not authors of competing proposals
>coming 
>forward and saying that we should change the decison, it would be 
>another matter.
>
>                    jak
>

- - -- 
Behcet 




_______________________________________________
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/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNkr
5WxMNRzg0Qv02oder+oZzLGR
=GIVv
- -----END PGP SIGNATURE-----


- -- 
Behcet 



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

iQA/AwUBPEb80jN1fXKoxmisEQI1VQCg5GPUGRH9dPLfYCvdyGvqVBHoc94An3Pq
mpgG87fcNYX2f/z3VLyTrSMN
=UwDF
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C19F74.AE017B80
Content-Type: text/html






RE: [Seamoby] Paging Protocol Decision Description




 

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

Hash: SHA1




To be honest, I don't see how this numbering scheme came into play.

It is the first time that I've ever heard of it within the IETF. If I

would have known that the evaluation team was doing this, I would

have stopped it.

 

The reason for the evaluation is to find the candidate protocol that

most closely matches the requirements, which the WG agreed upon. This

would ensure that there is less work involved in getting the protocol

up to par.

 

That was the process (and the same process has been used in many

other WGs)

 

PatC




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

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

Sent: Thursday, January 17, 2002 8:05 AM

To: Pat R. Calhoun

Cc: seamoby@ietf.org

Subject: Re: [Seamoby] Paging Protocol Decision Description






Hi Pat,

  So you are backing your cochair's decision to select the draft that

received 72 marks while all other drafts received 90 or so marks.

This means that the criteria was to select the worst draft as the WG

draft. Since this was the case of course the worst draft  people

would need other drafts in order to get something that makes sense. 

   The catch here is how to get the other draft people to agree on

this impossible task. This is the dilemma we are facing presently.

That's why the pleas are being written, and even some people are

being forced.

  My simple logic says this is impossible. If it is the WG chairship

to try to achieve the impossible, please continue to try it, you

won't get anywhere!

  




Regards,






  

Pat R. Calhoun wrote:








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

Hash: SHA1




Behcet,




The process, to which I provided you a pointer a few days ago,

clearly states that folks express their opinion on the list. Jim and

I will not read other mailing list archives to determine roush

consensus. The seamoby list is the only one we can use to gauge

consensus.




Again, as Jim clearly stated, the only objection we are seeing right

now is yours (although you claim two other people did, and 3 is still

short of rough consensus for a list that has 499 members). If we

guaged there was rough consensus on this issue, then we would most

certainly act. 




Our primary concern at this time is to get the work completed and

achieve our milestones. So how about we get to work and put this

behind us.




PatC




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

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

Sent: Wednesday, January 16, 2002 4:12 PM

To: seamoby@ietf.org

Subject: Re: [Seamoby] Paging Protocol Decision Description






Several people not authors of proposals (Vijay, Rene) voiced their 

concern on the murky assessment, or am I wrong, or are you waiting

for  

the sky to fall down?




To be on the positive side, we can offer Majordomo based mailing list

support for the design team, if only with no WG draft.




Take it or leave it.




James Kempf wrote:




>

>Any such decision is always subject to WG concensus. Unfortunately,

>the  only voice we are hearing on the mailing list right now is

>yours. One  voice isn't enough for concensus, nor is text from a

>private email 

>forwarded and posted apparently without the author's permission. 

>Goodness knows, we have enough vocal people on this list. It took us

>a  year to get CT requirements done (and we still don't have them in

>IESG  Last Call!) because everybody had an opinion. If I were seeing

>some of  these people, who were not authors of competing proposals

>coming 

>forward and saying that we should change the decison, it would be 

>another matter.

>

>                    jak

>




- - -- 

Behcet 










_______________________________________________

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/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNkr

5WxMNRzg0Qv02oder+oZzLGR

=GIVv

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






- -- 

Behcet 








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

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




iQA/AwUBPEb80jN1fXKoxmisEQI1VQCg5GPUGRH9dPLfYCvdyGvqVBHoc94An3Pq

mpgG87fcNYX2f/z3VLyTrSMN

=UwDF

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





------_=_NextPart_001_01C19F74.AE017B80--

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


From seamoby-admin@ietf.org  Thu Jan 17 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 LAA24262
	for ; Thu, 17 Jan 2002 11:59: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 LAA10842;
	Thu, 17 Jan 2002 11: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 LAA10808
	for ; Thu, 17 Jan 2002 11:45:52 -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 LAA23748
	for ; Thu, 17 Jan 2002 11:45:48 -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 IAA23331;
	Thu, 17 Jan 2002 08:45:19 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0HGjI405098;
	Thu, 17 Jan 2002 08:45:18 -0800
X-mProtect:  Thu, 17 Jan 2002 08:45:18 -0800 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14160.americas.nokia.com (172.18.141.60, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdLrx6We; Thu, 17 Jan 2002 08:45:15 PST
Message-ID: <3C46FF96.6010606@iprg.nokia.com>
Date: Thu, 17 Jan 2002 08:45:10 -0800
From: Cedric Westphal 
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Pat R. Calhoun" 
CC: "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description
References: 
Content-Type: multipart/alternative;
 boundary="------------080809030404050709010709"
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


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

Pat,

Pat R. Calhoun wrote:

>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Behcet,
>
> The process, to which I provided you a pointer a few days ago,
> clearly states that folks express their opinion on the list. Jim and
> I will not read other mailing list archives to determine roush
> consensus. The seamoby list is the only one we can use to gauge
> consensus.
>
> Again, as Jim clearly stated, the only objection we are seeing right
> now is yours (although you claim two other people did, and 3 is still
> short of rough consensus for a list that has 499 members). If we
> guaged there was rough consensus on this issue, then we would most
> certainly act.
>
First, I have not followed the debate. However, I find unacceptable
that you would tell Behcet not to voice his opinion because he is the
only one doing so. How do you get
to the conclusion that the roughly 495 who are not participating in this
debate agree with you (and not Behcet) just because they shut up?
Can you point to one debate where the rough consensus was reached
by way of more than 250 favorable opinions? I have seen proposals on
this list (say car discovery reqs, for instance) decided by 2 people in 
favor,
one against. For any outcome here to make sense, shouldn't the definition
of rough consensus be consistent?

Cedric.


> Our primary concern at this time is to get the work completed and
> achieve our milestones. So how about we get to work and put this
> behind us.
>
> PatC
>
> - -----Original Message-----
> From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ]
> Sent: Wednesday, January 16, 2002 4:12 PM
> To: seamoby@ietf.org
> Subject: Re: [Seamoby] Paging Protocol Decision Description
>
>
> Several people not authors of proposals (Vijay, Rene) voiced their
> concern on the murky assessment, or am I wrong, or are you waiting
> for 
> the sky to fall down?
>
> To be on the positive side, we can offer Majordomo based mailing list
> support for the design team, if only with no WG draft.
>
> Take it or leave it.
>
> James Kempf wrote:
>
> >
> >Any such decision is always subject to WG concensus. Unfortunately,
> >the  only voice we are hearing on the mailing list right now is
> >yours. One  voice isn't enough for concensus, nor is text from a
> >private email
> >forwarded and posted apparently without the author's permission.
> >Goodness knows, we have enough vocal people on this list. It took us
> >a  year to get CT requirements done (and we still don't have them in
> >IESG  Last Call!) because everybody had an opinion. If I were seeing
> >some of  these people, who were not authors of competing proposals
> >coming
> >forward and saying that we should change the decison, it would be
> >another matter.
> >
> >                    jak
> >
>
> - --
> Behcet
>
>
>
>
> _______________________________________________
> 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/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNkr
> 5WxMNRzg0Qv02oder+oZzLGR
> =GIVv
> -----END PGP SIGNATURE-----
>


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





Pat,



Pat R. Calhoun wrote:



  
  RE: [Seamoby] Paging Protocol Decision Description
  
 

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

  Hash: SHA1

  
Behcet,

  
The process, to which I provided you a pointer a few
days ago,

  clearly states that folks express their opinion on the list.
Jim and

  I will not read other mailing list archives to determine
roush

  consensus. The seamoby list is the only one we can use to
gauge

  consensus.

  
Again, as Jim clearly stated, the only objection we are
seeing right

  now is yours (although you claim two other people did, and
3 is still

  short of rough consensus for a list that has 499 members).
If we

  guaged there was rough consensus on this issue, then we
would most

  certainly act.

  

First, I have not followed the debate. However, I find unacceptable

that you would tell Behcet not to voice his opinion because he is the

only one doing so. How do you get

to the conclusion that the roughly 495 who are not participating in this

debate agree with you (and not Behcet) just because they shut up?

Can you point to one debate where the rough consensus was reached

by way of more than 250 favorable opinions? I have seen proposals on

this list (say car discovery reqs, for instance) decided by 2 people in favor,

one against. For any outcome here to make sense, shouldn't the definition

of rough consensus be consistent?

  

Cedric.

  

    
 

    

    

    

      
Our primary concern at this time is to get the work
completed and

      achieve our milestones. So how about we get to work
and put this

      behind us.

      
PatC

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

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

      Sent: Wednesday, January 16, 2002 4:12 PM

      To: seamoby@ietf.org

      Subject: Re: [Seamoby] Paging Protocol Decision Description

      

      
Several people not authors of proposals (Vijay, Rene)
voiced their 

      concern on the murky assessment, or am I wrong, or are
you waiting

      for  

      the sky to fall down?

      
To be on the positive side, we can offer Majordomo
based mailing list

      support for the design team, if only with no WG draft.

      
Take it or leave it.

      
James Kempf wrote:

      
>

      >Any such decision is always subject to WG concensus.
Unfortunately,

      >the  only voice we are hearing on the mailing list
right now is

      >yours. One  voice isn't enough for concensus, nor
is text from a

      >private email 

      >forwarded and posted apparently without the author's
permission. 

      >Goodness knows, we have enough vocal people on this
list. It took us

      >a  year to get CT requirements done (and we still
don't have them in

      >IESG  Last Call!) because everybody had an opinion.
If I were seeing

      >some of  these people, who were not authors of competing
proposals

      >coming 

      >forward and saying that we should change the decison,
it would be 

      >another matter.

      >

      >                    jak

      >

      
- -- 

      Behcet 

      

      

      

      
_______________________________________________

      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/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNkr

      5WxMNRzg0Qv02oder+oZzLGR

      =GIVv

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

      

      

      
      

--------------080809030404050709010709--


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


From seamoby-admin@ietf.org  Thu Jan 17 12:05: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 MAA24513
	for ; Thu, 17 Jan 2002 12:05: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 LAA11057;
	Thu, 17 Jan 2002 11:52: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 LAA11025
	for ; Thu, 17 Jan 2002 11:52:16 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24021
	for ; Thu, 17 Jan 2002 11:52:10 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 17 Jan 2002 08:51:42 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Cedric Westphal'" 
Cc: "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 08:51:07 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F77.288E65F0"
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_01C19F77.288E65F0
Content-Type: text/plain

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

 >  First, I have not followed the debate. However, I find
 > unacceptable 
 >  that you would tell Behcet not to voice his opinion because he is
the
 >  only one doing so. 
hmm... Correct me if I am wrong, but where did I state that Behcet
couldn't voice his opinions? That was certainly not my intention. He
is entitled to say what he wants, but that won't necessarily change
the WG's decision (and that was my point).

 >  How do you get
 >  to the conclusion that the roughly 495 who are not participating
in this
 >  debate agree with you (and not Behcet) just because they shut up?
My point here was that there are plenty of folks on this list, and if
you look at the archives, many of them certainly have voiced their
opinions many times over. I haven't heard anything from those folks
either.

 >  Can you point to one debate where the rough consensus was reached
 >  by way of more than 250 favorable opinions?
Hmmm.. Perhaps you misread my statement. Read above.

 > I have seen proposals on
 >  this list (say car discovery reqs, for instance) decided by 2
people in favor,
 >  one against. For any outcome here to make sense, shouldn't the
definition
 >  of rough consensus be consistent?
Again, read above.

PatC

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

iQA/AwUBPEcA+zN1fXKoxmisEQJBUgCffQTNJn1QIorXhYH9pNaRC2OShR0AmweI
y3XGSS9P8sbrVVp+sORYWuLb
=IaYu
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C19F77.288E65F0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Paging Protocol Decision Description




 

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

Hash: SHA1




 >  First, I have not followed the =
debate. However, I find

 > unacceptable 

 >  that you would tell Behcet not to =
voice his opinion because he is

the

 >  only one doing so. 

hmm... Correct me if I am wrong, but where did I =
state that Behcet

couldn't voice his opinions? That was certainly not =
my intention. He

is entitled to say what he wants, but that won't =
necessarily change

the WG's decision (and that was my point).




 >  How do you get

 >  to the conclusion that the roughly =
495 who are not participating

in this

 >  debate agree with you (and not =
Behcet) just because they shut up?

My point here was that there are plenty of folks on =
this list, and if

you look at the archives, many of them certainly =
have voiced their

opinions many times over. I haven't heard anything =
from those folks

either.




 >  Can you point to one debate where =
the rough consensus was reached

 >  by way of more than 250 favorable =
opinions?

Hmmm.. Perhaps you misread my statement. Read =
above.




 > I have seen proposals on

 >  this list (say car discovery reqs, =
for instance) decided by 2

people in favor,

 >  one against. For any outcome here =
to make sense, shouldn't the

definition

 >  of rough consensus be =
consistent?

Again, read above.




PatC




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

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




iQA/AwUBPEcA+zN1fXKoxmisEQJBUgCffQTNJn1QIorXhYH9pNaRC2OShR0Amwe=
I

y3XGSS9P8sbrVVp+sORYWuLb

=3DIaYu

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





------_=_NextPart_001_01C19F77.288E65F0--

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


From seamoby-admin@ietf.org  Thu Jan 17 12:37: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 MAA27732
	for ; Thu, 17 Jan 2002 12:37: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 MAA13857;
	Thu, 17 Jan 2002 12:26: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 MAA13828
	for ; Thu, 17 Jan 2002 12:25:58 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27276
	for ; Thu, 17 Jan 2002 12:25:54 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 17 Jan 2002 09:25:27 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Hesham Soliman (ERA)'" ,
        "'Cedric Westphal'" 
Cc: "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 09:24:22 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F7B.CE076730"
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_01C19F7B.CE076730
Content-Type: text/plain

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

IMHO numbers are irrelevant. What counts here is whether the protocol
matches up against the requirements. We picked the one that was the
closest, based on the input from the assessment team.
 
PatC

- -----Original Message-----
From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] 
Sent: Thursday, January 17, 2002 9:21 AM
To: Pat R. Calhoun; 'Cedric Westphal'
Cc: 'Behcet Sarikaya'; seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description


I don't want to take sides here since I'm not following 
the paging proposals and do not have an opinion on 
proposal X vs proposal Y, but really why are you having a numbering 
system if you're not going to follow it ???? 
What's the point of these numbers anyway if they are
(obviously) based on different criteria from those that 
the 'winning' protocol is assessed on ?
 
Seems very strange. 
 
Hesham


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

iQA/AwUBPEcIxjN1fXKoxmisEQIr5QCgsWwgPX40EZN6BwAeut/LgaG5SIoAoObH
DodVWjoI6EL8uOqzllISZN2u
=OaLx
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C19F7B.CE076730
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Paging Protocol Decision Description




 

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

Hash: SHA1




IMHO numbers are irrelevant. What counts here is =
whether the protocol

matches up against the requirements. We picked the =
one that was the

closest, based on the input from the assessment =
team.

 

PatC




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

From: Hesham Soliman (ERA) [mailto:hesham.soliman@era=
.ericsson.se] 

Sent: Thursday, January 17, 2002 9:21 AM

To: Pat R. Calhoun; 'Cedric Westphal'

Cc: 'Behcet Sarikaya'; seamoby@ietf.org

Subject: RE: [Seamoby] Paging Protocol Decision =
Description






I don't want to take sides here since I'm not =
following 

the paging proposals and do not have an opinion on =


proposal X vs proposal Y, but really why are you =
having a numbering 

system if you're not going to follow it ???? 

What's the point of these numbers anyway if they =
are

(obviously) based on different criteria from those =
that 

the 'winning' protocol is assessed on ?

 

Seems very strange. 

 

Hesham






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

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




iQA/AwUBPEcIxjN1fXKoxmisEQIr5QCgsWwgPX40EZN6BwAeut/LgaG5SIoAoOb=
H

DodVWjoI6EL8uOqzllISZN2u

=3DOaLx

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





------_=_NextPart_001_01C19F7B.CE076730--

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


From seamoby-admin@ietf.org  Thu Jan 17 12:42: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 MAA27879
	for ; Thu, 17 Jan 2002 12:42: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 MAA13611;
	Thu, 17 Jan 2002 12:21: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 MAA13561
	for ; Thu, 17 Jan 2002 12:21:08 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27146
	for ; Thu, 17 Jan 2002 12:21:04 -0500 (EST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HHL5K18604
	for ; Thu, 17 Jan 2002 18:21:05 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 17 18:20:48 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 17 Jan 2002 18:12:04 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C21A@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Pat R. Calhoun'" ,
        "'Cedric Westphal'"
	 
Cc: "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 18:20:46 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F7B.4CC30E90"
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_01C19F7B.4CC30E90
Content-Type: text/plain;
	charset="iso-8859-1"

I don't want to take sides here since I'm not following 
the paging proposals and do not have an opinion on 
proposal X vs proposal Y, but really why are you having a numbering 
system if you're not going to follow it ???? 
What's the point of these numbers anyway if they are
(obviously) based on different criteria from those that 
the 'winning' protocol is assessed on ?
 
Seems very strange. 
 
Hesham

------_=_NextPart_001_01C19F7B.4CC30E90
Content-Type: text/html;
	charset="iso-8859-1"




RE: [Seamoby] Paging Protocol Decision Description




I 
don't want to take sides here since I'm not following 


the 
paging proposals and do not have an opinion on 


proposal X vs proposal Y, but really why are you having a numbering 



system 
if you're not going to follow it ???? 


What's 
the point of these numbers anyway if they are


(obviously) based on different criteria from those that 



the 
'winning' protocol is assessed on ?


 


Seems 
very strange. 


 


Hesham


------_=_NextPart_001_01C19F7B.4CC30E90--

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


From seamoby-admin@ietf.org  Thu Jan 17 12:54: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 MAA28258
	for ; Thu, 17 Jan 2002 12:54: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 MAA14775;
	Thu, 17 Jan 2002 12:40: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 MAA14742
	for ; Thu, 17 Jan 2002 12:40: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 MAA27843
	for ; Thu, 17 Jan 2002 12:40:45 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0HHe8e28227;
	Thu, 17 Jan 2002 09:40:08 -0800 (PST)
Message-ID: <00c001c19f7d$c83bb890$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Marco Liebsch" , "Seamoby" 
References: <3C46FBE6.441E69BF@ccrle.nec.de>
Subject: Re: [Seamoby] paging issue#1: security mechanisms
Date: Thu, 17 Jan 2002 09:38: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

Marco,

Let's put aside security for now. We have not yet decided if
we want to treat this in a separate draft, like I believe
MIP is doing with BU security, or in the base draft.
The advantage of a separate draft is that it makes
the base draft shorter, which helps get IESG
attention faster, and we can send a security draft
to the security directorate, where they can specifically
focus on it without having to wade through other
details of the protocol.

            jak

----- Original Message -----
From: "Marco Liebsch" 
To: "Seamoby" 
Sent: Thursday, January 17, 2002 8:29 AM
Subject: [Seamoby] paging issue#1: security mechanisms


> Hi all,
>
> on security support, the submitted proposals refer to IPSec and TLS
> based mechanisms in order to make paging related signaling secure.
> Beside others, the base-line document makes use of IPSec to have
> appropriate mechanisms for authentication and possibly encryption.
> draft-ohba specifies a TLS mechansims in order to provide
authentication
> and refers to IPSec in order to provide encryption.
>
> As addressed already a bit earlier on the list, both mechansims have
> pros and cons. We should clarify in which direction the paging
protocol
> should go to, considering the transport mechanisms for paging related
> signaling. Signaling transport as described in the base-line draft
makes
> use of Destination Options for IPv6, but allows carrying messages over
> UDP as well. draft-ohba relies on UDP transport. The following is my
> current view on the two mechanisms:
>
> IPSec:
> *Needs to be open for mobility support
> *Would be the same mechanism for IPv6/Dest-Opt as well as for UDP
> transport
> *Allows a gateway mode (but this is not yet part of any IP paging
> protocol proposal, as far as I know)
>
> TLS:
> *Independence of lower layer specifics
> *Proprietary mechanism
> *Requires reliable transport
>
> Also SSL- /PBK-like mechanisms have been addressed, but we have to
> compare in order to go into one direction with the paging protocol.
>
> Marco
>
>
>
>
> _______________________________________________
> 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 Jan 17 12:54: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 MAA28270
	for ; Thu, 17 Jan 2002 12:54: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 MAA14845;
	Thu, 17 Jan 2002 12:41: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 MAA14816
	for ; Thu, 17 Jan 2002 12:41:26 -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 MAA27861
	for ; Thu, 17 Jan 2002 12:41:24 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0HHepe28247;
	Thu, 17 Jan 2002 09:40:51 -0800 (PST)
Message-ID: <00c501c19f7d$e1926280$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" ,
        "Pat R. Calhoun" 
Cc: 
References:  <3C46F60F.5050005@alcatel.com>
Subject: Re: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 09:39:14 -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,

>   So you are backing your cochair's decision to select the draft that
> received 72 marks while all other drafts received 90 or so marks. This
> means that the criteria was to select the worst draft as the WG draft.
> Since this was the case of course the worst draft  people would need
> other drafts in order to get something that makes sense.

There are two invalid assumptions here which might be
clarified by a more careful reading of
the text and email I sent out yesterday:

1) That I made the decision to select the WG draft. The decision
was joint between Pat and I, with approval of Allison as
the text I sent out yesterday explained.

2) That the rating system consisted of absolute numbers, like the
the price of groceries or something, that one could simply add up
and come up with a score. In fact, as I mentioned in my email yesterday,
the rating system was something I cooked up to let us
compare the drafts *on individual requirements*. It failed
miserably, because people kept making assumptions, like
the above, that the numbers were some absolute value that
could simply be added together to determine the result.
In retrospect, this is a natural assumption I suppose, but
it certainly was not how we performed the analysis. Perhaps
I need to add some text to the assessment draft explaining this.

>    The catch here is how to get the other draft people to agree on
this
> impossible task. This is the dilemma we are facing presently. That's
why
> the pleas are being written, and even some people are being forced.
>   My simple logic says this is impossible. If it is the WG chairship
to
> try to achieve the impossible, please continue to try it, you won't
get
> anywhere!
>
>

I'll let this go uncommented, since I don't understand the point.

            jak




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


From seamoby-admin@ietf.org  Thu Jan 17 12:54: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 MAA28290
	for ; Thu, 17 Jan 2002 12:54: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 MAA14945;
	Thu, 17 Jan 2002 12:43: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 MAA14913
	for ; Thu, 17 Jan 2002 12:43:53 -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 MAA27899
	for ; Thu, 17 Jan 2002 12:43:51 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0HHhJe28351;
	Thu, 17 Jan 2002 09:43:19 -0800 (PST)
Message-ID: <00cc01c19f7e$3a410580$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Pat R. Calhoun" ,
        "'Behcet Sarikaya'" 
Cc: 
References: 
Subject: Re: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 09:41:43 -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,

> To be honest, I don't see how this numbering scheme came into play.
> It is the first time that I've ever heard of it within the IETF. If I
> would have known that the evaluation team was doing this, I would
> have stopped it.
>  
> The reason for the evaluation is to find the candidate protocol that
> most closely matches the requirements, which the WG agreed upon. This
> would ensure that there is less work involved in getting the protocol
> up to par.
>  
> That was the process (and the same process has been used in many
> other WGs)
>  

It was just something I cooked up to allow the evaluation team
to quickly summarize the comparison between the different
protocols on individual requirements. It was never intended
to be used as an absolute measure of quality. I need to
put some text into the draft to this effect. 

You can rest assured, that I will *never* use something like
this again, and we should probably inform other WGs
that they shouldn't either! The danger of misinterpretation
is too great.

            jak



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


From seamoby-admin@ietf.org  Thu Jan 17 12:55: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 MAA28307
	for ; Thu, 17 Jan 2002 12:55: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 MAA14692;
	Thu, 17 Jan 2002 12:38: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 MAA14665
	for ; Thu, 17 Jan 2002 12:38:43 -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 MAA27759
	for ; Thu, 17 Jan 2002 12:38:39 -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 JAA26970;
	Thu, 17 Jan 2002 09:38:11 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0HHcAI27507;
	Thu, 17 Jan 2002 09:38:10 -0800
X-mProtect:  Thu, 17 Jan 2002 09:38:10 -0800 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14160.americas.nokia.com (172.18.141.60, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdFWbIBc; Thu, 17 Jan 2002 09:38:06 PST
Message-ID: <3C470BF8.5070208@iprg.nokia.com>
Date: Thu, 17 Jan 2002 09:38:00 -0800
From: Cedric Westphal 
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Pat R. Calhoun" 
CC: "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description
References: 
Content-Type: multipart/alternative;
 boundary="------------050109090900020900080209"
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


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

Pat,

Pat R. Calhoun wrote:

>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>  >  First, I have not followed the debate. However, I find
>  > unacceptable
>  >  that you would tell Behcet not to voice his opinion because he is
> the
>  >  only one doing so.
> hmm... Correct me if I am wrong, but where did I state that Behcet
> couldn't voice his opinions?
>
That was my interpretation of: 'how about we get to work and leave
this behind us'. Your co-chair did also call him a 'sour grape'.

> That was certainly not my intention. He
> is entitled to say what he wants, but that won't necessarily change
> the WG's decision (and that was my point).
>
>  >  How do you get
>  >  to the conclusion that the roughly 495 who are not participating
> in this
>  >  debate agree with you (and not Behcet) just because they shut up?
> My point here was that there are plenty of folks on this list, and if
> you look at the archives, many of them certainly have voiced their
> opinions many times over. I haven't heard anything from those folks
> either.
>
My point here is that these plenty of folks don't voice their support
to this process either. Behcet has counted Vijay and Rene supporting
him. I have not followed the debate, so please let me know who agreed
with this process, and that'd be the end of this.

>  >  Can you point to one debate where the rough consensus was reached
>  >  by way of more than 250 favorable opinions?
> Hmmm.. Perhaps you misread my statement. Read above.
>
I did push your statement to the extreme. The point was consensus does
not go by absolute numbers, but relative numbers of for and against, 
especially
since on any topic, the very vast majority never says a thing.
Thanks,

Cedric.

>  
>


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





Pat,



Pat R. Calhoun wrote:



  
  RE: [Seamoby] Paging Protocol Decision Description
  
 

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

  Hash: SHA1

  
 >  First, I have not followed the debate. However,
I find

   > unacceptable 

   >  that you would tell Behcet not to voice his opinion
because he is

  the

   >  only one doing so. 

  hmm... Correct me if I am wrong, but where did I state that
Behcet

  couldn't voice his opinions? 

  

That was my interpretation of: 'how about we get to work and leave

this behind us'. Your co-chair did also call him a 'sour grape'.

  

    
That was certainly not my intention. He

    is entitled to say what he wants, but that won't necessarily
change

    the WG's decision (and that was my point).

    
 >  How do you get

     >  to the conclusion that the roughly 495 who are
not participating

    in this

     >  debate agree with you (and not Behcet) just because
they shut up?

    My point here was that there are plenty of folks on this
list, and if

    you look at the archives, many of them certainly have
voiced their

    opinions many times over. I haven't heard anything from
those folks

    either.

    

My point here is that these plenty of folks don't voice their support

to this process either. Behcet has counted Vijay and Rene supporting

him. I have not followed the debate, so please let me know who agreed

with this process, and that'd be the end of this.

    

    

      
 >  Can you point to one debate where the rough
consensus was reached

       >  by way of more than 250 favorable opinions?

      Hmmm.. Perhaps you misread my statement. Read above.

      

I did push your statement to the extreme. The point was consensus does

not go by absolute numbers, but relative numbers of for and against, especially

since on any topic, the very vast majority never says a thing.

Thanks,

      

Cedric.

      

        
 

        

        

        
        

--------------050109090900020900080209--


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


From seamoby-admin@ietf.org  Thu Jan 17 13:08: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 NAA28711
	for ; Thu, 17 Jan 2002 13:08: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 MAA15295;
	Thu, 17 Jan 2002 12:57: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 MAA15267
	for ; Thu, 17 Jan 2002 12:57:00 -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 MAA28343
	for ; Thu, 17 Jan 2002 12:56: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 g0HHuCjh022186;
	Thu, 17 Jan 2002 12:56:12 -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 MAA02979;
	Thu, 17 Jan 2002 12:56:03 -0500 (EST)
Date: Thu, 17 Jan 2002 12:56:09 -0500
To: Marco Liebsch 
Cc: Seamoby 
Subject: Re: [Seamoby] paging issue#1: security mechanisms
Message-ID: <20020117175609.GC2465@catfish>
Mail-Followup-To: Marco Liebsch ,
	Seamoby 
References: <3C46FBE6.441E69BF@ccrle.nec.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
In-Reply-To: <3C46FBE6.441E69BF@ccrle.nec.de>
User-Agent: Mutt/1.3.25i
From: Yoshihiro Ohba 
X-Dispatcher: imput version 20000414(IM141)
Lines: 61
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

Exactlly speaking, draft-ohba introduces a higher layer security mechanism 
over UDP, but it is not the TLS protocol specified in RFC2246.

As Jim mentioned in the SLC meeting, DMHA has a lot of big security
issues.  Some of them is similar to Mobile IPv6 BU, but some are
completely different.  Most of the issues are addressed in draft-ohba,
but I don't think everything is addressed.

IMHO, before comparing IPsec and others, we may need to analyze at
first what makes the DMHA protocol design so difficult when we are
trying to meet all the DMHA security requirements.  Depending on the
analysis, we may need to put some restriction in protocool
functionality or loosen the requirement itself, but I'm not sure...

Just my impression,
Yoshihiro Ohba


On Thu, Jan 17, 2002 at 05:29:27PM +0100, Marco Liebsch wrote:
> Hi all,
> 
> on security support, the submitted proposals refer to IPSec and TLS
> based mechanisms in order to make paging related signaling secure.
> Beside others, the base-line document makes use of IPSec to have
> appropriate mechanisms for authentication and possibly encryption.
> draft-ohba specifies a TLS mechansims in order to provide authentication
> and refers to IPSec in order to provide encryption.
> 
> As addressed already a bit earlier on the list, both mechansims have
> pros and cons. We should clarify in which direction the paging protocol
> should go to, considering the transport mechanisms for paging related
> signaling. Signaling transport as described in the base-line draft makes
> use of Destination Options for IPv6, but allows carrying messages over
> UDP as well. draft-ohba relies on UDP transport. The following is my
> current view on the two mechanisms:
> 
> IPSec:
> *Needs to be open for mobility support
> *Would be the same mechanism for IPv6/Dest-Opt as well as for UDP
> transport
> *Allows a gateway mode (but this is not yet part of any IP paging
> protocol proposal, as far as I know)
> 
> TLS:
> *Independence of lower layer specifics
> *Proprietary mechanism
> *Requires reliable transport
> 
> Also SSL- /PBK-like mechanisms have been addressed, but we have to
> compare in order to go into one direction with the paging protocol.
> 
> Marco
> 
> 
> 
> 
> _______________________________________________
> 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 Jan 17 13:18: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 NAA29015
	for ; Thu, 17 Jan 2002 13:18: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 NAA15786;
	Thu, 17 Jan 2002 13:01: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 NAA15755
	for ; Thu, 17 Jan 2002 13: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 NAA28520
	for ; Thu, 17 Jan 2002 13: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 g0HI1WH59426;
	Thu, 17 Jan 2002 19:01:32 +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 TAA17286;
	Thu, 17 Jan 2002 19:01:02 +0100
Message-ID: <3C47115E.CAA05414@ccrle.nec.de>
Date: Thu, 17 Jan 2002 19:01:02 +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 
Subject: Re: [Seamoby] paging issue#1: security mechanisms
References: <3C46FBE6.441E69BF@ccrle.nec.de> <00c001c19f7d$c83bb890$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,

ok for me, but we should bear in mind not go with other architecture and
protocol issues into a direction restricting future security support to a
specific solution.

Marco

James Kempf wrote:

> Marco,
>
> Let's put aside security for now. We have not yet decided if
> we want to treat this in a separate draft, like I believe
> MIP is doing with BU security, or in the base draft.
> The advantage of a separate draft is that it makes
> the base draft shorter, which helps get IESG
> attention faster, and we can send a security draft
> to the security directorate, where they can specifically
> focus on it without having to wade through other
> details of the protocol.
>
>             jak
>
> ----- Original Message -----
> From: "Marco Liebsch" 
> To: "Seamoby" 
> Sent: Thursday, January 17, 2002 8:29 AM
> Subject: [Seamoby] paging issue#1: security mechanisms
>
> > Hi all,
> >
> > on security support, the submitted proposals refer to IPSec and TLS
> > based mechanisms in order to make paging related signaling secure.
> > Beside others, the base-line document makes use of IPSec to have
> > appropriate mechanisms for authentication and possibly encryption.
> > draft-ohba specifies a TLS mechansims in order to provide
> authentication
> > and refers to IPSec in order to provide encryption.
> >
> > As addressed already a bit earlier on the list, both mechansims have
> > pros and cons. We should clarify in which direction the paging
> protocol
> > should go to, considering the transport mechanisms for paging related
> > signaling. Signaling transport as described in the base-line draft
> makes
> > use of Destination Options for IPv6, but allows carrying messages over
> > UDP as well. draft-ohba relies on UDP transport. The following is my
> > current view on the two mechanisms:
> >
> > IPSec:
> > *Needs to be open for mobility support
> > *Would be the same mechanism for IPv6/Dest-Opt as well as for UDP
> > transport
> > *Allows a gateway mode (but this is not yet part of any IP paging
> > protocol proposal, as far as I know)
> >
> > TLS:
> > *Independence of lower layer specifics
> > *Proprietary mechanism
> > *Requires reliable transport
> >
> > Also SSL- /PBK-like mechanisms have been addressed, but we have to
> > compare in order to go into one direction with the paging protocol.
> >
> > Marco
> >
> >
> >
> >
> > _______________________________________________
> > 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 Jan 17 13:24: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 NAA29206
	for ; Thu, 17 Jan 2002 13:24: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 NAA16000;
	Thu, 17 Jan 2002 13:08: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 NAA15963
	for ; Thu, 17 Jan 2002 13:08:32 -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 NAA28671
	for ; Thu, 17 Jan 2002 13:08:30 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0HI7pe29342;
	Thu, 17 Jan 2002 10:07:51 -0800 (PST)
Message-ID: <00f501c19f81$a767cd80$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Cedric Westphal" ,
        "Pat R. Calhoun" 
Cc: "'Behcet Sarikaya'" , 
References:  <3C46FF96.6010606@iprg.nokia.com>
Subject: Re: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 10:06:15 -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

Cedric,

Behcet has the right to express his opinion, you are correct. But, my
interpretation of Behcet's remarks is the following:

1) That the process around the decision to select the WG draft was
murky. Others have made this
comment as well, and I agreed, several times in fact, that this was the
case. I sent out text yesterday
describing how the decision was made. Behcet's followup email had one
point about the decision
process, involving the rating numbers, which I attempted to clarify in
email, and I will put text
into the assessment draft explaining that the numbers are only designed
to compare the protocols
on a requirement by requirement basis. Perhaps I should even take the
numbers out of the
assessment draft, as they are too confusing. They were only a tool for
the assessment team, a
tool that fundamentally didn't work.

2) That the assessment process misjudged his contribution. What can I
say about this? I explained
yesterday why we we couldn't accept his design.

Now, I've made these same explainations several times to Behcet on the
list, cultivating patience, and I will continue
to do so, but, really, we need to get on with it. If you or any other WG
member has issues with the
assessment process or the selection result, please post them, but we
would really, really like to wind up
this discussion by the beginning of next week so that we can start with
the technical work. If it still seems
in our judgement that the WG is satisfied with the decision and is
satisfied with the explaination of
the decision process, then Behcet can file a grievance action with the
IESG. If there are other members
who have issues with the process or the result, then we will need to
discuss it.

If you recall last spring, Pat was beaten up by certain WG members for
running closed design teams to
do certain WG work items. At every IETF Plenium, somebody gets up and
complains about design teams.
As the text I sent out yesterday indicated, we do not consider the
current content of draft-renker
to be the final content of the draft, we consider it to be the starting
point. We would like the working
group, in a completely open fashion, to contribute to moving that
technical content forward. Now, it
seems, we are getting beaten up for *not* having a closed design team!

One simply cannot win.

            jak



----- Original Message -----
From: "Cedric Westphal" 
To: "Pat R. Calhoun" 
Cc: "'Behcet Sarikaya'" ;

Sent: Thursday, January 17, 2002 8:45 AM
Subject: Re: [Seamoby] Paging Protocol Decision Description


> Pat,
>
> Pat R. Calhoun wrote:
>
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Behcet,
> >
> > The process, to which I provided you a pointer a few days ago,
> > clearly states that folks express their opinion on the list. Jim and
> > I will not read other mailing list archives to determine roush
> > consensus. The seamoby list is the only one we can use to gauge
> > consensus.
> >
> > Again, as Jim clearly stated, the only objection we are seeing right
> > now is yours (although you claim two other people did, and 3 is
still
> > short of rough consensus for a list that has 499 members). If we
> > guaged there was rough consensus on this issue, then we would most
> > certainly act.
> >
> First, I have not followed the debate. However, I find unacceptable
> that you would tell Behcet not to voice his opinion because he is the
> only one doing so. How do you get
> to the conclusion that the roughly 495 who are not participating in
this
> debate agree with you (and not Behcet) just because they shut up?
> Can you point to one debate where the rough consensus was reached
> by way of more than 250 favorable opinions? I have seen proposals on
> this list (say car discovery reqs, for instance) decided by 2 people
in
> favor,
> one against. For any outcome here to make sense, shouldn't the
definition
> of rough consensus be consistent?
>
> Cedric.
>
>
> > Our primary concern at this time is to get the work completed and
> > achieve our milestones. So how about we get to work and put this
> > behind us.
> >
> > PatC
> >
> > - -----Original Message-----
> > From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ]
> > Sent: Wednesday, January 16, 2002 4:12 PM
> > To: seamoby@ietf.org
> > Subject: Re: [Seamoby] Paging Protocol Decision Description
> >
> >
> > Several people not authors of proposals (Vijay, Rene) voiced their
> > concern on the murky assessment, or am I wrong, or are you waiting
> > for
> > the sky to fall down?
> >
> > To be on the positive side, we can offer Majordomo based mailing
list
> > support for the design team, if only with no WG draft.
> >
> > Take it or leave it.
> >
> > James Kempf wrote:
> >
> > >
> > >Any such decision is always subject to WG concensus. Unfortunately,
> > >the  only voice we are hearing on the mailing list right now is
> > >yours. One  voice isn't enough for concensus, nor is text from a
> > >private email
> > >forwarded and posted apparently without the author's permission.
> > >Goodness knows, we have enough vocal people on this list. It took
us
> > >a  year to get CT requirements done (and we still don't have them
in
> > >IESG  Last Call!) because everybody had an opinion. If I were
seeing
> > >some of  these people, who were not authors of competing proposals
> > >coming
> > >forward and saying that we should change the decison, it would be
> > >another matter.
> > >
> > >                    jak
> > >
> >
> > - --
> > Behcet
> >
> >
> >
> >
> > _______________________________________________
> > 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/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNkr
> > 5WxMNRzg0Qv02oder+oZzLGR
> > =GIVv
> > -----END PGP SIGNATURE-----
> >
>
>


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


From seamoby-admin@ietf.org  Thu Jan 17 13:26: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 NAA29262
	for ; Thu, 17 Jan 2002 13:26: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 NAA16324;
	Thu, 17 Jan 2002 13:11: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 NAA16297
	for ; Thu, 17 Jan 2002 13:11:51 -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 NAA28799
	for ; Thu, 17 Jan 2002 13:11:49 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0HIBBe29513;
	Thu, 17 Jan 2002 10:11:11 -0800 (PST)
Message-ID: <011001c19f82$1ebd1e80$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Hesham Soliman \(ERA\)" ,
        "'Pat R. Calhoun'" ,
        "'Cedric Westphal'" 
Cc: "'Behcet Sarikaya'" , 
References: <4DA6EA82906FD511BE2F00508BCF053801C4C21A@Esealnt861.al.sw.ericsson.se>
Subject: Re: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 10:09:35 -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,

You are right. The numbering system was an experiment
that didn't work. It was meant to help the assessment
team, it only served to confuse the issue.

I will take the actual numbers out of the draft
and substitute a nonnumeric indication
of the status of the draft on particular
requirements.

            jak

----- Original Message -----
From: "Hesham Soliman (ERA)" 
To: "'Pat R. Calhoun'" ; "'Cedric
Westphal'" 
Cc: "'Behcet Sarikaya'" ;

Sent: Thursday, January 17, 2002 9:20 AM
Subject: RE: [Seamoby] Paging Protocol Decision Description


> I don't want to take sides here since I'm not following
> the paging proposals and do not have an opinion on
> proposal X vs proposal Y, but really why are you having a numbering
> system if you're not going to follow it ????
> What's the point of these numbers anyway if they are
> (obviously) based on different criteria from those that
> the 'winning' protocol is assessed on ?
>
> Seems very strange.
>
> Hesham
>


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


From seamoby-admin@ietf.org  Thu Jan 17 13:50: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 NAA00119
	for ; Thu, 17 Jan 2002 13:50: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 NAA17479;
	Thu, 17 Jan 2002 13:38: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 NAA17448
	for ; Thu, 17 Jan 2002 13:38:15 -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 NAA29603
	for ; Thu, 17 Jan 2002 13:38:12 -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 MAA05618;
	Thu, 17 Jan 2002 12:37:43 -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 g0HIbhs17175;
	Thu, 17 Jan 2002 12:37:43 -0600 (CST)
Message-ID: <3C4719E8.9080509@alcatel.com>
Date: Thu, 17 Jan 2002 12:37:28 -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: James Kempf 
CC: Cedric Westphal ,
        "Pat R. Calhoun" , seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description
References:  <3C46FF96.6010606@iprg.nokia.com> <00f501c19f81$a767cd80$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,
  The assessment for IP Paging was supposed to be announced at WG 
meeting in SLC. And it did. The minutes of this meeting contained 
strange text in paging part because the paging part talking or 
presentation was done by Kempf and the minutes was also taken by Kempf. 
Kempf did the talking based on the slides, almost literally he was 
reading from the slides. The slides were not posted despite several 
repeated request that I made on the mailing list.
  Because of the admitted irregularity, i.e. one draft was eliminated by 
sparing no comments I declared the assessment results moot.
  Kempf now wishes to correct this irregularity by adding an additional 
text which includes his own comments and does not include other's 
comments, e.g. I made an assessment of draft-renker and no one seems to 
have commented otherwise.
  Kempf wishes to keep adding some new criteria , e.g. remove some text 
from the the assessment I-D all designed to keep his own personal 
conclusion of the assessment process.
  The fact is that the assessment team was composed of volunteers. Their 
evaluation is similar to evaluating papers submitted to a conference by 
some anonymous referees. In such cases the acceptance/ rejection is made 
based on the marks given by the referees, so how come we ignore the 
marks? The marks are very consistent with the way the assessment team 
was selected and the assessment was conducted. So we argued that 
draft-renker must have been declared the worst based on these marks.
  How should the assessment team be formed otherwise? I think that the 
people with recognized expertise in IP Paging should have been consulted 
as they do in MIP WG. There are such people. These are the issues I 
wanted to discuss with Kempf when I asked him to call me or give his 
phone number so that I can call. He refused.
  IP Paging can not be equivalent to what Kempf knows of it, it is much 
more  than that.

Regards,

--behcet


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


From seamoby-admin@ietf.org  Thu Jan 17 14:06: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 OAA00614
	for ; Thu, 17 Jan 2002 14:06: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 NAA18048;
	Thu, 17 Jan 2002 13:54: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 NAA18015
	for ; Thu, 17 Jan 2002 13:54:56 -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 NAA00311
	for ; Thu, 17 Jan 2002 13:54:52 -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 KAA02740;
	Thu, 17 Jan 2002 10:54:22 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0HIsMY26519;
	Thu, 17 Jan 2002 10:54:22 -0800
X-mProtect:  Thu, 17 Jan 2002 10:54:22 -0800 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14160.americas.nokia.com (172.18.141.60, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdNvkn6s; Thu, 17 Jan 2002 10:54:20 PST
Message-ID: <3C471DD6.6090302@iprg.nokia.com>
Date: Thu, 17 Jan 2002 10:54:14 -0800
From: Cedric Westphal 
User-Agent: Mozilla/5.0 (Windows; U; Win98; 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: "Pat R. Calhoun" ,
        "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description
References:  <3C46FF96.6010606@iprg.nokia.com> <00f501c19f81$a767cd80$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,

my point was that there is no clear support either in favor of the decision
besides, I quote from you mail "in [your] judgement, the WG is satisfied 
with the decision".
The only claim to support this satisfaction is that, I paraphrase, 
'people are vocal on
this list, and would have said so if they disagreed' and the only 3 
voices (all against)
should not be counted as they are not many enough. Well, the argument 
could be
turned around, the same vocal people would have said so had they agreed.
As long as the WG is silent, I don't see why you should interprete this 
silence as
supporting your point of view, and not Behcet's.

 (for one, I have not given any opinion on whether or not draft-renker 
should be the design basis, not because I agree with you or Behcet, but 
because I don't have any opinion on this
specific question. I do feel wronged whenever I read that my silence 
supports either
side in this debate).

Cedric.



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


From seamoby-admin@ietf.org  Thu Jan 17 14:21: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 OAA01156
	for ; Thu, 17 Jan 2002 14:21: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 OAA19048;
	Thu, 17 Jan 2002 14:08: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 OAA19023
	for ; Thu, 17 Jan 2002 14:08:51 -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 OAA00729
	for ; Thu, 17 Jan 2002 14:08:47 -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 LAA04071;
	Thu, 17 Jan 2002 11:08:18 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0HJ8Hk18870;
	Thu, 17 Jan 2002 11:08:17 -0800
X-mProtect:  Thu, 17 Jan 2002 11:08:17 -0800 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdIsEucZ; Thu, 17 Jan 2002 11:08:15 PST
Message-ID: <3C47211F.3FDCC931@iprg.nokia.com>
Date: Thu, 17 Jan 2002 11:08:15 -0800
From: Vijay Devarapalli 
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Behcet Sarikaya 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description
References: <018c01c19ec7$6d761420$7e6015ac@T23KEMPF> <3C45E485.2010400@alcatel.com> <022701c19ed6$6646a3e0$7e6015ac@T23KEMPF> <3C4616E3.6060407@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,

You are quoting me out of context.... my comment was not about
the protocol assessment.

Vijay

Behcet Sarikaya wrote:
> 
> Several people not authors of proposals (Vijay, Rene) voiced their
> concern on the murky assessment, or am I wrong, or are you waiting for
> the sky to fall down?
> 
> To be on the positive side, we can offer Majordomo based mailing list
> support for the design team, if only with no WG draft.
> 
> Take it or leave it.
> 
> James Kempf wrote:
> 
> >
> >Any such decision is always subject to WG concensus.
> >Unfortunately, the only voice we are hearing on the mailing list
> >right now is yours. One voice isn't enough for concensus, nor
> >is text from a private email forwarded and posted apparently without the
> >author's permission. Goodness knows, we have enough vocal
> >people on this list. It took us a year to get CT requirements
> >done (and we still don't have them in IESG Last Call!) because
> >everybody had an opinion. If I were seeing some of these people, who
> >were not authors of competing proposals coming forward and
> >saying that we should change the decison, it would be another
> >matter.
> >
> >                    jak
> >
> 
> --
> 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 Jan 17 14:34: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 OAA02287
	for ; Thu, 17 Jan 2002 14:34: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 OAA19188;
	Thu, 17 Jan 2002 14:11: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 OAA19157
	for ; Thu, 17 Jan 2002 14:11: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 OAA00866
	for ; Thu, 17 Jan 2002 14:11:53 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0HJBJe02840;
	Thu, 17 Jan 2002 11:11:19 -0800 (PST)
Message-ID: <01b601c19f8a$85339ce0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" 
Cc: "Cedric Westphal" ,
        "Pat R. Calhoun" , 
References:  <3C46FF96.6010606@iprg.nokia.com> <00f501c19f81$a767cd80$7e6015ac@T23KEMPF> <3C4719E8.9080509@alcatel.com>
Subject: Re: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 11:09:43 -0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_01B3_01C19F47.77073520"
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
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_000_01B3_01C19F47.77073520
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Behcet,

>   The assessment for IP Paging was supposed to be announced at WG
> meeting in SLC. And it did. The minutes of this meeting contained
> strange text in paging part because the paging part talking or
> presentation was done by Kempf and the minutes was also taken by
Kempf.

This is incorrect. The minutes were taken by La Monte Henry Piggy
Yarroll.

> Kempf did the talking based on the slides, almost literally he was
> reading from the slides. The slides were not posted despite several
> repeated request that I made on the mailing list.

This is incorrect. As I stated in my reply to your email of yesterday,
the slides were sent to the IESG Secretariat on Monday, and
should appear shortly in the archives.

>   Because of the admitted irregularity, i.e. one draft was eliminated
by
> sparing no comments I declared the assessment results moot.
>   Kempf now wishes to correct this irregularity by adding an
additional
> text which includes his own comments and does not include other's
> comments, e.g. I made an assessment of draft-renker and no one seems
to
> have commented otherwise.

The only assessment I saw of yours about the current WG draft was
that it was "a mess." This is hardly enough to base a reevaluation of
the decision on.

>   Kempf wishes to keep adding some new criteria , e.g. remove some
text
> from the the assessment I-D all designed to keep his own personal
> conclusion of the assessment process.

Internet Drafts that are WG items are subject to review by the working
group and editing.
That is what the IETF is all about. This goes for every WG draft,
including
the current paging protocol WG draft :-). Some WG members have made
comments about the assessment draft, these need to be incorporated.

>   The fact is that the assessment team was composed of volunteers.
Their
> evaluation is similar to evaluating papers submitted to a conference
by
> some anonymous referees. In such cases the acceptance/ rejection is
made
> based on the marks given by the referees, so how come we ignore the
> marks?

Here you are way off base. This is a complete misinterpretation of what
the IETF is all about. The IETF is not an academic conference, despite
what many people these days seem to think. It is a standards body, and
the
decisions made will have great economic impact, that is why they need to
be weighed
and judged, and agreed upon by the entire WG. The assesment teams
results are subject to WG concensus like every other IETF decision.

> The marks are very consistent with the way the assessment team
> was selected and the assessment was conducted. So we argued that
> draft-renker must have been declared the worst based on these marks.
>   How should the assessment team be formed otherwise? I think that the
> people with recognized expertise in IP Paging should have been
consulted
> as they do in MIP WG. There are such people. These are the issues I
> wanted to discuss with Kempf when I asked him to call me or give his
> phone number so that I can call. He refused.
>   IP Paging can not be equivalent to what Kempf knows of it, it is
much
> more  than that.
>

Behcet, these are personal remarks and are completely out of order.
As I have explained three times within the past two days on email,
the decision to select the current WG draft was made by Pat
and myself, based on the assessment team's analysis and our
judgement. I did not act alone in this matter

Your remarks up until now, including your email from yesterday
(which I have attached with my responses), indicate to me that your
source of
discontent was based on the following two items:

1) Your unhappiness with the process. I posted some text
on that yesterday. Your comments indicated that there
was still some confusion about the ranking system,
so I've agreed with the suggestion of some other
WG members to remove the numerical ranking.

2) Your unhappiness that your draft was not
properly judged.

Do you have any further comment on 1? If not,
then I will make the changes to the assessment draft
that were suggested by the WG members
and yourself.

As for 2, well, what can I say? You know
the reasons why your proposal was rejected,
and I am really sorry that you are unhappy
about it, but I don't see a groundswell of
comment from other WG members recommending
we accept your proposal.

I've made every effort to be accommodating
and invite you to continue participating
in this process, yet you continue to
try to disrupt further progress. If you
are still unhappy, I suggest you file
a grievence action with the IESG and
leave the WG in peace so that we can get
about the business of working on the
Seamoby paging protocol!


            jak



------=_NextPart_000_01B3_01C19F47.77073520
Content-Type: message/rfc822;
	name="Re_ [Seamoby] Paging Protocol Decision Description.eml"
Content-Disposition: attachment;
	filename="Re_ [Seamoby] Paging Protocol Decision Description.eml"

Return-Path: 
Received: from mailhost.docomo-usa.com (closet.docomo-usa.com [172.21.96.232])
	by docomolabs-usa.com (8.11.3/8.11.3) with ESMTP id g0GMO8S22588;
	Wed, 16 Jan 2002 14:24:08 -0800 (PST)
Received: from optimus.ietf.org (ietf.org [132.151.1.19])
	by mailhost.docomo-usa.com (Postfix) with ESMTP
	id 70DA313608; Wed, 16 Jan 2002 14:24:07 -0800 (PST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20819;
	Wed, 16 Jan 2002 16:45: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 QAA20788
	for ; Wed, 16 Jan 2002 16:45:14 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21605
	for ; Wed, 16 Jan 2002 16:45:04 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0GLfxS20763;
	Wed, 16 Jan 2002 13:41:59 -0800 (PST)
Message-ID: <022701c19ed6$6646a3e0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Behcet Sarikaya" , 
References: <018c01c19ec7$6d761420$7e6015ac@T23KEMPF> <3C45E485.2010400@alcatel.com>
Subject: Re: [Seamoby] Paging Protocol Decision Description
Date: Wed, 16 Jan 2002 13:40:21 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
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
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
X-UIDL: 5c4cf1ad859a1d2fe43b4f050bf4c510
Content-Transfer-Encoding: 7bit

Behcet,

> 1. This text is not consistent with the minutes and the slides on
which
> your presentation was based at WG meeting in IETF 52.

The text I posted was my recollection, confirmed by Pat and
Allison, about the process we went through to make the decision.
There was a lot more detail than in my slides, because I wanted
to make sure that the authors of the proposals that were not
selected understood the decision process thoroughly. To the extent
that material from the slides was covered, I believe it is consistent.
For
example, the last paragraph cites a few examples of good
features in the various drafts that we would like to see in
the final result.Of those, only the security features from
draft-ohba were not on the slides, and that was an oversight
on my part, for which I apologize.

> 2. Regarding newly introduced comments on draft-guri, how come an
aspect
> that is good to have in the final draft becomes the reason for
rejection
> to select it?
>   Since you made no comments on draft-guri at SLC I could not raise
this
> question there, sorry about that :)

As I have told you before on this list, and as was stated in the
text I posted, draft-guri deals only with supporting L2 paging.
This is too limited to be the basis for the Seamoby IP paging protocol.
The text states that we want to see the ideas in draft-guri incorporated
into the final Seamoby protocol, and, as I have also told you before
on this list, we are working on
trying to organize a L2 Triggers BOF in Minneapolis so we can
discuss the kind of L2 triggers that are discussed on page 6 of
draft-guri. Seamoby is not the right place for this kind of work,
but we are trying to get one set up, and the L2 triggers work
for paging in draft-guri could be an important contribution. If, of
course,
you decide to participate.

> 3. The comments on hmipv6 belong to you personally, please check the
> slides on WG document status of MIP WG, you should be able to see the
> official opinion of WG chairs of MIP WG. I think that it is a serious
> problem to state strong opinions on the business of other WGs
especially
> if they are flawed.
>

I don't understand this comment. There is currently a draft,
draft-ietf-mobileip-lmm-requirements-00.txt, in the MIP
WG that outline requirements for an LMM solution. This
draft has not yet gone through WG Last Call, nor through
IETF Last Call, and so it does not yet have an RFC number.
That means that LMM is not yet out of the requirements phase.
This is what I said. We can't base the Seamoby paging
protocol on a protocol in another WG that isn't yet out
of requirements phase. The other WG might go through
the same kind of requirements assessment process for
competing protocols we've gone through
and come up with another protocol instead of HMIPv6
as the selected LMM protocol. Where would that leave
us?


> 4. The text does not mention the simple sum of the marks given to each
> draft?
>

A simple sum shows nothing. How should one rate under- versus
over-specification? In some cases, underspecification can be
a good thing, in other cases not. Same with overspecification.

In retrospect, I see now that putting numbers on these was a mistake.
It led people to believe that one could simply sum the numbers
and come up with a decision. Unfortunately, it was not so easy.
You can be assured that I will never use that technique again.

>   In short this text adds to the controversy failing to resolve
> anything.Regardless of what people say the conclusion is not going to
> change, right? Then why ask opinion of WG members? Is this normal? I
do
> not think such a system can be maintained.
>
>

Any such decision is always subject to WG concensus.
Unfortunately, the only voice we are hearing on the mailing list
right now is yours. One voice isn't enough for concensus, nor
is text from a private email forwarded and posted apparently without the
author's permission. Goodness knows, we have enough vocal
people on this list. It took us a year to get CT requirements
done (and we still don't have them in IESG Last Call!) because
everybody had an opinion. If I were seeing some of these people, who
were not authors of competing proposals coming forward and
saying that we should change the decison, it would be another
matter.

                    jak


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

------=_NextPart_000_01B3_01C19F47.77073520--


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


From seamoby-admin@ietf.org  Thu Jan 17 14:37: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 OAA02895
	for ; Thu, 17 Jan 2002 14:37: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 OAA19577;
	Thu, 17 Jan 2002 14:20: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 OAA19547
	for ; Thu, 17 Jan 2002 14:20:20 -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 OAA01126
	for ; Thu, 17 Jan 2002 14:20:17 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0HJJme03302;
	Thu, 17 Jan 2002 11:19:48 -0800 (PST)
Message-ID: <01ee01c19f8b$b49d4200$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Cc: , "Allison Mankin" 
Date: Thu, 17 Jan 2002 11:18:12 -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] Concensus Call:Reaching Closure on Paging Decision
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

All,

Pat and I made a selection for what to start with, not what to end with.
The WG will determine what the final technology looks like.

1) If you want to support or disagree with the selection of the starting
 ID, say so now please.

2) If there is not consensus that we should re-open the selection phase,
then we will move forward based on the selection in the next few days.

Thanx.

            jak





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


From seamoby-admin@ietf.org  Thu Jan 17 14:53: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 OAA04920
	for ; Thu, 17 Jan 2002 14:53: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 OAA20506;
	Thu, 17 Jan 2002 14:38: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 OAA20467
	for ; Thu, 17 Jan 2002 14:38:05 -0500 (EST)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02957
	for ; Thu, 17 Jan 2002 14:38:01 -0500 (EST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA12417 for ; Thu, 17 Jan 2002 12:27:49 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA11312 for ; Thu, 17 Jan 2002 12:38:01 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52)
	id ; Thu, 17 Jan 2002 13:38:00 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FD8C@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'Cedric Westphal'" ,
        "Pat R. Calhoun"
	 
Cc: "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 13:38:00 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F8E.79092760"
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_01C19F8E.79092760
Content-Type: text/plain

I hope I am not offending anyone, personally I don't care about paging, with
that
said:
I agree with Cedric here, In a true democracy, you count what inside the 
ballot box, and don't assume that the rest of the population that did not
vote (excuse the word) is in either side's favor. 
If a consensus is to take place, it should be announced and then the result
should be based on on whoever voices his opinion, not based on the silent 
audience.
 
I am just trying to learn something from of all this, for other work items 
 
Madjid

-----Original Message-----
From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
Sent: Thursday, January 17, 2002 10:45 AM
To: Pat R. Calhoun
Cc: 'Behcet Sarikaya'; seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description


Pat,

Pat R. Calhoun wrote:



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

Behcet,

The process, to which I provided you a pointer a few days ago,
clearly states that folks express their opinion on the list. Jim and
I will not read other mailing list archives to determine roush
consensus. The seamoby list is the only one we can use to gauge
consensus.

Again, as Jim clearly stated, the only objection we are seeing right
now is yours (although you claim two other people did, and 3 is still
short of rough consensus for a list that has 499 members). If we
guaged there was rough consensus on this issue, then we would most
certainly act.

First, I have not followed the debate. However, I find unacceptable
that you would tell Behcet not to voice his opinion because he is the
only one doing so. How do you get
to the conclusion that the roughly 495 who are not participating in this
debate agree with you (and not Behcet) just because they shut up?
Can you point to one debate where the rough consensus was reached
by way of more than 250 favorable opinions? I have seen proposals on
this list (say car discovery reqs, for instance) decided by 2 people in
favor,
one against. For any outcome here to make sense, shouldn't the definition
of rough consensus be consistent?

Cedric.





Our primary concern at this time is to get the work completed and
achieve our milestones. So how about we get to work and put this
behind us.

PatC

- -----Original Message-----
From: Behcet Sarikaya [  
mailto:behcet.sarikaya@alcatel.com ] 
Sent: Wednesday, January 16, 2002 4:12 PM
To: seamoby@ietf.org  
Subject: Re: [Seamoby] Paging Protocol Decision Description


Several people not authors of proposals (Vijay, Rene) voiced their 
concern on the murky assessment, or am I wrong, or are you waiting
for  
the sky to fall down?

To be on the positive side, we can offer Majordomo based mailing list
support for the design team, if only with no WG draft.

Take it or leave it.

James Kempf wrote:

>
>Any such decision is always subject to WG concensus. Unfortunately,
>the  only voice we are hearing on the mailing list right now is
>yours. One  voice isn't enough for concensus, nor is text from a
>private email 
>forwarded and posted apparently without the author's permission. 
>Goodness knows, we have enough vocal people on this list. It took us
>a  year to get CT requirements done (and we still don't have them in
>IESG  Last Call!) because everybody had an opinion. If I were seeing
>some of  these people, who were not authors of competing proposals
>coming 
>forward and saying that we should change the decison, it would be 
>another matter.
>
>                    jak
>

- -- 
Behcet 




_______________________________________________
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/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNkr
5WxMNRzg0Qv02oder+oZzLGR
=GIVv
-----END PGP SIGNATURE-----



------_=_NextPart_001_01C19F8E.79092760
Content-Type: text/html




RE: [Seamoby] Paging Protocol Decision Description




I hope 
I am not offending anyone, personally I don't care about paging, with 
that


said:


I 
agree with Cedric here, In a true democracy, you count what inside the 



ballot 
box, and don't assume that the rest of the population that did 
not


vote 
(excuse the word) is in either side's favor. 


If a 
consensus is to take place, it should be announced and then the 
result


should 
be based on on whoever voices his opinion, not based on the silent 



audience.


 


I am 
just trying to learn something from of all this, for other work items 



 


Madjid



  
-----Original Message-----
From: Cedric Westphal 
  [mailto:cedric@iprg.nokia.com]
Sent: Thursday, January 17, 2002 
  10:45 AM
To: Pat R. Calhoun
Cc: 'Behcet Sarikaya'; 
  seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision 
  Description

Pat,

Pat R. Calhoun wrote:

  

    
    

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

    
Behcet,

    
The process, to which I provided you a pointer a few days 
    ago,
clearly states that folks express their opinion 
    on the list. Jim and
I will not read other mailing 
    list archives to determine roush
consensus. The 
    seamoby list is the only one we can use to gauge
consensus.

    
Again, as Jim clearly stated, the only objection we are 
    seeing right
now is yours (although you claim two 
    other people did, and 3 is still
short of rough 
    consensus for a list that has 499 members). If we
guaged there was rough consensus on this issue, then we would 
    most
certainly act.
First, I 
  have not followed the debate. However, I find unacceptable
that you would 
  tell Behcet not to voice his opinion because he is the
only one doing so. 
  How do you get
to the conclusion that the roughly 495 who are not 
  participating in this
debate agree with you (and not Behcet) just because 
  they shut up?
Can you point to one debate where the rough consensus was 
  reached
by way of more than 250 favorable opinions? I have seen proposals 
  on
this list (say car discovery reqs, for instance) decided by 2 people in 
  favor,
one against. For any outcome here to make sense, shouldn't the 
  definition
of rough consensus be consistent?

Cedric.

  

    


  

    
Our primary concern at this time is to get the work 
    completed and
achieve our milestones. So how about we 
    get to work and put this
behind us.

    
PatC

    
- -----Original Message-----
From: 
    Behcet Sarikaya [ 
    mailto:behcet.sarikaya@alcatel.com ] 
Sent: 
    Wednesday, January 16, 2002 4:12 PM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision 
    Description


    
Several people not authors of proposals (Vijay, Rene) voiced 
    their 
concern on the murky assessment, or am I 
    wrong, or are you waiting
for  
the sky to fall down?

    
To be on the positive side, we can offer Majordomo based 
    mailing list
support for the design team, if only 
    with no WG draft.

    
Take it or leave it.

    
James Kempf wrote:

    
>
>Any such decision is always 
    subject to WG concensus. Unfortunately,
>the  
    only voice we are hearing on the mailing list right now is
>yours. One  voice isn't enough for concensus, nor is text 
    from a
>private email 
>forwarded and posted apparently without the author's permission. 
    
>Goodness knows, we have enough vocal people on 
    this list. It took us
>a  year to get CT 
    requirements done (and we still don't have them in
>IESG  Last Call!) because everybody had an opinion. If I 
    were seeing
>some of  these people, who were 
    not authors of competing proposals
>coming 
    
>forward and saying that we should change the 
    decison, it would be 
>another 
    matter.
>
>                    
    jak
>

    
- -- 
Behcet 




    
_______________________________________________
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/AwUBPEbuLjN1fXKoxmisEQJfYwCg+H6m+Uo6ly00ONoyYOFLLtGLGbgAoNkr
5WxMNRzg0Qv02oder+oZzLGR
=GIVv
-----END PGP 
SIGNATURE-----



------_=_NextPart_001_01C19F8E.79092760--

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


From seamoby-admin@ietf.org  Thu Jan 17 14:55: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 OAA05194
	for ; Thu, 17 Jan 2002 14:55: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 OAA20798;
	Thu, 17 Jan 2002 14:44: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 OAA20771
	for ; Thu, 17 Jan 2002 14:44:21 -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 OAA04520
	for ; Thu, 17 Jan 2002 14:44:18 -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 LAA07089;
	Thu, 17 Jan 2002 11:43:49 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0HJhmp16104;
	Thu, 17 Jan 2002 11:43:48 -0800
X-mProtect:  Thu, 17 Jan 2002 11:43:48 -0800 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdjlMBIJ; Thu, 17 Jan 2002 11:43:47 PST
Message-ID: <3C472973.7A523D53@iprg.nokia.com>
Date: Thu, 17 Jan 2002 11:43:47 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: "Hesham Soliman (ERA)" ,
        "'Pat R. Calhoun'" ,
        "'Cedric Westphal'" ,
        "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description
References: <4DA6EA82906FD511BE2F00508BCF053801C4C21A@Esealnt861.al.sw.ericsson.se> <011001c19f82$1ebd1e80$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 and Pat,

it seems like

a) pick a candidate first and then ask WG for consensus (excluding the
authors of submissions) against it
as opposed to
b) present results from assessment team and ask the WG what to do
is causing confusion and consternation. a) is seems to be especially
controversial because WG co-chairs picked a candidate superseeding (for
whatever seemingly justifiable reason(s)) the assessment process which
all submissions earnestly followed. I would have opted to do b), even
with the milestone pressure.

You might want to try
c) allow each submission to pick a candidate from the set not including
their own.
    (I don't know how to break a tie if any; others may have comments)

By having the larger, active folks involved in resolving the
"indeterminate" result from the assessment team, the process can be made
more transparent and perhaps more acceptable.

Regards,

-Rajeev







James Kempf wrote:

> Hesham,
>
> You are right. The numbering system was an experiment
> that didn't work. It was meant to help the assessment
> team, it only served to confuse the issue.
>
> I will take the actual numbers out of the draft
> and substitute a nonnumeric indication
> of the status of the draft on particular
> requirements.
>
>             jak
>
> --
> -- Original Message -----
> From: "Hesham Soliman (ERA)" 
> To: "'Pat R. Calhoun'" ; "'Cedric
> Westphal'" 
> Cc: "'Behcet Sarikaya'" ;
> 
> Sent: Thursday, January 17, 2002 9:20 AM
> Subject: RE: [Seamoby] Paging Protocol Decision Description
>
> > I don't want to take sides here since I'm not following
> > the paging proposals and do not have an opinion on
> > proposal X vs proposal Y, but really why are you having a numbering
> > system if you're not going to follow it ????
> > What's the point of these numbers anyway if they are
> > (obviously) based on different criteria from those that
> > the 'winning' protocol is assessed on ?
> >
> > Seems very strange.
> >
> > Hesham
> >
>
> _______________________________________________
> 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 Jan 17 14:59: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 OAA05857
	for ; Thu, 17 Jan 2002 14:59: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 OAA20946;
	Thu, 17 Jan 2002 14:48: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 OAA20914
	for ; Thu, 17 Jan 2002 14:48:47 -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 OAA04618
	for ; Thu, 17 Jan 2002 14:48:44 -0500 (EST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA05694 for ; Thu, 17 Jan 2002 12:48:46 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA29200 for ; Thu, 17 Jan 2002 12:37:55 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52)
	id ; Thu, 17 Jan 2002 13:48:45 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FD8D@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'James Kempf'" , seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 13:48:43 -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

James,

I have an issue with this process. 
You said that one of the drafts was rejected because it had
a dependency on a document that is under assessment in Mobile IP.

I guess this is new, on one hand we are saying that are
protocols needs to be interoperable, on the other hand we are
dismissing solutions that have interdependency:
This means that we need to wait for the solutions in other groups to 
become RFCs and then try to work them into our proposals? Aren't we
introducing a significant dead time here?

Can we set up or debate what the rules are here?

Thanks,

Madjid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Wednesday, January 16, 2002 1:53 PM
To: seamoby@ietf.org
Subject: [Seamoby] Paging Protocol Decision Description


As promised, here is a description of the decision process used to
select the Seamoby paging protocol. After discussion and
editing based on WG feedback, this will be incorporated into
draft-ietf-seamoby-paging-protocol-assessment-00.txt.

Comments please.

            jak

------------------------------------------------------------------------
------------------------------------------
Assessment and Decision Process

The assessment team spent three weeks reading through the protocol
proposals.
Each team member was assigned a proposal for assessment, with the
exception
of draft-sarikaya and draft-guri, which were both assigned to
one team member because not enough people volunteered. Each team member
wrote up the results of their assessment, and submitted it to
the assessment draft editor for assembly into this draft. A
teleconference
was held to discuss the assessments and normalize assessments between
different team members. The assessment team did not make a
recommendation
about which draft to pick; however, the team did recommend that the next
step should be to either go through another round of design in which the
authors would attempt to refine their proposals, or to immediately begin
the
process of harmonizing the protocols to come up with a working group
draft.

Given that the assessment team's recommendation about which draft to
accept
was indeterminate, a decision team was formed by the two Working Group
co-chairs, with the Area Director providing advice. The decision team
decided
to proceed toward selecting a draft as the basis of a harmonized
protocol, in
order to avoid further delay in starting on the process of desiging the
Seamoby paging protocol.

The decision about which draft to select was difficult, because each
draft
had particular aspects that were well thought out and recommended
themselves for inclusion in the final result, but none of the drafts
exhibited
the maturity of implementation and design that immediately suggested it
as
the only possible candidate for selection. Some drafts had particular
aspects
that mitigated strongly against selection. A good example of this
difficulty
is Requirement 4.6, Multiple Dormant Modes. This requirement was
intended to
foster support for hosts that have no explicit L2 paging support,
basically
time-slotted paging. Draft-sarikaya has an excellent discussion of
time-slotted paging mode, but the basis of that draft is a protocol
(HMIPv6)
that has been proposed in another working group for a problem that is
still
in the requirements phase. The other proposals had varying degrees
of support for time-slotted paging, but none was sufficient to recommend
itself on this particular requirement.

The assessment team's work allowed the decision team to reduce the
number of drafts under consideration from five to two. The decision team
quickly decided to rule out draft-koodli because the draft is lacking in
specifics and is vague on many requirements, as mentioned in the
assessment
team's report. 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. Also, draft-sarikaya exclusively supports
Mobile IPv6, and a primary requirement of all Seamoby work is that the
protocols be independent of mobility protocol. 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. However, the ideas expressed in draft-guri were
felt
to be valuable and necessary for including in the final Seamoby paging
protocol for those cases where Layer 2 paging support is available.

The decision between the remaining two drafts, draft-renker and
draft-ohba,
was especially difficult because they were judged to be about of equal
quality. The decision team decided to focus on three primary
requirements
that were thought to be crucial to the successful acceptance of IP
paging:
independence of mobility protocol, support for existing mobility
protocols,
and independence of paging area from subnet topology.

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. Draft-renker was judged by the assessment team to
be overspecific in these areas, in the sense that it contained two
modes,
explicit mode and implicit mode, depending on whether Mobile IP was
supported
or not. However, considering the relatively immature state of the paging
protocol design, the decision team felt that providing the working group
with choices, where the benefits and drawbacks of each choice could be
clearly weighed, was preferable to providing a fixed decision, so
draft-renker was judged to be better in this regard.

On the requirement for independence of paging area from subnet topology,
the
support described in draft-ohba was very sketchy and did not provide
the decision team with a clear idea about how this could be achieved,
particularly with regard to the movement of a mobile host while the host
is
in dormant mode. Draft-renker has a much clearer description of how this
could
be achieved, and was judged to be better in this regard.

Additional aspects of draft-renker that recommended it as the selection
were attention to details of interaction with existing IP
routing, and a survey of paging strategies. While probably not essential
to
the final protocol design, the material on paging strategies showed
that the authors had given some thought to separating policy from
mechanism,
and were familiar with the somewhat extensive academic
literature on paging, and IP paging in particular.

While draft-renker was selected by the decision team as the basis for
continued Seamoby paging protocol work, the decision team feels that it
is
important to incorporate the outstanding contributions of the other
authors
into the final protocol design, in particular, the time-slotted paging
discussion in draft-sarikaya, the Layer 2 interface work in draft-guri,
the
paging state machine discussion in draft-koodli, and the security
protocol
work in draft-ohba. Additional aspects of the other drafts that address
issues which were weakly addressed or not addressed at all in
draft-renker
should also be incorporated, as well as ideas from other working group
members that address requirement which none of the draft addressed
particularly
well.







_______________________________________________
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 Jan 17 15:10: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 PAA06928
	for ; Thu, 17 Jan 2002 15:10: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 OAA21249;
	Thu, 17 Jan 2002 14:58: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 OAA21223
	for ; Thu, 17 Jan 2002 14:58:55 -0500 (EST)
Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05728
	for ; Thu, 17 Jan 2002 14:58:51 -0500 (EST)
Received: from ee.ryerson.ca ([172.16.30.72])
	by eccles.ee.ryerson.ca (8.11.1/8.11.1) with ESMTP id g0HJwEr25622;
	Thu, 17 Jan 2002 14:58:14 -0500
Message-ID: <3C472CD8.5000604@ee.ryerson.ca>
Date: Thu, 17 Jan 2002 14:58:16 -0500
From: Muhammad Jaseemuddin 
Organization: Ryerson University
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Cedric Westphal 
CC: James Kempf ,
        "Pat R. Calhoun" ,
        "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description
References:  <3C46FF96.6010606@iprg.nokia.com> <00f501c19f81$a767cd80$7e6015ac@T23KEMPF> <3C471DD6.6090302@iprg.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

Cedric,

Cedric Westphal wrote:

> Jim,
>
> my point was that there is no clear support either in favor of the 
> decision
> besides, I quote from you mail "in [your] judgement, the WG is 
> satisfied with the decision".
> The only claim to support this satisfaction is that, I paraphrase, 
> 'people are vocal on
> this list, and would have said so if they disagreed' and the only 3 
> voices (all against)
> should not be counted as they are not many enough. Well, the argument 
> could be
> turned around, the same vocal people would have said so had they agreed.
> As long as the WG is silent, I don't see why you should interprete 
> this silence as
> supporting your point of view, and not Behcet's.
>
> (for one, I have not given any opinion on whether or not draft-renker 
> should be the design basis, not because I agree with you or Behcet, 
> but because I don't have any opinion on this
> specific question. I do feel wronged whenever I read that my silence 
> supports either
> side in this debate).
>
> Cedric.

I am also in your situation sharing your concern. The silence of great 
majoroity is interpreted by WG cochair as siding his opinion, which is 
not necessarily the case. Jim himself agreed in the previous email, and 
I copied below:

'That the process around the decision to select the WG draft was
murky. Others have made this
comment as well, and I agreed, several times in fact, that this was the
case.'

that the process was murky, then why the decision is being made in haste. We should work to resolve Behcet's concern. It is also quite mind boggling for me that a point-based evaluation criterion was designed by the one who is declairing that it 'miserably failed'. This also shows that Bechcet has a right to get a satisfactory answer.

- Muhammad Jaseemuddin


>
>
>
> _______________________________________________
> 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 Jan 17 15: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 PAA12027
	for ; Thu, 17 Jan 2002 15:39: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 PAA22585;
	Thu, 17 Jan 2002 15:27: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 PAA22555
	for ; Thu, 17 Jan 2002 15:27:28 -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 PAA08608
	for ; Thu, 17 Jan 2002 15:27:23 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA28253;
	Thu, 17 Jan 2002 14:26:54 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g0HKQrr25226;
	Thu, 17 Jan 2002 14:26:53 -0600 (CST)
Message-ID: <3C47337E.6080409@alcatel.com>
Date: Thu, 17 Jan 2002 14:26:38 -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: Vijay Devarapalli 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description
References: <018c01c19ec7$6d761420$7e6015ac@T23KEMPF> <3C45E485.2010400@alcatel.com> <022701c19ed6$6646a3e0$7e6015ac@T23KEMPF> <3C4616E3.6060407@alcatel.com> <3C47211F.3FDCC931@iprg.nokia.com>
Content-Type: multipart/alternative;
 boundary="------------000402040402070607050707"
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


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

Vijay,
  Really? Let me copy your email you sent on Jan. 14 :

>Hi Jim,
>
>just one comment.
>
>James Kempf wrote:
>
>>> 
>>>  Behcet,
>>> 
>>> Up until now, the only people who have expressed
>>> an opinion about the paging protocol decision were authors of protocols
>>> that
>>> were not selected. One could, quite frankly, view this as "sour grapes"
>>> on their part for not having been selected. However,
>>
>
>People spend a lot of their time to come up with proposals.
>and they also hope that their proposal goes somewhere in the
>WG. and when the protocol assessment turns out to be murky
>and they complain, I dont think it is right to call them 
>"sour grapes".
>
>Vijay
>
Was this not Vijay Devarapalli? If  not then my apologies.

>
>


Vijay Devarapalli wrote:

>Behcet,
>
>You are quoting me out of context.... my comment was not about
>the protocol assessment.
>
>Vijay
>
>Behcet Sarikaya wrote:
>
>>Several people not authors of proposals (Vijay, Rene) voiced their
>>concern on the murky assessment, or am I wrong, or are you waiting for
>>the sky to fall down?
>>
>>To be on the positive side, we can offer Majordomo based mailing list
>>support for the design team, if only with no WG draft.
>>
>>Take it or leave it.
>>
>>James Kempf wrote:
>>
>>>Any such decision is always subject to WG concensus.
>>>Unfortunately, the only voice we are hearing on the mailing list
>>>right now is yours. One voice isn't enough for concensus, nor
>>>is text from a private email forwarded and posted apparently without the
>>>author's permission. Goodness knows, we have enough vocal
>>>people on this list. It took us a year to get CT requirements
>>>done (and we still don't have them in IESG Last Call!) because
>>>everybody had an opinion. If I were seeing some of these people, who
>>>were not authors of competing proposals coming forward and
>>>saying that we should change the decison, it would be another
>>>matter.
>>>
>>>                   jak
>>>
>>--
>>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
>

-- 
Behcet 



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





Vijay,

  Really? Let me copy your email you sent on Jan. 14 :



  
Hi Jim,

just one comment.

James Kempf wrote:

  

    
> 
>  Behcet,
> 
> Up until now, the only people who have expressed
> an opinion about the paging protocol decision were authors of protocols
> that
> were not selected. One could, quite frankly, view this as "sour grapes"
> on their part for not having been selected. However,

    

    

People spend a lot of their time to come up with proposals.
and they also hope that their proposal goes somewhere in the
WG. and when the protocol assessment turns out to be murky
and they complain, I dont think it is right to call them 
"sour grapes".

Vijay

    

Was this not Vijay Devarapalli? If  not then my apologies.

    

      



      

      

      

Vijay Devarapalli wrote:

      

        
Behcet,

You are quoting me out of context.... my comment was not about
the protocol assessment.

Vijay

Behcet Sarikaya wrote:

        

          
Several people not authors of proposals (Vijay, Rene) voiced their
concern on the murky assessment, or am I wrong, or are you waiting for
the sky to fall down?

To be on the positive side, we can offer Majordomo based mailing list
support for the design team, if only with no WG draft.

Take it or leave it.

James Kempf wrote:


          

            
Any such decision is always subject to WG concensus.
Unfortunately, the only voice we are hearing on the mailing list
right now is yours. One voice isn't enough for concensus, nor
is text from a private email forwarded and posted apparently without the
author's permission. Goodness knows, we have enough vocal
people on this list. It took us a year to get CT requirements
done (and we still don't have them in IESG Last Call!) because
everybody had an opinion. If I were seeing some of these people, who
were not authors of competing proposals coming forward and
saying that we should change the decison, it would be another
matter.

                   jak


            

            
--
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

            

            

            
-- 
Behcet 

            

            
            

--------------000402040402070607050707--


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


From seamoby-admin@ietf.org  Thu Jan 17 16:01: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 QAA12694
	for ; Thu, 17 Jan 2002 16:01: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 PAA23520;
	Thu, 17 Jan 2002 15:45: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 PAA23489
	for ; Thu, 17 Jan 2002 15:45:33 -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 PAA12212
	for ; Thu, 17 Jan 2002 15:45:29 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA01094;
	Thu, 17 Jan 2002 14:45:01 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g0HKj1r29074;
	Thu, 17 Jan 2002 14:45:01 -0600 (CST)
Message-ID: <3C4737BD.6030608@alcatel.com>
Date: Thu, 17 Jan 2002 14:44:45 -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: Rajeev Koodli 
CC: James Kempf ,
        "Hesham Soliman (ERA)" ,
        "'Pat R. Calhoun'" ,
        "'Cedric Westphal'" , seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description
References: <4DA6EA82906FD511BE2F00508BCF053801C4C21A@Esealnt861.al.sw.ericsson.se> <011001c19f82$1ebd1e80$7e6015ac@T23KEMPF> <3C472973.7A523D53@iprg.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 Rajeev,
  There is already a positive and workable proposal:
let's have a design team open or closed whose work to be surveyed by WG 
chairs and ADs to design the protocol. We offered hosting the mailing 
list for this team.
I solicit your support to this.

Rajeev Koodli wrote:

>
>James and Pat,
>
>it seems like
>
>a) pick a candidate first and then ask WG for consensus (excluding the
>authors of submissions) against it
>as opposed to
>b) present results from assessment team and ask the WG what to do
>is causing confusion and consternation. a) is seems to be especially
>controversial because WG co-chairs picked a candidate superseeding (for
>whatever seemingly justifiable reason(s)) the assessment process which
>all submissions earnestly followed. I would have opted to do b), even
>with the milestone pressure.
>
>You might want to try
>c) allow each submission to pick a candidate from the set not including
>their own.
>    (I don't know how to break a tie if any; others may have comments)
>
>By having the larger, active folks involved in resolving the
>"indeterminate" result from the assessment team, the process can be made
>more transparent and perhaps more acceptable.
>
>Regards,
>
>-Rajeev
>
>
>
--behcet

>



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


From seamoby-admin@ietf.org  Thu Jan 17 16:37: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 QAA13706
	for ; Thu, 17 Jan 2002 16:37: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 QAA24899;
	Thu, 17 Jan 2002 16:23: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 QAA24859
	for ; Thu, 17 Jan 2002 16:23: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 QAA13298
	for ; Thu, 17 Jan 2002 16:23:35 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0HLN6e08766;
	Thu, 17 Jan 2002 13:23:06 -0800 (PST)
Message-ID: <020e01c19f9c$edc9e270$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Nakhjiri Madjid-MNAKHJI1" ,
        
References: <35DBB8B7AC89D4118E98009027B1009B0464FD8D@IL27EXM10.cig.mot.com>
Subject: Re: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 13:21:29 -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

Majhid,

That was only one consideration. Another was that it did not meet
the requirement of not being dependent on a specific
mobility protocol.

If you have an opinion on about whether we should re-open
the selection phase, please post it under the thread I
opened this morning.

Thanx.


            jak

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" 
To: "'James Kempf'" ; 
Sent: Thursday, January 17, 2002 11:48 AM
Subject: RE: [Seamoby] Paging Protocol Decision Description


> James,
>
> I have an issue with this process.
> You said that one of the drafts was rejected because it had
> a dependency on a document that is under assessment in Mobile IP.
>
> I guess this is new, on one hand we are saying that are
> protocols needs to be interoperable, on the other hand we are
> dismissing solutions that have interdependency:
> This means that we need to wait for the solutions in other groups to
> become RFCs and then try to work them into our proposals? Aren't we
> introducing a significant dead time here?
>
> Can we set up or debate what the rules are here?
>
> Thanks,
>
> Madjid
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Wednesday, January 16, 2002 1:53 PM
> To: seamoby@ietf.org
> Subject: [Seamoby] Paging Protocol Decision Description
>
>
> As promised, here is a description of the decision process used to
> select the Seamoby paging protocol. After discussion and
> editing based on WG feedback, this will be incorporated into
> draft-ietf-seamoby-paging-protocol-assessment-00.txt.
>
> Comments please.
>
>             jak
>
> ----------------------------------------------------------------------
--
> ------------------------------------------
> Assessment and Decision Process
>
> The assessment team spent three weeks reading through the protocol
> proposals.
> Each team member was assigned a proposal for assessment, with the
> exception
> of draft-sarikaya and draft-guri, which were both assigned to
> one team member because not enough people volunteered. Each team
member
> wrote up the results of their assessment, and submitted it to
> the assessment draft editor for assembly into this draft. A
> teleconference
> was held to discuss the assessments and normalize assessments between
> different team members. The assessment team did not make a
> recommendation
> about which draft to pick; however, the team did recommend that the
next
> step should be to either go through another round of design in which
the
> authors would attempt to refine their proposals, or to immediately
begin
> the
> process of harmonizing the protocols to come up with a working group
> draft.
>
> Given that the assessment team's recommendation about which draft to
> accept
> was indeterminate, a decision team was formed by the two Working Group
> co-chairs, with the Area Director providing advice. The decision team
> decided
> to proceed toward selecting a draft as the basis of a harmonized
> protocol, in
> order to avoid further delay in starting on the process of desiging
the
> Seamoby paging protocol.
>
> The decision about which draft to select was difficult, because each
> draft
> had particular aspects that were well thought out and recommended
> themselves for inclusion in the final result, but none of the drafts
> exhibited
> the maturity of implementation and design that immediately suggested
it
> as
> the only possible candidate for selection. Some drafts had particular
> aspects
> that mitigated strongly against selection. A good example of this
> difficulty
> is Requirement 4.6, Multiple Dormant Modes. This requirement was
> intended to
> foster support for hosts that have no explicit L2 paging support,
> basically
> time-slotted paging. Draft-sarikaya has an excellent discussion of
> time-slotted paging mode, but the basis of that draft is a protocol
> (HMIPv6)
> that has been proposed in another working group for a problem that is
> still
> in the requirements phase. The other proposals had varying degrees
> of support for time-slotted paging, but none was sufficient to
recommend
> itself on this particular requirement.
>
> The assessment team's work allowed the decision team to reduce the
> number of drafts under consideration from five to two. The decision
team
> quickly decided to rule out draft-koodli because the draft is lacking
in
> specifics and is vague on many requirements, as mentioned in the
> assessment
> team's report. 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. Also, draft-sarikaya exclusively
supports
> Mobile IPv6, and a primary requirement of all Seamoby work is that the
> protocols be independent of mobility protocol. 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. However, the ideas expressed in draft-guri
were
> felt
> to be valuable and necessary for including in the final Seamoby paging
> protocol for those cases where Layer 2 paging support is available.
>
> The decision between the remaining two drafts, draft-renker and
> draft-ohba,
> was especially difficult because they were judged to be about of equal
> quality. The decision team decided to focus on three primary
> requirements
> that were thought to be crucial to the successful acceptance of IP
> paging:
> independence of mobility protocol, support for existing mobility
> protocols,
> and independence of paging area from subnet topology.
>
> 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. Draft-renker was judged by the assessment team to
> be overspecific in these areas, in the sense that it contained two
> modes,
> explicit mode and implicit mode, depending on whether Mobile IP was
> supported
> or not. However, considering the relatively immature state of the
paging
> protocol design, the decision team felt that providing the working
group
> with choices, where the benefits and drawbacks of each choice could be
> clearly weighed, was preferable to providing a fixed decision, so
> draft-renker was judged to be better in this regard.
>
> On the requirement for independence of paging area from subnet
topology,
> the
> support described in draft-ohba was very sketchy and did not provide
> the decision team with a clear idea about how this could be achieved,
> particularly with regard to the movement of a mobile host while the
host
> is
> in dormant mode. Draft-renker has a much clearer description of how
this
> could
> be achieved, and was judged to be better in this regard.
>
> Additional aspects of draft-renker that recommended it as the
selection
> were attention to details of interaction with existing IP
> routing, and a survey of paging strategies. While probably not
essential
> to
> the final protocol design, the material on paging strategies showed
> that the authors had given some thought to separating policy from
> mechanism,
> and were familiar with the somewhat extensive academic
> literature on paging, and IP paging in particular.
>
> While draft-renker was selected by the decision team as the basis for
> continued Seamoby paging protocol work, the decision team feels that
it
> is
> important to incorporate the outstanding contributions of the other
> authors
> into the final protocol design, in particular, the time-slotted paging
> discussion in draft-sarikaya, the Layer 2 interface work in
draft-guri,
> the
> paging state machine discussion in draft-koodli, and the security
> protocol
> work in draft-ohba. Additional aspects of the other drafts that
address
> issues which were weakly addressed or not addressed at all in
> draft-renker
> should also be incorporated, as well as ideas from other working group
> members that address requirement which none of the draft addressed
> particularly
> well.
>
>
>
>
>
>
>
> _______________________________________________
> 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 Jan 17 17: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 RAA14263
	for ; Thu, 17 Jan 2002 17: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 QAA26041;
	Thu, 17 Jan 2002 16:51: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 QAA26013
	for ; Thu, 17 Jan 2002 16:51:37 -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 QAA14018
	for ; Thu, 17 Jan 2002 16:51:31 -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 NAA15451;
	Thu, 17 Jan 2002 13:51:02 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0HLp2w22693;
	Thu, 17 Jan 2002 13:51:02 -0800
X-mProtect:  Thu, 17 Jan 2002 13:51:02 -0800 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd4qJaEz; Thu, 17 Jan 2002 13:50:50 PST
Message-ID: <3C47471D.F6EA7A1@iprg.nokia.com>
Date: Thu, 17 Jan 2002 13:50:21 -0800
From: Vijay Devarapalli 
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Behcet Sarikaya 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description
References: <018c01c19ec7$6d761420$7e6015ac@T23KEMPF> <3C45E485.2010400@alcatel.com> <022701c19ed6$6646a3e0$7e6015ac@T23KEMPF> <3C4616E3.6060407@alcatel.com> <3C47211F.3FDCC931@iprg.nokia.com> <3C47337E.6080409@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


it doesnt matter now. James Kempf has started a separate thread.
I guess opinions sent on that thread alone will count.

Vijay

Behcet Sarikaya wrote:
> 
> Vijay,
>   Really? Let me copy your email you sent on Jan. 14 :
> 
> > Hi Jim,
> > just one comment.
> > James Kempf wrote:
> >
> >> >
> >> >  Behcet,
> >> >
> >> > Up until now, the only people who have expressed
> >> > an opinion about the paging protocol decision were authors of
> >> protocols
> >> > that
> >> > were not selected. One could, quite frankly, view this as "sour
> >> grapes"
> >> > on their part for not having been selected. However,
> >>
> > People spend a lot of their time to come up with proposals.
> > and they also hope that their proposal goes somewhere in the
> > WG. and when the protocol assessment turns out to be murky
> > and they complain, I dont think it is right to call them
> > "sour grapes".
> > Vijay
> >
> Was this not Vijay Devarapalli? If  not then my apologies.
> 
> Vijay Devarapalli wrote:
> 
> > Behcet,
> > You are quoting me out of context.... my comment was not about
> > the protocol assessment.
> > Vijay
> > Behcet Sarikaya wrote:
> >
> >> Several people not authors of proposals (Vijay, Rene) voiced their
> >> concern on the murky assessment, or am I wrong, or are you waiting
> >> for
> >> the sky to fall down?
> >> To be on the positive side, we can offer Majordomo based mailing
> >> list
> >> support for the design team, if only with no WG draft.
> >> Take it or leave it.
> >> James Kempf wrote:
> >>
> >> > Any such decision is always subject to WG concensus.
> >> > Unfortunately, the only voice we are hearing on the mailing list
> >> > right now is yours. One voice isn't enough for concensus, nor
> >> > is text from a private email forwarded and posted apparently
> >> > without the
> >> > author's permission. Goodness knows, we have enough vocal
> >> > people on this list. It took us a year to get CT requirements
> >> > done (and we still don't have them in IESG Last Call!) because
> >> > everybody had an opinion. If I were seeing some of these people,
> >> > who
> >> > were not authors of competing proposals coming forward and
> >> > saying that we should change the decison, it would be another
> >> > matter.
> >> >                    jak
> >> >
> >> --
> >> 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
> >
> 
> --
> Behcet

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


From seamoby-admin@ietf.org  Thu Jan 17 17:22: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 RAA14569
	for ; Thu, 17 Jan 2002 17:22:21 -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 RAA27163;
	Thu, 17 Jan 2002 17:10: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 RAA27132
	for ; Thu, 17 Jan 2002 17:10:45 -0500 (EST)
Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14399
	for ; Thu, 17 Jan 2002 17:10:40 -0500 (EST)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 17 Jan 2002 17:08:55 -0500
Message-ID: 
From: "Chitrapu, Prabhakar R" 
To: seamoby@ietf.org
Cc: "'James Kempf'" ,
        "Chitrapu, Prabhakar R"
	 
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 17:08:55 -0500
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

Hi All:

I would like to make a clarification on the scoring scheme and the
interpretation of the scores (in particular, high vs low values).
Unfortunately, I do not have those emails that were talking about the
interpretation of the scores, so that I am replying to this somewhat
randomly picked one on this topic.

I think that there is an inaccuracy in thinking that a higher aggregate
score is 'better' (in the present context). Recall that a score of 1 was
given if a requirement was not met and a score of 4 was given if the
requirement was met, so that indeed the higher score is 'better'. However,
score 2 indicated 'under-specification', whereas score 3 indicated
'over-specification'. Here, I am not sure if I can say that
'over-specification' is 'better' than 'under-specification' or vice versa.
Therefore, I think that it is incorrect to interpret a higher aggregate
score as necessarily denoting a 'better' protocol.

Please note that my comment is related only to score interpretation and not
to the much bigger topic of the assessment process and its results.
However, I do sincerely hope that this discussion will soon be settled
amicably among all of us!

Best regards
Prabhakar.
--------------------
Prabhakar Chitrapu
InterDigital Communications Corp.

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Thursday, January 17, 2002 2:10 PM
To: Behcet Sarikaya
Cc: Cedric Westphal; Pat R. Calhoun; seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description

Behcet,

>   The assessment for IP Paging was supposed to be announced at WG
> meeting in SLC. And it did. The minutes of this meeting contained
> strange text in paging part because the paging part talking or
> presentation was done by Kempf and the minutes was also taken by
Kempf.

This is incorrect. The minutes were taken by La Monte Henry Piggy
Yarroll.

> Kempf did the talking based on the slides, almost literally he was
> reading from the slides. The slides were not posted despite several
> repeated request that I made on the mailing list.

This is incorrect. As I stated in my reply to your email of yesterday,
the slides were sent to the IESG Secretariat on Monday, and
should appear shortly in the archives.

>   Because of the admitted irregularity, i.e. one draft was eliminated
by
> sparing no comments I declared the assessment results moot.
>   Kempf now wishes to correct this irregularity by adding an
additional
> text which includes his own comments and does not include other's
> comments, e.g. I made an assessment of draft-renker and no one seems
to
> have commented otherwise.

The only assessment I saw of yours about the current WG draft was
that it was "a mess." This is hardly enough to base a reevaluation of
the decision on.

>   Kempf wishes to keep adding some new criteria , e.g. remove some
text
> from the the assessment I-D all designed to keep his own personal
> conclusion of the assessment process.

Internet Drafts that are WG items are subject to review by the working
group and editing.
That is what the IETF is all about. This goes for every WG draft,
including
the current paging protocol WG draft :-). Some WG members have made
comments about the assessment draft, these need to be incorporated.

>   The fact is that the assessment team was composed of volunteers.
Their
> evaluation is similar to evaluating papers submitted to a conference
by
> some anonymous referees. In such cases the acceptance/ rejection is
made
> based on the marks given by the referees, so how come we ignore the
> marks?

Here you are way off base. This is a complete misinterpretation of what
the IETF is all about. The IETF is not an academic conference, despite
what many people these days seem to think. It is a standards body, and
the
decisions made will have great economic impact, that is why they need to
be weighed
and judged, and agreed upon by the entire WG. The assesment teams
results are subject to WG concensus like every other IETF decision.

> The marks are very consistent with the way the assessment team
> was selected and the assessment was conducted. So we argued that
> draft-renker must have been declared the worst based on these marks.
>   How should the assessment team be formed otherwise? I think that the
> people with recognized expertise in IP Paging should have been
consulted
> as they do in MIP WG. There are such people. These are the issues I
> wanted to discuss with Kempf when I asked him to call me or give his
> phone number so that I can call. He refused.
>   IP Paging can not be equivalent to what Kempf knows of it, it is
much
> more  than that.
>

Behcet, these are personal remarks and are completely out of order.
As I have explained three times within the past two days on email,
the decision to select the current WG draft was made by Pat
and myself, based on the assessment team's analysis and our
judgement. I did not act alone in this matter

Your remarks up until now, including your email from yesterday
(which I have attached with my responses), indicate to me that your
source of
discontent was based on the following two items:

1) Your unhappiness with the process. I posted some text
on that yesterday. Your comments indicated that there
was still some confusion about the ranking system,
so I've agreed with the suggestion of some other
WG members to remove the numerical ranking.

2) Your unhappiness that your draft was not
properly judged.

Do you have any further comment on 1? If not,
then I will make the changes to the assessment draft
that were suggested by the WG members
and yourself.

As for 2, well, what can I say? You know
the reasons why your proposal was rejected,
and I am really sorry that you are unhappy
about it, but I don't see a groundswell of
comment from other WG members recommending
we accept your proposal.

I've made every effort to be accommodating
and invite you to continue participating
in this process, yet you continue to
try to disrupt further progress. If you
are still unhappy, I suggest you file
a grievence action with the IESG and
leave the WG in peace so that we can get
about the business of working on the
Seamoby paging protocol!


            jak

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


From seamoby-admin@ietf.org  Thu Jan 17 17:23: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 RAA14585
	for ; Thu, 17 Jan 2002 17:23: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 RAA27250;
	Thu, 17 Jan 2002 17:12: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 RAA27222
	for ; Thu, 17 Jan 2002 17:12:46 -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 RAA14456
	for ; Thu, 17 Jan 2002 17:12:41 -0500 (EST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA05843 for ; Thu, 17 Jan 2002 15:12:44 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA04130 for ; Thu, 17 Jan 2002 15:01:52 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52)
	id ; Thu, 17 Jan 2002 16:12:43 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FD96@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'James Kempf'" ,
        Nakhjiri Madjid-MNAKHJI1
	 ,
        seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 16:12:42 -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

James,

As I said, I don't have any interest in paging right now.
obviously there has been a lot of obsanity flying around on the
list regarding paging proposals.
I just want to get the selection process straight for future
such as when we are to "select" CT or CAR proposals in the future, 
and  you still haven't answered my question (see my earlier email). 
How much interdependency can we have with work in Mobile IP
or other group?

Madjid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Thursday, January 17, 2002 3:21 PM
To: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description


Majhid,

That was only one consideration. Another was that it did not meet
the requirement of not being dependent on a specific
mobility protocol.

If you have an opinion on about whether we should re-open
the selection phase, please post it under the thread I
opened this morning.

Thanx.


            jak

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" 
To: "'James Kempf'" ; 
Sent: Thursday, January 17, 2002 11:48 AM
Subject: RE: [Seamoby] Paging Protocol Decision Description


> James,
>
> I have an issue with this process.
> You said that one of the drafts was rejected because it had
> a dependency on a document that is under assessment in Mobile IP.
>
> I guess this is new, on one hand we are saying that are
> protocols needs to be interoperable, on the other hand we are
> dismissing solutions that have interdependency:
> This means that we need to wait for the solutions in other groups to
> become RFCs and then try to work them into our proposals? Aren't we
> introducing a significant dead time here?
>
> Can we set up or debate what the rules are here?
>
> Thanks,
>
> Madjid
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Wednesday, January 16, 2002 1:53 PM
> To: seamoby@ietf.org
> Subject: [Seamoby] Paging Protocol Decision Description
>
>
> As promised, here is a description of the decision process used to
> select the Seamoby paging protocol. After discussion and
> editing based on WG feedback, this will be incorporated into
> draft-ietf-seamoby-paging-protocol-assessment-00.txt.
>
> Comments please.
>
>             jak
>
> ----------------------------------------------------------------------
--
> ------------------------------------------
> Assessment and Decision Process
>
> The assessment team spent three weeks reading through the protocol
> proposals.
> Each team member was assigned a proposal for assessment, with the
> exception
> of draft-sarikaya and draft-guri, which were both assigned to
> one team member because not enough people volunteered. Each team
member
> wrote up the results of their assessment, and submitted it to
> the assessment draft editor for assembly into this draft. A
> teleconference
> was held to discuss the assessments and normalize assessments between
> different team members. The assessment team did not make a
> recommendation
> about which draft to pick; however, the team did recommend that the
next
> step should be to either go through another round of design in which
the
> authors would attempt to refine their proposals, or to immediately
begin
> the
> process of harmonizing the protocols to come up with a working group
> draft.
>
> Given that the assessment team's recommendation about which draft to
> accept
> was indeterminate, a decision team was formed by the two Working Group
> co-chairs, with the Area Director providing advice. The decision team
> decided
> to proceed toward selecting a draft as the basis of a harmonized
> protocol, in
> order to avoid further delay in starting on the process of desiging
the
> Seamoby paging protocol.
>
> The decision about which draft to select was difficult, because each
> draft
> had particular aspects that were well thought out and recommended
> themselves for inclusion in the final result, but none of the drafts
> exhibited
> the maturity of implementation and design that immediately suggested
it
> as
> the only possible candidate for selection. Some drafts had particular
> aspects
> that mitigated strongly against selection. A good example of this
> difficulty
> is Requirement 4.6, Multiple Dormant Modes. This requirement was
> intended to
> foster support for hosts that have no explicit L2 paging support,
> basically
> time-slotted paging. Draft-sarikaya has an excellent discussion of
> time-slotted paging mode, but the basis of that draft is a protocol
> (HMIPv6)
> that has been proposed in another working group for a problem that is
> still
> in the requirements phase. The other proposals had varying degrees
> of support for time-slotted paging, but none was sufficient to
recommend
> itself on this particular requirement.
>
> The assessment team's work allowed the decision team to reduce the
> number of drafts under consideration from five to two. The decision
team
> quickly decided to rule out draft-koodli because the draft is lacking
in
> specifics and is vague on many requirements, as mentioned in the
> assessment
> team's report. 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. Also, draft-sarikaya exclusively
supports
> Mobile IPv6, and a primary requirement of all Seamoby work is that the
> protocols be independent of mobility protocol. 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. However, the ideas expressed in draft-guri
were
> felt
> to be valuable and necessary for including in the final Seamoby paging
> protocol for those cases where Layer 2 paging support is available.
>
> The decision between the remaining two drafts, draft-renker and
> draft-ohba,
> was especially difficult because they were judged to be about of equal
> quality. The decision team decided to focus on three primary
> requirements
> that were thought to be crucial to the successful acceptance of IP
> paging:
> independence of mobility protocol, support for existing mobility
> protocols,
> and independence of paging area from subnet topology.
>
> 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. Draft-renker was judged by the assessment team to
> be overspecific in these areas, in the sense that it contained two
> modes,
> explicit mode and implicit mode, depending on whether Mobile IP was
> supported
> or not. However, considering the relatively immature state of the
paging
> protocol design, the decision team felt that providing the working
group
> with choices, where the benefits and drawbacks of each choice could be
> clearly weighed, was preferable to providing a fixed decision, so
> draft-renker was judged to be better in this regard.
>
> On the requirement for independence of paging area from subnet
topology,
> the
> support described in draft-ohba was very sketchy and did not provide
> the decision team with a clear idea about how this could be achieved,
> particularly with regard to the movement of a mobile host while the
host
> is
> in dormant mode. Draft-renker has a much clearer description of how
this
> could
> be achieved, and was judged to be better in this regard.
>
> Additional aspects of draft-renker that recommended it as the
selection
> were attention to details of interaction with existing IP
> routing, and a survey of paging strategies. While probably not
essential
> to
> the final protocol design, the material on paging strategies showed
> that the authors had given some thought to separating policy from
> mechanism,
> and were familiar with the somewhat extensive academic
> literature on paging, and IP paging in particular.
>
> While draft-renker was selected by the decision team as the basis for
> continued Seamoby paging protocol work, the decision team feels that
it
> is
> important to incorporate the outstanding contributions of the other
> authors
> into the final protocol design, in particular, the time-slotted paging
> discussion in draft-sarikaya, the Layer 2 interface work in
draft-guri,
> the
> paging state machine discussion in draft-koodli, and the security
> protocol
> work in draft-ohba. Additional aspects of the other drafts that
address
> issues which were weakly addressed or not addressed at all in
> draft-renker
> should also be incorporated, as well as ideas from other working group
> members that address requirement which none of the draft addressed
> particularly
> well.
>
>
>
>
>
>
>
> _______________________________________________
> 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 Jan 17 17:31: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 RAA14660
	for ; Thu, 17 Jan 2002 17:31: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 RAA27432;
	Thu, 17 Jan 2002 17:17: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 RAA27401
	for ; Thu, 17 Jan 2002 17:17:38 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14511
	for ; Thu, 17 Jan 2002 17:17:33 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 17 Jan 2002 14:17:05 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Cedric Westphal'" 
Cc: "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Thu, 17 Jan 2002 14:16:52 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19FA4.AA3AFCD0"
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_01C19FA4.AA3AFCD0
Content-Type: text/plain

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

>>>  Can you point to one debate where the rough consensus was
>>> reached 
>>>  by way of more than 250 favorable opinions?
>>Hmmm.. Perhaps you misread my statement. Read above.
>
>I did push your statement to the extreme. The point was consensus
>does not go by absolute numbers, but relative numbers of for and
>against, especially since on any topic, the very vast majority never
>says a thing. 

Correct - and I am still waiting for others to express their view

PatC

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

iQA/AwUBPEdNUzN1fXKoxmisEQIAOACgul1IIl8/PG0D+OhE3IcorwY2AxgAn1RA
Fpop9qOZyA6XX6ZkdwkJovtK
=2/ws
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C19FA4.AA3AFCD0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Paging Protocol Decision Description




 

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

Hash: SHA1




>>>  Can you point to one debate where =
the rough consensus was

>>> reached 

>>>  by way of more than 250 favorable =
opinions?

>>Hmmm.. Perhaps you misread my statement. =
Read above.

>

>I did push your statement to the extreme. The =
point was consensus

>does not go by absolute numbers, but relative =
numbers of for and

>against, especially since on any topic, the very =
vast majority never

>says a thing. 




Correct - and I am still waiting for others to =
express their view




PatC




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

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




iQA/AwUBPEdNUzN1fXKoxmisEQIAOACgul1IIl8/PG0D+OhE3IcorwY2AxgAn1R=
A

Fpop9qOZyA6XX6ZkdwkJovtK

=3D2/ws

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





------_=_NextPart_001_01C19FA4.AA3AFCD0--

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


From seamoby-admin@ietf.org  Thu Jan 17 18:28: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 SAA15472
	for ; Thu, 17 Jan 2002 18:28: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 SAA29021;
	Thu, 17 Jan 2002 18: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 SAA28992
	for ; Thu, 17 Jan 2002 18:15:11 -0500 (EST)
Received: from smtp.tari.toshiba.com ([207.122.4.194])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15249
	for ; Thu, 17 Jan 2002 18:15:07 -0500 (EST)
Received: from localhost
	by smtp.tari.toshiba.com (8.9.1/3.7W-011204) with ESMTP id SAA03573;
	Thu, 17 Jan 2002 18:18:01 -0500
Date: Thu, 17 Jan 2002 18:18:06 -0500 (EST)
Message-Id: <20020117.181806.60851495.sbaba@tari.toshiba.com>
To: seamoby@ietf.org, sob@harvard.edu, mankin@isi.edu
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
From: Baba S 
In-Reply-To: <01ee01c19f8b$b49d4200$7e6015ac@T23KEMPF>
References: <01ee01c19f8b$b49d4200$7e6015ac@T23KEMPF>
X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI)
Mime-Version: 1.0
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

Chairs,

Does this mean you didn't do this call in SLC?
Or you may be re-calling the consensus to see
the difference from that.

In either case, I think it is still early to call
a consensus, as we just got your description yesterday.
It is already proved that a (rough) consensus without
enough understanding doesn't work even as the rough
consensus.
And I would like to wait and see an outcome of some
efforts on forming a design team.

baba//


From: "James Kempf" 
Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Thu, 17 Jan 2002 11:18:12 -0800

> All,
> 
> Pat and I made a selection for what to start with, not what to end with.
> The WG will determine what the final technology looks like.
> 
> 1) If you want to support or disagree with the selection of the starting
>  ID, say so now please.
> 
> 2) If there is not consensus that we should re-open the selection phase,
> then we will move forward based on the selection in the next few days.
> 
> 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  Thu Jan 17 18:45: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 SAA15704
	for ; Thu, 17 Jan 2002 18:45: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 SAA29764;
	Thu, 17 Jan 2002 18:34: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 SAA29733
	for ; Thu, 17 Jan 2002 18:34:53 -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 SAA15579
	for ; Thu, 17 Jan 2002 18:34:48 -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 PAA23775;
	Thu, 17 Jan 2002 15:34:19 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0HNYIr14035;
	Thu, 17 Jan 2002 15:34:18 -0800
X-mProtect:  Thu, 17 Jan 2002 15:34:18 -0800 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpd6eyoXO; Thu, 17 Jan 2002 15:34:17 PST
Message-ID: <3C475F7A.9E88C7D4@iprg.nokia.com>
Date: Thu, 17 Jan 2002 15:34:18 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Chitrapu, Prabhakar R" 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description
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


Hello Prabhakar,


"Chitrapu, Prabhakar R" wrote:

> Hi All:
>
> I would like to make a clarification on the scoring scheme and the
> interpretation of the scores (in particular, high vs low values).
> Unfortunately, I do not have those emails that were talking about the
> interpretation of the scores, so that I am replying to this somewhat
> randomly picked one on this topic.
>
> I think that there is an inaccuracy in thinking that a higher aggregate
> score is 'better' (in the present context). Recall that a score of 1 was
> given if a requirement was not met and a score of 4 was given if the
> requirement was met, so that indeed the higher score is 'better'. However,
> score 2 indicated 'under-specification', whereas score 3 indicated
> 'over-specification'. Here, I am not sure if I can say that
> 'over-specification' is 'better' than 'under-specification' or vice versa.
> Therefore, I think that it is incorrect to interpret a higher aggregate
> score as necessarily denoting a 'better' protocol.
>

It does appear from the text (from James) below that "over-specification"
(which implies a higher score) was considered better, at least in one of the
important areas.

For what it is worth..

Regards,

-Rajeev


> mobility protocols. Draft-renker was judged by the assessment team to
> be overspecific in these areas, in the sense that it contained two
> modes,
> explicit mode and implicit mode, depending on whether Mobile IP was
> supported
> or not. However, considering the relatively immature state of the paging
> protocol design, the decision team felt that providing the working group
> with choices, where the benefits and drawbacks of each choice could be
> clearly weighed, was preferable to providing a fixed decision, so
> draft-renker was judged to be better in this regard.

>
> Please note that my comment is related only to score interpretation and not
> to the much bigger topic of the assessment process and its results.
> However, I do sincerely hope that this discussion will soon be settled
> amicably among all of us!
>
> Best regards
> Prabhakar.
> --------------------
> Prabhakar Chitrapu
> InterDigital Communications Corp.
>
>
> _______________________________________________
> 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 Jan 17 18:56: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 SAA15841
	for ; Thu, 17 Jan 2002 18:56: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 SAA00005;
	Thu, 17 Jan 2002 18:45: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 SAA29973
	for ; Thu, 17 Jan 2002 18:45:28 -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 SAA15707
	for ; Thu, 17 Jan 2002 18:45:24 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0HNiQe15789;
	Thu, 17 Jan 2002 15:44:36 -0800 (PST)
Message-ID: <030301c19fb0$b8324fd0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: , , ,
        "Baba S" 
References: <01ee01c19f8b$b49d4200$7e6015ac@T23KEMPF> <20020117.181806.60851495.sbaba@tari.toshiba.com>
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Thu, 17 Jan 2002 15:42:49 -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

Hi Baba-san,

> Does this mean you didn't do this call in SLC?
> Or you may be re-calling the consensus to see
> the difference from that.
> 

Concensus calls made at IETF meetings need to
be confirmed by email to the list.

> In either case, I think it is still early to call
> a consensus, as we just got your description yesterday.
> It is already proved that a (rough) consensus without
> enough understanding doesn't work even as the rough
> consensus.

We will give people enough time to digest the description
we sent out yesterday.

> And I would like to wait and see an outcome of some
> efforts on forming a design team.
> 

Thanx for your opinion.

            jak



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


From seamoby-admin@ietf.org  Thu Jan 17 18:58: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 SAA15884
	for ; Thu, 17 Jan 2002 18:58: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 SAA00083;
	Thu, 17 Jan 2002 18:46: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 SAA00044
	for ; Thu, 17 Jan 2002 18:46:21 -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 SAA15725
	for ; Thu, 17 Jan 2002 18:46:18 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA00665;
	Thu, 17 Jan 2002 17:45:26 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g0HNjPr19055;
	Thu, 17 Jan 2002 17:45:25 -0600 (CST)
Message-ID: <3C47620E.8070503@alcatel.com>
Date: Thu, 17 Jan 2002 17:45: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: "Chitrapu, Prabhakar R" 
CC: seamoby@ietf.org, "'James Kempf'" 
Subject: Re: [Seamoby] Paging Protocol Decision Description
References: 
Content-Type: multipart/alternative;
 boundary="------------030509000106050307030303"
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


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

Hello Prabhakar,
  I do not think that anybody (myself or Yoshi who made this point 
first) claimed that higher marks indicated better protocol.
  What I said is if there is quite a large discrepancy in the marks 
received which is the case this time (72 versus 89s, 90s etc), one draft 
receives about 30% less than all others, can we say that this draft can 
be considered the worst draft compared with the rest based on 
draft-seamoby-paging-protocol-assessment?

Regards,

Chitrapu, Prabhakar R wrote:

>Hi All:
>
>I would like to make a clarification on the scoring scheme and the
>interpretation of the scores (in particular, high vs low values).
>Unfortunately, I do not have those emails that were talking about the
>interpretation of the scores, so that I am replying to this somewhat
>randomly picked one on this topic.
>
>I think that there is an inaccuracy in thinking that a higher aggregate
>score is 'better' (in the present context). Recall that a score of 1 was
>given if a requirement was not met and a score of 4 was given if the
>requirement was met, so that indeed the higher score is 'better'. However,
>score 2 indicated 'under-specification', whereas score 3 indicated
>'over-specification'. Here, I am not sure if I can say that
>'over-specification' is 'better' than 'under-specification' or vice versa.
>Therefore, I think that it is incorrect to interpret a higher aggregate
>score as necessarily denoting a 'better' protocol.
>
>Please note that my comment is related only to score interpretation and not
>to the much bigger topic of the assessment process and its results.
>However, I do sincerely hope that this discussion will soon be settled
>amicably among all of us!
>
>Best regards
>Prabhakar.
>--------------------
>Prabhakar Chitrapu
>InterDigital Communications Corp.
>
>-----Original Message-----
>From: James Kempf [mailto:kempf@docomolabs-usa.com]
>Sent: Thursday, January 17, 2002 2:10 PM
>To: Behcet Sarikaya
>Cc: Cedric Westphal; Pat R. Calhoun; seamoby@ietf.org
>Subject: Re: [Seamoby] Paging Protocol Decision Description
>
>Behcet,
>
>>  The assessment for IP Paging was supposed to be announced at WG
>>meeting in SLC. And it did. The minutes of this meeting contained
>>strange text in paging part because the paging part talking or
>>presentation was done by Kempf and the minutes was also taken by
>>
>Kempf.
>
>This is incorrect. The minutes were taken by La Monte Henry Piggy
>Yarroll.
>
>>Kempf did the talking based on the slides, almost literally he was
>>reading from the slides. The slides were not posted despite several
>>repeated request that I made on the mailing list.
>>
>
>This is incorrect. As I stated in my reply to your email of yesterday,
>the slides were sent to the IESG Secretariat on Monday, and
>should appear shortly in the archives.
>
>>  Because of the admitted irregularity, i.e. one draft was eliminated
>>
>by
>
>>sparing no comments I declared the assessment results moot.
>>  Kempf now wishes to correct this irregularity by adding an
>>
>additional
>
>>text which includes his own comments and does not include other's
>>comments, e.g. I made an assessment of draft-renker and no one seems
>>
>to
>
>>have commented otherwise.
>>
>
>The only assessment I saw of yours about the current WG draft was
>that it was "a mess." This is hardly enough to base a reevaluation of
>the decision on.
>
>>  Kempf wishes to keep adding some new criteria , e.g. remove some
>>
>text
>
>>from the the assessment I-D all designed to keep his own personal
>>conclusion of the assessment process.
>>
>
>Internet Drafts that are WG items are subject to review by the working
>group and editing.
>That is what the IETF is all about. This goes for every WG draft,
>including
>the current paging protocol WG draft :-). Some WG members have made
>comments about the assessment draft, these need to be incorporated.
>
>>  The fact is that the assessment team was composed of volunteers.
>>
>Their
>
>>evaluation is similar to evaluating papers submitted to a conference
>>
>by
>
>>some anonymous referees. In such cases the acceptance/ rejection is
>>
>made
>
>>based on the marks given by the referees, so how come we ignore the
>>marks?
>>
>
>Here you are way off base. This is a complete misinterpretation of what
>the IETF is all about. The IETF is not an academic conference, despite
>what many people these days seem to think. It is a standards body, and
>the
>decisions made will have great economic impact, that is why they need to
>be weighed
>and judged, and agreed upon by the entire WG. The assesment teams
>results are subject to WG concensus like every other IETF decision.
>
>>The marks are very consistent with the way the assessment team
>>was selected and the assessment was conducted. So we argued that
>>draft-renker must have been declared the worst based on these marks.
>>  How should the assessment team be formed otherwise? I think that the
>>people with recognized expertise in IP Paging should have been
>>
>consulted
>
>>as they do in MIP WG. There are such people. These are the issues I
>>wanted to discuss with Kempf when I asked him to call me or give his
>>phone number so that I can call. He refused.
>>  IP Paging can not be equivalent to what Kempf knows of it, it is
>>
>much
>
>>more  than that.
>>
>
>Behcet, these are personal remarks and are completely out of order.
>As I have explained three times within the past two days on email,
>the decision to select the current WG draft was made by Pat
>and myself, based on the assessment team's analysis and our
>judgement. I did not act alone in this matter
>
>Your remarks up until now, including your email from yesterday
>(which I have attached with my responses), indicate to me that your
>source of
>discontent was based on the following two items:
>
>1) Your unhappiness with the process. I posted some text
>on that yesterday. Your comments indicated that there
>was still some confusion about the ranking system,
>so I've agreed with the suggestion of some other
>WG members to remove the numerical ranking.
>
>2) Your unhappiness that your draft was not
>properly judged.
>
>Do you have any further comment on 1? If not,
>then I will make the changes to the assessment draft
>that were suggested by the WG members
>and yourself.
>
>As for 2, well, what can I say? You know
>the reasons why your proposal was rejected,
>and I am really sorry that you are unhappy
>about it, but I don't see a groundswell of
>comment from other WG members recommending
>we accept your proposal.
>
>I've made every effort to be accommodating
>and invite you to continue participating
>in this process, yet you continue to
>try to disrupt further progress. If you
>are still unhappy, I suggest you file
>a grievence action with the IESG and
>leave the WG in peace so that we can get
>about the business of working on the
>Seamoby paging protocol!
>
>
>            jak
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>

-- 
Behcet 



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





Hello Prabhakar,

  I do not think that anybody (myself or Yoshi who made this point first)
claimed that higher marks indicated better protocol.

  What I said is if there is quite a large discrepancy in the marks received
which is the case this time (72 versus 89s, 90s etc), one draft receives
about 30% less than all others, can we say that this draft can be considered
the worst draft compared with the rest based on draft-seamoby-paging-protocol-assessment?




Regards,



Chitrapu, Prabhakar R wrote:



  
Hi All:

I would like to make a clarification on the scoring scheme and the
interpretation of the scores (in particular, high vs low values).
Unfortunately, I do not have those emails that were talking about the
interpretation of the scores, so that I am replying to this somewhat
randomly picked one on this topic.

I think that there is an inaccuracy in thinking that a higher aggregate
score is 'better' (in the present context). Recall that a score of 1 was
given if a requirement was not met and a score of 4 was given if the
requirement was met, so that indeed the higher score is 'better'. However,
score 2 indicated 'under-specification', whereas score 3 indicated
'over-specification'. Here, I am not sure if I can say that
'over-specification' is 'better' than 'under-specification' or vice versa.
Therefore, I think that it is incorrect to interpret a higher aggregate
score as necessarily denoting a 'better' proto
col.

Please note that my comment is related only to score interpretation and not
to the much bigger topic of the assessment process and its results.
However, I do sincerely hope that this discussion will soon be settled
amicably among all of us!

Best regards
Prabhakar.
--------------------
Prabhakar Chitrapu
InterDigital Communications Corp.

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Thursday, January 17, 2002 2:10 PM
To: Behcet Sarikaya
Cc: Cedric Westphal; Pat R. Calhoun; seamoby@ietf.org
Subject: Re: [Seamoby] Paging Protocol Decision Description

Behcet,


  

    
  The assessment for IP Paging was supposed to be announced at WG
meeting in SLC. And it did. The minutes of this meeting contained
strange text in paging part because the paging part talking or
presentation was done by Kempf and the minutes was also taken by

    

    
Kempf.

This is incorrect. The minutes were taken by La Monte Henry Piggy
Yarroll.


    

      
Kempf did the talking based on the slides, almost literally he was
reading from the slides. The slides were not posted despite several
repeated request that I made on the mailing list.

      

      

This is incorrect. As I stated in my reply to your email of yesterday,
the slides were sent to the IESG Secretariat on Monday, and
should appear shortly in the archives.


      

        
  Because of the admitted irregularity, i.e. one draft was eliminated

        

        
by

        

          
sparing no comments I declared the assessment results moot.
  Kempf now wishes to correct this irregularity by adding an

          

          
additional

          

            
text which includes his own comments and does not include other's
comments, e.g. I made an assessment of draft-renker and no one seems

            

            
to

            

              
have commented otherwise.

              

              

The only assessment I saw of yours about the current WG draft was
that it was "a mess." This is hardly enough to base a reevaluation of
the decision on.


              

                
  Kempf wishes to keep adding some new criteria , e.g. remove some

                

                
text

                

                  
from the the assessment I-D all designed to keep his own personal
conclusion of the assessment process.

                  

                  

Internet Drafts that are WG items are subject to review by the working
group and editing.
That is what the IETF is all about. This goes for every WG draft,
including
the current paging protocol WG draft :-). Some WG members have made
comments about the assessment draft, these need to be incorporated.


                  

                    
  The fact is that the assessment team was composed of volunteers.

                    

                    
Their

                    

                      
evaluation is similar to evaluating papers submitted to a conference

                      

                      
by

                      

                        
some anonymous referees. In such cases the acceptance/ rejection is

                        

                        
made

                        

                          
based on the marks given by the referees, so how come we ignore the
marks?

                          

                          

Here you are way off base. This is a complete misinterpretation of what
the IETF is all about. The IETF is not an academic conference, despite
what many people these days seem to think. It is a standards body, and
the
decisions made will have great economic impact, that is why they need to
be weighed
and judged, and agreed upon by the entire WG. The assesment teams
results are subject to WG concensus like every other IETF decision.


                          

                            
The marks are very consistent with the way the assessment team
was selected and the assessment was conducted. So we argued that
draft-renker must have been declared the worst based on these marks.
  How should the assessment team be formed otherwise? I think that the
people with recognized expertise in IP Paging should have been

                            

                            
consulted

                            

                              
as they do in MIP WG. There are such people. These are the issues I
wanted to discuss with Kempf when I asked him to call me or give his
phone number so that I can call. He refused.
  IP Paging can not be equivalent to what Kempf knows of it, it is

                              

                              
much

                              

                                
more  than that.


                                

                                

Behcet, these are personal remarks and are completely out of order.
As I have explained three times within the past two days on email,
the decision to select the current WG draft was made by Pat
and myself, based on the assessment team's analysis and our
judgement. I did not act alone in this matter

Your remarks up until now, including your email from yesterday
(which I have attached with my responses), indicate to me that your
source of
discontent was based on the following two items:

1) Your unhappiness with the process. I posted some text
on that yesterday. Your comments indicated that there
was still some confusion about the ranking system,
so I've agreed with the suggestion of some other
WG members to remove the numerical ranking.

2) Your unhappiness that your draft was not
properly judged.

Do you have any further comment on 1? If not,
then I will m
ake the changes to the assessment draft
that were suggested by the WG members
and yourself.

As for 2, well, what can I say? You know
the reasons why your proposal was rejected,
and I am really sorry that you are unhappy
about it, but I don't see a groundswell of
comment from other WG members recommending
we accept your proposal.

I've made every effort to be accommodating
and invite you to continue participating
in this process, yet you continue to
try to disrupt further progress. If you
are still unhappy, I suggest you file
a grievence action with the IESG and
leave the WG in peace so that we can get
about the business of working on the
Seamoby paging protocol!


            jak

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

                                

                                

                                
-- 
Behcet 


                                

                                
                                

--------------030509000106050307030303--


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


From seamoby-admin@ietf.org  Thu Jan 17 19:22: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 TAA16218
	for ; Thu, 17 Jan 2002 19:22: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 TAA00863;
	Thu, 17 Jan 2002 19:09: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 TAA00832
	for ; Thu, 17 Jan 2002 19:09:28 -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 TAA16015
	for ; Thu, 17 Jan 2002 19:09:26 -0500 (EST)
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 g0I0B0Q01985
	for ; Thu, 17 Jan 2002 18:11:00 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 17 Jan 2002 18:09:27 -0600
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 17 Jan 2002 18:09:26 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Thu, 17 Jan 2002 18:09:26 -0600
Message-ID: <748E8123D183394982E32A511DB3E73610B0C1@daebe005.NOE.Nokia.com>
Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Thread-Index: AcGfjB5vADj3orhMSASYBVeaoRZw8wAJu5gQ
From: "Purnadi Rene (NRC/Dallas)" 
To: "'ext James Kempf'" , 
Cc: , "Allison Mankin" 
X-OriginalArrivalTime: 18 Jan 2002 00:09:26.0999 (UTC) FILETIME=[645F6E70:01C19FB4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA00833
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

James,

We vote to re-open the selection phase. By the way, Rene Purnadi is one
of the author in the draft koodli and his involvement in this vote is
not based on 'sour grapes' but to seek a valid selection procedure.

Thank you.

Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene Purnadi
and Srinivas Sreemanthula
Nokia Research Center

-----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Thursday, January 17, 2002 1:18 PM
To: seamoby@ietf.org
Cc: sob@harvard.edu; Allison Mankin
Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision


All,

Pat and I made a selection for what to start with, not what to end with.
The WG will determine what the final technology looks like.

1) If you want to support or disagree with the selection of the starting
 ID, say so now please.

2) If there is not consensus that we should re-open the selection phase,
then we will move forward based on the selection in the next few days.

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  Thu Jan 17 19:49: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 TAA16489
	for ; Thu, 17 Jan 2002 19:49: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 TAA01753;
	Thu, 17 Jan 2002 19:33: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 TAA01722
	for ; Thu, 17 Jan 2002 19:33:54 -0500 (EST)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16331
	for ; Thu, 17 Jan 2002 19:33:50 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.10.2/8.10.2) id g0I0XNN23694;
	Thu, 17 Jan 2002 19:33:23 -0500 (EST)
Date: Thu, 17 Jan 2002 19:33:23 -0500 (EST)
From: Scott  Bradner 
Message-Id: <200201180033.g0I0XNN23694@newdev.harvard.edu>
To: kempf@docomolabs-usa.com, rene.purnadi@nokia.com, seamoby@ietf.org
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Cc: mankin@isi.edu, sob@harvard.edu
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

> We vote to re-open

just to be sure - each of the listed people on their own came to that
conclusion?

----
From rene.purnadi@nokia.com  Thu Jan 17 19:09:34 2002
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Thu, 17 Jan 2002 18:09:26 -0600
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Thread-Index: AcGfjB5vADj3orhMSASYBVeaoRZw8wAJu5gQ
From: "Purnadi Rene (NRC/Dallas)" 
To: "'ext James Kempf'" , 
Cc: , "Allison Mankin" 
X-OriginalArrivalTime: 18 Jan 2002 00:09:26.0999 (UTC) FILETIME=[645F6E70:01C19FB4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by newdev.harvard.edu id g0I09TS23621

James,

We vote to re-open the selection phase. By the way, Rene Purnadi is one
of the author in the draft koodli and his involvement in this vote is
not based on 'sour grapes' but to seek a valid selection procedure.

Thank you.

Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene Purnadi
and Srinivas Sreemanthula
Nokia Research Center

-----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Thursday, January 17, 2002 1:18 PM
To: seamoby@ietf.org
Cc: sob@harvard.edu; Allison Mankin
Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision


All,

Pat and I made a selection for what to start with, not what to end with.
The WG will determine what the final technology looks like.

1) If you want to support or disagree with the selection of the starting
 ID, say so now please.

2) If there is not consensus that we should re-open the selection phase,
then we will move forward based on the selection in the next few days.

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  Thu Jan 17 21: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 VAA17363
	for ; Thu, 17 Jan 2002 21: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 UAA03773;
	Thu, 17 Jan 2002 20:37: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 UAA03742
	for ; Thu, 17 Jan 2002 20:37:14 -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 UAA17029
	for ; Thu, 17 Jan 2002 20:37:11 -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 RAA02100;
	Thu, 17 Jan 2002 17:36:35 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0I1aY110583;
	Thu, 17 Jan 2002 17:36:34 -0800
X-mProtect:  Thu, 17 Jan 2002 17:36:34 -0800 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdkvuwCa; Thu, 17 Jan 2002 17:36:32 PST
Message-ID: <3C477C20.7DEB37D0@iprg.nokia.com>
Date: Thu, 17 Jan 2002 17:36:32 -0800
From: Rajeev Koodli 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Bradner 
CC: kempf@docomolabs-usa.com, rene.purnadi@nokia.com, seamoby@ietf.org,
        mankin@isi.edu
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <200201180033.g0I0XNN23694@newdev.harvard.edu>
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

Scott Bradner wrote:

> > We vote to re-open
>
> just to be sure - each of the listed people on their own came to that
> conclusion?
>

I did.

Regards,

-Rajeev


>
> ----
> >From rene.purnadi@nokia.com  Thu Jan 17 19:09:34 2002
> X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
> content-class: urn:content-classes:message
> MIME-Version: 1.0
> Content-Type: text/plain;
>         charset="iso-8859-1"
> Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> Date: Thu, 17 Jan 2002 18:09:26 -0600
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
> Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> Thread-Index: AcGfjB5vADj3orhMSASYBVeaoRZw8wAJu5gQ
> From: "Purnadi Rene (NRC/Dallas)" 
> To: "'ext James Kempf'" , 
> Cc: , "Allison Mankin" 
> X-OriginalArrivalTime: 18 Jan 2002 00:09:26.0999 (UTC) FILETIME=[645F6E70:01C19FB4]
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by newdev.harvard.edu id g0I09TS23621
>
> James,
>
> We vote to re-open the selection phase. By the way, Rene Purnadi is one
> of the author in the draft koodli and his involvement in this vote is
> not based on 'sour grapes' but to seek a valid selection procedure.
>
> Thank you.
>
> Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene Purnadi
> and Srinivas Sreemanthula
> Nokia Research Center
>
> -----Original Message-----
> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Thursday, January 17, 2002 1:18 PM
> To: seamoby@ietf.org
> Cc: sob@harvard.edu; Allison Mankin
> Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
>
> All,
>
> Pat and I made a selection for what to start with, not what to end with.
> The WG will determine what the final technology looks like.
>
> 1) If you want to support or disagree with the selection of the starting
>  ID, say so now please.
>
> 2) If there is not consensus that we should re-open the selection phase,
> then we will move forward based on the selection in the next few days.
>
> 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


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


From seamoby-admin@ietf.org  Thu Jan 17 22:21: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 WAA19546
	for ; Thu, 17 Jan 2002 22:21: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 WAA07021;
	Thu, 17 Jan 2002 22:10: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 WAA06990
	for ; Thu, 17 Jan 2002 22:10:46 -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 WAA19399
	for ; Thu, 17 Jan 2002 22:10:41 -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 TAA06185;
	Thu, 17 Jan 2002 19:09:57 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0I39t318986;
	Thu, 17 Jan 2002 19:09:55 -0800
X-mProtect:  Thu, 17 Jan 2002 19:09:55 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com smtpdo300lT; Thu, 17 Jan 2002 19:09:53 PST
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id TAA25608; Thu, 17 Jan 2002 19:09:54 -0800 (PST)
Message-ID: <3C479202.74742484@iprg.nokia.com>
Date: Thu, 17 Jan 2002 19:09:54 -0800
From: "Jari T. Malinen" 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Bradner 
CC: kempf@docomolabs-usa.com, rene.purnadi@nokia.com, seamoby@ietf.org,
        mankin@isi.edu
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <200201180033.g0I0XNN23694@newdev.harvard.edu>
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

Scott,

> 
> > We vote to re-open
> 
> just to be sure - each of the listed people on their own came to that
> conclusion?

It is obvious we did discuss this issue among the co-authors,
hence the common expression of opinion by Rene. However, I have
to admit I also on my own favor 2. The selection process did not
generate support for alternative 1. If an I-D written by an
evaluation team is such that the selection outcome is not at
all readable from it, as was the case at SLC, it gives a
precedence for other working groups. More straightforward
would have been to say that an AD and the wg chairs simply
picked the protocol.

I would like to be informed if I am wrong, but to
my understanding that is not how standardization in the
IETF is supposed to happen. If it is, that unfortunately
has implications as of how we can motivate the usefulness
of the IETF process from our perspective. Formation of a
rough concensus among participants (those expressing their
opinion) is a more understandable way. It may be less efficient,
but more acceptable to parties, who, afterall, should finally
adopt the chosen solution, implement it, test it in interops
and defend its usefulness to various parties challenging it.

I have to say I am not totally happy with any of the proposals and
technically I do not see it as a big issue which of the protocols
is the starting point, the process is the more worrying aspect.
Also, we know from too many wg:s that once there is a wg item,
even just as a starting point, the authors seem to be defensive
in a manner making realistic possibilities to accept changes
proposed by non-authors extremely tedious. Therefore I do not
see much of an alternative to a design team that actually
starts from scratch, unless the chosen proposal is fairly
ready (which the Renker draft on my opinion is not). If a
closed design team is a problem, why not have an open one?

Best Regards,

-Jari

Jari T. Malinen
Nokia Research Center

> ----
> >From rene.purnadi@nokia.com  Thu Jan 17 19:09:34 2002
> X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
> content-class: urn:content-classes:message
> MIME-Version: 1.0
> Content-Type: text/plain;
>         charset="iso-8859-1"
> Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> Date: Thu, 17 Jan 2002 18:09:26 -0600
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
> Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> Thread-Index: AcGfjB5vADj3orhMSASYBVeaoRZw8wAJu5gQ
> From: "Purnadi Rene (NRC/Dallas)" 
> To: "'ext James Kempf'" , 
> Cc: , "Allison Mankin" 
> X-OriginalArrivalTime: 18 Jan 2002 00:09:26.0999 (UTC) FILETIME=[645F6E70:01C19FB4]
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by newdev.harvard.edu id g0I09TS23621
> 
> James,
> 
> We vote to re-open the selection phase. By the way, Rene Purnadi is one
> of the author in the draft koodli and his involvement in this vote is
> not based on 'sour grapes' but to seek a valid selection procedure.
> 
> Thank you.
> 
> Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene Purnadi
> and Srinivas Sreemanthula
> Nokia Research Center
> 
> -----Original Message-----
> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Thursday, January 17, 2002 1:18 PM
> To: seamoby@ietf.org
> Cc: sob@harvard.edu; Allison Mankin
> Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> 
> All,
> 
> Pat and I made a selection for what to start with, not what to end with.
> The WG will determine what the final technology looks like.
> 
> 1) If you want to support or disagree with the selection of the starting
>  ID, say so now please.
> 
> 2) If there is not consensus that we should re-open the selection phase,
> then we will move forward based on the selection in the next few days.
> 
> 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

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


From seamoby-admin@ietf.org  Thu Jan 17 22:52: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 WAA21172
	for ; Thu, 17 Jan 2002 22:52: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 WAA08201;
	Thu, 17 Jan 2002 22:42: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 WAA08172
	for ; Thu, 17 Jan 2002 22:42:10 -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 WAA20983
	for ; Thu, 17 Jan 2002 22:42:06 -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 TAA07702;
	Thu, 17 Jan 2002 19:41:28 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0I3fSG06682;
	Thu, 17 Jan 2002 19:41:28 -0800
X-mProtect:  Thu, 17 Jan 2002 19:41:28 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com smtpdy4DtP5; Thu, 17 Jan 2002 19:41:26 PST
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id TAA25638; Thu, 17 Jan 2002 19:41:26 -0800 (PST)
Message-ID: <3C479966.28E98F85@iprg.nokia.com>
Date: Thu, 17 Jan 2002 19:41:26 -0800
From: "Jari T. Malinen" 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Bradner , kempf@docomolabs-usa.com,
        rene.purnadi@nokia.com, seamoby@ietf.org, mankin@isi.edu
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <200201180033.g0I0XNN23694@newdev.harvard.edu> <3C479202.74742484@iprg.nokia.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

Oops, I mis-read the choices, the item is not number 2 but
the other which I interpret as giving possibility to re-open
the design process.

BR,

-Jari

"Jari T. Malinen" wrote:
> 
> Scott,
> 
> >
> > > We vote to re-open
> >
> > just to be sure - each of the listed people on their own came to that
> > conclusion?
> 
> It is obvious we did discuss this issue among the co-authors,
> hence the common expression of opinion by Rene. However, I have
> to admit I also on my own favor 2. The selection process did not
> generate support for alternative 1. If an I-D written by an
> evaluation team is such that the selection outcome is not at
> all readable from it, as was the case at SLC, it gives a
> precedence for other working groups. More straightforward
> would have been to say that an AD and the wg chairs simply
> picked the protocol.
> 
> I would like to be informed if I am wrong, but to
> my understanding that is not how standardization in the
> IETF is supposed to happen. If it is, that unfortunately
> has implications as of how we can motivate the usefulness
> of the IETF process from our perspective. Formation of a
> rough concensus among participants (those expressing their
> opinion) is a more understandable way. It may be less efficient,
> but more acceptable to parties, who, afterall, should finally
> adopt the chosen solution, implement it, test it in interops
> and defend its usefulness to various parties challenging it.
> 
> I have to say I am not totally happy with any of the proposals and
> technically I do not see it as a big issue which of the protocols
> is the starting point, the process is the more worrying aspect.
> Also, we know from too many wg:s that once there is a wg item,
> even just as a starting point, the authors seem to be defensive
> in a manner making realistic possibilities to accept changes
> proposed by non-authors extremely tedious. Therefore I do not
> see much of an alternative to a design team that actually
> starts from scratch, unless the chosen proposal is fairly
> ready (which the Renker draft on my opinion is not). If a
> closed design team is a problem, why not have an open one?
> 
> Best Regards,
> 
> -Jari
> 
> Jari T. Malinen
> Nokia Research Center
> 
> > ----
> > >From rene.purnadi@nokia.com  Thu Jan 17 19:09:34 2002
> > X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
> > content-class: urn:content-classes:message
> > MIME-Version: 1.0
> > Content-Type: text/plain;
> >         charset="iso-8859-1"
> > Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> > Date: Thu, 17 Jan 2002 18:09:26 -0600
> > X-MS-Has-Attach:
> > X-MS-TNEF-Correlator:
> > Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> > Thread-Index: AcGfjB5vADj3orhMSASYBVeaoRZw8wAJu5gQ
> > From: "Purnadi Rene (NRC/Dallas)" 
> > To: "'ext James Kempf'" , 
> > Cc: , "Allison Mankin" 
> > X-OriginalArrivalTime: 18 Jan 2002 00:09:26.0999 (UTC) FILETIME=[645F6E70:01C19FB4]
> > Content-Transfer-Encoding: 8bit
> > X-MIME-Autoconverted: from quoted-printable to 8bit by newdev.harvard.edu id g0I09TS23621
> >
> > James,
> >
> > We vote to re-open the selection phase. By the way, Rene Purnadi is one
> > of the author in the draft koodli and his involvement in this vote is
> > not based on 'sour grapes' but to seek a valid selection procedure.
> >
> > Thank you.
> >
> > Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene Purnadi
> > and Srinivas Sreemanthula
> > Nokia Research Center
> >
> > -----Original Message-----
> > From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> > Sent: Thursday, January 17, 2002 1:18 PM
> > To: seamoby@ietf.org
> > Cc: sob@harvard.edu; Allison Mankin
> > Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> >
> > All,
> >
> > Pat and I made a selection for what to start with, not what to end with.
> > The WG will determine what the final technology looks like.
> >
> > 1) If you want to support or disagree with the selection of the starting
> >  ID, say so now please.
> >
> > 2) If there is not consensus that we should re-open the selection phase,
> > then we will move forward based on the selection in the next few days.
> >
> > 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
> 
> _______________________________________________
> 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 Jan 17 23:35: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 XAA22307
	for ; Thu, 17 Jan 2002 23:35: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 XAA11660;
	Thu, 17 Jan 2002 23:24: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 XAA11563
	for ; Thu, 17 Jan 2002 23: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 XAA21719
	for ; Thu, 17 Jan 2002 23:24:10 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 17 Jan 2002 20:23:43 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Jari T. Malinen'" ,
        Scott Bradner
	 
Cc: kempf@docomolabs-usa.com, rene.purnadi@nokia.com, seamoby@ietf.org,
        mankin@isi.edu
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Thu, 17 Jan 2002 20:23:23 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19FD7.DE295400"
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_01C19FD7.DE295400
Content-Type: text/plain

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

Jari,

Although I am beginning to feel like a broken record, we didn't just
"pick" one. It was based on the input from the assessment team. The
draft that most closely matched the requirements, approved by the WG,
is the one that we decided on.

In any case, let's finish this concensus call and see where it leads.

PatC

- -----Original Message-----
From: Jari T. Malinen [mailto:jmalinen@iprg.nokia.com] 
Sent: Thursday, January 17, 2002 7:10 PM
To: Scott Bradner
Cc: kempf@docomolabs-usa.com; rene.purnadi@nokia.com;
seamoby@ietf.org; mankin@isi.edu
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision


Scott,

> 
> > We vote to re-open
> 
> just to be sure - each of the listed people on their own came to
> that  conclusion?

It is obvious we did discuss this issue among the co-authors, hence
the common expression of opinion by Rene. However, I have to admit I
also on my own favor 2. The selection process did not generate
support for alternative 1. If an I-D written by an evaluation team is
such that the selection outcome is not at all readable from it, as
was the case at SLC, it gives a precedence for other working groups.
More straightforward would have been to say that an AD and the wg
chairs simply picked the protocol.

I would like to be informed if I am wrong, but to
my understanding that is not how standardization in the
IETF is supposed to happen. If it is, that unfortunately
has implications as of how we can motivate the usefulness
of the IETF process from our perspective. Formation of a
rough concensus among participants (those expressing their
opinion) is a more understandable way. It may be less efficient, but
more acceptable to parties, who, afterall, should finally adopt the
chosen solution, implement it, test it in interops and defend its
usefulness to various parties challenging it.

I have to say I am not totally happy with any of the proposals and
technically I do not see it as a big issue which of the protocols is
the starting point, the process is the more worrying aspect. Also, we
know from too many wg:s that once there is a wg item, even just as a
starting point, the authors seem to be defensive in a manner making
realistic possibilities to accept changes proposed by non-authors
extremely tedious. Therefore I do not see much of an alternative to a
design team that actually starts from scratch, unless the chosen
proposal is fairly ready (which the Renker draft on my opinion is
not). If a closed design team is a problem, why not have an open one?

Best Regards,

- -Jari

Jari T. Malinen
Nokia Research Center

> ----
> >From rene.purnadi@nokia.com  Thu Jan 17 19:09:34 2002
> X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
> content-class: urn:content-classes:message
> MIME-Version: 1.0
> Content-Type: text/plain;
>         charset="iso-8859-1"
> Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging 
> Decision
> Date: Thu, 17 Jan 2002 18:09:26 -0600
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
> Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging
> Decision Thread-Index: AcGfjB5vADj3orhMSASYBVeaoRZw8wAJu5gQ
> From: "Purnadi Rene (NRC/Dallas)" 
> To: "'ext James Kempf'" ,
>  Cc: , "Allison Mankin"
> 
> X-OriginalArrivalTime: 18 Jan 2002 00:09:26.0999 (UTC)
> FILETIME=[645F6E70:01C19FB4] Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by
> newdev.harvard.edu id g0I09TS23621  
> 
> James,
> 
> We vote to re-open the selection phase. By the way, Rene Purnadi is
>  one of the author in the draft koodli and his involvement in this
> vote  is not based on 'sour grapes' but to seek a valid selection
> procedure.  
> 
> Thank you.
> 
> Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene 
> Purnadi and Srinivas Sreemanthula Nokia Research Center
> 
> -----Original Message-----
> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Thursday, January 17, 2002 1:18 PM
> To: seamoby@ietf.org
> Cc: sob@harvard.edu; Allison Mankin
> Subject: [Seamoby] Concensus Call:Reaching Closure on Paging
> Decision  
> 
> All,
> 
> Pat and I made a selection for what to start with, not what to end 
> with. The WG will determine what the final technology looks like.
> 
> 1) If you want to support or disagree with the selection of the 
> starting  ID, say so now please.
> 
> 2) If there is not consensus that we should re-open the selection 
> phase, then we will move forward based on the selection in the next
>  few days.
> 
> 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

_______________________________________________
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/AwUBPEejOzN1fXKoxmisEQLv1wCggqMTWsBVKPj51QlhhaTLbUATcs0AoKOF
rIZpqNruWjx8UAtY/Jz9ZvfC
=KkvU
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C19FD7.DE295400
Content-Type: text/html






RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision




 

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

Hash: SHA1




Jari,




Although I am beginning to feel like a broken record, we didn't just

"pick" one. It was based on the input from the assessment team. The

draft that most closely matched the requirements, approved by the WG,

is the one that we decided on.




In any case, let's finish this concensus call and see where it leads.




PatC




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

From: Jari T. Malinen [mailto:jmalinen@iprg.nokia.com] 

Sent: Thursday, January 17, 2002 7:10 PM

To: Scott Bradner

Cc: kempf@docomolabs-usa.com; rene.purnadi@nokia.com;

seamoby@ietf.org; mankin@isi.edu

Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging

Decision






Scott,




> 

> > We vote to re-open

> 

> just to be sure - each of the listed people on their own came to

> that  conclusion?




It is obvious we did discuss this issue among the co-authors, hence

the common expression of opinion by Rene. However, I have to admit I

also on my own favor 2. The selection process did not generate

support for alternative 1. If an I-D written by an evaluation team is

such that the selection outcome is not at all readable from it, as

was the case at SLC, it gives a precedence for other working groups.

More straightforward would have been to say that an AD and the wg

chairs simply picked the protocol.




I would like to be informed if I am wrong, but to

my understanding that is not how standardization in the

IETF is supposed to happen. If it is, that unfortunately

has implications as of how we can motivate the usefulness

of the IETF process from our perspective. Formation of a

rough concensus among participants (those expressing their

opinion) is a more understandable way. It may be less efficient, but

more acceptable to parties, who, afterall, should finally adopt the

chosen solution, implement it, test it in interops and defend its

usefulness to various parties challenging it.




I have to say I am not totally happy with any of the proposals and

technically I do not see it as a big issue which of the protocols is

the starting point, the process is the more worrying aspect. Also, we

know from too many wg:s that once there is a wg item, even just as a

starting point, the authors seem to be defensive in a manner making

realistic possibilities to accept changes proposed by non-authors

extremely tedious. Therefore I do not see much of an alternative to a

design team that actually starts from scratch, unless the chosen

proposal is fairly ready (which the Renker draft on my opinion is

not). If a closed design team is a problem, why not have an open one?




Best Regards,




- -Jari




Jari T. Malinen

Nokia Research Center




> ----

> >From rene.purnadi@nokia.com  Thu Jan 17 19:09:34 2002

> X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0

> content-class: urn:content-classes:message

> MIME-Version: 1.0

> Content-Type: text/plain;

>         charset="iso-8859-1"

> Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging 

> Decision

> Date: Thu, 17 Jan 2002 18:09:26 -0600

> X-MS-Has-Attach:

> X-MS-TNEF-Correlator:

> Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging

> Decision Thread-Index: AcGfjB5vADj3orhMSASYBVeaoRZw8wAJu5gQ

> From: "Purnadi Rene (NRC/Dallas)" <rene.purnadi@nokia.com>

> To: "'ext James Kempf'" <kempf@docomolabs-usa.com>,

> <seamoby@ietf.org> Cc: <sob@harvard.edu>, "Allison Mankin"

> <mankin@isi.edu>

> X-OriginalArrivalTime: 18 Jan 2002 00:09:26.0999 (UTC)

> FILETIME=[645F6E70:01C19FB4] Content-Transfer-Encoding: 8bit

> X-MIME-Autoconverted: from quoted-printable to 8bit by

> newdev.harvard.edu id g0I09TS23621  

> 

> James,

> 

> We vote to re-open the selection phase. By the way, Rene Purnadi is

>  one of the author in the draft koodli and his involvement in this

> vote  is not based on 'sour grapes' but to seek a valid selection

> procedure.  

> 

> Thank you.

> 

> Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene 

> Purnadi and Srinivas Sreemanthula Nokia Research Center

> 

> -----Original Message-----

> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]

> Sent: Thursday, January 17, 2002 1:18 PM

> To: seamoby@ietf.org

> Cc: sob@harvard.edu; Allison Mankin

> Subject: [Seamoby] Concensus Call:Reaching Closure on Paging

> Decision  

> 

> All,

> 

> Pat and I made a selection for what to start with, not what to end 

> with. The WG will determine what the final technology looks like.

> 

> 1) If you want to support or disagree with the selection of the 

> starting  ID, say so now please.

> 

> 2) If there is not consensus that we should re-open the selection 

> phase, then we will move forward based on the selection in the next

>  few days.

> 

> 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




_______________________________________________

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/AwUBPEejOzN1fXKoxmisEQLv1wCggqMTWsBVKPj51QlhhaTLbUATcs0AoKOF

rIZpqNruWjx8UAtY/Jz9ZvfC

=KkvU

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





------_=_NextPart_001_01C19FD7.DE295400--

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


From seamoby-admin@ietf.org  Thu Jan 17 23:35: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 XAA22320
	for ; Thu, 17 Jan 2002 23:35: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 XAA10609;
	Thu, 17 Jan 2002 23:21: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 XAA10473
	for ; Thu, 17 Jan 2002 23: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 XAA21549
	for ; Thu, 17 Jan 2002 23:20:57 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 17 Jan 2002 20:20:28 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Purnadi Rene (NRC/Dallas)'" ,
        "'ext James Kempf'" , seamoby@ietf.org
Cc: sob@harvard.edu, Allison Mankin 
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Thu, 17 Jan 2002 20:19:11 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19FD7.47E883D0"
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_01C19FD7.47E883D0
Content-Type: text/plain

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

Would it be possible to have folks speak for themselves? It would
sure be easier than to get into a debate later about folks not
agreeing with their comments that were posted by a third party.

PatC

- -----Original Message-----
From: Purnadi Rene (NRC/Dallas) [mailto:rene.purnadi@nokia.com] 
Sent: Thursday, January 17, 2002 4:09 PM
To: 'ext James Kempf'; seamoby@ietf.org
Cc: sob@harvard.edu; Allison Mankin
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision


James,

We vote to re-open the selection phase. By the way, Rene Purnadi is
one of the author in the draft koodli and his involvement in this
vote is not based on 'sour grapes' but to seek a valid selection
procedure.

Thank you.

Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene
Purnadi and Srinivas Sreemanthula Nokia Research Center

- -----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Thursday, January 17, 2002 1:18 PM
To: seamoby@ietf.org
Cc: sob@harvard.edu; Allison Mankin
Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision


All,

Pat and I made a selection for what to start with, not what to end
with. The WG will determine what the final technology looks like.

1) If you want to support or disagree with the selection of the
starting  ID, say so now please.

2) If there is not consensus that we should re-open the selection
phase, then we will move forward based on the selection in the next
few days.

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/AwUBPEeiPzN1fXKoxmisEQI43wCgtvdbD0lHDNfFv4tg3195L/69TOgAn06q
1nD1bDrYG1ZsbKauP7n3BYT9
=tZ79
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C19FD7.47E883D0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Concensus Call:Reaching Closure on Paging =
Decision




 

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

Hash: SHA1




Would it be possible to have folks speak for =
themselves? It would

sure be easier than to get into a debate later about =
folks not

agreeing with their comments that were posted by a =
third party.




PatC




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

From: Purnadi Rene (NRC/Dallas) [mailto:rene.purnadi@nokia.com=
] 

Sent: Thursday, January 17, 2002 4:09 PM

To: 'ext James Kempf'; seamoby@ietf.org

Cc: sob@harvard.edu; Allison Mankin

Subject: RE: [Seamoby] Concensus Call:Reaching =
Closure on Paging

Decision






James,




We vote to re-open the selection phase. By the way, =
Rene Purnadi is

one of the author in the draft koodli and his =
involvement in this

vote is not based on 'sour grapes' but to seek a =
valid selection

procedure.




Thank you.




Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. =
Malinen, Rene

Purnadi and Srinivas Sreemanthula Nokia Research =
Center




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

From: ext James Kempf [mailto:kempf@docomolabs-usa.com=
]

Sent: Thursday, January 17, 2002 1:18 PM

To: seamoby@ietf.org

Cc: sob@harvard.edu; Allison Mankin

Subject: [Seamoby] Concensus Call:Reaching Closure =
on Paging Decision






All,




Pat and I made a selection for what to start with, =
not what to end

with. The WG will determine what the final =
technology looks like.




1) If you want to support or disagree with the =
selection of the

starting  ID, say so now please.




2) If there is not consensus that we should re-open =
the selection

phase, then we will move forward based on the =
selection in the next

few days.




Thanx.




          &nb=
sp; 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/AwUBPEeiPzN1fXKoxmisEQI43wCgtvdbD0lHDNfFv4tg3195L/69TOgAn06=
q

1nD1bDrYG1ZsbKauP7n3BYT9

=3DtZ79

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





------_=_NextPart_001_01C19FD7.47E883D0--

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


From seamoby-admin@ietf.org  Fri Jan 18 01:33: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 BAA23756
	for ; Fri, 18 Jan 2002 01:33: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 BAA23123;
	Fri, 18 Jan 2002 01: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 BAA23062
	for ; Fri, 18 Jan 2002 01:11:44 -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 BAA23633
	for ; Fri, 18 Jan 2002 01:11:42 -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 WAA12367;
	Thu, 17 Jan 2002 22:11:01 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0I6Ax510043;
	Thu, 17 Jan 2002 22:10:59 -0800
X-mProtect:  Thu, 17 Jan 2002 22:10:59 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com smtpdDCRMEK; Thu, 17 Jan 2002 22:10:58 PST
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id WAA25799; Thu, 17 Jan 2002 22:10:59 -0800 (PST)
Message-ID: <3C47BC73.AFE6CD30@iprg.nokia.com>
Date: Thu, 17 Jan 2002 22:10:59 -0800
From: "Jari T. Malinen" 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Pat R. Calhoun" 
CC: Scott Bradner , kempf@docomolabs-usa.com,
        rene.purnadi@nokia.com, seamoby@ietf.org, mankin@isi.edu
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
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,

> Jari,
> 
> Although I am beginning to feel like a broken record, we didn't just
> "pick" one. It was based on the input from the assessment team. The
> draft that most closely matched the requirements, approved by the WG,
> is the one that we decided on.
 
Maybe I misread the mail by James but the quote below seems not exactly
to be what you say. The team did not recommed a draft to pick (at least
so James's text says), but either to have a new design round or harmonization
of multiple protocols. The latter could also mean design team work.

>> Given that the assessment team's recommendation about which draft to accept
>> was indeterminate, a decision team was formed by the two Working Group
>> co-chairs, with the Area Director providing advice. The decision team decided
>> to proceed toward selecting a draft as the basis of a harmonized protocol

The input from the team was insufficient so chairs decided to form
a new team to do the actual selection. Technically sound argumentation
may have been selectively used but procedurally it sets a problematic example.

Particularly, the text describing the decision actually outlines a particular
new compositional design suggesting selective components from the various
proposals to be in the solution. In fact, one could also read this as
the wg chairs (re)designing (an outline for the overall) solution. Are you
sure you'd like this to also happen in any other working group? Maybe
this was unintentional and the design components enumerated were given
as examples (this as a suggestion to modify the text)?

The worry above may be out of its true proportions in this context but it
would still be rather important to procedurally be as precise as possible.
Hence my wish for opening the process e.g. for a design team.

> In any case, let's finish this concensus call and see where it leads.

OK.
 
> PatC

BR,

-Jari

> - -----Original Message-----
> From: Jari T. Malinen [mailto:jmalinen@iprg.nokia.com]
> Sent: Thursday, January 17, 2002 7:10 PM
> To: Scott Bradner
> Cc: kempf@docomolabs-usa.com; rene.purnadi@nokia.com;
> seamoby@ietf.org; mankin@isi.edu
> Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
> Decision
> 
> Scott,
> 
> >
> > > We vote to re-open
> >
> > just to be sure - each of the listed people on their own came to
> > that  conclusion?
> 
> It is obvious we did discuss this issue among the co-authors, hence
> the common expression of opinion by Rene. However, I have to admit I
> also on my own favor 2. The selection process did not generate
> support for alternative 1. If an I-D written by an evaluation team is
> such that the selection outcome is not at all readable from it, as
> was the case at SLC, it gives a precedence for other working groups.
> More straightforward would have been to say that an AD and the wg
> chairs simply picked the protocol.
> 
> I would like to be informed if I am wrong, but to
> my understanding that is not how standardization in the
> IETF is supposed to happen. If it is, that unfortunately
> has implications as of how we can motivate the usefulness
> of the IETF process from our perspective. Formation of a
> rough concensus among participants (those expressing their
> opinion) is a more understandable way. It may be less efficient, but
> more acceptable to parties, who, afterall, should finally adopt the
> chosen solution, implement it, test it in interops and defend its
> usefulness to various parties challenging it.
> 
> I have to say I am not totally happy with any of the proposals and
> technically I do not see it as a big issue which of the protocols is
> the starting point, the process is the more worrying aspect. Also, we
> know from too many wg:s that once there is a wg item, even just as a
> starting point, the authors seem to be defensive in a manner making
> realistic possibilities to accept changes proposed by non-authors
> extremely tedious. Therefore I do not see much of an alternative to a
> design team that actually starts from scratch, unless the chosen
> proposal is fairly ready (which the Renker draft on my opinion is
> not). If a closed design team is a problem, why not have an open one?
> 
> Best Regards,
> 
> - -Jari
> 
> Jari T. Malinen
> Nokia Research Center
> 
> > ----
> > >From rene.purnadi@nokia.com  Thu Jan 17 19:09:34 2002
> > X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
> > content-class: urn:content-classes:message
> > MIME-Version: 1.0
> > Content-Type: text/plain;
> >         charset="iso-8859-1"
> > Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging
> > Decision
> > Date: Thu, 17 Jan 2002 18:09:26 -0600
> > X-MS-Has-Attach:
> > X-MS-TNEF-Correlator:
> > Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging
> > Decision Thread-Index: AcGfjB5vADj3orhMSASYBVeaoRZw8wAJu5gQ
> > From: "Purnadi Rene (NRC/Dallas)" 
> > To: "'ext James Kempf'" ,
> >  Cc: , "Allison Mankin"
> > 
> > X-OriginalArrivalTime: 18 Jan 2002 00:09:26.0999 (UTC)
> > FILETIME=[645F6E70:01C19FB4] Content-Transfer-Encoding: 8bit
> > X-MIME-Autoconverted: from quoted-printable to 8bit by
> > newdev.harvard.edu id g0I09TS23621
> >
> > James,
> >
> > We vote to re-open the selection phase. By the way, Rene Purnadi is
> >  one of the author in the draft koodli and his involvement in this
> > vote  is not based on 'sour grapes' but to seek a valid selection
> > procedure.
> >
> > Thank you.
> >
> > Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene
> > Purnadi and Srinivas Sreemanthula Nokia Research Center
> >
> > -----Original Message-----
> > From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> > Sent: Thursday, January 17, 2002 1:18 PM
> > To: seamoby@ietf.org
> > Cc: sob@harvard.edu; Allison Mankin
> > Subject: [Seamoby] Concensus Call:Reaching Closure on Paging
> > Decision
> >
> > All,
> >
> > Pat and I made a selection for what to start with, not what to end
> > with. The WG will determine what the final technology looks like.
> >
> > 1) If you want to support or disagree with the selection of the
> > starting  ID, say so now please.
> >
> > 2) If there is not consensus that we should re-open the selection
> > phase, then we will move forward based on the selection in the next
> >  few days.
> >
> > 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
> 
> _______________________________________________
> 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/AwUBPEejOzN1fXKoxmisEQLv1wCggqMTWsBVKPj51QlhhaTLbUATcs0AoKOF
> rIZpqNruWjx8UAtY/Jz9ZvfC
> =KkvU
> -----END PGP SIGNATURE-----

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


From seamoby-admin@ietf.org  Fri Jan 18 01:47: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 BAA23973
	for ; Fri, 18 Jan 2002 01:47: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 BAA25816;
	Fri, 18 Jan 2002 01:34: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 BAA25787
	for ; Fri, 18 Jan 2002 01:34:09 -0500 (EST)
Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23770
	for ; Fri, 18 Jan 2002 01:34:07 -0500 (EST)
Received: from punasaari.cs.Helsinki.FI (IDENT:jmanner@punasaari.cs.Helsinki.FI [128.214.11.52])
	by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g0I6Xrp27708;
	Fri, 18 Jan 2002 08:33:53 +0200
Date: Fri, 18 Jan 2002 08:33:51 +0200 (EET)
From: Jukka Manner 
To: James Kempf 
cc: Phil Neumiller , 
Subject: Re: [Seamoby] Terminology Draft Needed
In-Reply-To: <005d01c19eb1$df1cc850$7e6015ac@T23KEMPF>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


	Hi,

	as I am the editor of the terminology draft, I would like to
continue the work me and my colleagues started a year ago (yes, the
terminology draft is today 1 year and 6 days old). Since the document is
already 28 pages long, I would rather add only a bare minimal set of
security terminology, only the ones absolutely needed in
Seamoby/MIP/MANET---a full security terminology would belong to another
WG.

	Second, the pointer Charlie gave is false. It is the old version
from summer, although it somehow has the "03" in the name... hmm... A new
version has been on the IETF draft repository since November. This is the
right version to discuss:

        Title           : Mobility Related Terminology
        Author(s)       : J. Manner et al.
        Filename        : draft-manner-seamoby-terms-03.txt
        Pages           : 28
        Date            : 28-Nov-01

There is a need for common definitions of terminology in the work to
be done around IP mobility. This memo defines terms for mobility
related terminology. It is intended as a living document for use by
the Seamoby working group, and especially for use in Seamoby drafts
and in WG discussions. Other working groups dealing with mobility may
also take advantage of this terminology

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-manner-seamoby-terms-03.txt

	Regards,

	Jukka



On Wed, 16 Jan 2002, James Kempf wrote:

> Phil,
>
> Pat and I were planning on sending a message out about this. I had asked
> Charlie for a pointer to
> the draft, you have helpfully supplied it (see below). Thanx.
>
> So we have one strong endorsement of adopting the Charlie's terminology
> draft as a WG item.
> Anyone else have strong feelings one way or the other on the issue?
>
>             jak
>
> ----- Original Message -----
> From: "Phil Neumiller" 
> To: ; 
> Sent: Wednesday, January 16, 2002 6:39 AM
> Subject: [Seamoby] Terminology Draft Needed
>
>
> > Hi,
> >
> > I have seen Charlie pull out the terminology draft at least a few
> times! :-)  Why can't
> > some WG chair in SeaMoby or MANET adopt it as WG draft?
> >
> > http://people.nokia.net/~charliep/txt/seamoby/term.txt
> >
> > It seems that many times arguments are over terminology.  IMO, I would
> like to
> > the SeaMoby WG become a bridge between MANET and MIP technologies,
> > especially with respect to AR discovery and CT.  This terminology
> draft would make
> > a very nice addition to the SeaMoby WG draft list.
> >
> > Best regards,
> >
> > Phil
> >
> >
> > _______________________________________________
> > 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 Jan 18 04: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 EAA05169
	for ; Fri, 18 Jan 2002 04: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 EAA02476;
	Fri, 18 Jan 2002 04:39: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 EAA02444
	for ; Fri, 18 Jan 2002 04:39:52 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04902
	for ; Fri, 18 Jan 2002 04:39:46 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0I9dmJ12277
	for ; Fri, 18 Jan 2002 10:39:48 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Jan 18 10:36:07 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Fri, 18 Jan 2002 10:36:24 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C223@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'James Kempf'" ,
        Nakhjiri Madjid-MNAKHJI1
	 ,
        seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Fri, 18 Jan 2002 10:36:05 +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

  > That was only one consideration. Another was that it did not meet
  > the requirement of not being dependent on a specific
  > mobility protocol.
  > 

=> 'considerations' should be part of the requirements. 
Not withstanding that, to go by your comments about the 
process (being murky), I think it seems reasonable 
to reconsider the outcome. Especially since (at least 
it seems to me) that the clarifications for the basis of 
selection have significantly 'expanded' since the meeting
in SLC. 

So maybe the decision needs some revisiting, at least
for reassurances, if nothing else. 
There seems to be some concern from several people.

Hesham


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


From seamoby-admin@ietf.org  Fri Jan 18 07:08: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 HAA07688
	for ; Fri, 18 Jan 2002 07:08: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 GAA07722;
	Fri, 18 Jan 2002 06:56: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 GAA07694
	for ; Fri, 18 Jan 2002 06:56:29 -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 GAA07184;
	Fri, 18 Jan 2002 06:56:26 -0500 (EST)
Message-Id: <200201181156.GAA07184@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: seamoby@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 18 Jan 2002 06:56:26 -0500
Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-cardiscovery-issues-02.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		: Issues in candidate access router discovery for 
                          seamless IP-level handoffs
	Author(s)	: D. Trossen, G. Krishnamurthi, H. Chaskar, J. Kempf
	Filename	: draft-ietf-seamoby-cardiscovery-issues-02.txt
	Pages		: 10
	Date		: 17-Jan-02
	
Handoff in IP mobility protocols involves moving a mobile node's
Layer 3 routing reachability point from one access router to another,
before or after the mobile node has established a Layer 2 connection
with the radio access point that is covered by the new access router.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-seamoby-cardiscovery-issues-02.txt

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-seamoby-cardiscovery-issues-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-seamoby-cardiscovery-issues-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020117103058.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 Jan 18 07:55: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 HAA08933
	for ; Fri, 18 Jan 2002 07:55: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 HAA09583;
	Fri, 18 Jan 2002 07:30: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 HAA09542
	for ; Fri, 18 Jan 2002 07:30:53 -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 HAA08304
	for ; Fri, 18 Jan 2002 07:30:49 -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 g0ICUYH65829;
	Fri, 18 Jan 2002 13:30:34 +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 NAA26657;
	Fri, 18 Jan 2002 13:30:04 +0100
Message-ID: <3C48154C.FCF948C6@ccrle.nec.de>
Date: Fri, 18 Jan 2002 13:30: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: "Jari T. Malinen" 
CC: Scott Bradner , kempf@docomolabs-usa.com,
        rene.purnadi@nokia.com, seamoby@ietf.org, mankin@isi.edu
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <200201180033.g0I0XNN23694@newdev.harvard.edu> <3C479202.74742484@iprg.nokia.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

Jari,

...

> I have to say I am not totally happy with any of the proposals and
> technically I do not see it as a big issue which of the protocols
> is the starting point, the process is the more worrying aspect.
> Also, we know from too many wg:s that once there is a wg item,
> even just as a starting point, the authors seem to be defensive
> in a manner making realistic possibilities to accept changes
> proposed by non-authors extremely tedious. Therefore I do not
> see much of an alternative to a design team that actually
> starts from scratch, unless the chosen proposal is fairly
> ready (which the Renker draft on my opinion is not).

...

it's not ready, as the other proposals are not, too, but in my opinion the design is flexible
and open enough to allow integration of features for enhancement. And anyway, the authors of
draft-renker are open as well to accept additions and changes, otherwise we would not have
submitted the protocol to the WG as a proposal for a base protocol in order to come up with a
WG standard, whose work is to be based on the WG. Work on this WG draft needs to be based on
more authors than the draft currently names. As far as my work as an editor of the WG draft is
concerned, I am 'editor', not 'single author'. Otherwise it would not be a WG document.

Regards,

Marco



> If a
> closed design team is a problem, why not have an open one?
>
> Best Regards,
>
> -Jari
>
> Jari T. Malinen
> Nokia Research Center
>
> > ----
> > >From rene.purnadi@nokia.com  Thu Jan 17 19:09:34 2002
> > X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
> > content-class: urn:content-classes:message
> > MIME-Version: 1.0
> > Content-Type: text/plain;
> >         charset="iso-8859-1"
> > Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> > Date: Thu, 17 Jan 2002 18:09:26 -0600
> > X-MS-Has-Attach:
> > X-MS-TNEF-Correlator:
> > Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> > Thread-Index: AcGfjB5vADj3orhMSASYBVeaoRZw8wAJu5gQ
> > From: "Purnadi Rene (NRC/Dallas)" 
> > To: "'ext James Kempf'" , 
> > Cc: , "Allison Mankin" 
> > X-OriginalArrivalTime: 18 Jan 2002 00:09:26.0999 (UTC) FILETIME=[645F6E70:01C19FB4]
> > Content-Transfer-Encoding: 8bit
> > X-MIME-Autoconverted: from quoted-printable to 8bit by newdev.harvard.edu id g0I09TS23621
> >
> > James,
> >
> > We vote to re-open the selection phase. By the way, Rene Purnadi is one
> > of the author in the draft koodli and his involvement in this vote is
> > not based on 'sour grapes' but to seek a valid selection procedure.
> >
> > Thank you.
> >
> > Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene Purnadi
> > and Srinivas Sreemanthula
> > Nokia Research Center
> >
> > -----Original Message-----
> > From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> > Sent: Thursday, January 17, 2002 1:18 PM
> > To: seamoby@ietf.org
> > Cc: sob@harvard.edu; Allison Mankin
> > Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> >
> > All,
> >
> > Pat and I made a selection for what to start with, not what to end with.
> > The WG will determine what the final technology looks like.
> >
> > 1) If you want to support or disagree with the selection of the starting
> >  ID, say so now please.
> >
> > 2) If there is not consensus that we should re-open the selection phase,
> > then we will move forward based on the selection in the next few days.
> >
> > 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
>
> _______________________________________________
> 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 Jan 18 08:56: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 IAA10923
	for ; Fri, 18 Jan 2002 08:56: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 IAA12171;
	Fri, 18 Jan 2002 08:35: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 IAA12147
	for ; Fri, 18 Jan 2002 08:35:06 -0500 (EST)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10008
	for ; Fri, 18 Jan 2002 08:35:04 -0500 (EST)
Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id C7800Z50; Fri, 18 Jan 2002 08:34:54 -0500
Message-ID: <004d01c1a024$e9cd7eb0$6200000a@meshnetworks.com>
From: "Phil Neumiller" 
To: 
Date: Fri, 18 Jan 2002 08:34:54 -0500
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] The Terminology Draft is it OK to start to discuss?
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

WG Chairs,

Since you have expressed the desire to make the draft:

draft-manner-seamoby-terms-03.txt

a SeaMoby WG draft, and you seem to have the AD's blessing.
Can we begin to discuss this draft on the list?

Thanks,

Phil

-- 
Phillip D. Neumiller
Staff Scientist
MeshNetworks, Inc (www.meshnetworks.com)



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


From seamoby-admin@ietf.org  Fri Jan 18 11:14: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 LAA16808
	for ; Fri, 18 Jan 2002 11:14: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 KAA19171;
	Fri, 18 Jan 2002 10:56: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 KAA19142
	for ; Fri, 18 Jan 2002 10:56:32 -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 KAA15746
	for ; Fri, 18 Jan 2002 10:56:27 -0500 (EST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA14228 for ; Fri, 18 Jan 2002 08:56:26 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA25475 for ; Fri, 18 Jan 2002 08:45:34 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52)
	id ; Fri, 18 Jan 2002 09:56:25 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FD99@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 
To: "'Hesham Soliman (ERA)'" ,
        "'James Kempf'" ,
        Nakhjiri Madjid-MNAKHJI1
	 ,
        seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description
Date: Fri, 18 Jan 2002 09:56:25 -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

I agree with Heshams, going forward with this and all
future "selections", it is better to have a clear selection 
process even before submissions. Rules should not be expanded
or contracted during the selection process.

Madjid

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
Sent: Friday, January 18, 2002 3:36 AM
To: 'James Kempf'; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
Subject: RE: [Seamoby] Paging Protocol Decision Description


  > That was only one consideration. Another was that it did not meet
  > the requirement of not being dependent on a specific
  > mobility protocol.
  > 

=> 'considerations' should be part of the requirements. 
Not withstanding that, to go by your comments about the 
process (being murky), I think it seems reasonable 
to reconsider the outcome. Especially since (at least 
it seems to me) that the clarifications for the basis of 
selection have significantly 'expanded' since the meeting
in SLC. 

So maybe the decision needs some revisiting, at least
for reassurances, if nothing else. 
There seems to be some concern from several people.

Hesham

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


From seamoby-admin@ietf.org  Fri Jan 18 12:39: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 MAA20229
	for ; Fri, 18 Jan 2002 12:39: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 MAA24366;
	Fri, 18 Jan 2002 12:06: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 MAA24334
	for ; Fri, 18 Jan 2002 12:06: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 MAA19014
	for ; Fri, 18 Jan 2002 12:05:59 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0IH5Ge11408;
	Fri, 18 Jan 2002 09:05:16 -0800 (PST)
Message-ID: <005f01c1a042$13962fe0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Jari T. Malinen" ,
        "Scott Bradner" 
Cc: , , 
References: <200201180033.g0I0XNN23694@newdev.harvard.edu> <3C479202.74742484@iprg.nokia.com>
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Fri, 18 Jan 2002 09:03:39 -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

Jari,

>More straightforward
> would have been to say that an AD and the wg chairs simply
> picked the protocol.
> 
> I would like to be informed if I am wrong, but to
> my understanding that is not how standardization in the
> IETF is supposed to happen. 

My understanding, and Allision and Scott can correct
me if I am wrong, is that WG chairs may propose
what drafts should become WG documents. Whether
or not that draft becomes a WG document depends
on WG concensus, which is what this thread is
about. So the process we are following is entirely
consistent with IETF rules and practice.

            jak



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


From seamoby-admin@ietf.org  Fri Jan 18 12:46: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 MAA20527
	for ; Fri, 18 Jan 2002 12:46: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 MAA24914;
	Fri, 18 Jan 2002 12:20: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 MAA24887
	for ; Fri, 18 Jan 2002 12:20:27 -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 MAA19483
	for ; Fri, 18 Jan 2002 12:20:22 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0IHJde11940;
	Fri, 18 Jan 2002 09:19:39 -0800 (PST)
Message-ID: <008d01c1a044$16045ed0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Jukka Manner" 
Cc: "Phil Neumiller" , 
References: 
Subject: Re: [Seamoby] Terminology Draft Needed
Date: Fri, 18 Jan 2002 09:18:03 -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

Jukka,

The issue is the following. Due to a difference between the security
terminology used in RFC 2002, which was also used in
draft-mobileip-ietf-aaa-key-08.txt, and standard IETF security
terminology, there was a misunderstanding about
the nature of the solution in the AAA keys draft that led the IESG
security reviewer to reject the draft. For example,
nowhere in the AAA keys draft does it talk about a session key, but, if
you read the draft, that is really what it is about. Since
the security terminology in RFC 2002 is, in some sense, fairly standard
in the mobile networking community,
it has been suggested that the terminology draft include a short (it
need not be lengthy) mapping between the
terminology used in RFC 2002 and standard IETF security terminology to
avoid this problem in the future.

Do you think this is doable?

            jak

----- Original Message -----
From: "Jukka Manner" 
To: "James Kempf" 
Cc: "Phil Neumiller" ; 
Sent: Thursday, January 17, 2002 10:33 PM
Subject: Re: [Seamoby] Terminology Draft Needed


>
> Hi,
>
> as I am the editor of the terminology draft, I would like to
> continue the work me and my colleagues started a year ago (yes, the
> terminology draft is today 1 year and 6 days old). Since the document
is
> already 28 pages long, I would rather add only a bare minimal set of
> security terminology, only the ones absolutely needed in
> Seamoby/MIP/MANET---a full security terminology would belong to
another
> WG.
>
> Second, the pointer Charlie gave is false. It is the old version
> from summer, although it somehow has the "03" in the name... hmm... A
new
> version has been on the IETF draft repository since November. This is
the
> right version to discuss:
>
>         Title           : Mobility Related Terminology
>         Author(s)       : J. Manner et al.
>         Filename        : draft-manner-seamoby-terms-03.txt
>         Pages           : 28
>         Date            : 28-Nov-01
>
> There is a need for common definitions of terminology in the work to
> be done around IP mobility. This memo defines terms for mobility
> related terminology. It is intended as a living document for use by
> the Seamoby working group, and especially for use in Seamoby drafts
> and in WG discussions. Other working groups dealing with mobility may
> also take advantage of this terminology
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-manner-seamoby-terms-03.txt
>
> Regards,
>
> Jukka
>
>
>
> On Wed, 16 Jan 2002, James Kempf wrote:
>
> > Phil,
> >
> > Pat and I were planning on sending a message out about this. I had
asked
> > Charlie for a pointer to
> > the draft, you have helpfully supplied it (see below). Thanx.
> >
> > So we have one strong endorsement of adopting the Charlie's
terminology
> > draft as a WG item.
> > Anyone else have strong feelings one way or the other on the issue?
> >
> >             jak
> >
> > ----- Original Message -----
> > From: "Phil Neumiller" 
> > To: ; 
> > Sent: Wednesday, January 16, 2002 6:39 AM
> > Subject: [Seamoby] Terminology Draft Needed
> >
> >
> > > Hi,
> > >
> > > I have seen Charlie pull out the terminology draft at least a few
> > times! :-)  Why can't
> > > some WG chair in SeaMoby or MANET adopt it as WG draft?
> > >
> > > http://people.nokia.net/~charliep/txt/seamoby/term.txt
> > >
> > > It seems that many times arguments are over terminology.  IMO, I
would
> > like to
> > > the SeaMoby WG become a bridge between MANET and MIP technologies,
> > > especially with respect to AR discovery and CT.  This terminology
> > draft would make
> > > a very nice addition to the SeaMoby WG draft list.
> > >
> > > Best regards,
> > >
> > > Phil
> > >
> > >
> > > _______________________________________________
> > > 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 Jan 18 12:48: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 MAA20589
	for ; Fri, 18 Jan 2002 12:48: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 MAA25058;
	Fri, 18 Jan 2002 12:25: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 MAA25031
	for ; Fri, 18 Jan 2002 12:25:08 -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 MAA19650
	for ; Fri, 18 Jan 2002 12:25:04 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0IHOae12105;
	Fri, 18 Jan 2002 09:24:36 -0800 (PST)
Message-ID: <00d201c1a044$c6e43770$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Phil Neumiller" , 
References: <004d01c1a024$e9cd7eb0$6200000a@meshnetworks.com>
Subject: Re: [Seamoby] The Terminology Draft is it OK to start to discuss?
Date: Fri, 18 Jan 2002 09:22:59 -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

Please do.

I haven't seen anyone yet say that they don't want it to be
a WG draft.

            jak

----- Original Message ----- 
From: "Phil Neumiller" 
To: 
Sent: Friday, January 18, 2002 5:34 AM
Subject: [Seamoby] The Terminology Draft is it OK to start to discuss?


> WG Chairs,
> 
> Since you have expressed the desire to make the draft:
> 
> draft-manner-seamoby-terms-03.txt
> 
> a SeaMoby WG draft, and you seem to have the AD's blessing.
> Can we begin to discuss this draft on the list?
> 
> Thanks,
> 
> Phil
> 
> -- 
> Phillip D. Neumiller
> Staff Scientist
> MeshNetworks, Inc (www.meshnetworks.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 Jan 18 14:25: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 OAA24163
	for ; Fri, 18 Jan 2002 14:25: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 OAA29622;
	Fri, 18 Jan 2002 14:01: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 OAA29591
	for ; Fri, 18 Jan 2002 14:01:49 -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 OAA23568
	for ; Fri, 18 Jan 2002 14:01:45 -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 LAA15348;
	Fri, 18 Jan 2002 11:01:06 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0IJ15e19143;
	Fri, 18 Jan 2002 11:01:05 -0800
X-mProtect:  Fri, 18 Jan 2002 11:01:05 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com smtpduI44Ya; Fri, 18 Jan 2002 11:01:03 PST
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id LAA26892; Fri, 18 Jan 2002 11:01:04 -0800 (PST)
Message-ID: <3C4870F0.3CAB2777@iprg.nokia.com>
Date: Fri, 18 Jan 2002 11:01:04 -0800
From: "Jari T. Malinen" 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: Scott Bradner , rene.purnadi@nokia.com, seamoby@ietf.org,
        mankin@isi.edu
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <200201180033.g0I0XNN23694@newdev.harvard.edu> <3C479202.74742484@iprg.nokia.com> <005f01c1a042$13962fe0$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 Kempf wrote:
> 
> Jari,
> 
> >More straightforward
> > would have been to say that an AD and the wg chairs simply
> > picked the protocol.
> >
> > I would like to be informed if I am wrong, but to
> > my understanding that is not how standardization in the
> > IETF is supposed to happen.
> 
> My understanding, and Allision and Scott can correct
> me if I am wrong, is that WG chairs may propose
> what drafts should become WG documents. Whether
> or not that draft becomes a WG document depends
> on WG concensus, which is what this thread is
> about. So the process we are following is entirely
> consistent with IETF rules and practice.

What you say seems ok and correct, but only if everybody
do have an equal vote in the discussion. For a while it
looked like votes and opinions differing from the
decision were disregarded by wg chairs when coming
from participants of work with other protocols,
which made it look as if a decision was already made
without really involving whole of the wg.

In summary: chairs to decide the wg protocol: not ok,
to propose for the wg to consider: ok. That's the
difference I was after.

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

BR,

-Jari

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


From seamoby-admin@ietf.org  Fri Jan 18 17:23: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 RAA29161
	for ; Fri, 18 Jan 2002 17:23: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 QAA06408;
	Fri, 18 Jan 2002 16:59: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 QAA06381
	for ; Fri, 18 Jan 2002 16:59:41 -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 QAA28650
	for ; Fri, 18 Jan 2002 16:59:37 -0500 (EST)
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 g0IM1CQ22867
	for ; Fri, 18 Jan 2002 16:01:12 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 18 Jan 2002 15:59:39 -0600
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 18 Jan 2002 15:59:39 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Consensus Call:Reaching Closure on Paging Decision
Date: Fri, 18 Jan 2002 15:59:38 -0600
Message-ID: <82ECD4351A4A9547957C606034A3CB8D0B02D0@daebe005.NOE.Nokia.com>
Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Thread-Index: AcGfuBkZVw4WtxPOQOuDzSRmHxgZvwAsIi9w
From: "Faccin Stefano (NRC/Dallas)" 
To: "'ext Scott  Bradner'" , ,
        "Purnadi Rene (NRC/Dallas)" ,
        
Cc: 
X-OriginalArrivalTime: 18 Jan 2002 21:59:39.0105 (UTC) FILETIME=[6CD6DD10:01C1A06B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA06382
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

Scott,

I support the position that Rene expressed on my behalf. Without going
into the details with the risk to inflame and confuse even more the
discussion, I do not agree with the way the decision for the WG draft
has been made. 

Personally I do not believe that just re-opening the selection of the
starting ID is the solution. My first choice would be the creation of a
design team that starts from scratch, i.e. none of the current IDs is
the starting point. Whether the team is open or closed is not important
to me. 

If this is not acceptable, although I do not see any other realistic
solution my second choice is to support re-opening the selection process
for a starting ID. However, this time we need to clearly define up-front
how the decision is going to be made and avoid any decision that may be
interpreted as shady and lead to further delays.

Cheers,
Stefano

-----Original Message-----
From: ext Scott Bradner [mailto:sob@harvard.edu]
Sent: Thursday, January 17, 2002 6:33 PM
To: kempf@docomolabs-usa.com; Purnadi Rene (NRC/Dallas);
seamoby@ietf.org
Cc: mankin@isi.edu; sob@harvard.edu
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision


> We vote to re-open

just to be sure - each of the listed people on their own came to that
conclusion?

----
From rene.purnadi@nokia.com  Thu Jan 17 19:09:34 2002
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision
Date: Thu, 17 Jan 2002 18:09:26 -0600
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision
Thread-Index: AcGfjB5vADj3orhMSASYBVeaoRZw8wAJu5gQ
From: "Purnadi Rene (NRC/Dallas)" 
To: "'ext James Kempf'" , 
Cc: , "Allison Mankin" 
X-OriginalArrivalTime: 18 Jan 2002 00:09:26.0999 (UTC)
FILETIME=[645F6E70:01C19FB4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by
newdev.harvard.edu id g0I09TS23621

James,

We vote to re-open the selection phase. By the way, Rene Purnadi is one
of the author in the draft koodli and his involvement in this vote is
not based on 'sour grapes' but to seek a valid selection procedure.

Thank you.

Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene Purnadi
and Srinivas Sreemanthula
Nokia Research Center

-----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Thursday, January 17, 2002 1:18 PM
To: seamoby@ietf.org
Cc: sob@harvard.edu; Allison Mankin
Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision


All,

Pat and I made a selection for what to start with, not what to end with.
The WG will determine what the final technology looks like.

1) If you want to support or disagree with the selection of the starting
 ID, say so now please.

2) If there is not consensus that we should re-open the selection phase,
then we will move forward based on the selection in the next few days.

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

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


From seamoby-admin@ietf.org  Fri Jan 18 18: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 SAA00941
	for ; Fri, 18 Jan 2002 18: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 SAA09475;
	Fri, 18 Jan 2002 18:26: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 SAA09444
	for ; Fri, 18 Jan 2002 18:26: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 SAA00707
	for ; Fri, 18 Jan 2002 18:26:44 -0500 (EST)
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 g0INOGQ04514
	for ; Fri, 18 Jan 2002 17:24:16 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 18 Jan 2002 17:22:42 -0600
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 18 Jan 2002 17:22:42 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Fri, 18 Jan 2002 17:22:42 -0600
Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF646@daebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Thread-Index: AcGfjAvUdMkpPrTuTXeqlUqz4oYjZwA6JAAw
From: "Sreemanthula Srinivas (NRC/Dallas)" 
To: "'ext James Kempf'" , 
Cc: , "Allison Mankin" 
X-OriginalArrivalTime: 18 Jan 2002 23:22:42.0490 (UTC) FILETIME=[072B11A0:01C1A077]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA09445
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,
After all these discussions, I feel that the selection or reselection of
any particular proposal as a starting point seems like an impossible
feat to me.  Particularly because none of them have met the requirements
completely, not even draft-renker.  I can comment on this because I was
part of the evaluation team and I was the evaluator for Renker proposal.


For the next step, I join Stefano and Bechet in proposing a team to
design the protocol from scratch.  Although it is not clear, I assume
this consensus call covers this option also.

Thanks,
Srini

-----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: 17 January, 2002 1:18 PM
To: seamoby@ietf.org
Cc: sob@harvard.edu; Allison Mankin
Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision


All,

Pat and I made a selection for what to start with, not what to end with.
The WG will determine what the final technology looks like.

1) If you want to support or disagree with the selection of the starting
 ID, say so now please.

2) If there is not consensus that we should re-open the selection phase,
then we will move forward based on the selection in the next few days.

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  Fri Jan 18 20:07: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 UAA02082
	for ; Fri, 18 Jan 2002 20:07: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 TAA11472;
	Fri, 18 Jan 2002 19:51: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 TAA11444
	for ; Fri, 18 Jan 2002 19:51:45 -0500 (EST)
Received: from smtp.tari.toshiba.com ([207.122.4.194])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01940
	for ; Fri, 18 Jan 2002 19:51:41 -0500 (EST)
Received: from localhost
	by smtp.tari.toshiba.com (8.9.1/3.7W-011204) with ESMTP id TAA08062;
	Fri, 18 Jan 2002 19:54:20 -0500
Date: Fri, 18 Jan 2002 19:54:26 -0500 (EST)
Message-Id: <20020118.195426.91278056.sbaba@tari.toshiba.com>
To: Srinivas.Sreemanthula@nokia.com
Cc: seamoby@ietf.org, sob@harvard.edu, mankin@isi.edu
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
From: Baba S 
In-Reply-To: <07EE0E021034014F99A57B032BC9C0E50FF646@daebe001.NOE.Nokia.com>
References: <07EE0E021034014F99A57B032BC9C0E50FF646@daebe001.NOE.Nokia.com>
X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI)
Mime-Version: 1.0
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 Srini,

I also like design team idea, as I have the same
view about the re-selection with you and Stefano.
But my problem is the fact that I'm not sure about
the details of design team.

For example, I prefer to put whole five documents
on the table instead of to start from the scratch.
To me, starting from the scratch means 'let's go
back to August, 2001'. It seems too much.
Since starting with five drafts seems 'let's go
back to November, 2001' and I think the assessment
draft is still helpful to design, I expect this
can work and save the time somehow.

How about the editor. I think Marco is still
fine as an editor, since he is showing his
flexibility and respectfulness so far, however
he is also under a hard situation now. As it just
happens to him, why do we need to spend a time to
change this fact?

I may be too optimistic. We may not be able to
escape going back to the green field situation anyway.
But I'm just wondering if there is a way to
save a time. So taking a time to discuss
this kind of details is not my intention either.
Though, let me put my 2 bits.

Have a good weekend!

baba//


From: "Sreemanthula Srinivas (NRC/Dallas)" 
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Fri, 18 Jan 2002 17:22:42 -0600

> Hi all,
> After all these discussions, I feel that the selection or reselection of
> any particular proposal as a starting point seems like an impossible
> feat to me.  Particularly because none of them have met the requirements
> completely, not even draft-renker.  I can comment on this because I was
> part of the evaluation team and I was the evaluator for Renker proposal.
> 
> 
> For the next step, I join Stefano and Bechet in proposing a team to
> design the protocol from scratch.  Although it is not clear, I assume
> this consensus call covers this option also.
> 
> Thanks,
> Srini
> 
> -----Original Message-----
> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: 17 January, 2002 1:18 PM
> To: seamoby@ietf.org
> Cc: sob@harvard.edu; Allison Mankin
> Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> 
> 
> All,
> 
> Pat and I made a selection for what to start with, not what to end with.
> The WG will determine what the final technology looks like.
> 
> 1) If you want to support or disagree with the selection of the starting
>  ID, say so now please.
> 
> 2) If there is not consensus that we should re-open the selection phase,
> then we will move forward based on the selection in the next few days.
> 
> 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


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


From seamoby-admin@ietf.org  Mon Jan 21 04:01: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 EAA03036
	for ; Mon, 21 Jan 2002 04:01: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 DAA26246;
	Mon, 21 Jan 2002 03:46: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 DAA26214
	for ; Mon, 21 Jan 2002 03:45:59 -0500 (EST)
Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02835
	for ; Mon, 21 Jan 2002 03:45:54 -0500 (EST)
Received: from punasaari.cs.Helsinki.FI (IDENT:jmanner@punasaari.cs.Helsinki.FI [128.214.11.52])
	by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g0L8jUp29724;
	Mon, 21 Jan 2002 10:45:32 +0200
Date: Mon, 21 Jan 2002 10:45:27 +0200 (EET)
From: Jukka Manner 
To: James Kempf 
cc: Phil Neumiller , 
Subject: Re: [Seamoby] Terminology Draft Needed
In-Reply-To: <008d01c1a044$16045ed0$7e6015ac@T23KEMPF>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting  
X-BeenThere: seamoby@ietf.org


	Hi,

	I never meant to deny any security terminology from the draft. Of
course some key mobile/wireless specific terms/interpretations should be
there, I agree. It is doable, if "someone does it"...:) Perhaps Charlie
could edit a brief RFC 2002 security terminology for this terminology
draft?

	Jim

On Fri, 18 Jan 2002, James Kempf wrote:

> Jukka,
>
> The issue is the following. Due to a difference between the security
> terminology used in RFC 2002, which was also used in
> draft-mobileip-ietf-aaa-key-08.txt, and standard IETF security
> terminology, there was a misunderstanding about
> the nature of the solution in the AAA keys draft that led the IESG
> security reviewer to reject the draft. For example,
> nowhere in the AAA keys draft does it talk about a session key, but, if
> you read the draft, that is really what it is about. Since
> the security terminology in RFC 2002 is, in some sense, fairly standard
> in the mobile networking community,
> it has been suggested that the terminology draft include a short (it
> need not be lengthy) mapping between the
> terminology used in RFC 2002 and standard IETF security terminology to
> avoid this problem in the future.
>
> Do you think this is doable?
>
>             jak
>
> ----- Original Message -----
> From: "Jukka Manner" 
> To: "James Kempf" 
> Cc: "Phil Neumiller" ; 
> Sent: Thursday, January 17, 2002 10:33 PM
> Subject: Re: [Seamoby] Terminology Draft Needed
>
>
> >
> > Hi,
> >
> > as I am the editor of the terminology draft, I would like to
> > continue the work me and my colleagues started a year ago (yes, the
> > terminology draft is today 1 year and 6 days old). Since the document
> is
> > already 28 pages long, I would rather add only a bare minimal set of
> > security terminology, only the ones absolutely needed in
> > Seamoby/MIP/MANET---a full security terminology would belong to
> another
> > WG.
> >
> > Second, the pointer Charlie gave is false. It is the old version
> > from summer, although it somehow has the "03" in the name... hmm... A
> new
> > version has been on the IETF draft repository since November. This is
> the
> > right version to discuss:
> >
> >         Title           : Mobility Related Terminology
> >         Author(s)       : J. Manner et al.
> >         Filename        : draft-manner-seamoby-terms-03.txt
> >         Pages           : 28
> >         Date            : 28-Nov-01
> >
> > There is a need for common definitions of terminology in the work to
> > be done around IP mobility. This memo defines terms for mobility
> > related terminology. It is intended as a living document for use by
> > the Seamoby working group, and especially for use in Seamoby drafts
> > and in WG discussions. Other working groups dealing with mobility may
> > also take advantage of this terminology
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-manner-seamoby-terms-03.txt
> >
> > Regards,
> >
> > Jukka
> >
> >
> >
> > On Wed, 16 Jan 2002, James Kempf wrote:
> >
> > > Phil,
> > >
> > > Pat and I were planning on sending a message out about this. I had
> asked
> > > Charlie for a pointer to
> > > the draft, you have helpfully supplied it (see below). Thanx.
> > >
> > > So we have one strong endorsement of adopting the Charlie's
> terminology
> > > draft as a WG item.
> > > Anyone else have strong feelings one way or the other on the issue?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Phil Neumiller" 
> > > To: ; 
> > > Sent: Wednesday, January 16, 2002 6:39 AM
> > > Subject: [Seamoby] Terminology Draft Needed
> > >
> > >
> > > > Hi,
> > > >
> > > > I have seen Charlie pull out the terminology draft at least a few
> > > times! :-)  Why can't
> > > > some WG chair in SeaMoby or MANET adopt it as WG draft?
> > > >
> > > > http://people.nokia.net/~charliep/txt/seamoby/term.txt
> > > >
> > > > It seems that many times arguments are over terminology.  IMO, I
> would
> > > like to
> > > > the SeaMoby WG become a bridge between MANET and MIP technologies,
> > > > especially with respect to AR discovery and CT.  This terminology
> > > draft would make
> > > > a very nice addition to the SeaMoby WG draft list.
> > > >
> > > > Best regards,
> > > >
> > > > Phil
> > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
> >
>


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


From seamoby-admin@ietf.org  Mon Jan 21 10:22: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 KAA12202
	for ; Mon, 21 Jan 2002 10:22: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 KAA11154;
	Mon, 21 Jan 2002 10:06: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 KAA11115
	for ; Mon, 21 Jan 2002 10:06:20 -0500 (EST)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11601
	for ; Mon, 21 Jan 2002 10:06:17 -0500 (EST)
Received: by RRMAIL01 with Internet Mail Service (5.5.2653.19)
	id ; Mon, 21 Jan 2002 10:05:50 -0500
Message-ID: <8C92E23A3E87FB479988285F9E22BE464BB3AD@ftmail>
From: Scott Corson 
To: "'Phil Neumiller'" , manet@itd.nrl.navy.mil,
        seamoby@ietf.org
Date: Mon, 21 Jan 2002 10:05:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Seamoby] RE: Terminology Draft Needed
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 have seen Charlie pull out the terminology draft at least a 
> few times! :-)  Why can't 
> some WG chair in SeaMoby or MANET adopt it as WG draft?

I cannot see this being a MANET draft, far too many non-MANET concepts
involved.

As far as Seamoby effectively bridging between MIP and MANET, it seems
reasonable.  IMO the best-baked architectural notion within Seamoby is the
notion of an AR, its discovery and possible subsequent CT between ARs.  The
AR stands at the edge of a domain, and mobile hosts (MIP) or routers (MANET
or MONET?) seeking access to the domain do so via an AR...the AR and
consequently Seamoby forms a natural bridge.

As for the terminology draft, if included in Seamoby, IMO it needs to be
simplified and clarified big time.  For example, it needs deletion of
irrelevant/unclear IP architectural elements (e.g. APs, ANs, ANRs, ANGs) and
all references thereto/implications thereof. 
* APs are layer 2 elements (need I say more?)
* Access Network Routers (ANR) are IP routers (presumably fixed)...Are these
notably different from non-access network routers?  Perhaps they run a
different routing algorithm, but what of it?  Perhaps they do not!
* Moreover, what is an Access Network?...the doc says it's an IP network
full of ANRs?  This is a bit circular!  If the ANRs are normal IP routers
(and they well could be), then the definition of the AN is completely and
suddenly vacuous...POOF!!! ;-)
* Access Network Gateway (ANG) is just another name for a gateway router.

To my way of thinking, at IP such an "access network" is just a routed
domain, accessed at the edge via access routers and interfaced to the core
thru some gateway router functionality.  No new terms are (yet) needed.  If
you think differently, either you have truly invented something new and I'd
love to hear about it, or you are probably too buried in L2 specifics to see
clearly. ;-)

My 2 cents...for starters, just delete the whole notion of an Access Network
until this can be meaningfully defined at IP layer and differentiated from
existing IP terminology.  Presently, whereever the text addresses the issue
of an "access network", the related definitions (e.g. relating to handoff)
break down as they implicitly assume certain L2 architectures and
capabilities.  These assumptions do not apply in the general case of IP
mobility or hold for all L2 technologies.  There's plenty more that could be
said as well.

But, without wasting more time, on the whole I think this document is mostly
a waste of time.  Whilst specific terminology drafts may be of value (such
as the recently suggested MIP/Security Terminology harmonization draft), IMO
these all-things-to-all-people drafts try to overreach and are generally not
worth bother.

-Scott

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


From seamoby-admin@ietf.org  Mon Jan 21 12:17: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 MAA17344
	for ; Mon, 21 Jan 2002 12:16: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 MAA18876;
	Mon, 21 Jan 2002 12:05: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 MAA18847
	for ; Mon, 21 Jan 2002 12:05:39 -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 MAA17043
	for ; Mon, 21 Jan 2002 12:05:35 -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 LAA00184
	for ; Mon, 21 Jan 2002 11:05:08 -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 g0LH57m07294
	for ; Mon, 21 Jan 2002 11:05:07 -0600 (CST)
Message-ID: <3C4C4A3E.2070208@alcatel.com>
Date: Mon, 21 Jan 2002 11:05:02 -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] Concensus Call:Reaching Closure on Paging Decision
References: <07EE0E021034014F99A57B032BC9C0E50FF646@daebe001.NOE.Nokia.com> <20020118.195426.91278056.sbaba@tari.toshiba.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,
  What we need right now is the declaration by WG chairs of the result 
of the consensus call, i.e. reselection/design team.
Then we can discuss the details of the type Baba talks in his email.
Regards

Baba S wrote:

>Hi Srini,
>
>I also like design team idea, as I have the same
>view about the re-selection with you and Stefano.
>But my problem is the fact that I'm not sure about
>the details of design team.
>


>--behcet
>



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


From seamoby-admin@ietf.org  Mon Jan 21 13:24: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 NAA19381
	for ; Mon, 21 Jan 2002 13:24: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 NAA21578;
	Mon, 21 Jan 2002 13:12: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 NAA21553
	for ; Mon, 21 Jan 2002 13:12:55 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19188
	for ; Mon, 21 Jan 2002 13:12:52 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 21 Jan 2002 10:12:24 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Mon, 21 Jan 2002 10:10:23 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A2A6.E53485E0"
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_01C1A2A6.E53485E0
Content-Type: text/plain

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

Right but the WG chairs are just giving folks a little more time for
those that were off last week. Then, as you state, we can decide what
the right direction should be.

PatC

- -----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] 
Sent: Monday, January 21, 2002 9:05 AM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision


Dear all,
  What we need right now is the declaration by WG chairs of the
result 
of the consensus call, i.e. reselection/design team.
Then we can discuss the details of the type Baba talks in his email.
Regards

Baba S wrote:

>Hi Srini,
>
>I also like design team idea, as I have the same
>view about the re-selection with you and Stefano.
>But my problem is the fact that I'm not sure about
>the details of design team.
>


>--behcet
>



_______________________________________________
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/AwUBPExZjzN1fXKoxmisEQL4ZACg1j0j1c/VsTg0y20z8yxA4re9AHsAnR7M
7U158fg96ginut+QVOthcyoX
=b36R
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1A2A6.E53485E0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby] Concensus Call:Reaching Closure on Paging =
Decision




 

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

Hash: SHA1




Right but the WG chairs are just giving folks a =
little more time for

those that were off last week. Then, as you state, =
we can decide what

the right direction should be.




PatC




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

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

Sent: Monday, January 21, 2002 9:05 AM

To: seamoby@ietf.org

Subject: Re: [Seamoby] Concensus Call:Reaching =
Closure on Paging

Decision






Dear all,

  What we need right now is the declaration by =
WG chairs of the

result 

of the consensus call, i.e. reselection/design =
team.

Then we can discuss the details of the type Baba =
talks in his email.

Regards




Baba S wrote:




>Hi Srini,

>

>I also like design team idea, as I have the =
same

>view about the re-selection with you and =
Stefano.

>But my problem is the fact that I'm not sure =
about

>the details of design team.

>






>--behcet

>








_______________________________________________

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/AwUBPExZjzN1fXKoxmisEQL4ZACg1j0j1c/VsTg0y20z8yxA4re9AHsAnR7=
M

7U158fg96ginut+QVOthcyoX

=3Db36R

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





------_=_NextPart_001_01C1A2A6.E53485E0--

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


From seamoby-admin@ietf.org  Mon Jan 21 13:40: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 NAA19668
	for ; Mon, 21 Jan 2002 13:40: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 NAA21794;
	Mon, 21 Jan 2002 13:22: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 NAA21765
	for ; Mon, 21 Jan 2002 13:22:53 -0500 (EST)
Received: from smtp.tari.toshiba.com ([207.122.4.194])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19320
	for ; Mon, 21 Jan 2002 13:22:49 -0500 (EST)
Received: from localhost
	by smtp.tari.toshiba.com (8.9.1/3.7W-011204) with ESMTP id NAA16719
	for ; Mon, 21 Jan 2002 13:26:00 -0500
Date: Mon, 21 Jan 2002 13:26:09 -0500 (EST)
Message-Id: <20020121.132609.60852381.sbaba@tari.toshiba.com>
To: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
From: Baba S 
In-Reply-To: <3C4C4A3E.2070208@alcatel.com>
References: <07EE0E021034014F99A57B032BC9C0E50FF646@daebe001.NOE.Nokia.com>
	<20020118.195426.91278056.sbaba@tari.toshiba.com>
	<3C4C4A3E.2070208@alcatel.com>
X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI)
Mime-Version: 1.0
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 Behcet,

I agree that we need to take consensus step by step.
Otherwise, we will be apart from the path.

And I might be go farther at this beginning stage.
But I'm afraid that the thing may not be so simple
like 'reselection or design team', i.e. it may be
up to a type/configuration of design team.

Though we have a large audience, number of people
interested in paging right now seems not so large.
So I think we just have more little time to discuss
the point and see other's preference through that.
If people's preference is obvious, we don't need to
make a concensus call then.
At least, before consensus call, I would like to
know briefly about what will happen next by each
selection, reselection/design team.
# I need your imagination for that :)

One problem to me on the consensu call by the chairs
last time was that I couldn't understand what would
happen if the consensus became "no".

And I'm afraid that design team with no editor and
no document could be lead to us into the same situation,
later, as the player is almost the same, though it
looks reasonable right now. That's my 2 bits.

Regards,

baba//


From: Behcet Sarikaya 
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Mon, 21 Jan 2002 11:05:02 -0600

> Dear all,
>   What we need right now is the declaration by WG chairs of the result 
> of the consensus call, i.e. reselection/design team.
> Then we can discuss the details of the type Baba talks in his email.
> Regards
> 
> Baba S wrote:
> 
> >Hi Srini,
> >
> >I also like design team idea, as I have the same
> >view about the re-selection with you and Stefano.
> >But my problem is the fact that I'm not sure about
> >the details of design team.
> >
> 
> 
> >--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 Jan 21 14:04: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 OAA20114
	for ; Mon, 21 Jan 2002 14:04: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 NAA22763;
	Mon, 21 Jan 2002 13:53: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 NAA22732
	for ; Mon, 21 Jan 2002 13:53:10 -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 NAA19899
	for ; Mon, 21 Jan 2002 13:53:07 -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 g0LIsjQ12421
	for ; Mon, 21 Jan 2002 12:54:45 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 21 Jan 2002 12:53:06 -0600
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 21 Jan 2002 12:52:53 -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] Concensus Call:Reaching Closure on Paging Decision
Date: Mon, 21 Jan 2002 12:52:53 -0600
Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF64A@daebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Thread-Index: AcGiqLXR6wGn/IxYTvmxxhaoXfVhewAAVhyg
To: 
Cc: 
X-OriginalArrivalTime: 21 Jan 2002 18:52:53.0293 (UTC) FILETIME=[D4E4E5D0:01C1A2AC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA22733
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 agree with Baba that while the consensus on the next step is being reached, in parallel, we should also discuss on the mechanics of the next step. Starting the work from scratch, for the design team, seems like an easy solution. But, as Baba pointed out, it may be expensive in terms of the time we lose and what we have achieved so far.  Selecting an editor may be a right step in the direction and I am sure Marco can do a good job on editorship. 

I am also a little cautious on what exactly the consensus is about. My understanding is that the consensus is whether there should be any starting ID or not. If there is no consensus, automatically, the reselection of existing solutions must take take place of a basis protocol to continue work.  But the discussion of the design team, I believe, automatically means we have a consensus to disagree for a starting ID.

James or Pat, could you please comment on our understanding so that it would make clear for others to come out and comment.

Thanks,
Srini

-----Original Message-----
From: ext Baba S [mailto:sbaba@tari.toshiba.com]
Sent: 21 January, 2002 12:26 PM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision


Hi Behcet,

I agree that we need to take consensus step by step.
Otherwise, we will be apart from the path.

And I might be go farther at this beginning stage.
But I'm afraid that the thing may not be so simple
like 'reselection or design team', i.e. it may be
up to a type/configuration of design team.

Though we have a large audience, number of people
interested in paging right now seems not so large.
So I think we just have more little time to discuss
the point and see other's preference through that.
If people's preference is obvious, we don't need to
make a concensus call then.
At least, before consensus call, I would like to
know briefly about what will happen next by each
selection, reselection/design team.
# I need your imagination for that :)

One problem to me on the consensu call by the chairs
last time was that I couldn't understand what would
happen if the consensus became "no".

And I'm afraid that design team with no editor and
no document could be lead to us into the same situation,
later, as the player is almost the same, though it
looks reasonable right now. That's my 2 bits.

Regards,

baba//


From: Behcet Sarikaya 
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Mon, 21 Jan 2002 11:05:02 -0600

> Dear all,
>   What we need right now is the declaration by WG chairs of the result 
> of the consensus call, i.e. reselection/design team.
> Then we can discuss the details of the type Baba talks in his email.
> Regards
> 
> Baba S wrote:
> 
> >Hi Srini,
> >
> >I also like design team idea, as I have the same
> >view about the re-selection with you and Stefano.
> >But my problem is the fact that I'm not sure about
> >the details of design team.
> >
> 
> 
> >--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

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


From seamoby-admin@ietf.org  Mon Jan 21 14:40: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 OAA21492
	for ; Mon, 21 Jan 2002 14:40: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 OAA23987;
	Mon, 21 Jan 2002 14:27: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 OAA23962
	for ; Mon, 21 Jan 2002 14:27:05 -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 OAA21043
	for ; Mon, 21 Jan 2002 14:27:01 -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 g0LJR1H84673;
	Mon, 21 Jan 2002 20:27:01 +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 UAA02301;
	Mon, 21 Jan 2002 20:26:29 +0100
Message-ID: <3C4C6B66.88E13BAF@ccrle.nec.de>
Date: Mon, 21 Jan 2002 20:26:30 +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: sbaba@tari.toshiba.com, seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <07EE0E021034014F99A57B032BC9C0E50FF64A@daebe001.NOE.Nokia.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

Hi all,

just a comment from my side. As I read on the list several times, none of the architecture and protocol proposals seem to match the requirements for 100% (otherwise we would have finished the task on DMHA right now:), all have really good ideas in. Why is it proposed to start from scratch then or by throwing all the proposals on the table? What was the purpose of the assessment and selection process then? As far as I can think back, nobody complained
when such a selection process has been proposed. Did anybody expect a proposal that fits 100%, getting a consensus of the entire WG? Everybody followed the 'rule'. From September deadline to Nov., making an assesment draft public, there was a lot of time in between and, as far as I can think back, there was no discussion on the list providing feedback on the other proposals, as requested sometimes. I did not hear any voice after submission deadline
describing the other protocols in a way not meeting the requirements sufficiently, even not after the assessment draft was available. Should this time period of selection be for nothing, having as a result that none of the proposals meets the requirements for 100% and to start from scratch? Why not taking the selected open design (and I think our concept is open enough  in order to allow) and work together on the WG draft?

Marco

Srinivas.Sreemanthula@nokia.com wrote:

> Hi all,
> I agree with Baba that while the consensus on the next step is being reached, in parallel, we should also discuss on the mechanics of the next step. Starting the work from scratch, for the design team, seems like an easy solution. But, as Baba pointed out, it may be expensive in terms of the time we lose and what we have achieved so far.  Selecting an editor may be a right step in the direction and I am sure Marco can do a good job on editorship.
>
> I am also a little cautious on what exactly the consensus is about. My understanding is that the consensus is whether there should be any starting ID or not. If there is no consensus, automatically, the reselection of existing solutions must take take place of a basis protocol to continue work.  But the discussion of the design team, I believe, automatically means we have a consensus to disagree for a starting ID.
>
> James or Pat, could you please comment on our understanding so that it would make clear for others to come out and comment.
>
> Thanks,
> Srini
>
> -----Original Message-----
> From: ext Baba S [mailto:sbaba@tari.toshiba.com]
> Sent: 21 January, 2002 12:26 PM
> To: seamoby@ietf.org
> Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
> Decision
>
> Hi Behcet,
>
> I agree that we need to take consensus step by step.
> Otherwise, we will be apart from the path.
>
> And I might be go farther at this beginning stage.
> But I'm afraid that the thing may not be so simple
> like 'reselection or design team', i.e. it may be
> up to a type/configuration of design team.
>
> Though we have a large audience, number of people
> interested in paging right now seems not so large.
> So I think we just have more little time to discuss
> the point and see other's preference through that.
> If people's preference is obvious, we don't need to
> make a concensus call then.
> At least, before consensus call, I would like to
> know briefly about what will happen next by each
> selection, reselection/design team.
> # I need your imagination for that :)
>
> One problem to me on the consensu call by the chairs
> last time was that I couldn't understand what would
> happen if the consensus became "no".
>
> And I'm afraid that design team with no editor and
> no document could be lead to us into the same situation,
> later, as the player is almost the same, though it
> looks reasonable right now. That's my 2 bits.
>
> Regards,
>
> baba//
>
> From: Behcet Sarikaya 
> Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
> Date: Mon, 21 Jan 2002 11:05:02 -0600
>
> > Dear all,
> >   What we need right now is the declaration by WG chairs of the result
> > of the consensus call, i.e. reselection/design team.
> > Then we can discuss the details of the type Baba talks in his email.
> > Regards
> >
> > Baba S wrote:
> >
> > >Hi Srini,
> > >
> > >I also like design team idea, as I have the same
> > >view about the re-selection with you and Stefano.
> > >But my problem is the fact that I'm not sure about
> > >the details of design team.
> > >
> >
> >
> > >--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
>
> _______________________________________________
> 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 Jan 21 15:21: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 PAA22724
	for ; Mon, 21 Jan 2002 15:20: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 PAA25648;
	Mon, 21 Jan 2002 15:09: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 PAA25618
	for ; Mon, 21 Jan 2002 15:09:27 -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 PAA22311
	for ; Mon, 21 Jan 2002 15:09:23 -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 OAA00556
	for ; Mon, 21 Jan 2002 14:08:53 -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 g0LK8qs07471
	for ; Mon, 21 Jan 2002 14:08:52 -0600 (CST)
Message-ID: <3C4C754E.8010200@alcatel.com>
Date: Mon, 21 Jan 2002 14:08:46 -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] Concensus Call:Reaching Closure on Paging Decision
References: <07EE0E021034014F99A57B032BC9C0E50FF64A@daebe001.NOE.Nokia.com> <3C4C6B66.88E13BAF@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

Dear all,
  Sorry but I do not understand neither do I agree with Marco's point 
which says that the selection results are OK and so we should move forward.
  Instead people have disagreed and voted for reselection/design team.
  I think that some people do not read emails or misunderstand whatever 
is written.
Unfortunately this may jeopardize the possibility of editorship of the 
probable design team by such a person.
  Please correct me if I am wrong.

Regards,

Marco Liebsch wrote:

>Hi all,
>
>just a comment from my side. As I read on the list several times, none of the architecture and protocol proposals seem to match the requirements for 100% (otherwise we would have finished the task on DMHA right now:), all have really good ideas in. Why is it proposed to start from scratch then or by throwing all the proposals on the table? What was the purpose of the assessment and selection process then? As far as I can think back, nobody complained
>when such a selection process has been proposed. Did anybody expect a proposal that fits 100%, getting a consensus of the entire WG? Everybody followed the 'rule'. From September deadline to Nov., making an assesment draft public, there was a lot of time in between and, as far as I can think back, there was no discussion on the list providing feedback on the other proposals, as requested sometimes. I did not hear any voice after submission deadline
>describing the other protocols in a way not meeting the requirements sufficiently, even not after the assessment draft was available. Should this time period of selection be for nothing, having as a result that none of the proposals meets the requirements for 100% and to start from scratch? Why not taking the selected open design (and I think our concept is open enough  in order to allow) and work together on the WG draft?
>
>Marco
>
>--behcet
>



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


From seamoby-admin@ietf.org  Mon Jan 21 16:00: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 QAA24318
	for ; Mon, 21 Jan 2002 16: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 PAA26721;
	Mon, 21 Jan 2002 15:45:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26689
	for ; Mon, 21 Jan 2002 15:45:07 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23698
	for ; Mon, 21 Jan 2002 15:45:02 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 21 Jan 2002 12:44:35 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Behcet Sarikaya'" , seamoby@ietf.org
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Mon, 21 Jan 2002 12:42:27 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A2BC.233F0AD0"
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_01C1A2BC.233F0AD0
Content-Type: text/plain

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

Who is editor of the WG document is not what is being discussed right
now, so how about we leave that one behind. Whether or not people
understand the english language, and what is being discussed is also
out of scope.

What we are discussing here is whether we move forward with the
renker draft as a *starting point* or not. 

Allison, Jim and I are looking into the possible ways to move
forward, but as some folks have clearly expressed, none of them are
great. We know that none of the proposals fit the requirements 100%,
and restarting the assessment process is of dubious use. Another
alternative is to start from scratch, but what kind of delay does
this introduce, and how do we do this (and will we really forget what
we've learned from existing proposals)?

The three of us will be chatting in the next couple of days, and will
inform the WG of our findings.

PatC

- -----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] 
Sent: Monday, January 21, 2002 12:09 PM
To: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision


Dear all,
  Sorry but I do not understand neither do I agree with Marco's point
which says that the selection results are OK and so we should move
forward.
  Instead people have disagreed and voted for reselection/design
team.
  I think that some people do not read emails or misunderstand
whatever 
is written.
Unfortunately this may jeopardize the possibility of editorship of
the 
probable design team by such a person.
  Please correct me if I am wrong.

Regards,

Marco Liebsch wrote:

>Hi all,
>
>just a comment from my side. As I read on the list several times,
>none  of the architecture and protocol proposals seem to match the 
>requirements for 100% (otherwise we would have finished the task on 
>DMHA right now:), all have really good ideas in. Why is it proposed
>to  start from scratch then or by throwing all the proposals on the
>table?  What was the purpose of the assessment and selection process
>then? As  far as I can think back, nobody complained when such a
>selection 
>process has been proposed. Did anybody expect a proposal that fits 
>100%, getting a consensus of the entire WG? Everybody followed the 
>'rule'. From September deadline to Nov., making an assesment draft 
>public, there was a lot of time in between and, as far as I can
>think  back, there was no discussion on the list providing feedback
>on the  other proposals, as requested sometimes. I did not hear any
>voice after  submission deadline describing the other protocols in a
>way not meeting  the requirements sufficiently, even not after the
>assessment draft was  available. Should this time period of
>selection be for nothing, having  as a result that none of the
>proposals meets the requirements for 100%  and to start from
>scratch? Why not taking the selected open design (and  I think our
>concept is open enough  in order to allow) and work 
>together on the WG draft?
>
>Marco
>
>--behcet
>



_______________________________________________
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/AwUBPEx9MzN1fXKoxmisEQLqfgCcDzvYqu7YByu4JA+TtIJQtHAYiykAoLvm
fwrUQJmoyyIvuv2JBOo4QR4+
=m+JC
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1A2BC.233F0AD0
Content-Type: text/html






RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision




 

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

Hash: SHA1




Who is editor of the WG document is not what is being discussed right

now, so how about we leave that one behind. Whether or not people

understand the english language, and what is being discussed is also

out of scope.




What we are discussing here is whether we move forward with the

renker draft as a *starting point* or not. 




Allison, Jim and I are looking into the possible ways to move

forward, but as some folks have clearly expressed, none of them are

great. We know that none of the proposals fit the requirements 100%,

and restarting the assessment process is of dubious use. Another

alternative is to start from scratch, but what kind of delay does

this introduce, and how do we do this (and will we really forget what

we've learned from existing proposals)?




The three of us will be chatting in the next couple of days, and will

inform the WG of our findings.




PatC




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

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

Sent: Monday, January 21, 2002 12:09 PM

To: seamoby@ietf.org

Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging

Decision






Dear all,

  Sorry but I do not understand neither do I agree with Marco's point

which says that the selection results are OK and so we should move

forward.

  Instead people have disagreed and voted for reselection/design

team.

  I think that some people do not read emails or misunderstand

whatever 

is written.

Unfortunately this may jeopardize the possibility of editorship of

the 

probable design team by such a person.

  Please correct me if I am wrong.




Regards,




Marco Liebsch wrote:




>Hi all,

>

>just a comment from my side. As I read on the list several times,

>none  of the architecture and protocol proposals seem to match the 

>requirements for 100% (otherwise we would have finished the task on 

>DMHA right now:), all have really good ideas in. Why is it proposed

>to  start from scratch then or by throwing all the proposals on the

>table?  What was the purpose of the assessment and selection process

>then? As  far as I can think back, nobody complained when such a

>selection 

>process has been proposed. Did anybody expect a proposal that fits 

>100%, getting a consensus of the entire WG? Everybody followed the 

>'rule'. From September deadline to Nov., making an assesment draft 

>public, there was a lot of time in between and, as far as I can

>think  back, there was no discussion on the list providing feedback

>on the  other proposals, as requested sometimes. I did not hear any

>voice after  submission deadline describing the other protocols in a

>way not meeting  the requirements sufficiently, even not after the

>assessment draft was  available. Should this time period of

>selection be for nothing, having  as a result that none of the

>proposals meets the requirements for 100%  and to start from

>scratch? Why not taking the selected open design (and  I think our

>concept is open enough  in order to allow) and work 

>together on the WG draft?

>

>Marco

>

>--behcet

>








_______________________________________________

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/AwUBPEx9MzN1fXKoxmisEQLqfgCcDzvYqu7YByu4JA+TtIJQtHAYiykAoLvm

fwrUQJmoyyIvuv2JBOo4QR4+

=m+JC

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





------_=_NextPart_001_01C1A2BC.233F0AD0--

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


From seamoby-admin@ietf.org  Mon Jan 21 18:17: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 SAA27788
	for ; Mon, 21 Jan 2002 18:17: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 SAA01002;
	Mon, 21 Jan 2002 18:04: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 SAA00964
	for ; Mon, 21 Jan 2002 18:04: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 SAA27602
	for ; Mon, 21 Jan 2002 18:04:23 -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 RAA28531;
	Mon, 21 Jan 2002 17:03:57 -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 g0LN3us13174;
	Mon, 21 Jan 2002 17:03:56 -0600 (CST)
Message-ID: <3C4C9E56.5070007@alcatel.com>
Date: Mon, 21 Jan 2002 17:03: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: "Pat R. Calhoun" 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: 
Content-Type: multipart/alternative;
 boundary="------------080500010204060106010904"
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


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

May I propose the following alternatives:
- restart the selection process which means let everybody to revise and 
resubmit independently which of course is open to the new players;
This solution brings the assessment problem, then the assessment process 
should be agreed. I would recommend getting expert opinion rather than 
the volunteers.
- A closed design team composed only of one author from each of the 5 
candidate drafts. This design team needs no design team leader.
- An open design team. Maybe someone to lead the discussions might be 
needed, in this case someone from universities or research centers would 
be appropriate.
- Completely dropping this work item, is this an option?
My 0.02 euros.

Pat R. Calhoun wrote:

>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Who is editor of the WG document is not what is being discussed right
> now, so how about we leave that one behind. Whether or not people
> understand the english language, and what is being discussed is also
> out of scope.
>
> What we are discussing here is whether we move forward with the
> renker draft as a *starting point* or not.
>
> Allison, Jim and I are looking into the possible ways to move
> forward, but as some folks have clearly expressed, none of them are
> great. We know that none of the proposals fit the requirements 100%,
> and restarting the assessment process is of dubious use. Another
> alternative is to start from scratch, but what kind of delay does
> this introduce, and how do we do this (and will we really forget what
> we've learned from existing proposals)?
>
> The three of us will be chatting in the next couple of days, and will
> inform the WG of our findings.
>
> PatC
>

> --behcet
>


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





May I propose the following alternatives:

- restart the selection process which means let everybody to revise and resubmit
independently which of course is open to the new players; 

This solution brings the assessment problem, then the assessment process
should be agreed. I would recommend getting expert opinion rather than the
volunteers.

- A closed design team composed only of one author from each of the 5 candidate
drafts. This design team needs no design team leader.

- An open design team. Maybe someone to lead the discussions might be needed,
in this case someone from universities or research centers would be appropriate.

- Completely dropping this work item, is this an option?

My 0.02 euros.



Pat R. Calhoun wrote:



  
  RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
  
 

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

  Hash: SHA1

  
Who is editor of the WG document is not what is being
discussed right

  now, so how about we leave that one behind. Whether or not
people

  understand the english language, and what is being discussed
is also

  out of scope.

  
What we are discussing here is whether we move forward
with the

  renker draft as a *starting point* or not. 

  
Allison, Jim and I are looking into the possible ways
to move

  forward, but as some folks have clearly expressed, none
of them are

  great. We know that none of the proposals fit the requirements
100%,

  and restarting the assessment process is of dubious use.
Another

  alternative is to start from scratch, but what kind of delay
does

  this introduce, and how do we do this (and will we really
forget what

  we've learned from existing proposals)?

  
The three of us will be chatting in the next couple of
days, and will

  inform the WG of our findings.

  
PatC

  

  

  

    
--behcet

    

    

    

    
    

--------------080500010204060106010904--


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


From seamoby-admin@ietf.org  Mon Jan 21 18:41: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 SAA28228
	for ; Mon, 21 Jan 2002 18:41: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 SAA01834;
	Mon, 21 Jan 2002 18:30: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 SAA01799
	for ; Mon, 21 Jan 2002 18:30:38 -0500 (EST)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28102
	for ; Mon, 21 Jan 2002 18:30:33 -0500 (EST)
Received: by RRMAIL01 with Internet Mail Service (5.5.2653.19)
	id ; Mon, 21 Jan 2002 18:30:07 -0500
Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB9B8@ftmail>
From: George Tsirtsis 
To: seamoby@ietf.org
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Mon, 21 Jan 2002 18:29:55 -0500
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


-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Monday, January 21, 2002 11:04 PM
To: Pat R. Calhoun
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision

...
- Completely dropping this work item, is this an option?

GT> I will risk the following opinion since I have been following this
discussion for some time: I like the option above. Given the level of
resentment between people in this sub-group I can not see how this work will
be successful no matter what the process is. Any processes is flawed unless
people want to work with it. 

Do not despair, the work item will reincarnate it self when there is actual
need for it.

George

 

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


From seamoby-admin@ietf.org  Mon Jan 21 19:08: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 TAA28623
	for ; Mon, 21 Jan 2002 19:08: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 SAA02604;
	Mon, 21 Jan 2002 18:57: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 SAA02575
	for ; Mon, 21 Jan 2002 18:57:44 -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 SAA28481
	for ; Mon, 21 Jan 2002 18:57:40 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA05496;
	Mon, 21 Jan 2002 17:57:13 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g0LNvCr11232;
	Mon, 21 Jan 2002 17:57:12 -0600 (CST)
Message-ID: <3C4CAAD8.1020405@alcatel.com>
Date: Mon, 21 Jan 2002 17:57: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: George Tsirtsis 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <8C92E23A3E87FB479988285F9E22BE465AB9B8@ftmail>
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

George,
  You forgot your 2 euro cents.

George Tsirtsis wrote:

>-----Original Message-----
>From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
>Sent: Monday, January 21, 2002 11:04 PM
>To: Pat R. Calhoun
>Cc: seamoby@ietf.org
>Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
>
>...
>- Completely dropping this work item, is this an option?
>
>GT> I will risk the following opinion since I have been following this
>discussion for some time: I like the option above. Given the level of
>resentment between people in this sub-group I can not see how this work will
>be successful no matter what the process is. Any processes is flawed unless
>people want to work with it. 
>
>Do not despair, the work item will reincarnate it self when there is actual
>need for it.
>
>George
>
> 
>



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


From seamoby-admin@ietf.org  Tue Jan 22 03:34: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 DAA13756
	for ; Tue, 22 Jan 2002 03:34: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 DAA26041;
	Tue, 22 Jan 2002 03:18:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26010
	for ; Tue, 22 Jan 2002 03:18:07 -0500 (EST)
Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13636
	for ; Tue, 22 Jan 2002 03:18:03 -0500 (EST)
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134])
	by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id RAA05097;
	Tue, 22 Jan 2002 17:18:03 +0900 (JST)
Received: (from root@localhost)
	by tsb-wall.toshiba.co.jp (8.11.5/3.7W) id g0M8I3a25688;
	Tue, 22 Jan 2002 17:18:03 +0900 (JST)
Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id TAA25683 ; Tue, 22 Jan 2002 17:18:03 +0900
Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317)
	id RAA03784; Tue, 22 Jan 2002 17:18:02 +0900 (JST)
Received: from tsbpo1.po.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id RAA28823; Tue, 22 Jan 2002 17:18:02 +0900 (JST)
Received: from localhost (kddlos0109.mobile.toshiba.co.jp)
 by tsbpo1.po.toshiba.co.jp
 (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4)
 with ESMTP id <0GQB0001TZ1UVQ@tsbpo1.po.toshiba.co.jp>; Tue,
 22 Jan 2002 17:18:00 +0900 (JST)
Date: Tue, 22 Jan 2002 03:21:56 -0500 (EST)
From: Baba S 
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
In-reply-to: <3C4C9E56.5070007@alcatel.com>
To: behcet.sarikaya@alcatel.com
Cc: seamoby@ietf.org
Message-id: <20020122.032156.60852681.shinichi1.baba@toshiba.co.jp>
MIME-version: 1.0
X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI)
Content-type: Text/Plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: 
 <3C4C9E56.5070007@alcatel.com>
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 Behcet,

> May I propose the following alternatives:
> - restart the selection process which means let everybody to revise and 
> resubmit independently which of course is open to the new players;
> This solution brings the assessment problem, then the assessment process 
> should be agreed. I would recommend getting expert opinion rather than 
> the volunteers.

How about assessing each other. Since we don't have
so much experts so far, I think.

> - A closed design team composed only of one author from each of the 5 
> candidate drafts. This design team needs no design team leader.
> - An open design team. Maybe someone to lead the discussions might be 
> needed, in this case someone from universities or research centers would 
> be appropriate.
> - Completely dropping this work item, is this an option?

Yes, it is, I think, and it is not bad either.
Though I like doing something instead of stopping.

Regards.

baba//


> My 0.02 euros.
> 
> Pat R. Calhoun wrote:
> 
> >  
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Who is editor of the WG document is not what is being discussed right
> > now, so how about we leave that one behind. Whether or not people
> > understand the english language, and what is being discussed is also
> > out of scope.
> >
> > What we are discussing here is whether we move forward with the
> > renker draft as a *starting point* or not.
> >
> > Allison, Jim and I are looking into the possible ways to move
> > forward, but as some folks have clearly expressed, none of them are
> > great. We know that none of the proposals fit the requirements 100%,
> > and restarting the assessment process is of dubious use. Another
> > alternative is to start from scratch, but what kind of delay does
> > this introduce, and how do we do this (and will we really forget what
> > we've learned from existing proposals)?
> >
> > The three of us will be chatting in the next couple of days, and will
> > inform the WG of our findings.
> >
> > PatC
> >
> 
> > --behcet
> >
> 


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


From seamoby-admin@ietf.org  Tue Jan 22 04:52: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 EAA14672
	for ; Tue, 22 Jan 2002 04:52: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 EAA28942;
	Tue, 22 Jan 2002 04:38: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 EAA28911
	for ; Tue, 22 Jan 2002 04:38:19 -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 EAA14514
	for ; Tue, 22 Jan 2002 04:38:15 -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 g0M9cJH87577;
	Tue, 22 Jan 2002 10:38:19 +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 KAA09084;
	Tue, 22 Jan 2002 10:37:45 +0100
Message-ID: <3C4D32EA.BEAFA6D4@ccrle.nec.de>
Date: Tue, 22 Jan 2002 10:37:46 +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] Concensus Call:Reaching Closure on Paging Decision
References: <07EE0E021034014F99A57B032BC9C0E50FF64A@daebe001.NOE.Nokia.com> <3C4C6B66.88E13BAF@ccrle.nec.de> <3C4C754E.8010200@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,
I am sorry if you misunderstood my mail. The only thing I wanted to express
is not to throw away what we already have as input and start from scratch.
Starting from scratch would cause current authors to justify their proposal
from scratch, isn't it? This would at least initiate discussions and 'technical'
feeback on the other proposals, what I missed somehow during the last
months. Anyway, see Pat's reply to your mail, referring to 'starting from
scratch', 're-selection' or 'going ahead' with what we have now. This is
what I tried to comment on in my previous mail.

oh..., to meet your expectation: My 2 (euro) cents

Regards,

Marco


Behcet Sarikaya wrote:

> Dear all,
>   Sorry but I do not understand neither do I agree with Marco's point
> which says that the selection results are OK and so we should move forward.
>   Instead people have disagreed and voted for reselection/design team.
>   I think that some people do not read emails or misunderstand whatever
> is written.
> Unfortunately this may jeopardize the possibility of editorship of the
> probable design team by such a person.
>   Please correct me if I am wrong.
>
> Regards,
>
> Marco Liebsch wrote:
>
> >Hi all,
> >
> >just a comment from my side. As I read on the list several times, none of the architecture and protocol proposals seem to match the requirements for 100% (otherwise we would have finished the task on DMHA right now:), all have really good ideas in. Why is it proposed to start from scratch then or by throwing all the proposals on the table? What was the purpose of the assessment and selection process then? As far as I can think back, nobody complained
> >when such a selection process has been proposed. Did anybody expect a proposal that fits 100%, getting a consensus of the entire WG? Everybody followed the 'rule'. From September deadline to Nov., making an assesment draft public, there was a lot of time in between and, as far as I can think back, there was no discussion on the list providing feedback on the other proposals, as requested sometimes. I did not hear any voice after submission deadline
> >describing the other protocols in a way not meeting the requirements sufficiently, even not after the assessment draft was available. Should this time period of selection be for nothing, having as a result that none of the proposals meets the requirements for 100% and to start from scratch? Why not taking the selected open design (and I think our concept is open enough  in order to allow) and work together on the WG draft?
> >
> >Marco
> >
> >--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 Jan 22 06:39: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 GAA15807
	for ; Tue, 22 Jan 2002 06:39: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 GAA02293;
	Tue, 22 Jan 2002 06:16: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 GAA02266
	for ; Tue, 22 Jan 2002 06:16:05 -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 GAA15568
	for ; Tue, 22 Jan 2002 06:16:00 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0MBG3H88397;
	Tue, 22 Jan 2002 12:16:03 +0100 (CET)
Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP
	id 1AD89C05B; Tue, 22 Jan 2002 12:15:29 +0100 (CET)
Date: Tue, 22 Jan 2002 12:27:14 +0100
From: Marcus Brunner 
Reply-To: brunner@ccrle.nec.de
To: Behcet Sarikaya , seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Message-ID: <8085065.1011702434@[192.168.102.79]>
In-Reply-To: <3C4C754E.8010200@alcatel.com>
References: <07EE0E021034014F99A57B032BC9C0E50FF64A@daebe001.NOE.Nokia.com>
 <3C4C6B66.88E13BAF@ccrle.nec.de> <3C4C754E.8010200@alcatel.com>
X-Mailer: Mulberry/2.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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,

The focus of Marcos mail was on MOVE FORWARD. Because out of the three 
possibilities (design team, re-selection, move forward), the first and the 
third are IMO equivalent. A design team is exactly what we have now, where 
Marco is waiting for text from his co-authors (most likely authors from the 
competing proposals).

The second possibility does not help it just means another draft is 
selected as starting point, and we will have the same unsatisfactory 
situation again.

Marcus

--On Monday, January 21, 2002 2:08 PM -0600 Behcet Sarikaya 
 wrote:

> Dear all,
>   Sorry but I do not understand neither do I agree with Marco's point
> which says that the selection results are OK and so we should move
> forward.   Instead people have disagreed and voted for reselection/design
> team.   I think that some people do not read emails or misunderstand
> whatever is written. Unfortunately this may jeopardize the possibility of
> editorship of the probable design team by such a person.   Please correct
> me if I am wrong.
>
> Regards,
>
> Marco Liebsch wrote:
>
>> Hi all,
>>
>> just a comment from my side. As I read on the list several times, none
>> of the architecture and protocol proposals seem to match the
>> requirements for 100% (otherwise we would have finished the task on DMHA
>> right now:), all have really good ideas in. Why is it proposed to start
>> from scratch then or by throwing all the proposals on the table? What
>> was the purpose of the assessment and selection process then? As far as
>> I can think back, nobody complained when such a selection process has
>> been proposed. Did anybody expect a proposal that fits 100%, getting a
>> consensus of the entire WG? Everybody followed the 'rule'. From
>> September deadline to Nov., making an assesment draft public, there was
>> a lot of time in between and, as far as I can think back, there was no
>> discussion on the list providing feedback on the other proposals, as
>> requested sometimes. I did not hear any voice after submission deadline
>> describing the other protocols in a way not meeting the requirements
>> sufficiently, even not after the assessment draft was available. Should
>> this time period of selection be for nothing, having as a result that
>> none of the proposals meets the requirements for 100% and to start from
>> scratch? Why not taking the selected open design (and I think our
>> concept is open enough  in order to allow) and work together on the WG
>> draft?
>>
>> Marco
>>
>> --behcet
>>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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


From seamoby-admin@ietf.org  Tue Jan 22 06:39: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 GAA15819
	for ; Tue, 22 Jan 2002 06:39: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 GAA02502;
	Tue, 22 Jan 2002 06:24: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 GAA02471
	for ; Tue, 22 Jan 2002 06:24:48 -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 GAA15643
	for ; Tue, 22 Jan 2002 06:24:44 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0MBOfH88534;
	Tue, 22 Jan 2002 12:24:41 +0100 (CET)
Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP
	id 839D6C05B; Tue, 22 Jan 2002 12:24:07 +0100 (CET)
Date: Tue, 22 Jan 2002 12:35:53 +0100
From: Marcus Brunner 
Reply-To: brunner@ccrle.nec.de
To: Behcet Sarikaya ,
        "Pat R. Calhoun" 
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Message-ID: <8604072.1011702953@[192.168.102.79]>
In-Reply-To: <3C4C9E56.5070007@alcatel.com>
References:  <3C4C9E56.5070007@alcatel.com>
X-Mailer: Mulberry/2.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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,

see inline

--On Monday, January 21, 2002 5:03 PM -0600 Behcet Sarikaya 
 wrote:

> May I propose the following alternatives:
> - restart the selection process which means let everybody to revise and
> resubmit independently which of course is open to the new players;  This
> solution brings the assessment problem, then the assessment process
> should be agreed. I would recommend getting expert opinion rather than
> the volunteers.

I don't think the evaluator regard themself as non-experts. And as said in 
the previous mail, starting again the selection process means every body 
comes up with a similar proposal and the same problem arises again.

>- A closed design team composed only of one author from
> each of the 5 candidate drafts. This design team needs no design team
> leader.

Have you ever seen a team without a coordinator putting together text from 
various co-authors and pushing the co-authors to deliver text?

>- An open design team. Maybe someone to lead the discussions
> might be needed, in this case someone from universities or research
> centers would be appropriate.

You are right that somebody should lead the discussion, but I have not seen 
any substantial comments on the various draft and the assessment document 
before the selection. Strange that this happens after the selection.

>- Completely dropping this work item, is
> this an option?

I disagree dropping the item.

Marcus

> My 0.02 euros.
>
> Pat R. Calhoun wrote:
>
>
>
>
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
> Who is editor of the WG document is not what is being discussed right
>  now, so how about we leave that one behind. Whether or not people
>  understand the english language, and what is being discussed is also
>  out of scope.
>
> What we are discussing here is whether we move forward with the
>  renker draft as a *starting point* or not.
>
> Allison, Jim and I are looking into the possible ways to move
>  forward, but as some folks have clearly expressed, none of them are
>  great. We know that none of the proposals fit the requirements 100%,
>  and restarting the assessment process is of dubious use. Another
>  alternative is to start from scratch, but what kind of delay does
>  this introduce, and how do we do this (and will we really forget what
>  we've learned from existing proposals)?
>
> The three of us will be chatting in the next couple of days, and will
>  inform the WG of our findings.
>
> PatC
>
>
>
>
> --behcet
>
>
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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


From seamoby-admin@ietf.org  Tue Jan 22 06:39: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 GAA15832
	for ; Tue, 22 Jan 2002 06:39: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 GAA02585;
	Tue, 22 Jan 2002 06:26: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 GAA02560
	for ; Tue, 22 Jan 2002 06:26:47 -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 GAA15668
	for ; Tue, 22 Jan 2002 06:26:44 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0MBQjH88562;
	Tue, 22 Jan 2002 12:26:45 +0100 (CET)
Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP
	id 38B8BC05B; Tue, 22 Jan 2002 12:26:11 +0100 (CET)
Date: Tue, 22 Jan 2002 12:37:56 +0100
From: Marcus Brunner 
Reply-To: brunner@ccrle.nec.de
To: George Tsirtsis , seamoby@ietf.org
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Message-ID: <8727759.1011703076@[192.168.102.79]>
In-Reply-To: <8C92E23A3E87FB479988285F9E22BE465AB9B8@ftmail>
References:  <8C92E23A3E87FB479988285F9E22BE465AB9B8@ftmail>
X-Mailer: Mulberry/2.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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

George,

If there is no need, there would not have been 5 proposals and that kind of 
discussion, because nobody would care about the outcome.

Marcus

--On Monday, January 21, 2002 6:29 PM -0500 George Tsirtsis 
 wrote:

>
> -----Original Message-----
> From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> Sent: Monday, January 21, 2002 11:04 PM
> To: Pat R. Calhoun
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
>
> ...
> - Completely dropping this work item, is this an option?
>
> GT> I will risk the following opinion since I have been following this
> discussion for some time: I like the option above. Given the level of
> resentment between people in this sub-group I can not see how this work
> will be successful no matter what the process is. Any processes is flawed
> unless people want to work with it.
>
> Do not despair, the work item will reincarnate it self when there is
> actual need for it.
>
> George
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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


From seamoby-admin@ietf.org  Tue Jan 22 06:45: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 GAA15904
	for ; Tue, 22 Jan 2002 06:45: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 GAA03107;
	Tue, 22 Jan 2002 06:32: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 GAA03077
	for ; Tue, 22 Jan 2002 06:32:17 -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 GAA15728
	for ; Tue, 22 Jan 2002 06:32:14 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0MBWHH88630;
	Tue, 22 Jan 2002 12:32:17 +0100 (CET)
Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP
	id C961DC05B; Tue, 22 Jan 2002 12:31:43 +0100 (CET)
Date: Tue, 22 Jan 2002 12:43:29 +0100
From: Marcus Brunner 
Reply-To: brunner@ccrle.nec.de
To: "Faccin Stefano (NRC/Dallas)" , seamoby@ietf.org
Subject: RE: [Seamoby] Consensus Call:Reaching Closure on Paging Decision
Message-ID: <9060298.1011703409@[192.168.102.79]>
In-Reply-To: <82ECD4351A4A9547957C606034A3CB8D0B02D0@daebe005.NOE.Nokia.com>
References:  <82ECD4351A4A9547957C606034A3CB8D0B02D0@daebe005.NOE.Nokia.com>
X-Mailer: Mulberry/2.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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

Stefano,

It is not possible to start from scratch, the proposals are on the table, 
and following the discussion it does not seam that people forget their 
proposal if starting from scatch.

And again we have an open design team already with Marco as editor (not 
protocol designer, ...), and he wants help from co-authors with their 
expertise, which he expressed quite often.

Marcus


--On Friday, January 18, 2002 3:59 PM -0600 "Faccin Stefano (NRC/Dallas)" 
 wrote:

> Scott,
>
> I support the position that Rene expressed on my behalf. Without going
> into the details with the risk to inflame and confuse even more the
> discussion, I do not agree with the way the decision for the WG draft
> has been made.
>
> Personally I do not believe that just re-opening the selection of the
> starting ID is the solution. My first choice would be the creation of a
> design team that starts from scratch, i.e. none of the current IDs is
> the starting point. Whether the team is open or closed is not important
> to me.
>
> If this is not acceptable, although I do not see any other realistic
> solution my second choice is to support re-opening the selection process
> for a starting ID. However, this time we need to clearly define up-front
> how the decision is going to be made and avoid any decision that may be
> interpreted as shady and lead to further delays.
>
> Cheers,
> Stefano
>
> -----Original Message-----
> From: ext Scott Bradner [mailto:sob@harvard.edu]
> Sent: Thursday, January 17, 2002 6:33 PM
> To: kempf@docomolabs-usa.com; Purnadi Rene (NRC/Dallas);
> seamoby@ietf.org
> Cc: mankin@isi.edu; sob@harvard.edu
> Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging
> Decision
>
>
>> We vote to re-open
>
> just to be sure - each of the listed people on their own came to that
> conclusion?
>
> ----
> From rene.purnadi@nokia.com  Thu Jan 17 19:09:34 2002
> X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
> content-class: urn:content-classes:message
> MIME-Version: 1.0
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging
> Decision
> Date: Thu, 17 Jan 2002 18:09:26 -0600
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
> Thread-Topic: [Seamoby] Concensus Call:Reaching Closure on Paging
> Decision
> Thread-Index: AcGfjB5vADj3orhMSASYBVeaoRZw8wAJu5gQ
> From: "Purnadi Rene (NRC/Dallas)" 
> To: "'ext James Kempf'" , 
> Cc: , "Allison Mankin" 
> X-OriginalArrivalTime: 18 Jan 2002 00:09:26.0999 (UTC)
> FILETIME=[645F6E70:01C19FB4]
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by
> newdev.harvard.edu id g0I09TS23621
>
> James,
>
> We vote to re-open the selection phase. By the way, Rene Purnadi is one
> of the author in the draft koodli and his involvement in this vote is
> not based on 'sour grapes' but to seek a valid selection procedure.
>
> Thank you.
>
> Stefano Faccin, Rajeev Koodli, Franck Le, Jari T. Malinen, Rene Purnadi
> and Srinivas Sreemanthula
> Nokia Research Center
>
> -----Original Message-----
> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Thursday, January 17, 2002 1:18 PM
> To: seamoby@ietf.org
> Cc: sob@harvard.edu; Allison Mankin
> Subject: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
>
>
> All,
>
> Pat and I made a selection for what to start with, not what to end with.
> The WG will determine what the final technology looks like.
>
> 1) If you want to support or disagree with the selection of the starting
>  ID, say so now please.
>
> 2) If there is not consensus that we should re-open the selection phase,
> then we will move forward based on the selection in the next few days.
>
> 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
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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


From seamoby-admin@ietf.org  Tue Jan 22 07:06: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 HAA16083
	for ; Tue, 22 Jan 2002 07:06: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 GAA03442;
	Tue, 22 Jan 2002 06:47: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 GAA03413
	for ; Tue, 22 Jan 2002 06:47:35 -0500 (EST)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15949
	for ; Tue, 22 Jan 2002 06:47:32 -0500 (EST)
Received: by RRMAIL01 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 22 Jan 2002 06:47:03 -0500
Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB9C5@ftmail>
From: George Tsirtsis 
To: "'brunner@ccrle.nec.de'" , seamoby@ietf.org
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Tue, 22 Jan 2002 06:46:58 -0500
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

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

Well, the chairs asked who is planning to implement a possible
standard in the area in a product any time soon...I did not see many
hands going up...in fact I did not see any.

My main point, however, was that I do not see how any process will
allow you to go forward given the current climate. Anyway, I have no
intention or power to stop you so good luck.

Regards
George

- -----Original Message-----
From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
Sent: Tuesday, January 22, 2002 11:38 AM
To: George Tsirtsis; seamoby@ietf.org
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision


George,

If there is no need, there would not have been 5 proposals and that
kind of 
discussion, because nobody would care about the outcome.

Marcus

- --On Monday, January 21, 2002 6:29 PM -0500 George Tsirtsis 
 wrote:

>
> -----Original Message-----
> From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> Sent: Monday, January 21, 2002 11:04 PM
> To: Pat R. Calhoun
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
> Decision 
>
> ...
> - Completely dropping this work item, is this an option?
>
> GT> I will risk the following opinion since I have been following
> this discussion for some time: I like the option above. Given the
> level of resentment between people in this sub-group I can not see
> how this work will be successful no matter what the process is. Any
> processes is flawed unless people want to work with it.
>
> Do not despair, the work item will reincarnate it self when there
> is actual need for it.
>
> George
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>



- --------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus


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

iQA/AwUBPE1Q4akwWXc3MfAbEQJW1ACgghEo7z0+qXSRrZBy9faHRE5dkkkAoONF
diXAng3tmaaDh/t5qiv1tO7W
=MXnq
-----END PGP SIGNATURE-----

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


From seamoby-admin@ietf.org  Tue Jan 22 11:54: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 LAA00032
	for ; Tue, 22 Jan 2002 11:54: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 LAA20134;
	Tue, 22 Jan 2002 11:38: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 LAA20105
	for ; Tue, 22 Jan 2002 11:38:28 -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 LAA29283
	for ; Tue, 22 Jan 2002 11:38:24 -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 KAA09511
	for ; Tue, 22 Jan 2002 10:37:57 -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 g0MGbum22133
	for ; Tue, 22 Jan 2002 10:37:56 -0600 (CST)
Message-ID: <3C4D955E.4090506@alcatel.com>
Date: Tue, 22 Jan 2002 10:37: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] Concensus Call:Reaching Closure on Paging Decision
References:  <3C4C9E56.5070007@alcatel.com> <8604072.1011702953@[192.168.102.79]>
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, (George, Baba, Maroc, Marcus, et al.)

    Thanks for your comments.
It seems that Pat has not offered the design team as a choice. So the 
two design team choices I gave seem to be out of question.
  In this case, what is the most widely accepted choice? In my opinion 
it WAS the reselection and NOT to  move forward.
  Move forward is only supported by draft-renker people but nobody else.
  To George's comments: my last choice was there because Yoshi talked in 
his recent mail, on the need for modifying the requirements.

  I think we should make sure clearly what was the consensus on the two 
choices given by Pat. I clearly am stating that my opinion is the 
reselection.

Regards,

--behcet


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


From seamoby-admin@ietf.org  Tue Jan 22 12:58: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 MAA02344
	for ; Tue, 22 Jan 2002 12:58: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 MAA00849;
	Tue, 22 Jan 2002 12:40: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 MAA00804
	for ; Tue, 22 Jan 2002 12:40:09 -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 MAA01802
	for ; Tue, 22 Jan 2002 12:40:07 -0500 (EST)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA22696;
	Tue, 22 Jan 2002 11:39:38 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g0MHdbr00856;
	Tue, 22 Jan 2002 11:39:37 -0600 (CST)
Message-ID: <3C4DA3D2.7070203@alcatel.com>
Date: Tue, 22 Jan 2002 11:39:31 -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: Baba S 
CC: seamoby@ietf.org
Subject: Re: [Seamoby]  Paging Expertise
References:  <3C4C9E56.5070007@alcatel.com> <20020122.032156.60852681.shinichi1.baba@toshiba.co.jp>
Content-Type: multipart/alternative;
 boundary="------------070405060009080205010001"
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


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


I am starting a new thread here.
It is not true that there are no paging experts out there who can make 
judgements on architectural and algorithmic aspects of solutions. On IP 
Paging I can mention Ramjee Ramachandran (Lucent), Claude Castelluccia 
(Inria), Andrew Campbell (Columbia).
  Layer 2 paging is an old area, there are so many academic researchers 
who wrote papers just look in any ICC, Globecom, Infocom proceedings.

Regards,
Baba S wrote:

>Hi Behcet,
>
>>May I propose the following alternatives:
>>- restart the selection process which means let everybody to revise and 
>>resubmit independently which of course is open to the new players;
>>This solution brings the assessment problem, then the assessment process 
>>should be agreed. I would recommend getting expert opinion rather than 
>>the volunteers.
>>
>
>How about assessing each other. Since we don't have
>so much experts so far, I think.
>
--behcet


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







I am starting a new thread here.

It is not true that there are no paging experts out there who can make judgements
on architectural and algorithmic aspects of solutions. On IP Paging I can
mention Ramjee Ramachandran (Lucent), Claude Castelluccia (Inria), Andrew
Campbell (Columbia).

  Layer 2 paging is an old area, there are so many academic researchers who
wrote papers just look in any ICC, Globecom, Infocom proceedings. 



Regards,

Baba S wrote:



  
Hi Behcet,


  

    
May I propose the following alternatives:
- restart the selection process which means let everybody to revise and 
resubmit independently which of course is open to the new players;
This solution brings the assessment problem, then the assessment process 
should be agreed. I would recommend getting expert opinion rather than 
the volunteers.

    

    

How about assessing each other. Since we don't have
so much experts so far, I think.


    

--behcet

    

    
    

--------------070405060009080205010001--


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


From seamoby-admin@ietf.org  Tue Jan 22 13:12: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 NAA02745
	for ; Tue, 22 Jan 2002 13:12: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 MAA01324;
	Tue, 22 Jan 2002 12:54: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 MAA01293
	for ; Tue, 22 Jan 2002 12:54:28 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02246
	for ; Tue, 22 Jan 2002 12:54:25 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 22 Jan 2002 09:53:57 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Behcet Sarikaya'" ,
        Baba S
	 
Cc: seamoby@ietf.org
Subject: RE: [Seamoby]  Paging Expertise
Date: Tue, 22 Jan 2002 09:53:31 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A36D.B42FF890"
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_01C1A36D.B42FF890
Content-Type: text/plain

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

Behcet,
 
Please discontinue any further procedural discussions on the list,
and continue with the technical threads. In case you are interested,
the procedures for gauging WG concensus can be found in RFC 2026.
 
As I previously stated, Jim, Allison and I are discussing the
possible paths forward and will notify the WG of our findings.
 
PatC

- -----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] 
Sent: Tuesday, January 22, 2002 9:40 AM
To: Baba S
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Paging Expertise



I am starting a new thread here.
It is not true that there are no paging experts out there who can
make judgements on architectural and algorithmic aspects of
solutions. On IP Paging I can mention Ramjee Ramachandran (Lucent),
Claude Castelluccia (Inria), Andrew Campbell (Columbia).
  Layer 2 paging is an old area, there are so many academic
researchers who wrote papers just look in any ICC, Globecom, Infocom
proceedings. 

Regards,
Baba S wrote:


Hi Behcet,


May I propose the following alternatives:
- - restart the selection process which means let everybody to revise
and 
resubmit independently which of course is open to the new players;
This solution brings the assessment problem, then the assessment
process 
should be agreed. I would recommend getting expert opinion rather
than 
the volunteers.


How about assessing each other. Since we don't have
so much experts so far, I think.


- --behcet




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

iQA/AwUBPE2nGzN1fXKoxmisEQKSTwCg20Sw3FQxoEzpHde2BzDfHqk1xeEAoJmN
40hokszTQZ4saXW7RYAuApmm
=B6ul
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1A36D.B42FF890
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [Seamoby]  Paging Expertise




 

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

Hash: SHA1




Behcet,

 

Please discontinue any further procedural =
discussions on the list,

and continue with the technical threads. In case you =
are interested,

the procedures for gauging WG concensus can be found =
in RFC 2026.

 

As I previously stated, Jim, Allison and I are =
discussing the

possible paths forward and will notify the WG of our =
findings.

 

PatC




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

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

Sent: Tuesday, January 22, 2002 9:40 AM

To: Baba S

Cc: seamoby@ietf.org

Subject: Re: [Seamoby] Paging Expertise








I am starting a new thread here.

It is not true that there are no paging experts out =
there who can

make judgements on architectural and algorithmic =
aspects of

solutions. On IP Paging I can mention Ramjee =
Ramachandran (Lucent),

Claude Castelluccia (Inria), Andrew Campbell =
(Columbia).

  Layer 2 paging is an old area, there are so =
many academic

researchers who wrote papers just look in any ICC, =
Globecom, Infocom

proceedings. 




Regards,

Baba S wrote:






Hi Behcet,






May I propose the following alternatives:

- - restart the selection process which means let =
everybody to revise

and 

resubmit independently which of course is open to =
the new players;

This solution brings the assessment problem, then =
the assessment

process 

should be agreed. I would recommend getting expert =
opinion rather

than 

the volunteers.






How about assessing each other. Since we don't =
have

so much experts so far, I think.






- --behcet










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

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




iQA/AwUBPE2nGzN1fXKoxmisEQKSTwCg20Sw3FQxoEzpHde2BzDfHqk1xeEAoJm=
N

40hokszTQZ4saXW7RYAuApmm

=3DB6ul

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





------_=_NextPart_001_01C1A36D.B42FF890--

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


From seamoby-admin@ietf.org  Tue Jan 22 14:47: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 OAA07765
	for ; Tue, 22 Jan 2002 14:47: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 OAA07209;
	Tue, 22 Jan 2002 14:30: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 OAA07181
	for ; Tue, 22 Jan 2002 14:30:40 -0500 (EST)
Received: from NS1.US.PRSERV.NET ([64.180.246.83])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06739
	for ; Tue, 22 Jan 2002 14:30:36 -0500 (EST)
From: sydney@vkistudios.org
Message-Id: <200201221930.OAA06739@ietf.org>
Reply-To: seo@vkistudios.org
To: seamoby@ietf.org
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Date: Tue, 22 Jan 2002 11:34:10 -0800
Subject: [Seamoby] ADV: Professional Internet Marketing
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



Professional Internet Marketing, VKI Studios 1-866-733-8899














  
 
    
    1-866-733-8899 
  

  
 
    
  

  
 
    
  

  
 
    
  

  
 
    
  

  
 
    
  

  
 
    
  

  
 
    
  

  
 
    
  

  
 
    
  

  
 
    
  

  

    
  




 




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


From seamoby-admin@ietf.org  Tue Jan 22 17:13: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 RAA12937
	for ; Tue, 22 Jan 2002 17:13: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 QAA14387;
	Tue, 22 Jan 2002 16:57: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 QAA14357
	for ; Tue, 22 Jan 2002 16:57:31 -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 QAA12404
	for ; Tue, 22 Jan 2002 16:57:26 -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 NAA14118;
	Tue, 22 Jan 2002 13:56:49 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0MLuno11180;
	Tue, 22 Jan 2002 13:56:49 -0800
X-mProtect:  Tue, 22 Jan 2002 13:56:49 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com smtpdXUKXqz; Tue, 22 Jan 2002 13:56:47 PST
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id NAA36398; Tue, 22 Jan 2002 13:56:47 -0800 (PST)
Message-ID: <3C4DE01F.7396E55C@iprg.nokia.com>
Date: Tue, 22 Jan 2002 13:56:47 -0800
From: "Jari T. Malinen" 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: George Tsirtsis 
CC: "'brunner@ccrle.nec.de'" , seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <8C92E23A3E87FB479988285F9E22BE465AB9C5@ftmail>
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

All,

> Well, the chairs asked who is planning to implement a possible
> standard in the area in a product any time soon...I did not see many
> hands going up...in fact I did not see any.

At this stage, what would be the risks in products? Would there
not be some research prototypes first when the protocol starts
to show signs of consolidation?

> My main point, however, was that I do not see how any process will
> allow you to go forward given the current climate. Anyway, I have no
> intention or power to stop you so good luck.

I am more optimistic. If grievances for process and participation
are aired openly now, and everybody's concerns are addressed while
all understanding that their proposal (mostly) alone will not make it,
this could also bring together a coauthoring design team willing to
defend a common text, a compromise, yes, but adopted by all.

As a side note, I appreciate Marco's comments on being open
and have no objections seeing him edit the text. If all have
the urge to go forward, it is a matter of definition, whether we
"officially" go from draft-renker, or from an empty proposal. With
the knowledge that it will anyway take big chuncks from draft-
renker as well as from other drafts, some signs of willingness to
compromise from certain parties (wink, wink) might move things
ahead.. With Marco's comment and wg chairs' recommendations in
mind, it will anyway be a puzzle with discussions how to put the
pieces together.

> Regards
> George

BR,

-Jari

> - -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: Tuesday, January 22, 2002 11:38 AM
> To: George Tsirtsis; seamoby@ietf.org
> Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging
> Decision
> 
> George,
> 
> If there is no need, there would not have been 5 proposals and that
> kind of
> discussion, because nobody would care about the outcome.
> 
> Marcus
> 
> - --On Monday, January 21, 2002 6:29 PM -0500 George Tsirtsis
>  wrote:
> 
> >
> > -----Original Message-----
> > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > Sent: Monday, January 21, 2002 11:04 PM
> > To: Pat R. Calhoun
> > Cc: seamoby@ietf.org
> > Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
> > Decision
> >
> > ...
> > - Completely dropping this work item, is this an option?
> >
> > GT> I will risk the following opinion since I have been following
> > this discussion for some time: I like the option above. Given the
> > level of resentment between people in this sub-group I can not see
> > how this work will be successful no matter what the process is. Any
> > processes is flawed unless people want to work with it.
> >
> > Do not despair, the work item will reincarnate it self when there
> > is actual need for it.
> >
> > George
> >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> 
> - --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use 
> 
> iQA/AwUBPE1Q4akwWXc3MfAbEQJW1ACgghEo7z0+qXSRrZBy9faHRE5dkkkAoONF
> diXAng3tmaaDh/t5qiv1tO7W
> =MXnq
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> 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 Jan 22 18:23: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 SAA14239
	for ; Tue, 22 Jan 2002 18:23: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 SAA17361;
	Tue, 22 Jan 2002 18:10: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 SAA17331
	for ; Tue, 22 Jan 2002 18:10:28 -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 SAA14135
	for ; Tue, 22 Jan 2002 18:10:21 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0MN9se09910
	for ; Tue, 22 Jan 2002 15:09:54 -0800 (PST)
Message-ID: <028f01c1a399$ad4fdaa0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Date: Tue, 22 Jan 2002 15:08: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] Summary of Discussion 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

Hi folks,

I've just read through the back email on this thread over the past
couple weeks
in response to Phil and  Govind's original posting, and here
are a couple observations and proposals.

1) There seems to be broad agreement that we need a requirement saying
that
the CAR discovery protocol MUST support IPv4 and IPv6.

2) There was some difference of opinion on whether the requirements
draft
should say anything about how this might be done. If nobody has a
further
objection, can we leave this as an implementation issue?

3) There also seems to be a certain degree of agreement that we have
an explicit requirement, in addition to Requirement 9, which states that
a solution MUST be provided which supports existing mobility protocols.
Thus, the protocol must be both independent of mobility protocol
and capable of supporting existing mobility protocols. Again, if
there is no objection, can we include this as a requirement?

4) There was some difference of opinion about whether support
for interdomain discovery SHOULD or MUST be required.
Since some good arguments were made for supporting
interdomain discovery, I'd like to suggest we keep this
in for now as a SHOULD unless there are any further objections
to be discussed.

5) Some working group members suggested that the requirements
for MN-based v.s. AR-based discovery be separated. The
draft editors would like to see examples of requirements that
need to be separated. Does anyone have some examples?
If not, can we just go forward with a single set of requirements
for now?

Comments?

            jak




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


From seamoby-admin@ietf.org  Tue Jan 22 19:30: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 TAA15390
	for ; Tue, 22 Jan 2002 19:30: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 SAA18353;
	Tue, 22 Jan 2002 18:47: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 SAA18315
	for ; Tue, 22 Jan 2002 18:46:57 -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 SAA14589
	for ; Tue, 22 Jan 2002 18:46:52 -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 RAA27045;
	Tue, 22 Jan 2002 17:46:26 -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 g0MNkPm03085;
	Tue, 22 Jan 2002 17:46:25 -0600 (CST)
Message-ID: <3C4DF9C8.4090609@alcatel.com>
Date: Tue, 22 Jan 2002 17:46:16 -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: "Jari T. Malinen" 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <8C92E23A3E87FB479988285F9E22BE465AB9C5@ftmail> <3C4DE01F.7396E55C@iprg.nokia.com>
Content-Type: multipart/alternative;
 boundary="------------020400050604040907000707"
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


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

Dear All,
  This is a mail on TECHNICAL issues. It may refer to the procedural 
issues when relevant
I looked at the drafts first time seriously!
First of all from size perspective: draft-renker 59 pages
draft-ohba 52 pages
draft-koodli 31 pages
draft-sarikaya 22 pages
draft-guri 16 pages.
  Combining all these would give a document of 180 pages of extreme 
complexity and confusion. So I agree with Jari, attaching text from 
different proposals written with different background is simply NOT 
going to work.
  Now, draft-renker starts with a very simple architecture: of
PA -- AR -- MN
using only PA entity of the requirements document. The rest of 
draft-renker after page 11  is on Mobile IPv6 mapping. Draft-sarikaya is 
also based on Mobile IPv6 and so these two drafts should have been 
treated in a similar way. What do you say Srinivas? i.e most possibly 
refuse both.
  Next draft-ohba,  it has DMA, PA and TA of the requirements draft. The 
basic architecture has the DMA on the link which is I think an 
architectural problem and uses only TA. Remember this draft is called 
Last Hop DMHA Protocol. Next, draft-ohba tries to handle host mobility 
and there draft-ohba introduces PA. There is a long list of the states 
maintained in each entity which takes several pages. There is also a 
description of an 802.11 implementation in the annex.
  Next draft-koodli, it has PF entity which probably stands for DMA, TA 
and PA which is in charge of paging and the ARs on subnets with MNs. The 
mobility is handled by the L2 and L3 paging areas but only textual 
description. From p.10 onwards it covers security and from p.15 onwards 
it covers mapping to MIPv6, regional registration and TO HMIPv6.
  However, draft-sarikaya completely integrates paging to MIPv6 and 
HMIPv6 (as such it is not the only draft that covers HMIPv6).
  Draft-guri is completely on the architectural entities of the 
requirements draft. It uses DMA, PA and TA. It defines a model for L2 
and L3 paging areas. It is a complete IP paging protocol independent of MIP.

  Can someone tell me how can we integrate these drafts by giving some 
text to Marco? Do you think that I am rigid and non conciliatory Jari?

Jari T. Malinen wrote:

>All,
>
>>Well, the chairs asked who is planning to implement a possible
>>standard in the area in a product any time soon...I did not see many
>>hands going up...in fact I did not see any.
>>
>
>At this stage, what would be the risks in products? Would there
>not be some research prototypes first when the protocol starts
>to show signs of consolidation?
>
>>My main point, however, was that I do not see how any process will
>>allow you to go forward given the current climate. Anyway, I have no
>>intention or power to stop you so good luck.
>>
>
>I am more optimistic. If grievances for process and participation
>are aired openly now, and everybody's concerns are addressed while
>all understanding that their proposal (mostly) alone will not make it,
>this could also bring together a coauthoring design team willing to
>defend a common text, a compromise, yes, but adopted by all.
>
>As a side note, I appreciate Marco's comments on being open
>and have no objections seeing him edit the text. If all have
>the urge to go forward, it is a matter of definition, whether we
>"officially" go from draft-renker, or from an empty proposal. With
>the knowledge that it will anyway take big chuncks from draft-
>renker as well as from other drafts, some signs of willingness to
>compromise from certain parties (wink, wink) might move things
>ahead.. With Marco's comment and wg chairs' recommendations in
>mind, it will anyway be a puzzle with discussions how to put the
>pieces together.
>
>>Regards
>>George
>>
>
>BR,
>
>-Jari
>
>>- -----Original Message-----
>>From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
>>Sent: Tuesday, January 22, 2002 11:38 AM
>>To: George Tsirtsis; seamoby@ietf.org
>>Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging
>>Decision
>>
>>George,
>>
>>If there is no need, there would not have been 5 proposals and that
>>kind of
>>discussion, because nobody would care about the outcome.
>>
>>Marcus
>>
>>- --On Monday, January 21, 2002 6:29 PM -0500 George Tsirtsis
>> wrote:
>>
>>>-----Original Message-----
>>>From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
>>>Sent: Monday, January 21, 2002 11:04 PM
>>>To: Pat R. Calhoun
>>>Cc: seamoby@ietf.org
>>>Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
>>>Decision
>>>
>>>...
>>>- Completely dropping this work item, is this an option?
>>>
>>>GT> I will risk the following opinion since I have been following
>>>this discussion for some time: I like the option above. Given the
>>>level of resentment between people in this sub-group I can not see
>>>how this work will be successful no matter what the process is. Any
>>>processes is flawed unless people want to work with it.
>>>
>>>Do not despair, the work item will reincarnate it self when there
>>>is actual need for it.
>>>
>>>George
>>>
>>>
>>>
>>>_______________________________________________
>>>Seamoby mailing list
>>>Seamoby@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/seamoby
>>>
>>- --------------------------------------
>>Dr. Marcus Brunner
>>Network Laboratories
>>NEC Europe Ltd.
>>
>>E-Mail: brunner@ccrle.nec.de
>>WWW:    http://www.ccrle.nec.de/
>>personal home page: http://www.brubers.org/marcus
>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: PGPfreeware 7.0.3 for non-commercial use 
>>
>>iQA/AwUBPE1Q4akwWXc3MfAbEQJW1ACgghEo7z0+qXSRrZBy9faHRE5dkkkAoONF
>>diXAng3tmaaDh/t5qiv1tO7W
>>=MXnq
>>-----END PGP SIGNATURE-----
>>
>>_______________________________________________
>>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
>

-- 
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



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





Dear All,

  This is a mail on TECHNICAL issues. It may refer to the procedural issues
when relevant

I looked at the drafts first time seriously!

First of all from size perspective: draft-renker 59 pages

draft-ohba 52 pages

draft-koodli 31 pages

draft-sarikaya 22 pages

draft-guri 16 pages.

  Combining all these would give a document of 180 pages of extreme complexity
and confusion. So I agree with Jari, attaching text from different proposals
written with different background is simply NOT going to work.

  Now, draft-renker starts with a very simple architecture: of

PA -- AR -- MN

using only PA entity of the requirements document. The rest of draft-renker
after page 11  is on Mobile IPv6 mapping. Draft-sarikaya is also based on
Mobile IPv6 and so these two drafts should have been treated in a similar
way. What do you say Srinivas? i.e most possibly refuse both.

  Next draft-ohba,  it has DMA, PA and TA of the requirements draft. The
basic architecture has the DMA on the link which is I think an architectural
problem and uses only TA. Remember this draft is called Last Hop DMHA Protocol.
Next, draft-ohba tries to handle host mobility and there draft-ohba introduces
PA. There is a long list of the states maintained in each entity which takes
several pages. There is also a description of an 802.11 implementation in
the annex.

  Next draft-koodli, it has PF entity which probably stands for DMA, TA and
PA which is in charge of paging and the ARs on subnets with MNs. The mobility
is handled by the L2 and L3 paging areas but only textual description. From
p.10 onwards it covers security and from p.15 onwards it covers mapping to
MIPv6, regional registration and TO HMIPv6.

  However, draft-sarikaya completely integrates paging to MIPv6 and HMIPv6
(as such it is not the only draft that covers HMIPv6).

  Draft-guri is completely on the architectural entities of the requirements
draft. It uses DMA, PA and TA. It defines a model for L2 and L3 paging areas.
It is a complete IP paging protocol independent of MIP.



  Can someone tell me how can we integrate these drafts by giving some text
to Marco? Do you think that I am rigid and non conciliatory Jari?



Jari T. Malinen wrote:



  
All,


  

    
Well, the chairs asked who is planning to implement a possible
standard in the area in a product any time soon...I did not see many
hands going up...in fact I did not see any.

    

    

At this stage, what would be the risks in products? Would there
not be some research prototypes first when the protocol starts
to show signs of consolidation?


    

      
My main point, however, was that I do not see how any process will
allow you to go forward given the current climate. Anyway, I have no
intention or power to stop you so good luck.

      

      

I am more optimistic. If grievances for process and participation
are aired openly now, and everybody's concerns are addressed while
all understanding that their proposal (mostly) alone will not make it,
this could also bring together a coauthoring design team willing to
defend a common text, a compromise, yes, but adopted by all.

As a side note, I appreciate Marco's comments on being open
and have no objections seeing him edit the text. If all have
the urge to go forward, it is a matter of definition, whether we
"officially" go from draft-renker, or from an empty proposal. With
the knowledge that it will anyway take big chuncks from draft-
renker as well as from other drafts, some signs of willingness to
compromise from certain parties (wink, wink) might move things
ahead.. With Marco's comment and wg chairs' recommendations in
mind, it will anyway be a puzzle with discussions how to put the
pieces 
together.


      

        
Regards
George

        

        

BR,

-Jari


        

          
- -----Original Message-----
From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
Sent: Tuesday, January 22, 2002 11:38 AM
To: George Tsirtsis; seamoby@ietf.org
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision

George,

If there is no need, there would not have been 5 proposals and that
kind of
discussion, because nobody would care about the outcome.

Marcus

- --On Monday, January 21, 2002 6:29 PM -0500 George Tsirtsis
<G.Tsirtsis@flarion.com> wrote:


          

            
-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Monday, January 21, 2002 11:04 PM
To: Pat R. Calhoun
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision

...
- Completely dropping this work item, is this an option?

GT> I will risk the following opinion since I have been following
this discussion for some time: I like the option above. Given the
level of resentment between people in this sub-group I can not see
how this work will be successful no matter what the process is. Any
processes is flawed unless people want to work with it.

Do not despair, the work item will reincarnate it self when there
is actual need for it.

George



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


            

            
- --------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

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

iQA/AwUBPE1Q4akwWXc3MfAbEQJW1ACgghEo7z0+qXSRrZBy9faHRE5dkkkAoONF
diXAng3tmaaDh/t5qiv1tO7W
=MXnq
-----END PGP SIGNATURE-----

_______________________________________________
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

            

            

            
-- 
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


            

            
            

--------------020400050604040907000707--


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


From seamoby-admin@ietf.org  Tue Jan 22 21:03: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 VAA17169
	for ; Tue, 22 Jan 2002 21:03: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 TAA20347;
	Tue, 22 Jan 2002 19:50: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 TAA20315
	for ; Tue, 22 Jan 2002 19:50:15 -0500 (EST)
Received: from hotmail.com (f112.law9.hotmail.com [64.4.9.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15782
	for ; Tue, 22 Jan 2002 19:50:12 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 22 Jan 2002 16:49:44 -0800
Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP;
	Wed, 23 Jan 2002 00:49:43 GMT
X-Originating-IP: [63.78.179.4]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Tue, 22 Jan 2002 19:49:43 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 23 Jan 2002 00:49:44.0119 (UTC) FILETIME=[D9276C70:01C1A3A7]
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 James,

My comments inline

-Govind.

>
>Hi folks,
>
>I've just read through the back email on this thread over the past
>couple weeks
>in response to Phil and  Govind's original posting, and here
>are a couple observations and proposals.
>
>1) There seems to be broad agreement that we need a requirement saying
>that
>the CAR discovery protocol MUST support IPv4 and IPv6.
>
>2) There was some difference of opinion on whether the requirements
>draft
>should say anything about how this might be done. If nobody has a
>further
>objection, can we leave this as an implementation issue?
>

[GK] I think it is a strong requirement that we MUST support
IPv4 and IPv6. I agree, how this is done is a protocol specification issue. 
I also pointed out to Phil that this requirement is very much
already there in the given set of requirements and IMO an
explicit statement is redundant. I did not get a response from Phil
about this so I don't know whether he agrees with my comment.

>3) There also seems to be a certain degree of agreement that we have
>an explicit requirement, in addition to Requirement 9, which states that
>a solution MUST be provided which supports existing mobility protocols.
>Thus, the protocol must be both independent of mobility protocol
>and capable of supporting existing mobility protocols. Again, if
>there is no objection, can we include this as a requirement?
>

[GK] Again Phil did not answer Dirk's question regarding what he
means by the above statement that it MUST support mobility management
protocols? CAR discovery happens parallel to mobility management. It
is in the definition of CAR discovery that mobility management
protocols are going to use CAR discovery for the purpose of handovers.
What else is needed? Why do we need a separate requirement. Essentially
we are stating the need for CAR discovery here. Also, by the very fact
that we say we support inter-technology handovers (which clearly may
have different mobility management protocols) we imply that any mobility
management protocol will be able to use the output of CAR discovery.
Ofcourse, I might be wrong about this and Phil may have something else
in his mind.


>4) There was some difference of opinion about whether support
>for interdomain discovery SHOULD or MUST be required.
>Since some good arguments were made for supporting
>interdomain discovery, I'd like to suggest we keep this
>in for now as a SHOULD unless there are any further objections
>to be discussed.
>

[GK] Again with this I thought the majority decision was to go with
a MUST.

>5) Some working group members suggested that the requirements
>for MN-based v.s. AR-based discovery be separated. The
>draft editors would like to see examples of requirements that
>need to be separated. Does anyone have some examples?
>If not, can we just go forward with a single set of requirements
>for now?

[GK] I am almost ready with the first version of the requirements
draft. Please point out any differences that you perceive just because
CAR discovery is MN based or AR based. Also, I feel that this point
came up because we hadn't made it clear in the Issues draft that the
differentiation was based on time of CAR discovery rather than who initiates 
the process. But again I might be wrong about this and I welcome anyone's 
input on this.

>
>Comments?
>
>             jak
>
>
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby




_________________________________________________________________
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  Tue Jan 22 21:12:21 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 VAA17299
	for ; Tue, 22 Jan 2002 21:12:21 -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 UAA22270;
	Tue, 22 Jan 2002 20:45: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 UAA22242
	for ; Tue, 22 Jan 2002 20:45:39 -0500 (EST)
Received: from EXCHSRV.stormventures.com ([65.107.25.226])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16926
	for ; Tue, 22 Jan 2002 20:45:35 -0500 (EST)
Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 22 Jan 2002 17:44:43 -0800
Message-ID: 
From: "Pat R. Calhoun" 
To: "'Behcet Sarikaya'" ,
        "Jari T. Malinen"
	 
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Tue, 22 Jan 2002 17:43:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A3AF.688ED540"
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_01C1A3AF.688ED540
Content-Type: text/plain

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

You said "Can someone tell me how can we integrate these drafts by
giving some text to Marco? "

Which is *Exactly* what we have been trying to achieve. The deal is,
however, that we need a working base. Just pulling text from all over
will never work well, so we needed a starting point. What Jim,
Allison and I had decided was that Renker was the *starting point*
and that problems that were identified would be fixed, probably by
pulling text from other proposals, as the need arises.

However, as I've stated numerous times, we are looking at alternative
ways to move forward.

PatC
- -----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] 
Sent: Tuesday, January 22, 2002 3:46 PM
To: Jari T. Malinen
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging
Decision


Dear All,
  This is a mail on TECHNICAL issues. It may refer to the procedural
issues when relevant
I looked at the drafts first time seriously!
First of all from size perspective: draft-renker 59 pages
draft-ohba 52 pages
draft-koodli 31 pages
draft-sarikaya 22 pages
draft-guri 16 pages.
  Combining all these would give a document of 180 pages of extreme
complexity and confusion. So I agree with Jari, attaching text from
different proposals written with different background is simply NOT
going to work.
  Now, draft-renker starts with a very simple architecture: of
PA -- AR -- MN
using only PA entity of the requirements document. The rest of
draft-renker after page 11  is on Mobile IPv6 mapping. Draft-sarikaya
is also based on Mobile IPv6 and so these two drafts should have been
treated in a similar way. What do you say Srinivas? i.e most possibly
refuse both.
  Next draft-ohba,  it has DMA, PA and TA of the requirements draft.
The basic architecture has the DMA on the link which is I think an
architectural problem and uses only TA. Remember this draft is called
Last Hop DMHA Protocol. Next, draft-ohba tries to handle host
mobility and there draft-ohba introduces PA. There is a long list of
the states maintained in each entity which takes several pages. There
is also a description of an 802.11 implementation in the annex.
  Next draft-koodli, it has PF entity which probably stands for DMA,
TA and PA which is in charge of paging and the ARs on subnets with
MNs. The mobility is handled by the L2 and L3 paging areas but only
textual description. From p.10 onwards it covers security and from
p.15 onwards it covers mapping to MIPv6, regional registration and TO
HMIPv6.
  However, draft-sarikaya completely integrates paging to MIPv6 and
HMIPv6 (as such it is not the only draft that covers HMIPv6).
  Draft-guri is completely on the architectural entities of the
requirements draft. It uses DMA, PA and TA. It defines a model for L2
and L3 paging areas. It is a complete IP paging protocol independent
of MIP.

  Can someone tell me how can we integrate these drafts by giving
some text to Marco? Do you think that I am rigid and non conciliatory
Jari?

Jari T. Malinen wrote:

All,
Well, the chairs asked who is planning to implement a
possiblestandard in the area in a product any time soon...I did not
see manyhands going up...in fact I did not see any.
At this stage, what would be the risks in products? Would therenot be
some research prototypes first when the protocol startsto show signs
of consolidation?
My main point, however, was that I do not see how any process
willallow you to go forward given the current climate. Anyway, I have
nointention or power to stop you so good luck.
I am more optimistic. If grievances for process and participationare
aired openly now, and everybody's concerns are addressed whileall
understanding that their proposal (mostly) alone will not make
it,this could also bring together a coauthoring design team willing
todefend a common text, a compromise, yes, but adopted by all.As a
side note, I appreciate Marco's comments on being openand have no
objections seeing him edit the text. If all havethe urge to go
forward, it is a matter of definition, whether we"officially" go from
draft-renker, or from an empty proposal. Withthe knowledge that it
will anyway take big chuncks from draft-renker as well as from other
drafts, some signs of willingness tocompromise from certain parties
(wink, wink) might move thingsahead.. With Marco's comment and wg
chairs' recommendations inmind, it will anyway be a puzzle with
discussions how to put thepieces 
together.
RegardsGeorge
BR,-Jari
- - -----Original Message-----From: Marcus Brunner
[mailto:brunner@ccrle.nec.de]Sent: Tuesday, January 22, 2002 11:38
AMTo: George Tsirtsis; seamoby@ietf.orgSubject: RE: [Seamoby]
Concensus Call:Reaching Closure on PagingDecisionGeorge,If there is
no need, there would not have been 5 proposals and thatkind
ofdiscussion, because nobody would care about the outcome.Marcus-
- --On Monday, January 21, 2002 6:29 PM -0500 George
Tsirtsis wrote:
- -----Original Message-----From: Behcet Sarikaya
[mailto:behcet.sarikaya@alcatel.com]Sent: Monday, January 21, 2002
11:04 PMTo: Pat R. CalhounCc: seamoby@ietf.orgSubject: Re: [Seamoby]
Concensus Call:Reaching Closure on PagingDecision...- Completely
dropping this work item, is this an option?GT> I will risk the
following opinion since I have been followingthis discussion for some
time: I like the option above. Given thelevel of resentment between
people in this sub-group I can not seehow this work will be
successful no matter what the process is. Anyprocesses is flawed
unless people want to work with it.Do not despair, the work item will
reincarnate it self when thereis actual need for
it.George____________
___________________________________Seamoby mailing
listSeamoby@ietf.orghttps://www1.ietf.org/mailman/listinfo/seamoby
- - --------------------------------------Dr. Marcus BrunnerNetwork
LaboratoriesNEC Europe Ltd.E-Mail: brunner@ccrle.nec.deWWW:   
http://www.ccrle.nec.de/personal home page:
http://www.brubers.org/marcus-----BEGIN PGP SIGNATURE-----Version:
PGPfreeware 7.0.3 for non-commercial use
iQA/AwUBPE1Q4akwWXc3MfAbEQJW1ACgghEo7z0+qXSRrZBy9f
aHRE5dkkkAoONFdiXAng3tmaaDh/t5qiv1tO7W=MXnq-----END PGP
SIGNATURE-----_______________________________________________Seamoby
mailing
listSeamoby@ietf.orghttps://www1.ietf.org/mailman/listinfo/seamoby
_______________________________________________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/AwUBPE4VVjN1fXKoxmisEQLD7ACgxh2YYa5ocrHlqCInVwgzPPNjrW0AnRRU
tch0dVffA3bQ2kywlbFrGMoQ
=ndu1
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1A3AF.688ED540
Content-Type: text/html






RE: [Seamoby] Concensus Call:Reaching Closure on Paging Decision




 

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

Hash: SHA1




You said "Can someone tell me how can we integrate these drafts by

giving some text to Marco? "




Which is *Exactly* what we have been trying to achieve. The deal is,

however, that we need a working base. Just pulling text from all over

will never work well, so we needed a starting point. What Jim,

Allison and I had decided was that Renker was the *starting point*

and that problems that were identified would be fixed, probably by

pulling text from other proposals, as the need arises.




However, as I've stated numerous times, we are looking at alternative

ways to move forward.




PatC

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

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

Sent: Tuesday, January 22, 2002 3:46 PM

To: Jari T. Malinen

Cc: seamoby@ietf.org

Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging

Decision






Dear All,

  This is a mail on TECHNICAL issues. It may refer to the procedural

issues when relevant

I looked at the drafts first time seriously!

First of all from size perspective: draft-renker 59 pages

draft-ohba 52 pages

draft-koodli 31 pages

draft-sarikaya 22 pages

draft-guri 16 pages.

  Combining all these would give a document of 180 pages of extreme

complexity and confusion. So I agree with Jari, attaching text from

different proposals written with different background is simply NOT

going to work.

  Now, draft-renker starts with a very simple architecture: of

PA -- AR -- MN

using only PA entity of the requirements document. The rest of

draft-renker after page 11  is on Mobile IPv6 mapping. Draft-sarikaya

is also based on Mobile IPv6 and so these two drafts should have been

treated in a similar way. What do you say Srinivas? i.e most possibly

refuse both.

  Next draft-ohba,  it has DMA, PA and TA of the requirements draft.

The basic architecture has the DMA on the link which is I think an

architectural problem and uses only TA. Remember this draft is called

Last Hop DMHA Protocol. Next, draft-ohba tries to handle host

mobility and there draft-ohba introduces PA. There is a long list of

the states maintained in each entity which takes several pages. There

is also a description of an 802.11 implementation in the annex.

  Next draft-koodli, it has PF entity which probably stands for DMA,

TA and PA which is in charge of paging and the ARs on subnets with

MNs. The mobility is handled by the L2 and L3 paging areas but only

textual description. From p.10 onwards it covers security and from

p.15 onwards it covers mapping to MIPv6, regional registration and TO

HMIPv6.

  However, draft-sarikaya completely integrates paging to MIPv6 and

HMIPv6 (as such it is not the only draft that covers HMIPv6).

  Draft-guri is completely on the architectural entities of the

requirements draft. It uses DMA, PA and TA. It defines a model for L2

and L3 paging areas. It is a complete IP paging protocol independent

of MIP.




  Can someone tell me how can we integrate these drafts by giving

some text to Marco? Do you think that I am rigid and non conciliatory

Jari?




Jari T. Malinen wrote:




All,

Well, the chairs asked who is planning to implement a

possiblestandard in the area in a product any time soon...I did not

see manyhands going up...in fact I did not see any.

At this stage, what would be the risks in products? Would therenot be

some research prototypes first when the protocol startsto show signs

of consolidation?

My main point, however, was that I do not see how any process

willallow you to go forward given the current climate. Anyway, I have

nointention or power to stop you so good luck.

I am more optimistic. If grievances for process and participationare

aired openly now, and everybody's concerns are addressed whileall

understanding that their proposal (mostly) alone will not make

it,this could also bring together a coauthoring design team willing

todefend a common text, a compromise, yes, but adopted by all.As a

side note, I appreciate Marco's comments on being openand have no

objections seeing him edit the text. If all havethe urge to go

forward, it is a matter of definition, whether we"officially" go from

draft-renker, or from an empty proposal. Withthe knowledge that it

will anyway take big chuncks from draft-renker as well as from other

drafts, some signs of willingness tocompromise from certain parties

(wink, wink) might move thingsahead.. With Marco's comment and wg

chairs' recommendations inmind, it will anyway be a puzzle with

discussions how to put thepieces 

together.

RegardsGeorge

BR,-Jari

- - -----Original Message-----From: Marcus Brunner

[mailto:brunner@ccrle.nec.de]Sent: Tuesday, January 22, 2002 11:38

AMTo: George Tsirtsis; seamoby@ietf.orgSubject: RE: [Seamoby]

Concensus Call:Reaching Closure on PagingDecisionGeorge,If there is

no need, there would not have been 5 proposals and thatkind

ofdiscussion, because nobody would care about the outcome.Marcus-

- --On Monday, January 21, 2002 6:29 PM -0500 George

Tsirtsis<G.Tsirtsis@flarion.com> wrote:

- -----Original Message-----From: Behcet Sarikaya

[mailto:behcet.sarikaya@alcatel.com]Sent: Monday, January 21, 2002

11:04 PMTo: Pat R. CalhounCc: seamoby@ietf.orgSubject: Re: [Seamoby]

Concensus Call:Reaching Closure on PagingDecision...- Completely

dropping this work item, is this an option?GT> I will risk the

following opinion since I have been followingthis discussion for some

time: I like the option above. Given thelevel of resentment between

people in this sub-group I can not seehow this work will be

successful no matter what the process is. Anyprocesses is flawed

unless people want to work with it.Do not despair, the work item will

reincarnate it self when thereis actual need for

it.George____________

___________________________________Seamoby mailing

listSeamoby@ietf.orghttps://www1.ietf.org/mailman/listinfo/seamoby

- - --------------------------------------Dr. Marcus BrunnerNetwork

LaboratoriesNEC Europe Ltd.E-Mail: brunner@ccrle.nec.deWWW:   

http://www.ccrle.nec.de/personal home page:

http://www.brubers.org/marcus-----BEGIN PGP SIGNATURE-----Version:

PGPfreeware 7.0.3 for non-commercial use

<http://www.pgp.com>iQA/AwUBPE1Q4akwWXc3MfAbEQJW1ACgghEo7z0+qXSRrZBy9f

aHRE5dkkkAoONFdiXAng3tmaaDh/t5qiv1tO7W=MXnq-----END PGP

SIGNATURE-----_______________________________________________Seamoby

mailing

listSeamoby@ietf.orghttps://www1.ietf.org/mailman/listinfo/seamoby

_______________________________________________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/AwUBPE4VVjN1fXKoxmisEQLD7ACgxh2YYa5ocrHlqCInVwgzPPNjrW0AnRRU

tch0dVffA3bQ2kywlbFrGMoQ

=ndu1

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





------_=_NextPart_001_01C1A3AF.688ED540--

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


From seamoby-admin@ietf.org  Tue Jan 22 22:08: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 WAA19202
	for ; Tue, 22 Jan 2002 22:08: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 VAA25127;
	Tue, 22 Jan 2002 21:50: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 VAA25100
	for ; Tue, 22 Jan 2002 21:50:19 -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 VAA18830
	for ; Tue, 22 Jan 2002 21:50:15 -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 SAA03850;
	Tue, 22 Jan 2002 18:49:46 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0N2njP29290;
	Tue, 22 Jan 2002 18:49:45 -0800
X-mProtect:  Tue, 22 Jan 2002 18:49:45 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com smtpdg5tFyC; Tue, 22 Jan 2002 18:49:44 PST
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id SAA36689; Tue, 22 Jan 2002 18:49:44 -0800 (PST)
Message-ID: <3C4E24C8.771CC63A@iprg.nokia.com>
Date: Tue, 22 Jan 2002 18:49:44 -0800
From: "Jari T. Malinen" 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Behcet Sarikaya 
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <8C92E23A3E87FB479988285F9E22BE465AB9C5@ftmail> <3C4DE01F.7396E55C@iprg.nokia.com> <3C4DF9C8.4090609@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,

If we are in a hurry, the complexity will be mind-boggling.
A construction may be a possibility, maybe I'm optimistic,
using the material as a set of design elements (build a framework
based on components in the proposals)..

>   Now, draft-renker starts with a very simple architecture: of
> PA -- AR -- MN
> using only PA entity of the requirements document. The rest of
> draft-renker after page 11  is on Mobile IPv6 mapping. Draft-sarikaya is
> also based on Mobile IPv6 and so these two drafts should have been treated
> in a similar way. What do you say Srinivas? i.e most possibly refuse both.

A first observation is that there is an architecture each
proposal presents. Some try to follow that outlined in the RFC, some
go with a simpler model. The first question is: do we go with the
good preliminary work of James et al in choosing the architecture or
can we agree on a simpler model which was a hint given by wg chairs'
recommendation etc. Maybe that's a first decision to do. Also,
having some sense of understanding of requirement priority could
help. Chairs have stated their preference, maybe these should be
checked in the discussion..

Whenever a choice is made, that material in most drafts can be skipped.
By construction maybe a simpler / shorter text could be possible.
Even though not bad, genericity in draft-renker was problematic
to me, a design should rather economically communicate an unambiguous
design without going to surveys etc. By construction that might be
more likely than patching a large framework, perhaps.

Sure it is not going to be easy, probably impossible. That is not
sure yet, though. Maybe Marco could try to build towards a more
short/readable a framework this way, reflecting issues discussed,
I don't know?

>   Next draft-ohba,  it has DMA, PA and TA of the requirements draft. The
> basic architecture has the DMA on the link which is I think an
> architectural problem and uses only TA. Remember this draft is called Last
> Hop DMHA Protocol. Next, draft-ohba tries to handle host mobility and
> there draft-ohba introduces PA. There is a long list of the states 
> maintained in each entity which takes several pages. There is also a
> description of an 802.11 implementation in the annex.
>   Next draft-koodli, it has PF entity which probably stands for DMA, TA 
> and PA which is in charge of paging and the ARs on subnets with MNs. The
> mobility is handled by the L2 and L3 paging areas but only textual
> description. From p.10 onwards it covers security and from p.15 onwards it > covers mapping to MIPv6, regional registration and TO HMIPv6.
>   However, draft-sarikaya completely integrates paging to MIPv6 and HMIPv6
> (as such it is not the only draft that covers HMIPv6).
>   Draft-guri is completely on the architectural entities of the
> requirements draft. It uses DMA, PA and TA. It defines a model for L2 and
> L3 paging areas. It is a complete IP paging protocol independent of MIP.

To some degree, appendix implementation description and integration with
other protocols may be something to omit first..

>   Can someone tell me how can we integrate these drafts by giving some
> text to Marco? Do you think that I am rigid and non conciliatory Jari?

Almost quoting my M-X doctor: Does it bother you that you think
I think you are rigid and non conciliatory? :) No I do not, really..

> Behcet Sarikaya

BR,

-Jari

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


From seamoby-admin@ietf.org  Wed Jan 23 09:24: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 JAA09795
	for ; Wed, 23 Jan 2002 09:24: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 JAA26648;
	Wed, 23 Jan 2002 09:00: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 JAA26601
	for ; Wed, 23 Jan 2002 09:00:16 -0500 (EST)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08527
	for ; Wed, 23 Jan 2002 09:00:13 -0500 (EST)
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 23 Jan 2002 08:59:59 -0500
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048616696@meshpdc.meshnetworks.com>
From: Phillip Neumiller 
To: "'Govind Krishnamurthi'" , seamoby@ietf.org
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Wed, 23 Jan 2002 08:59:56 -0500
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

Hi Govind,

I will try to fill in some of the blanks below.

> -----Original Message-----
> From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
> Hello James,
> 
> My comments inline
> 
> -Govind.
> 
> >
> >Hi folks,
> >
> >I've just read through the back email on this thread over the past
> >couple weeks
> >in response to Phil and  Govind's original posting, and here
> >are a couple observations and proposals.
> >
> >1) There seems to be broad agreement that we need a 
> requirement saying
> >that
> >the CAR discovery protocol MUST support IPv4 and IPv6.
> >
> >2) There was some difference of opinion on whether the requirements
> >draft
> >should say anything about how this might be done. If nobody has a
> >further
> >objection, can we leave this as an implementation issue?
> >
> 
> [GK] I think it is a strong requirement that we MUST support
> IPv4 and IPv6. I agree, how this is done is a protocol 
> specification issue. 
> I also pointed out to Phil that this requirement is very much
> already there in the given set of requirements and IMO an
> explicit statement is redundant. I did not get a response from Phil
> about this so I don't know whether he agrees with my comment.

pdn>To me it did not seem explicit enough.  If others feel its in
pdn>there than that's OK with me.
 
> >3) There also seems to be a certain degree of agreement that we have
> >an explicit requirement, in addition to Requirement 9, which 
> states that
> >a solution MUST be provided which supports existing mobility 
> protocols.
> >Thus, the protocol must be both independent of mobility protocol
> >and capable of supporting existing mobility protocols. Again, if
> >there is no objection, can we include this as a requirement?
> >
> 
> [GK] Again Phil did not answer Dirk's question regarding what he
> means by the above statement that it MUST support mobility management
> protocols? CAR discovery happens parallel to mobility management. It
> is in the definition of CAR discovery that mobility management
> protocols are going to use CAR discovery for the purpose of handovers.
> What else is needed? Why do we need a separate requirement. 
> Essentially
> we are stating the need for CAR discovery here. Also, by the very fact
> that we say we support inter-technology handovers (which clearly may
> have different mobility management protocols) we imply that 
> any mobility
> management protocol will be able to use the output of CAR discovery.
> Ofcourse, I might be wrong about this and Phil may have something else
> in his mind.
> 
pdn>I think James hit it exactly.  Yes, we don't want to bind the CAR
pdn>protocol to MIP and MANET protocols only, but we also do not want to
pdn>ignore their existence.  There has been too much ignoring going on
pdn>between the respective WGs.  CAR can be a nice bridge and as such
pdn>we must diligently support the best of MIP and MANET protocols.
pdn>I think we can do this without precluding future mobility protocols.
pdn>To get something useful out of CAR early on, it MUST support MIP and
pdn>MANET protocols, and in fact it should be aware of them and facilitate
pdn>candidate discovery for the respective protocols.

Thanks,

Phil
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 

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


From seamoby-admin@ietf.org  Wed Jan 23 11:14: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 LAA14250
	for ; Wed, 23 Jan 2002 11:14: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 LAA02144;
	Wed, 23 Jan 2002 11:02: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 LAA02116
	for ; Wed, 23 Jan 2002 11:02:14 -0500 (EST)
Received: from hotmail.com (f43.law9.hotmail.com [64.4.9.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13762
	for ; Wed, 23 Jan 2002 11:02:11 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 23 Jan 2002 08:01:42 -0800
Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP;
	Wed, 23 Jan 2002 16:01:42 GMT
X-Originating-IP: [63.78.179.4]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Wed, 23 Jan 2002 11:01:42 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 23 Jan 2002 16:01:42.0951 (UTC) FILETIME=[401E9370:01C1A427]
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 Phil,
I'm not able to understand your concern clearly.

>
>Hi Govind,
>
>I will try to fill in some of the blanks below.
>
> > -----Oriinal Message-----
> > From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
> > Hello James,
> >
> > My comments inline
> >
> > -Govind.
> >
> > >
> > >Hi folks,
> > >
> > >I've just read through the back email on this thread over the past
> > >couple weeks
> > >in response to Phil and  Govind's original posting, and here
> > >are a couple observations and proposals.
> > >
> > >1) There seems to be broad agreement that we need a
> > requirement saying
> > >that
> > >the CAR discovery protocol MUST support IPv4 and IPv6.
> > >
> > >2) There was some difference of opinion on whether the requirements
> > >draft
> > >should say anything about how this might be done. If nobody has a
> > >further
> > >objection, can we leave this as an implementation issue?
> > >
> >
> > [GK] I think it is a strong requirement that we MUST support
> > IPv4 and IPv6. I agree, how this is done is a protocol
> > specification issue.
> > I also pointed out to Phil that this requirement is very much
> > already there in the given set of requirements and IMO an
> > explicit statement is redundant. I did not get a response from Phil
> > about this so I don't know whether he agrees with my comment.
>
>pdn>To me it did not seem explicit enough.  If others feel its in
>pdn>there than that's OK with me.

[GK]  ---> OK.
>
> > >3) There also seems to be a certain degree of agreement that we have
> > >an explicit requirement, in addition to Requirement 9, which
> > states that
> > >a solution MUST be provided which supports existing mobility
> > protocols.
> > >Thus, the protocol must be both independent of mobility protocol
> > >and capable of supporting existing mobility protocols. Again, if
> > >there is no objection, can we include this as a requirement?
> > >
> >
> > [GK] Again Phil did not answer Dirk's question regarding what he
> > means by the above statement that it MUST support mobility management
> > protocols? CAR discovery happens parallel to mobility management. It
> > is in the definition of CAR discovery that mobility management
> > protocols are going to use CAR discovery for the purpose of handovers.
> > What else is needed? Why do we need a separate requirement.
> > Essentially
> > we are stating the need for CAR discovery here. Also, by the very fact
> > that we say we support inter-technology handovers (which clearly may
> > have different mobility management protocols) we imply that
> > any mobility
> > management protocol will be able to use the output of CAR discovery.
> > Ofcourse, I might be wrong about this and Phil may have something else
> > in his mind.
> >
>pdn>I think James hit it exactly.  Yes, we don't want to bind the CAR
>pdn>protocol to MIP and MANET protocols only, but we also do not want to
>pdn>ignore their existence.  There has been too much ignoring going on
>pdn>between the respective WGs.  CAR can be a nice bridge and as such
>pdn>we must diligently support the best of MIP and MANET protocols.
>pdn>I think we can do this without precluding future mobility protocols.
>pdn>To get something useful out of CAR early on, it MUST support MIP and
>pdn>MANET protocols, and in fact it should be aware of them and facilitate
>pdn>candidate discovery for the respective protocols.


[GK] ----> First, how CAR discovery is useful in Ad-hoc
networks is quite unclear to me as every communication is line of sight, 
unless you mean that we can exchange capabilities. Or do you mean
an environment wherein a fixed infrastructure as well as a ad-hoc
nodes are there.

Second what do you mean by it should support MIP and MANET? The reason
why CAR discovery is needed is to support the need for MIP (for example) in 
finding the next router for handover. So where does the question come of 
ignoring MIP? The approriate TAR selection algorithm is going to act
on the bunch of ARs selected by CAR along with other parameters and then 
decide an AR for handover.  Infact, the current set of requirements
go much farther and say that the CAR discovery protocol output must
be available (The Inter-technology requirement) to other mobility management 
protocols other than MIP.

I think the main ability it should
have is that of translating different types of L2 identifiers to appropriate 
L3 Identifiers. It must be able
to give its output to the TAR selection algorithm used to select
the TAR. But this is obvious.
If any other need is there for the output of CAR discovery then it is 
implementation specific.



Sorry again if I missed your point :)

Regards,
Govind.







_________________________________________________________________
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  Wed Jan 23 11: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 LAA14433
	for ; Wed, 23 Jan 2002 11: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 KAA01549;
	Wed, 23 Jan 2002 10:59: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 KAA01518
	for ; Wed, 23 Jan 2002 10:59:22 -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 KAA13624
	for ; Wed, 23 Jan 2002 10:59:19 -0500 (EST)
From: Dirk.Trossen@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 g0NFuCQ02589
	for ; Wed, 23 Jan 2002 09:56:12 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Wed, 23 Jan 2002 09:54:35 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 23 Jan 2002 09:54:35 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: FW: [Seamoby] Summary of Discussion on CAR Discovery Requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 23 Jan 2002 10:54:34 -0500
Message-ID: 
Thread-Topic: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Thread-Index: AcGkFmO3cVg//decSJad4YI5hjYu/wADIdRAAADQBeA=
To: 
X-OriginalArrivalTime: 23 Jan 2002 15:54:35.0097 (UTC) FILETIME=[41193C90:01C1A426]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA01519
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,

sorry, forgot to press 'Reply to All' for the below answer to
Phil's email.

Thanks,


Dirk

-----Original Message-----
From: Trossen Dirk (NRC/Boston) 
Sent: Wednesday, January 23, 2002 10:51 AM
To: 'ext Phillip Neumiller'
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery
Requirements


Hi Phil,

comment inline. 

 
> pdn>I think James hit it exactly.  Yes, we don't want to bind the CAR
> pdn>protocol to MIP and MANET protocols only, but we also do 
> not want to
> pdn>ignore their existence.  There has been too much ignoring going on
> pdn>between the respective WGs.  CAR can be a nice bridge and as such
> pdn>we must diligently support the best of MIP and MANET protocols.
> pdn>I think we can do this without precluding future mobility 
> protocols.
> pdn>To get something useful out of CAR early on, it MUST 
> support MIP and
> pdn>MANET protocols, and in fact it should be aware of them 
> and facilitate
> pdn>candidate discovery for the respective protocols.

Again, I'd like to point out that it is not clear to me what 
'MUST support MIP and MANET' means. 

Firstly, MUST is a very strong statement. Is a solution that discovers
CARs in MIP, MANET, and any other mobility environment bad (or even
out of scope due to the MUST) if it doesn't take the mobility management
protocol into account but fulfils the task, namely discovering the CARs??

Secondly, what does 'support' means? We had this discussion before and
for me you haven't made clear what you exactly mean by that. The 
independence of mobility management (MM) is a very strong argument.
It means that it has to work with any MM protocol, which from my point of
view means that it must support MIP and MANET (and, BTW, other MM protocols).
However, how you achieve this is totally in the solution space. It can 
be a protocol comprised of modules for all sorts of MM protocols. It is 
therefore independent (at least for the existing ones). But if you propose 
a solution that does not take specific MIP/MANET/etc features into account, the
requirement is fulfilled, too, and I don't see any disadvantage in this.

Again, it comes to the differentiation, I asked to clarify, namely the
difference between being compatible to MM protocols or to accomodate
MM features. The first one is addressed by the independence requirement
from my point of view. Making the second one mandatory or even a SHOULD 
only doesn't make sense as a requirement (see question above regarding a
solution that doesn't accomodate MM features). Although nobody prevents 
you from proposing a solution that does accomodate MM features as long 
as you don't restrict your solution to specific, e.g., MIP, environments 
only.

In conclusion, we should first clearly define what 'support' really
means. The terms above, i.e., 'being compatible' and 'accomodate',
might help for this. If we agree on this, we have to discuss if
we really want this (at this point hopefully more clear) requirement or
if it even necessary.

Regards,


Dirk

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


From seamoby-admin@ietf.org  Wed Jan 23 11:38: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 LAA15484
	for ; Wed, 23 Jan 2002 11:38: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 LAA02851;
	Wed, 23 Jan 2002 11: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 LAA02816
	for ; Wed, 23 Jan 2002 11:22:47 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14759
	for ; Wed, 23 Jan 2002 11:22:43 -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 g0NGMiw10127
	for ; Wed, 23 Jan 2002 17:22:44 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Jan 23 17:22:44 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 23 Jan 2002 17:22:27 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A937@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'James Kempf'" ,
        "'seamoby@ietf.org'"
	 
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Wed, 23 Jan 2002 17:22:19 +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

Hi James, 


  > 4) There was some difference of opinion about whether support
  > for interdomain discovery SHOULD or MUST be required.
  > Since some good arguments were made for supporting
  > interdomain discovery, I'd like to suggest we keep this
  > in for now as a SHOULD unless there are any further objections
  > to be discussed.
  > 
  > 5) Some working group members suggested that the requirements
  > for MN-based v.s. AR-based discovery be separated. The
  > draft editors would like to see examples of requirements that
  > need to be separated. Does anyone have some examples?
  > If not, can we just go forward with a single set of requirements
  > for now?
  > 

=> So here's a scenario: in point 4) above, if we
consider the MN-AR interface then I can't see why 
it wouldn't be a MUST. However, for the AR- AR 
protocol, I can see some scalability and other
business issues that may force us to avoid 
mandating this requirement. 

Hesham


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


From seamoby-admin@ietf.org  Wed Jan 23 11:59: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 LAA16279
	for ; Wed, 23 Jan 2002 11:59: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 LAA04045;
	Wed, 23 Jan 2002 11:46: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 LAA04016
	for ; Wed, 23 Jan 2002 11:46: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 LAA15856
	for ; Wed, 23 Jan 2002 11:46:30 -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 g0NGm9Q12662
	for ; Wed, 23 Jan 2002 10:48:09 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 23 Jan 2002 10:46:31 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 23 Jan 2002 10:46:31 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 23 Jan 2002 11:46:30 -0500
Message-ID: 
Thread-Topic: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Thread-Index: AcGkKjypjs4fHpE+Sh+6EC2jK3hwQQAAEPdw
To: , ,
        
X-OriginalArrivalTime: 23 Jan 2002 16:46:31.0450 (UTC) FILETIME=[8296F7A0:01C1A42D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA04017
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 Hesham,

> => So here's a scenario: in point 4) above, if we
> consider the MN-AR interface then I can't see why 
> it wouldn't be a MUST. However, for the AR- AR 
> protocol, I can see some scalability and other
> business issues that may force us to avoid 
> mandating this requirement. 
> 

The requirement states that ARs SHOULD or MUST be discovered 
irrespectively of the domain to which they belong. This is a 
generic requirement which reflects one very fundamental nature 
of seamless mobility, namely seamlessly roaming between ARs 
irrespectively of the domain to which they belong. 
Apparently you want the focus of seamlessness more on time
(reducing the connectivity disruption) rather than on networks 
(roaming seamlessly between networks). 

Furthermore, I have a problem what exactly you mean with 'MN-AR'
and 'AR-AR' interfaces. But let me interpret how I understood these
terms. Do you mean by 'MN-AR interface' an MN-based discovery scheme, 
hence 'AR-AR interface' is an AR-based scheme for discovery? 

If so, do you propose that if the MN is doing (mainly) the job, 
it MUST discover ARs irrespectively of the domain, while in the 
(mainly) AR-based scheme it should only (if at all), i.e., it doesn't
have to? Does this make sense? With that, you fix the solution space
in a sense that seems inappropriate to me. This will open doors
for fights to which 'category' the solution belongs. What about
schemes that divide the tasks between AR and MN? MUST or SHOULD
they fulfill the requirement? What about a scheme that uses MN
for discovery but AR for capability exchange? Do you really 
propose (which is the natural extension of demanding two 
categories of requirements) that we first define categories
for our solution space and then assign requirements (and their
strengths) to them?

If we want to enable seamlessness in the sense I described
above, namely between networks, reflected by the inter-domain
requirement, the requirement is a MUST. Probably, we should
think about the possibility that a solution that does not fulfill 
this requirement is one that shouldn't be considered.

BTW, I see your scalability point. But again, if a solution that
tries to fulfill the inter-domain requirement doesn't scale, it
is probably simply not a good solution? 

Do you really want to have a requirements document that says 
'we want CAR discovery in inter-domain case, but if you have 
an AR-based solution you don't really have to do the job'???

I don't see your business reason. If you are talking about hiding
ARs to ARs of other domains, you can do this by a) private address
space and b) not revealing your capabilities during the exchange.

In conclusion, as a first step, it is necessary that you define
your terms 'MN-AR interface' and 'AR-AR interface' so that we
know what we are talking about in the context of separating
requirements.

Regards,



Dirk

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


From seamoby-admin@ietf.org  Wed Jan 23 12:01: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 MAA16377
	for ; Wed, 23 Jan 2002 12:01: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 LAA04217;
	Wed, 23 Jan 2002 11:49: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 LAA04180
	for ; Wed, 23 Jan 2002 11:49:43 -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 LAA15959
	for ; Wed, 23 Jan 2002 11:49:40 -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 g0NGmZj00174;
	Wed, 23 Jan 2002 17:48:35 +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 RAA30204;
	Wed, 23 Jan 2002 17:48:02 +0100
Message-ID: <3C4EE941.471AB594@ccrle.nec.de>
Date: Wed, 23 Jan 2002 17:48:01 +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: "Jari T. Malinen" 
CC: Behcet Sarikaya , seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <8C92E23A3E87FB479988285F9E22BE465AB9C5@ftmail> <3C4DE01F.7396E55C@iprg.nokia.com> <3C4DF9C8.4090609@alcatel.com> <3C4E24C8.771CC63A@iprg.nokia.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

Jari,

thanks for your constructive comments. The way you propose on
how to proceed leads into a right direction, which is first to clarify
how to map the functional elements to the architecture.
That's why I sent an e-mail to the list, referring to the architecture
as it is described in draft-renker and taking it over to the very first
cut of the WG draft. As already said, optimization parts as well
as specifics on paging policies are a candidate to not be part of the
generic architecture and protocol description. Coming up with a
framework and a first cut of a WG draft would require to extract specific
information and to form the generic parts into a clear order for the framework.
That's what I can do. For the architecture, the WG should express an opinion,
but maybe we should address this better in a separate thread again.

Regards,

Marco


"Jari T. Malinen" wrote:

> Behcet,
>
> If we are in a hurry, the complexity will be mind-boggling.
> A construction may be a possibility, maybe I'm optimistic,
> using the material as a set of design elements (build a framework
> based on components in the proposals)..
>
> >   Now, draft-renker starts with a very simple architecture: of
> > PA -- AR -- MN
> > using only PA entity of the requirements document. The rest of
> > draft-renker after page 11  is on Mobile IPv6 mapping. Draft-sarikaya is
> > also based on Mobile IPv6 and so these two drafts should have been treated
> > in a similar way. What do you say Srinivas? i.e most possibly refuse both.
>
> A first observation is that there is an architecture each
> proposal presents. Some try to follow that outlined in the RFC, some
> go with a simpler model. The first question is: do we go with the
> good preliminary work of James et al in choosing the architecture or
> can we agree on a simpler model which was a hint given by wg chairs'
> recommendation etc. Maybe that's a first decision to do. Also,
> having some sense of understanding of requirement priority could
> help. Chairs have stated their preference, maybe these should be
> checked in the discussion..
>
> Whenever a choice is made, that material in most drafts can be skipped.
> By construction maybe a simpler / shorter text could be possible.
> Even though not bad, genericity in draft-renker was problematic
> to me, a design should rather economically communicate an unambiguous
> design without going to surveys etc. By construction that might be
> more likely than patching a large framework, perhaps.
>
> Sure it is not going to be easy, probably impossible. That is not
> sure yet, though. Maybe Marco could try to build towards a more
> short/readable a framework this way, reflecting issues discussed,
> I don't know?
>
> >   Next draft-ohba,  it has DMA, PA and TA of the requirements draft. The
> > basic architecture has the DMA on the link which is I think an
> > architectural problem and uses only TA. Remember this draft is called Last
> > Hop DMHA Protocol. Next, draft-ohba tries to handle host mobility and
> > there draft-ohba introduces PA. There is a long list of the states
> > maintained in each entity which takes several pages. There is also a
> > description of an 802.11 implementation in the annex.
> >   Next draft-koodli, it has PF entity which probably stands for DMA, TA
> > and PA which is in charge of paging and the ARs on subnets with MNs. The
> > mobility is handled by the L2 and L3 paging areas but only textual
> > description. From p.10 onwards it covers security and from p.15 onwards it > covers mapping to MIPv6, regional registration and TO HMIPv6.
> >   However, draft-sarikaya completely integrates paging to MIPv6 and HMIPv6
> > (as such it is not the only draft that covers HMIPv6).
> >   Draft-guri is completely on the architectural entities of the
> > requirements draft. It uses DMA, PA and TA. It defines a model for L2 and
> > L3 paging areas. It is a complete IP paging protocol independent of MIP.
>
> To some degree, appendix implementation description and integration with
> other protocols may be something to omit first..
>
> >   Can someone tell me how can we integrate these drafts by giving some
> > text to Marco? Do you think that I am rigid and non conciliatory Jari?
>
> Almost quoting my M-X doctor: Does it bother you that you think
> I think you are rigid and non conciliatory? :) No I do not, really..
>
> > Behcet Sarikaya
>
> BR,
>
> -Jari
>
> _______________________________________________
> 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 Jan 23 12:25: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 MAA17242
	for ; Wed, 23 Jan 2002 12:25: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 MAA05987;
	Wed, 23 Jan 2002 12: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 MAA05955
	for ; Wed, 23 Jan 2002 12:09:42 -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 MAA16642
	for ; Wed, 23 Jan 2002 12:09:37 -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 g0NH9gj00335
	for ; Wed, 23 Jan 2002 18:09:42 +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 SAA30492
	for ; Wed, 23 Jan 2002 18:09:08 +0100
Message-ID: <3C4EEE34.7ABC8427@ccrle.nec.de>
Date: Wed, 23 Jan 2002 18:09: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: Seamoby 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] Paging issue#0: clarification on architecture
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,

as it has been addressed on the list again, we should clarify if each
functional entity described in RFC 3154 needs to be mapped to an
individual architecture element, or if we can go for a more composite
architecture, as it is described in draft-renker-paging-ipv6-01.txt as
well as in draft-koodli-paging-01.txt.
Any comments are welcome.

Marco



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


From seamoby-admin@ietf.org  Wed Jan 23 12:34: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 MAA17598
	for ; Wed, 23 Jan 2002 12:34: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 MAA06423;
	Wed, 23 Jan 2002 12:22: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 MAA06394
	for ; Wed, 23 Jan 2002 12:22:55 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17170
	for ; Wed, 23 Jan 2002 12:22:49 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g0NHMoIB029143
	for ; Wed, 23 Jan 2002 18:22:51 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Jan 23 18:22:50 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 23 Jan 2002 18:22:33 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A93A@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'Dirk.Trossen@nokia.com'" ,
        kempf@docomolabs-usa.com, seamoby@ietf.org
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Wed, 23 Jan 2002 18:22:25 +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

Dirk,

  > The requirement states that ARs SHOULD or MUST be discovered 
  > irrespectively of the domain to which they belong. This is a 
  > generic requirement which reflects one very fundamental nature 
  > of seamless mobility, namely seamlessly roaming between ARs 
  > irrespectively of the domain to which they belong. 
  > Apparently you want the focus of seamlessness more on time
  > (reducing the connectivity disruption) rather than on networks 
  > (roaming seamlessly between networks). 

=> Did I say that ? I don't think so, I simply 
said that a MN listening to ARs directly
(possibly multi-homes) would relatively easily
discover GAARs outside its current domain. 
On the other hand, for ARs to discover GAARs
outside their domain, several security issues and 
'agreements' between operators are needed. So 
It does seem more difficult for the AR - AR protocol
to work across domains. 
To conclude: If AR discovers GAARs then inter-domain
is more difficult.
If MN discovers GAARs then inter-domain discovery is 
not so difficult.

  > 
  > Furthermore, I have a problem what exactly you mean with 'MN-AR'
  > and 'AR-AR' interfaces. But let me interpret how I understood these
  > terms. Do you mean by 'MN-AR interface' an MN-based 
  > discovery scheme, 
  > hence 'AR-AR interface' is an AR-based scheme for discovery? 

=> Yes. I realise that AR-AR can also be relayed
to the MN (in some cases). 

  > 
  > If so, do you propose that if the MN is doing (mainly) the job, 
  > it MUST discover ARs irrespectively of the domain, while in the 
  > (mainly) AR-based scheme it should only (if at all), i.e., 
  > it doesn't
  > have to? 

=> It doesn't need to be a MUST. 

Does this make sense? 

=> Why don't we let the WG decide that.


With that, you fix the solution space
  > in a sense that seems inappropriate to me. 

=> Huh ? can you elaborate. I'm not fixing 
anything, I said one is simpler than the other.

This will open doors
  > for fights to which 'category' the solution belongs. What about
  > schemes that divide the tasks between AR and MN? MUST or SHOULD
  > they fulfill the requirement? What about a scheme that uses MN
  > for discovery but AR for capability exchange? 

=> I'm only interested in technical reasons. 

Do you really 
  > propose (which is the natural extension of demanding two 
  > categories of requirements) that we first define categories
  > for our solution space and then assign requirements (and their
  > strengths) to them?
  > 
  > If we want to enable seamlessness in the sense I described
  > above, namely between networks, reflected by the inter-domain
  > requirement, the requirement is a MUST. Probably, we should
  > think about the possibility that a solution that does not fulfill 
  > this requirement is one that shouldn't be considered.


=> I really think you're reading way too much
into my emails.

  > 
  > BTW, I see your scalability point. But again, if a solution that
  > tries to fulfill the inter-domain requirement doesn't scale, it
  > is probably simply not a good solution? 

=> Well there may not be a 'good' solution for this.
People make design choices and tradeoffs, what do you 
mean by 'good' ?


  > In conclusion, as a first step, it is necessary that you define
  > your terms 'MN-AR interface' and 'AR-AR interface' so that we

=> If communication between AR and GAARs exists e2e
then there is some AR - AR protocol. 

MN - AR : AR sends information to MN about itself 
and (possibly) GAARs. 

I hope this is clearer.

Hesham



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


From seamoby-admin@ietf.org  Wed Jan 23 12:40: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 MAA17832
	for ; Wed, 23 Jan 2002 12:40: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 MAA06677;
	Wed, 23 Jan 2002 12:29: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 MAA06648
	for ; Wed, 23 Jan 2002 12:29:08 -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 MAA17371
	for ; Wed, 23 Jan 2002 12:29:04 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0NHSae08069;
	Wed, 23 Jan 2002 09:28:36 -0800 (PST)
Message-ID: <002801c1a433$2a29bbb0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Govind Krishnamurthi" , 
References: 
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Wed, 23 Jan 2002 09:27: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

Govind,

> >3) There also seems to be a certain degree of agreement that we have
> >an explicit requirement, in addition to Requirement 9, which states
that
> >a solution MUST be provided which supports existing mobility
protocols.
> >Thus, the protocol must be both independent of mobility protocol
> >and capable of supporting existing mobility protocols. Again, if
> >there is no objection, can we include this as a requirement?
> >
>
> [GK] Again Phil did not answer Dirk's question regarding what he
> means by the above statement that it MUST support mobility management
> protocols? CAR discovery happens parallel to mobility management. It
> is in the definition of CAR discovery that mobility management
> protocols are going to use CAR discovery for the purpose of handovers.
> What else is needed? Why do we need a separate requirement.
Essentially
> we are stating the need for CAR discovery here. Also, by the very fact
> that we say we support inter-technology handovers (which clearly may
> have different mobility management protocols) we imply that any
mobility
> management protocol will be able to use the output of CAR discovery.
> Ofcourse, I might be wrong about this and Phil may have something else
> in his mind.
>

The point about the need to support existing mobility protocols
was not only made by Phil, it was made by Hesham and others.
So I think there is a group of people that would like to see this
as a requirement. It also seems almost a given to me, why
would the WG want to come up with a protocol that
doesn't support existing mobility protocols, so I'm
having a hard time seeing why you're resisting putting
it in.

As to what it might mean, suppose that the requirement wasn't
there and someone proposed a protocol that supported
a routing update approach to mobility, such as HAWAII
or Cellular IP, but it did not work for Mobile IP. As a practical
matter, the WG and IESG would be unlikely to accept such
an approach, but having it in the requirements makes a statement
up front that the protocol must work with Mobile IP and MANET.

Also, as came up in the WG meeting in SLC, some work has
been proposed in the MANET group solving a similar problem to
CAR discovery, and Scott agreed to vector those people to
Seamoby. So we need to make sure the requirements
state that the protocol will be usable by MANET clients.

Perhaps the wording of the requirment could be changed?
How about:

    The CAR discovery protocol MUST be usable by Internet
    hosts and nodes that support existing IP mobility protocols,
    such as Mobile IP and MANET.

>
> >4) There was some difference of opinion about whether support
> >for interdomain discovery SHOULD or MUST be required.
> >Since some good arguments were made for supporting
> >interdomain discovery, I'd like to suggest we keep this
> >in for now as a SHOULD unless there are any further objections
> >to be discussed.
> >
>
> [GK] Again with this I thought the majority decision was to go with
> a MUST.
>

I saw one objection to even having the requirement, most other
people seemed OK with it.

Any further objection to MUST? Otherwise, I think we
should go with it.

> >5) Some working group members suggested that the requirements
> >for MN-based v.s. AR-based discovery be separated. The
> >draft editors would like to see examples of requirements that
> >need to be separated. Does anyone have some examples?
> >If not, can we just go forward with a single set of requirements
> >for now?
>
> [GK] I am almost ready with the first version of the requirements
> draft. Please point out any differences that you perceive just because
> CAR discovery is MN based or AR based. Also, I feel that this point
> came up because we hadn't made it clear in the Issues draft that the
> differentiation was based on time of CAR discovery rather than who
initiates
> the process. But again I might be wrong about this and I welcome
anyone's
> input on this.
>

If there are no specific examples of how these two areas should be
separated, then I think we can go forward with one set of
requirements.

            jak


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


From seamoby-admin@ietf.org  Wed Jan 23 12:47: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 MAA18042
	for ; Wed, 23 Jan 2002 12:47: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 MAA07215;
	Wed, 23 Jan 2002 12:32: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 MAA07192
	for ; Wed, 23 Jan 2002 12:32:47 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17540
	for ; Wed, 23 Jan 2002 12:32:43 -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 g0NHWiw10891
	for ; Wed, 23 Jan 2002 18:32:44 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Jan 23 18:32:44 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 23 Jan 2002 18:23:37 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A93E@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "'James Kempf'" ,
        Govind Krishnamurthi
	 , seamoby@ietf.org
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Wed, 23 Jan 2002 18:32:17 +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


  > The point about the need to support existing mobility protocols
  > was not only made by Phil, it was made by Hesham and others.
  > So I think there is a group of people that would like to see this
  > as a requirement. It also seems almost a given to me, why
  > would the WG want to come up with a protocol that
  > doesn't support existing mobility protocols, so I'm
  > having a hard time seeing why you're resisting putting
  > it in.

=> Fully agree. 

Hesham

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


From seamoby-admin@ietf.org  Wed Jan 23 12:58: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 MAA18489
	for ; Wed, 23 Jan 2002 12:58: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 MAA07472;
	Wed, 23 Jan 2002 12:41: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 MAA07444
	for ; Wed, 23 Jan 2002 12:41: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 MAA17860
	for ; Wed, 23 Jan 2002 12:41:34 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0NHese08573;
	Wed, 23 Jan 2002 09:40:54 -0800 (PST)
Message-ID: <003001c1a434$e22d7890$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Jari T. Malinen" ,
        "Behcet Sarikaya" 
Cc: 
References: <8C92E23A3E87FB479988285F9E22BE465AB9C5@ftmail> <3C4DE01F.7396E55C@iprg.nokia.com> <3C4DF9C8.4090609@alcatel.com> <3C4E24C8.771CC63A@iprg.nokia.com>
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
Date: Wed, 23 Jan 2002 09:39: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
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

Jari,

> If we are in a hurry, the complexity will be mind-boggling.
> A construction may be a possibility, maybe I'm optimistic,
> using the material as a set of design elements (build a framework
> based on components in the proposals)..
> 

Actually, I don't think we are in a hurry. As the response to
the survey I sent out indicated, nobody is doing product
in this area in the near future, so we have some time to
get this right. 

Counting pages and figuring out how to do a merge on
the existing specs isn't the right way to go, IMHO. 
We want 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. 

I still believe that draft-renker is a good starting
point for the design. It is easier to find the faults
in something that exists and fix them than try
to start from scratch. But if the working group isn't 
happy with using draft-renker as the base, then Allison, 
Pat and I need to figure out a way to go forward that 
will result in a good technical solution. We have some ideas, 
but the question in my mind right now is: is the WG
interested in getting the right technical solution?

            jak


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


From seamoby-admin@ietf.org  Wed Jan 23 13:13: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 NAA19045
	for ; Wed, 23 Jan 2002 13:13: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 MAA07820;
	Wed, 23 Jan 2002 12:52: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 MAA07789
	for ; Wed, 23 Jan 2002 12:52:00 -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 MAA18251
	for ; Wed, 23 Jan 2002 12:51:59 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0NHpNe09035;
	Wed, 23 Jan 2002 09:51:23 -0800 (PST)
Message-ID: <008401c1a436$597084a0$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Govind Krishnamurthi" , 
References: 
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Wed, 23 Jan 2002 09:49: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

Govind,

> [GK] ----> First, how CAR discovery is useful in Ad-hoc
> networks is quite unclear to me as every communication is line of
sight,
> unless you mean that we can exchange capabilities. Or do you mean
> an environment wherein a fixed infrastructure as well as a ad-hoc
> nodes are there.
>

I believe the issue here was discovering an access router that
would let the MANET route back into the fixed network.

            jak


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


From seamoby-admin@ietf.org  Wed Jan 23 13:23: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 NAA19352
	for ; Wed, 23 Jan 2002 13:23: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 NAA08976;
	Wed, 23 Jan 2002 13:07: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 NAA08951
	for ; Wed, 23 Jan 2002 13:07: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 NAA18836
	for ; Wed, 23 Jan 2002 13:07:40 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0NI7Ae09703
	for ; Wed, 23 Jan 2002 10:07:10 -0800 (PST)
Message-ID: <00e501c1a438$8dccfd30$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: 
Date: Wed, 23 Jan 2002 10:05:34 -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] CT Protocol Selection Postponed
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, JohnL, and I have been discussing what to do about 
the CT protocol selection. As announced in SLC, deadline 
for proposals had been set for Feb. 1; however, the CT requirements
have not yet passed IESG review. Since we
might see some changes after IESG review, we have
decided to postpone the CT protocol selection process
until we have a set of approved requirements.

In addition, given the amount of controversy around
the paging protocol selection, we have decided that
it would be better to have a complete description
of how the selection will be done, including 
contingency planning should the assessment fail
to come up with a selection, before the assessment
process starts. That way, nobody can claim that
the rules of the game were changed in the middle. 

JohnL will prepare a description of how the
protocol selection will proceed and present
it at the Minneapolis meeting. If this presents
difficulties for anyone, please send private email to
Pat or me.

            jak


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


From seamoby-admin@ietf.org  Wed Jan 23 13:25: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 NAA19409
	for ; Wed, 23 Jan 2002 13:25: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 MAA08137;
	Wed, 23 Jan 2002 12:57: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 MAA08110
	for ; Wed, 23 Jan 2002 12:57:39 -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 MAA18478
	for ; Wed, 23 Jan 2002 12:57:38 -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 LAA22831
	for ; Wed, 23 Jan 2002 11:57:08 -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 g0NHv7s06320
	for ; Wed, 23 Jan 2002 11:57:07 -0600 (CST)
Message-ID: <3C4EF965.6040604@alcatel.com>
Date: Wed, 23 Jan 2002 11:56: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] Concensus Call:Reaching Closure on Paging Decision
References: <8C92E23A3E87FB479988285F9E22BE465AB9C5@ftmail> <3C4DE01F.7396E55C@iprg.nokia.com> <3C4DF9C8.4090609@alcatel.com> <3C4E24C8.771CC63A@iprg.nokia.com> <003001c1a434$e22d7890$7e6015ac@T23KEMPF>
Content-Type: multipart/alternative;
 boundary="------------020008010405090607060706"
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


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

Dear All,
  Let me say that, probably to everybody's surprise, I completely concur 
with James's view. There is no rush and IP paging will be an important 
component in future wireless networks.
So let's not go for a cheap solution.

  Regards,

James Kempf wrote:

>Jari,
>
>>If we are in a hurry, the complexity will be mind-boggling.
>>A construction may be a possibility, maybe I'm optimistic,
>>using the material as a set of design elements (build a framework
>>based on components in the proposals)..
>>
>
>Actually, I don't think we are in a hurry. As the response to
>the survey I sent out indicated, nobody is doing product
>in this area in the near future, so we have some time to
>get this right. 
>
>Counting pages and figuring out how to do a merge on
>the existing specs isn't the right way to go, IMHO. 
>We want 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. 
>
>I still believe that draft-renker is a good starting
>point for the design. It is easier to find the faults
>in something that exists and fix them than try
>to start from scratch. But if the working group isn't 
>happy with using draft-renker as the base, then Allison, 
>Pat and I need to figure out a way to go forward that 
>will result in a good technical solution. We have some ideas, 
>but the question in my mind right now is: is the WG
>interested in getting the right technical solution?
>
>            jak
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>

-- 
Behcet 



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





Dear All,

  Let me say that, probably to everybody's surprise, I completely concur
with James's view. There is no rush and IP paging will be an important component
in future wireless networks.

So let's not go for a cheap solution.



  Regards,



James Kempf wrote:



  
Jari,


  

    
If we are in a hurry, the complexity will be mind-boggling.
A construction may be a possibility, maybe I'm optimistic,
using the material as a set of design elements (build a framework
based on components in the proposals)..


    

    

Actually, I don't think we are in a hurry. As the response to
the survey I sent out indicated, nobody is doing product
in this area in the near future, so we have some time to
get this right. 

Counting pages and figuring out how to do a merge on
the existing specs isn't the right way to go, IMHO. 
We want 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. 

I still believe that draft-renker is a good starting
point for the design. It is easier to find the faults
in something that exists and fix them than try
to start from scratch. But if the working group isn't 
happy with using draft-renker as the base, then Allison, 
Pat and I need to figure out a way to go forward that 
will result in a good technical solution. We h
ave some ideas, 
but the question in my mind right now is: is the WG
interested in getting the right technical solution?

            jak


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

    

    

    
-- 
Behcet 

    

    
    

--------------020008010405090607060706--


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


From seamoby-admin@ietf.org  Wed Jan 23 13:31: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 NAA19609
	for ; Wed, 23 Jan 2002 13:31: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 NAA09325;
	Wed, 23 Jan 2002 13:12: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 NAA09296
	for ; Wed, 23 Jan 2002 13:12: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 NAA19015
	for ; Wed, 23 Jan 2002 13:12:20 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0NIBke09906;
	Wed, 23 Jan 2002 10:11:46 -0800 (PST)
Message-ID: <00e901c1a439$3214ce40$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Hesham Soliman \(ERA\)" ,
        , 
References: <4DA6EA82906FD511BE2F00508BCF053802C6A93A@Esealnt861.al.sw.ericsson.se>
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Wed, 23 Jan 2002 10:10:10 -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/Hesham,

So it sounds like there is a case for interdomain discovery, but it
might be mitigated by certain difficulties. Business considerations
shouldn't really be an issue here, but scalability certainly should,
and I can see an argument about technical difficulty integrating
the CAR discovery with interdomain routing, in both the MN
and AR cases.

There was really not much technical discussion on this issue
at SLC. Since then, there has been more, and the
outlines of possible problems are beginning to emerge.
I think we really need to do a deeper study to determine
whether or not this is technically doable.

How about if we keep the requirement a SHOULD? I
believe that is how Govind originally listed it.

            jak

----- Original Message -----
From: "Hesham Soliman (ERA)" 
To: ; ;

Sent: Wednesday, January 23, 2002 9:22 AM
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery
Requirements


> Dirk,
>
>   > The requirement states that ARs SHOULD or MUST be discovered
>   > irrespectively of the domain to which they belong. This is a
>   > generic requirement which reflects one very fundamental nature
>   > of seamless mobility, namely seamlessly roaming between ARs
>   > irrespectively of the domain to which they belong.
>   > Apparently you want the focus of seamlessness more on time
>   > (reducing the connectivity disruption) rather than on networks
>   > (roaming seamlessly between networks).
>
> => Did I say that ? I don't think so, I simply
> said that a MN listening to ARs directly
> (possibly multi-homes) would relatively easily
> discover GAARs outside its current domain.
> On the other hand, for ARs to discover GAARs
> outside their domain, several security issues and
> 'agreements' between operators are needed. So
> It does seem more difficult for the AR - AR protocol
> to work across domains.
> To conclude: If AR discovers GAARs then inter-domain
> is more difficult.
> If MN discovers GAARs then inter-domain discovery is
> not so difficult.
>
>   >
>   > Furthermore, I have a problem what exactly you mean with 'MN-AR'
>   > and 'AR-AR' interfaces. But let me interpret how I understood
these
>   > terms. Do you mean by 'MN-AR interface' an MN-based
>   > discovery scheme,
>   > hence 'AR-AR interface' is an AR-based scheme for discovery?
>
> => Yes. I realise that AR-AR can also be relayed
> to the MN (in some cases).
>
>   >
>   > If so, do you propose that if the MN is doing (mainly) the job,
>   > it MUST discover ARs irrespectively of the domain, while in the
>   > (mainly) AR-based scheme it should only (if at all), i.e.,
>   > it doesn't
>   > have to?
>
> => It doesn't need to be a MUST.
>
> Does this make sense?
>
> => Why don't we let the WG decide that.
>
>
> With that, you fix the solution space
>   > in a sense that seems inappropriate to me.
>
> => Huh ? can you elaborate. I'm not fixing
> anything, I said one is simpler than the other.
>
> This will open doors
>   > for fights to which 'category' the solution belongs. What about
>   > schemes that divide the tasks between AR and MN? MUST or SHOULD
>   > they fulfill the requirement? What about a scheme that uses MN
>   > for discovery but AR for capability exchange?
>
> => I'm only interested in technical reasons.
>
> Do you really
>   > propose (which is the natural extension of demanding two
>   > categories of requirements) that we first define categories
>   > for our solution space and then assign requirements (and their
>   > strengths) to them?
>   >
>   > If we want to enable seamlessness in the sense I described
>   > above, namely between networks, reflected by the inter-domain
>   > requirement, the requirement is a MUST. Probably, we should
>   > think about the possibility that a solution that does not fulfill
>   > this requirement is one that shouldn't be considered.
>
>
> => I really think you're reading way too much
> into my emails.
>
>   >
>   > BTW, I see your scalability point. But again, if a solution that
>   > tries to fulfill the inter-domain requirement doesn't scale, it
>   > is probably simply not a good solution?
>
> => Well there may not be a 'good' solution for this.
> People make design choices and tradeoffs, what do you
> mean by 'good' ?
>
>
>   > In conclusion, as a first step, it is necessary that you define
>   > your terms 'MN-AR interface' and 'AR-AR interface' so that we
>
> => If communication between AR and GAARs exists e2e
> then there is some AR - AR protocol.
>
> MN - AR : AR sends information to MN about itself
> and (possibly) GAARs.
>
> I hope this is clearer.
>
> Hesham
>
>
>


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


From seamoby-admin@ietf.org  Wed Jan 23 13:41:21 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 NAA19956
	for ; Wed, 23 Jan 2002 13:41:21 -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 NAA09983;
	Wed, 23 Jan 2002 13:29: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 NAA09952
	for ; Wed, 23 Jan 2002 13:29:45 -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 NAA19481
	for ; Wed, 23 Jan 2002 13:29:43 -0500 (EST)
From: Dirk.Trossen@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 g0NIVKQ00615
	for ; Wed, 23 Jan 2002 12:31:20 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 23 Jan 2002 12:29:43 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 23 Jan 2002 12:29:42 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 23 Jan 2002 13:29:41 -0500
Message-ID: 
Thread-Topic: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Thread-Index: AcGkOYFbkRcjLtyvTQukZzVzgKOm7AAAYuMw
To: , ,
        
X-OriginalArrivalTime: 23 Jan 2002 18:29:42.0780 (UTC) FILETIME=[ECE8F3C0:01C1A43B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA09953
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,

> So it sounds like there is a case for interdomain discovery, but it
> might be mitigated by certain difficulties. Business considerations
> shouldn't really be an issue here, but scalability certainly should,
> and I can see an argument about technical difficulty integrating
> the CAR discovery with interdomain routing, in both the MN
> and AR cases.
> 
> There was really not much technical discussion on this issue
> at SLC. Since then, there has been more, and the
> outlines of possible problems are beginning to emerge.
> I think we really need to do a deeper study to determine
> whether or not this is technically doable.
> 
> How about if we keep the requirement a SHOULD? I
> believe that is how Govind originally listed it.

I'm fine with keeping it a SHOULD since this has been the original
proposal anyway. The solutions will show if it is indeed technically
doable. A SHOULD would reflect the desire that CAR discovery aims at
discovering GAARs irrespectively of their domains, if possible. 

But the discussion started actually by asking for separation of the 
requirements, and this particular item was given as an example. And 
I simply don't agree that we define different ones (a MUST and a SHOULD 
version) for different solution spaces. Either we want to make the above
desire mandatory for ALL solutions or not, but only for a subset
does not sound well.

Regards,



Dirk

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


From seamoby-admin@ietf.org  Wed Jan 23 13:54: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 NAA20516
	for ; Wed, 23 Jan 2002 13:54: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 NAA10861;
	Wed, 23 Jan 2002 13:42: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 NAA10829
	for ; Wed, 23 Jan 2002 13:42:16 -0500 (EST)
Received: from hotmail.com (f253.law9.hotmail.com [64.4.8.128])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20031
	for ; Wed, 23 Jan 2002 13:42:13 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 23 Jan 2002 10:41:44 -0800
Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP;
	Wed, 23 Jan 2002 18:41:44 GMT
X-Originating-IP: [63.78.179.5]
From: "Govind Krishnamurthi" 
To: kempf@docomolabs-usa.com, hesham.soliman@era.ericsson.se,
        Dirk.Trossen@nokia.com, seamoby@ietf.org
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Wed, 23 Jan 2002 13:41:44 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 23 Jan 2002 18:41:44.0290 (UTC) FILETIME=[9AF6A420:01C1A43D]
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


James,
I don't mind this requirement being a SHOULD for now.
But there were a large number
of people who were of the opinion (including one of our ADs :)) that
this requirement should be changed to a MUST. So maybe they can speakup now 
and let us know why they felt so strongly about this requirement.

Regards,
Govind.

>Dirk/Hesham,
>
>So it sounds like there is a case for interdomain discovery, but it
>might be mitigated by certain difficulties. Business considerations
>shouldn't really be an issue here, but scalability certainly should,
>and I can see an argument about technical difficulty integrating
>the CAR discovery with interdomain routing, in both the MN
>and AR cases.
>
>There was really not much technical discussion on this issue
>at SLC. Since then, there has been more, and the
>outlines of possible problems are beginning to emerge.
>I think we really need to do a deeper study to determine
>whether or not this is technically doable.
>
>How about if we keep the requirement a SHOULD? I
>believe that is how Govind originally listed it.
>
>             jak
>
>----- Original Message -----
>From: "Hesham Soliman (ERA)" 
>To: ; ;
>
>Sent: Wednesday, January 23, 2002 9:22 AM
>Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery
>Requirements
>
>
> > Dirk,
> >
> >   > The requirement states that ARs SHOULD or MUST be discovered
> >   > irrespectively of the domain to which they belong. This is a
> >   > generic requirement which reflects one very fundamental nature
> >   > of seamless mobility, namely seamlessly roaming between ARs
> >   > irrespectively of the domain to which they belong.
> >   > Apparently you want the focus of seamlessness more on time
> >   > (reducing the connectivity disruption) rather than on networks
> >   > (roaming seamlessly between networks).
> >
> > => Did I say that ? I don't think so, I simply
> > said that a MN listening to ARs directly
> > (possibly multi-homes) would relatively easily
> > discover GAARs outside its current domain.
> > On the other hand, for ARs to discover GAARs
> > outside their domain, several security issues and
> > 'agreements' between operators are needed. So
> > It does seem more difficult for the AR - AR protocol
> > to work across domains.
> > To conclude: If AR discovers GAARs then inter-domain
> > is more difficult.
> > If MN discovers GAARs then inter-domain discovery is
> > not so difficult.
> >
> >   >
> >   > Furthermore, I have a problem what exactly you mean with 'MN-AR'
> >   > and 'AR-AR' interfaces. But let me interpret how I understood
>these
> >   > terms. Do you mean by 'MN-AR interface' an MN-based
> >   > discovery scheme,
> >   > hence 'AR-AR interface' is an AR-based scheme for discovery?
> >
> > => Yes. I realise that AR-AR can also be relayed
> > to the MN (in some cases).
> >
> >   >
> >   > If so, do you propose that if the MN is doing (mainly) the job,
> >   > it MUST discover ARs irrespectively of the domain, while in the
> >   > (mainly) AR-based scheme it should only (if at all), i.e.,
> >   > it doesn't
> >   > have to?
> >
> > => It doesn't need to be a MUST.
> >
> > Does this make sense?
> >
> > => Why don't we let the WG decide that.
> >
> >
> > With that, you fix the solution space
> >   > in a sense that seems inappropriate to me.
> >
> > => Huh ? can you elaborate. I'm not fixing
> > anything, I said one is simpler than the other.
> >
> > This will open doors
> >   > for fights to which 'category' the solution belongs. What about
> >   > schemes that divide the tasks between AR and MN? MUST or SHOULD
> >   > they fulfill the requirement? What about a scheme that uses MN
> >   > for discovery but AR for capability exchange?
> >
> > => I'm only interested in technical reasons.
> >
> > Do you really
> >   > propose (which is the natural extension of demanding two
> >   > categories of requirements) that we first define categories
> >   > for our solution space and then assign requirements (and their
> >   > strengths) to them?
> >   >
> >   > If we want to enable seamlessness in the sense I described
> >   > above, namely between networks, reflected by the inter-domain
> >   > requirement, the requirement is a MUST. Probably, we should
> >   > think about the possibility that a solution that does not fulfill
> >   > this requirement is one that shouldn't be considered.
> >
> >
> > => I really think you're reading way too much
> > into my emails.
> >
> >   >
> >   > BTW, I see your scalability point. But again, if a solution that
> >   > tries to fulfill the inter-domain requirement doesn't scale, it
> >   > is probably simply not a good solution?
> >
> > => Well there may not be a 'good' solution for this.
> > People make design choices and tradeoffs, what do you
> > mean by 'good' ?
> >
> >
> >   > In conclusion, as a first step, it is necessary that you define
> >   > your terms 'MN-AR interface' and 'AR-AR interface' so that we
> >
> > => If communication between AR and GAARs exists e2e
> > then there is some AR - AR protocol.
> >
> > MN - AR : AR sends information to MN about itself
> > and (possibly) GAARs.
> >
> > I hope this is clearer.
> >
> > Hesham
> >
> >
> >
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby




_________________________________________________________________
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 Jan 23 13:55: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 NAA20535
	for ; Wed, 23 Jan 2002 13:55: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 NAA09824;
	Wed, 23 Jan 2002 13:24: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 NAA09794
	for ; Wed, 23 Jan 2002 13:24:09 -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 NAA19368
	for ; Wed, 23 Jan 2002 13:24:07 -0500 (EST)
From: Dirk.Trossen@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 g0NIPiQ00013
	for ; Wed, 23 Jan 2002 12:25:44 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Wed, 23 Jan 2002 12:24:06 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 23 Jan 2002 12:24:06 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: FW: [Seamoby] Summary of Discussion on CAR Discovery Requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 23 Jan 2002 13:24:05 -0500
Message-ID: 
Thread-Topic: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Thread-Index: AcGkMpjH/PQ81LpCRoCHFhL9CC2Z6AABl8QQAACGplA=
To: 
X-OriginalArrivalTime: 23 Jan 2002 18:24:06.0420 (UTC) FILETIME=[246C7D40:01C1A43B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA09795
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,

ups, I forgot the 'reply all' button again. See comments in 
mail below.

-----Original Message-----
From: Trossen Dirk (NRC/Boston) 
Sent: Wednesday, January 23, 2002 1:23 PM
To: 'ext Hesham Soliman (ERA)'
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery
Requirements


Hi Hesham,

> => Did I say that ? I don't think so, I simply 
> said that a MN listening to ARs directly
> (possibly multi-homes) would relatively easily
> discover GAARs outside its current domain. 
> On the other hand, for ARs to discover GAARs
> outside their domain, several security issues and 
> 'agreements' between operators are needed. So 
> It does seem more difficult for the AR - AR protocol
> to work across domains. 
> To conclude: If AR discovers GAARs then inter-domain
> is more difficult.
> If MN discovers GAARs then inter-domain discovery is 
> not so difficult.

As I said, I see your point that for specific solutions,
it might be more difficult to do CAR discovery. But the
question here is, do we want to make the requirement
mandatory or not that GAARs are discovered independent of their
domains? This is certainly an open point for discussion within
the WG and will eventually lead to a SHOULD or MUST for this
requirements. 

But then we should make this decision for ALL solutions. Making 
it mandatory for MN-based schemes but not for AR-based, doesn't 
make sense from my point of view. That was my concern regarding 
'separation' of requirements.

> With that, you fix the solution space
>   > in a sense that seems inappropriate to me. 
> 
> => Huh ? can you elaborate. I'm not fixing 
> anything, I said one is simpler than the other.

You do in the sense that you imply a certain complexity for
certain solutions (or categories for solutions) so that you
want to soften or to harden certain requirements for certain 
(categories of) solutions.

>   > 
>   > BTW, I see your scalability point. But again, if a solution that
>   > tries to fulfill the inter-domain requirement doesn't scale, it
>   > is probably simply not a good solution? 
> 
> => Well there may not be a 'good' solution for this.
> People make design choices and tradeoffs, what do you 
> mean by 'good' ?

Good in the sense that it fulfils the requirement or not. If we
define the requirement as a SHOULD for all, that's ok. But if it
is a MUST, it should be defined for all solutions. I'm trying to
avoid that we define requirements for different solution spaces
for the same problem.

Regards,


Dirk

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


From seamoby-admin@ietf.org  Wed Jan 23 14:07: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 OAA20897
	for ; Wed, 23 Jan 2002 14:07: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 NAA11464;
	Wed, 23 Jan 2002 13:54: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 NAA11416
	for ; Wed, 23 Jan 2002 13:54:26 -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 NAA20504
	for ; Wed, 23 Jan 2002 13:54:24 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0NIrne11840;
	Wed, 23 Jan 2002 10:53:49 -0800 (PST)
Message-ID: <014601c1a43f$11dcea30$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: , ,
        
References: 
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Wed, 23 Jan 2002 10:52:13 -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,

> I'm fine with keeping it a SHOULD since this has been the original
> proposal anyway. The solutions will show if it is indeed technically
> doable. A SHOULD would reflect the desire that CAR discovery aims at
> discovering GAARs irrespectively of their domains, if possible.
>

OK.

> But the discussion started actually by asking for separation of the
> requirements, and this particular item was given as an example. And
> I simply don't agree that we define different ones (a MUST and a
SHOULD
> version) for different solution spaces. Either we want to make the
above
> desire mandatory for ALL solutions or not, but only for a subset
> does not sound well.
>

So far, I haven't seen anybody support separating requirements
other than this one. If SHOULD doesn't cover it, then I think
it would probably be more economical to have a few words about the two
cases directly in the requirment rather than split them.

So if anybody thinks that more is needed for this requirement,
please propose some text. Otherwise, can we go forward
with SHOULD?

                jak


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


From seamoby-admin@ietf.org  Wed Jan 23 14:54: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 OAA22657
	for ; Wed, 23 Jan 2002 14:54: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 OAA13570;
	Wed, 23 Jan 2002 14:35: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 OAA13538
	for ; Wed, 23 Jan 2002 14:35:48 -0500 (EST)
Received: from hotmail.com (f117.law9.hotmail.com [64.4.9.117])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21863
	for ; Wed, 23 Jan 2002 14:35:45 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 23 Jan 2002 11:35:16 -0800
Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP;
	Wed, 23 Jan 2002 19:35:16 GMT
X-Originating-IP: [63.78.179.5]
From: "Govind Krishnamurthi" 
To: seamoby@ietf.org
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Wed, 23 Jan 2002 14:35:16 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 23 Jan 2002 19:35:16.0783 (UTC) FILETIME=[15C22BF0:01C1A445]
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 will add statements to Requirement 9 to reflect the fact that CAR 
discovery's output must be usable by existing IP mobility protocols.
Please let me know if there are any more concerns.

Regards,
Govind.

>Perhaps the wording of the requirment could be changed?
>How about:
>
>     The CAR discovery protocol MUST be usable by Internet
>     hosts and nodes that support existing IP mobility protocols,
>     such as Mobile IP and MANET.
>






_________________________________________________________________
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 Jan 23 20:00: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 UAA00464
	for ; Wed, 23 Jan 2002 20:00: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 TAA25149;
	Wed, 23 Jan 2002 19:41: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 TAA25120
	for ; Wed, 23 Jan 2002 19:41:51 -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 TAA00343
	for ; Wed, 23 Jan 2002 19:41:49 -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 QAA04777
	for ; Wed, 23 Jan 2002 16:41:19 -0800 (PST)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0O0fJM14672
	for ; Wed, 23 Jan 2002 16:41:19 -0800
X-mProtect:  Wed, 23 Jan 2002 16:41:19 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com smtpdAYov5F; Wed, 23 Jan 2002 16:41:17 PST
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id QAA38466 for ; Wed, 23 Jan 2002 16:41:17 -0800 (PST)
Message-ID: <3C4F582D.65F3D8@iprg.nokia.com>
Date: Wed, 23 Jan 2002 16:41:17 -0800
From: "Jari T. Malinen" 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
CC: seamoby@ietf.org
Subject: Re: [Seamoby] Concensus Call:Reaching Closure on Paging Decision
References: <8C92E23A3E87FB479988285F9E22BE465AB9C5@ftmail> <3C4DE01F.7396E55C@iprg.nokia.com> <3C4DF9C8.4090609@alcatel.com> <3C4E24C8.771CC63A@iprg.nokia.com> <003001c1a434$e22d7890$7e6015ac@T23KEMPF> <3C4EF965.6040604@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

All,

Also agreed, except that a construction is a better way than
starting from draft-renker.

BR,

-Jari

Behcet Sarikaya wrote:
> 
> Dear All,
>   Let me say that, probably to everybody's surprise, I completely concur with James's view. There is no rush and IP paging will be an important component in future wireless networks.
> So let's not go for a cheap solution.
> 
>   Regards,
> 
> James Kempf wrote:
> 
> > Jari,
> >
> >> If we are in a hurry, the complexity will be mind-boggling.
> >> A construction may be a possibility, maybe I'm optimistic,
> >> using the material as a set of design elements (build a framework
> >> based on components in the proposals)..
> >>
> > Actually, I don't think we are in a hurry. As the response to
> > the survey I sent out indicated, nobody is doing product
> > in this area in the near future, so we have some time to
> > get this right.
> > Counting pages and figuring out how to do a merge on
> > the existing specs isn't the right way to go, IMHO.
> > We want 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.
> > I still believe that draft-renker is a good starting
> > point for the design. It is easier to find the faults
> > in something that exists and fix them than try
> > to start from scratch. But if the working group isn't
> > happy with using draft-renker as the base, then Allison,
> > Pat and I need to figure out a way to go forward that
> > will result in a good technical solution. We h
> > ave some ideas,
> > but the question in my mind right now is: is the WG
> > interested in getting the right technical solution?
> >             jak
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> 
> --
> Behcet

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


From seamoby-admin@ietf.org  Thu Jan 24 08:26: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 IAA20902
	for ; Thu, 24 Jan 2002 08:26: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 IAA26941;
	Thu, 24 Jan 2002 08:12: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 IAA26910
	for ; Thu, 24 Jan 2002 08:12:25 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20728
	for ; Thu, 24 Jan 2002 08:12:17 -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 g0ODCIIB023981
	for ; Thu, 24 Jan 2002 14:12:18 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 24 14:12:01 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 24 Jan 2002 14:03:09 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A942@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "Hesham Soliman (ERA)" ,
        "'Dirk.Trossen@nokia.com'" ,
        "'kempf@docomolabs-usa.com'" ,
        "'seamoby@ietf.org'" 
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Thu, 24 Jan 2002 14:11:54 +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

uHi, 

Another requirement which is more relevant 
for the inter-domain case (if an AR is to 
discover GAARs) is that the protocol must 
be able to function despite of network 
renumbering of either domain. 

Regs,
Hesham

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


From seamoby-admin@ietf.org  Thu Jan 24 12:11: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 MAA27844
	for ; Thu, 24 Jan 2002 12:11: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 LAA08024;
	Thu, 24 Jan 2002 11:58: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 LAA07995
	for ; Thu, 24 Jan 2002 11:58:39 -0500 (EST)
Received: from hotmail.com (f150.law7.hotmail.com [216.33.237.150])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27170
	for ; Thu, 24 Jan 2002 11:58:35 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 24 Jan 2002 08:58:03 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP;
	Thu, 24 Jan 2002 16:58:00 GMT
X-Originating-IP: [63.78.179.5]
From: "Hemant Chaskar" 
To: hesham.soliman@era.ericsson.se, kempf@docomolabs-usa.com,
        govs23@hotmail.com, seamoby@ietf.org
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Thu, 24 Jan 2002 16:58:00 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 24 Jan 2002 16:58:03.0406 (UTC) FILETIME=[4970D2E0:01C1A4F8]
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:

I think the central issue in CAR discovery is about "IP handoffs", actually 
"capability-aware IP handoffs". Every IP mobility management protocol that 
has handoff as a central theme, may it be Mobile IP, MANET or something 
else, should be able to use CAR discovery protocol. This means that:

1. CAR discovery protocol cannot use any  "protocol specific technique" (of 
course other than handoff as it is central to all mobility management 
protocols).

2. Output of CAR discovery needs to be usable by these mobility management 
protocols.

Do we agree with this or is there anything more in Mobile IP and MANET that 
solicits their explicit MUST mention in the requirements document?

Hemant


>From: "Hesham Soliman (ERA)" 
>To: "'James Kempf'" ,        Govind Krishnamurthi 
>  , seamoby@ietf.org
>Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
>Date: Wed, 23 Jan 2002 18:32:17 +0100
>
>
>   > The point about the need to support existing mobility protocols
>   > was not only made by Phil, it was made by Hesham and others.
>   > So I think there is a group of people that would like to see this
>   > as a requirement. It also seems almost a given to me, why
>   > would the WG want to come up with a protocol that
>   > doesn't support existing mobility protocols, so I'm
>   > having a hard time seeing why you're resisting putting
>   > it in.
>
>=> Fully agree.
>
>Hesham
>
>_______________________________________________
>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  Thu Jan 24 12: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 MAA28341
	for ; Thu, 24 Jan 2002 12:22: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 MAA09870;
	Thu, 24 Jan 2002 12:11: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 MAA09838
	for ; Thu, 24 Jan 2002 12:11:32 -0500 (EST)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27896
	for ; Thu, 24 Jan 2002 12:11:27 -0500 (EST)
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 24 Jan 2002 12:11:10 -0500
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E04861669C@meshpdc.meshnetworks.com>
From: Phillip Neumiller 
To: "'Hemant Chaskar'" , hesham.soliman@era.ericsson.se,
        kempf@docomolabs-usa.com, govs23@hotmail.com, seamoby@ietf.org
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Thu, 24 Jan 2002 12:11:06 -0500
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


Seems reasonable to me.

--
Mesh Networks, Inc. (www.meshnetworks.com)
Phillip D. Neumiller, Staff Scientist
pneumiller@meshnetworks.com PH: 1-407-659-5387

> -----Original Message-----
> From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
> Sent: Thursday, January 24, 2002 11:58 AM
> To: hesham.soliman@era.ericsson.se; kempf@docomolabs-usa.com;
> govs23@hotmail.com; seamoby@ietf.org
> Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery
> Requirements
> 
> 
> Hi:
> 
> I think the central issue in CAR discovery is about "IP 
> handoffs", actually 
> "capability-aware IP handoffs". Every IP mobility management 
> protocol that 
> has handoff as a central theme, may it be Mobile IP, MANET or 
> something 
> else, should be able to use CAR discovery protocol. This means that:
> 
> 1. CAR discovery protocol cannot use any  "protocol specific 
> technique" (of 
> course other than handoff as it is central to all mobility management 
> protocols).
> 
> 2. Output of CAR discovery needs to be usable by these 
> mobility management 
> protocols.
> 
> Do we agree with this or is there anything more in Mobile IP 
> and MANET that 
> solicits their explicit MUST mention in the requirements document?
> 
> Hemant
> 
> 
> >From: "Hesham Soliman (ERA)" 
> >To: "'James Kempf'" ,        
> Govind Krishnamurthi 
> >  , seamoby@ietf.org
> >Subject: RE: [Seamoby] Summary of Discussion on CAR 
> Discovery Requirements
> >Date: Wed, 23 Jan 2002 18:32:17 +0100
> >
> >
> >   > The point about the need to support existing mobility protocols
> >   > was not only made by Phil, it was made by Hesham and others.
> >   > So I think there is a group of people that would like 
> to see this
> >   > as a requirement. It also seems almost a given to me, why
> >   > would the WG want to come up with a protocol that
> >   > doesn't support existing mobility protocols, so I'm
> >   > having a hard time seeing why you're resisting putting
> >   > it in.
> >
> >=> Fully agree.
> >
> >Hesham
> >
> >_______________________________________________
> >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
> 
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 

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


From seamoby-admin@ietf.org  Thu Jan 24 13:22: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 NAA00758
	for ; Thu, 24 Jan 2002 13:22: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 NAA13193;
	Thu, 24 Jan 2002 13:10: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 NAA13162
	for ; Thu, 24 Jan 2002 13:10: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 NAA00040
	for ; Thu, 24 Jan 2002 13:10: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 g0OIAJe22311;
	Thu, 24 Jan 2002 10:10:19 -0800 (PST)
Message-ID: <00c301c1a502$287db850$7e6015ac@T23KEMPF>
From: "James Kempf" 
To: "Hesham Soliman \(ERA\)" ,
        , 
References: <4DA6EA82906FD511BE2F00508BCF053802C6A942@Esealnt861.al.sw.ericsson.se>
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Thu, 24 Jan 2002 10:07: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

Hesham,

Good point.

Would you care to propose a requirement for discussion?

        jak

----- Original Message -----
From: "Hesham Soliman (ERA)" 
To: "Hesham Soliman (ERA)" ;
; ; 
Sent: Thursday, January 24, 2002 5:11 AM
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery
Requirements


> uHi,
>
> Another requirement which is more relevant
> for the inter-domain case (if an AR is to
> discover GAARs) is that the protocol must
> be able to function despite of network
> renumbering of either domain.
>
> Regs,
> Hesham
>


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


From seamoby-admin@ietf.org  Thu Jan 24 13:23: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 NAA00807
	for ; Thu, 24 Jan 2002 13:23: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 NAA12786;
	Thu, 24 Jan 2002 13:03: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 NAA12757
	for ; Thu, 24 Jan 2002 13:03:41 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29694
	for ; Thu, 24 Jan 2002 13:03:37 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g0OI3aIB022590
	for ; Thu, 24 Jan 2002 19:03:37 +0100 (MET)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Jan 24 19:03:19 2002 +0100
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 24 Jan 2002 18:54:28 +0100
Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A94C@Esealnt861.al.sw.ericsson.se>
From: "Hesham Soliman (ERA)" 
To: "Hesham Soliman (ERA)" ,
        "'Dirk.Trossen@nokia.com'" ,
        "'kempf@docomolabs-usa.com'" ,
        "'seamoby@ietf.org'" 
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Thu, 24 Jan 2002 19:03:18 +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

Sorry...replying to my own mail.
This was said to give another example of 
why AR - AR may need different requirements
from MN - AR. 

Hesham

  > -----Original Message-----
  > From: Hesham Soliman (ERA) 
  > Sent: Thursday, January 24, 2002 2:12 PM
  > To: Hesham Soliman (ERA); 'Dirk.Trossen@nokia.com';
  > 'kempf@docomolabs-usa.com'; 'seamoby@ietf.org'
  > Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery
  > Requirements
  > 
  > 
  > uHi, 
  > 
  > Another requirement which is more relevant 
  > for the inter-domain case (if an AR is to 
  > discover GAARs) is that the protocol must 
  > be able to function despite of network 
  > renumbering of either domain. 
  > 
  > Regs,
  > Hesham
  > 

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


From seamoby-admin@ietf.org  Thu Jan 24 21:18: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 VAA12086
	for ; Thu, 24 Jan 2002 21:18: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 VAA08020;
	Thu, 24 Jan 2002 21:07: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 VAA07990
	for ; Thu, 24 Jan 2002 21:07:40 -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 VAA11903
	for ; Thu, 24 Jan 2002 21:07:36 -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 SAA18065;
	Thu, 24 Jan 2002 18:07:08 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0P278806319;
	Thu, 24 Jan 2002 18:07:08 -0800
X-mProtect:  Thu, 24 Jan 2002 18:07:08 -0800 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com smtpd6nQISb; Thu, 24 Jan 2002 18:07:06 PST
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id SAA40432; Thu, 24 Jan 2002 18:07:06 -0800 (PST)
Message-ID: <3C50BDCA.47D8700B@iprg.nokia.com>
Date: Thu, 24 Jan 2002 18:07:06 -0800
From: "Jari T. Malinen" 
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf 
CC: Govind Krishnamurthi , seamoby@ietf.org
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
References:  <008401c1a436$597084a0$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,

> Govind,
> 
> > [GK] ----> First, how CAR discovery is useful in Ad-hoc
> > networks is quite unclear to me as every communication is line of
> sight,
> > unless you mean that we can exchange capabilities. Or do you mean
> > an environment wherein a fixed infrastructure as well as a ad-hoc
> > nodes are there.
> >
> 
> I believe the issue here was discovering an access router that
> would let the MANET route back into the fixed network.
> 
>             jak

There are several issues to let MANET route back to the fixed
network. Discovering an on-link fixed access router by a manet
node, and establishing the routable communication.

There, establishment of communication with the fixed network
is more of an addressing problem, how to get a routable
address from the edge box. Manet nodes communicate among
themselver with potentially topologically incorrect addresses.
When connecting with the fixed network, obtaining a
topologically correct address is needed.

There use of gateway discovery to obtain the topologically correct
address is being considered in work in the MANET working group,
see drafts

http://search.ietf.org/internet-drafts/draft-wakikawa-manet-globalv6-00.txt
http://search.ietf.org/internet-drafts/draft-royer-manet-globalv4-00.txt

for IPv6 and IPv4 gateway discovery, respectively.

Clearly, the MANET gateway discovery and addressing issues are out
of scope of CAR, but it is possible CAR can direct an edge MANET node
to connect to a suitable fixed network node for link establishment.

This should, however, be independent of the MANET protocols or
MANET connectivity protocols, and minimally consider
MANET itself, except, perhaps, by providing capabilities for
the immediate MANET nodes connecting to the fixed network to
locate, e.g., a globalv6-capable fixed access router or an
access router that can hand out topologically correct prefixes
to be used by a mobile globalv6 gateway node.

Hence, independence of mobility protocol should basically be
a valid and an adequate requirement for MANET operation while
recognizing that CAR does not solve the MANET node-fixed network
routing or reachability problem, just link establishment for
mobile nodes, MANET edge nodes included.

BR,

-Jari

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


From seamoby-admin@ietf.org  Fri Jan 25 16:43: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 QAA15126
	for ; Fri, 25 Jan 2002 16:43: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 QAA11053;
	Fri, 25 Jan 2002 16:27: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 QAA11024
	for ; Fri, 25 Jan 2002 16:27:42 -0500 (EST)
Received: from hotmail.com (f108.law7.hotmail.com [216.33.237.108])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14786
	for ; Fri, 25 Jan 2002 16:27:37 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 25 Jan 2002 13:27:09 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP;
	Fri, 25 Jan 2002 21:27:09 GMT
X-Originating-IP: [63.78.179.5]
From: "Hemant Chaskar" 
To: seamoby@ietf.org
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Fri, 25 Jan 2002 21:27:09 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 25 Jan 2002 21:27:09.0571 (UTC) FILETIME=[0BB7D530:01C1A5E7]
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,

I agree with Jari on the MANET issue. If MANET has to use CAR discovery, it 
is only the "edge" nodes that are connected to the Internet gateways that 
use it. There can be a whole family of nodes of MANET behind the edge nodes 
which do not do handoffs between gateways. In other words, these other nodes 
may not need to use CAR discovery. Thus, I see no difference between handoff 
performed by an isolated single node and edge node of MANET, as far as CAR 
discovery is concerned. So why does MANET need an explicit "MUST" mention in 
requirements?

Hemant




>From: "Jari T. Malinen" 
>To: James Kempf 
>CC: Govind Krishnamurthi , seamoby@ietf.org
>Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
>Date: Thu, 24 Jan 2002 18:07:06 -0800
>
>James,
>
> > Govind,
> >
> > > [GK] ----> First, how CAR discovery is useful in Ad-hoc
> > > networks is quite unclear to me as every communication is line of
> > sight,
> > > unless you mean that we can exchange capabilities. Or do you mean
> > > an environment wherein a fixed infrastructure as well as a ad-hoc
> > > nodes are there.
> > >
> >
> > I believe the issue here was discovering an access router that
> > would let the MANET route back into the fixed network.
> >
> >             jak
>
>There are several issues to let MANET route back to the fixed
>network. Discovering an on-link fixed access router by a manet
>node, and establishing the routable communication.
>
>There, establishment of communication with the fixed network
>is more of an addressing problem, how to get a routable
>address from the edge box. Manet nodes communicate among
>themselver with potentially topologically incorrect addresses.
>When connecting with the fixed network, obtaining a
>topologically correct address is needed.
>
>There use of gateway discovery to obtain the topologically correct
>address is being considered in work in the MANET working group,
>see drafts
>
>http://search.ietf.org/internet-drafts/draft-wakikawa-manet-globalv6-00.txt
>http://search.ietf.org/internet-drafts/draft-royer-manet-globalv4-00.txt
>
>for IPv6 and IPv4 gateway discovery, respectively.
>
>Clearly, the MANET gateway discovery and addressing issues are out
>of scope of CAR, but it is possible CAR can direct an edge MANET node
>to connect to a suitable fixed network node for link establishment.
>
>This should, however, be independent of the MANET protocols or
>MANET connectivity protocols, and minimally consider
>MANET itself, except, perhaps, by providing capabilities for
>the immediate MANET nodes connecting to the fixed network to
>locate, e.g., a globalv6-capable fixed access router or an
>access router that can hand out topologically correct prefixes
>to be used by a mobile globalv6 gateway node.
>
>Hence, independence of mobility protocol should basically be
>a valid and an adequate requirement for MANET operation while
>recognizing that CAR does not solve the MANET node-fixed network
>routing or reachability problem, just link establishment for
>mobile nodes, MANET edge nodes included.
>
>BR,
>
>-Jari
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby


_________________________________________________________________
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  Fri Jan 25 17:57: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 RAA17388
	for ; Fri, 25 Jan 2002 17:57: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 RAA15394;
	Fri, 25 Jan 2002 17:42: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 RAA15365
	for ; Fri, 25 Jan 2002 17:42:44 -0500 (EST)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17043
	for ; Fri, 25 Jan 2002 17:42:38 -0500 (EST)
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 25 Jan 2002 17:42:31 -0500
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0486166AB@meshpdc.meshnetworks.com>
From: Phillip Neumiller 
To: "'Hemant Chaskar'" , seamoby@ietf.org
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Fri, 25 Jan 2002 17:42:21 -0500
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 disagree, but I can not respond till next week.  
> -----Original Message-----
> From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
> Sent: Friday, January 25, 2002 4:27 PM
> To: seamoby@ietf.org
> Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery
> Requirements
> 
> 
> Hi,
> 
> I agree with Jari on the MANET issue. If MANET has to use CAR 
> discovery, it 
> is only the "edge" nodes that are connected to the Internet 
> gateways that 
> use it. There can be a whole family of nodes of MANET behind 
> the edge nodes 
> which do not do handoffs between gateways. In other words, 
> these other nodes 
> may not need to use CAR discovery. Thus, I see no difference 
> between handoff 
> performed by an isolated single node and edge node of MANET, 
> as far as CAR 
> discovery is concerned. So why does MANET need an explicit 
> "MUST" mention in 
> requirements?
> 
> Hemant
> 
> 
> 
> 
> >From: "Jari T. Malinen" 
> >To: James Kempf 
> >CC: Govind Krishnamurthi , seamoby@ietf.org
> >Subject: Re: [Seamoby] Summary of Discussion on CAR 
> Discovery Requirements
> >Date: Thu, 24 Jan 2002 18:07:06 -0800
> >
> >James,
> >
> > > Govind,
> > >
> > > > [GK] ----> First, how CAR discovery is useful in Ad-hoc
> > > > networks is quite unclear to me as every communication 
> is line of
> > > sight,
> > > > unless you mean that we can exchange capabilities. Or 
> do you mean
> > > > an environment wherein a fixed infrastructure as well 
> as a ad-hoc
> > > > nodes are there.
> > > >
> > >
> > > I believe the issue here was discovering an access router that
> > > would let the MANET route back into the fixed network.
> > >
> > >             jak
> >
> >There are several issues to let MANET route back to the fixed
> >network. Discovering an on-link fixed access router by a manet
> >node, and establishing the routable communication.
> >
> >There, establishment of communication with the fixed network
> >is more of an addressing problem, how to get a routable
> >address from the edge box. Manet nodes communicate among
> >themselver with potentially topologically incorrect addresses.
> >When connecting with the fixed network, obtaining a
> >topologically correct address is needed.
> >
> >There use of gateway discovery to obtain the topologically correct
> >address is being considered in work in the MANET working group,
> >see drafts
> >
> >http://search.ietf.org/internet-drafts/draft-wakikawa-manet-g
lobalv6-00.txt
>http://search.ietf.org/internet-drafts/draft-royer-manet-globalv4-00.txt
>
>for IPv6 and IPv4 gateway discovery, respectively.
>
>Clearly, the MANET gateway discovery and addressing issues are out
>of scope of CAR, but it is possible CAR can direct an edge MANET node
>to connect to a suitable fixed network node for link establishment.
>
>This should, however, be independent of the MANET protocols or
>MANET connectivity protocols, and minimally consider
>MANET itself, except, perhaps, by providing capabilities for
>the immediate MANET nodes connecting to the fixed network to
>locate, e.g., a globalv6-capable fixed access router or an
>access router that can hand out topologically correct prefixes
>to be used by a mobile globalv6 gateway node.
>
>Hence, independence of mobility protocol should basically be
>a valid and an adequate requirement for MANET operation while
>recognizing that CAR does not solve the MANET node-fixed network
>routing or reachability problem, just link establishment for
>mobile nodes, MANET edge nodes included.
>
>BR,
>
>-Jari
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby


_________________________________________________________________
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
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 

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


From seamoby-admin@ietf.org  Mon Jan 28 09:15: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 JAA26597
	for ; Mon, 28 Jan 2002 09:15: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 IAA10603;
	Mon, 28 Jan 2002 08:50: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 IAA10572
	for ; Mon, 28 Jan 2002 08:50:25 -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 IAA25475;
	Mon, 28 Jan 2002 08:50:21 -0500 (EST)
Message-Id: <200201281350.IAA25475@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: Mon, 28 Jan 2002 08:50:21 -0500
Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-ct-reqs-03.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		: General Requirements for a Context Transfer
	Author(s)	: H. Syed, G. Kenward et al.
	Filename	: draft-ietf-seamoby-ct-reqs-03.txt
	Pages		: 
	Date		: 25-Jan-02
	
The success of time sensitive services like VoIP telephony, video, 
etc., in a mobile environment depends heavily on the ability to 
minimize the impact of the traffic redirection during a change of 
packet forwarding path. In the process of establishing the new 
forwarding path, the nodes along the new path must be prepared to 
provide similar forwarding treatment to the IP packets. The transfer
of context information may be advantageous in minimizing the impact
of host mobility on IP services. This document captures the set of 
requirements for a context transfer framework and the requirements
for a generic context transfer protocol to carry the context between
the context transfer peers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-seamoby-ct-reqs-03.txt

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

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

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-seamoby-ct-reqs-03.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:	<20020125134200.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-seamoby-ct-reqs-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-seamoby-ct-reqs-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



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


From seamoby-admin@ietf.org  Mon Jan 28 09:15: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 JAA26610
	for ; Mon, 28 Jan 2002 09:15: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 JAA12254;
	Mon, 28 Jan 2002 09:02: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 JAA12223
	for ; Mon, 28 Jan 2002 09:02:32 -0500 (EST)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25993
	for ; Mon, 28 Jan 2002 09:02:28 -0500 (EST)
Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DP47K042; Mon, 28 Jan 2002 09:01:26 -0500
Message-ID: <009401c1a804$47137e80$6200000a@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: , 
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Mon, 28 Jan 2002 09:01:26 -0500
Organization: MeshNetworks, Inc.
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 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


Heman Chaskar wrote:

>I agree with Jari on the MANET issue. If MANET has to use CAR discovery, it 
>is only the "edge" nodes that are connected to the Internet gateways that 
>use it. 

You have introduced a word "edge" that is not defined by the MANET group to 
my knowledge.  What do you mean by this?  Also, what do you mean by "if
MANET *has* to use CAR discovery?   If CAR discovery *is* useful, then wouldn't
MANET protocols want to make use of it?  Also, all nodes in MANETs can 
function as ARs so I find your description a bit skewed.

> There can be a whole family of nodes of MANET behind the edge nodes 
>which do not do handoffs between gateways. 

If all nodes in MANETS are ARs then what is the difference?  Recall peer-to-peer
traffic and "handing off" between these nodes.  With high speed mobiles, no known
MANET routing algorithm will converge fast enough to hand off between micro-cells.
This is precisely why CAR is needed for MANETs, irrespective of your edge/core
distinction.

> In other words, these other nodes 
>may not need to use CAR discovery. Thus, I see no difference between handoff 
>performed by an isolated single node and edge node of MANET, as far as CAR 
>discovery is concerned. 

Again, you have some kind of "architecture" in mind here and that is a no-no.  When 
referring to MANETs we should stick to the pure definition of ad hoc and not impose
hierarchy as you are doing.

> So why does MANET need an explicit "MUST" mention in 
>requirements?

Because CAR MUST be useful (i.e. have utility) for mobile IP, MANET, and any other
IETF created mobility protocol.

Thanks,

Phil Neumiller
MeshNetworks, Inc.




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


From seamoby-admin@ietf.org  Mon Jan 28 11:56: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 LAA02375
	for ; Mon, 28 Jan 2002 11:56: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 LAA21474;
	Mon, 28 Jan 2002 11:43: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 LAA21444
	for ; Mon, 28 Jan 2002 11:43:18 -0500 (EST)
Received: from hotmail.com (f71.law7.hotmail.com [216.33.237.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02010
	for ; Mon, 28 Jan 2002 11:43:14 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 28 Jan 2002 08:42:47 -0800
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP;
	Mon, 28 Jan 2002 16:42:47 GMT
X-Originating-IP: [63.78.179.5]
From: "Hemant Chaskar" 
To: seamoby@ietf.org
Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
Date: Mon, 28 Jan 2002 16:42:47 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 28 Jan 2002 16:42:47.0729 (UTC) FILETIME=[D14E9A10:01C1A81A]
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 Phil:

I have only the following "cannonical" architecture in mind. There is a 
mobile node attached to access router, and it needs to change its physical 
connectivity seamlessly to another access router, i.e., execute IP-level 
handoff. CAR discovery will help you do that. If the mobility management 
protocol has the above cannonical central idea, it will use the CAR 
discovery.

What you are suggesting is just a scenario in which the above central theme 
can be indentified. This is a good example of how one can easily map this 
cannonical central theme to scenarios and mobility management protocols at 
hand and apply CAR discovery to it.

Hence, IMHO, I see no need to do explicit mention of MANET or MOBILE IP as 
MUST consumers in the requirements document. This is because, both of them 
(at least MANET) carry much more baggage with them in addition to the 
central idea of seamelss handoff described above.

Hemant


>From: "Phil Neumiller" 
>Reply-To: "Phil Neumiller" 
>To: , 
>Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
>Date: Mon, 28 Jan 2002 09:01:26 -0500
>
>
>Heman Chaskar wrote:
>
> >I agree with Jari on the MANET issue. If MANET has to use CAR discovery, 
>it
> >is only the "edge" nodes that are connected to the Internet gateways that
> >use it.
>
>You have introduced a word "edge" that is not defined by the MANET group to
>my knowledge.  What do you mean by this?  Also, what do you mean by "if
>MANET *has* to use CAR discovery?   If CAR discovery *is* useful, then 
>wouldn't
>MANET protocols want to make use of it?  Also, all nodes in MANETs can
>function as ARs so I find your description a bit skewed.
>
> > There can be a whole family of nodes of MANET behind the edge nodes
> >which do not do handoffs between gateways.
>
>If all nodes in MANETS are ARs then what is the difference?  Recall 
>peer-to-peer
>traffic and "handing off" between these nodes.  With high speed mobiles, no 
>known
>MANET routing algorithm will converge fast enough to hand off between 
>micro-cells.
>This is precisely why CAR is needed for MANETs, irrespective of your 
>edge/core
>distinction.
>
> > In other words, these other nodes
> >may not need to use CAR discovery. Thus, I see no difference between 
>handoff
> >performed by an isolated single node and edge node of MANET, as far as 
>CAR
> >discovery is concerned.
>
>Again, you have some kind of "architecture" in mind here and that is a 
>no-no.  When
>referring to MANETs we should stick to the pure definition of ad hoc and 
>not impose
>hierarchy as you are doing.
>
> > So why does MANET need an explicit "MUST" mention in
> >requirements?
>
>Because CAR MUST be useful (i.e. have utility) for mobile IP, MANET, and 
>any other
>IETF created mobility protocol.
>
>Thanks,
>
>Phil Neumiller
>MeshNetworks, Inc.
>
>
>


_________________________________________________________________
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  Thu Jan 31 07:14: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 HAA24287
	for ; Thu, 31 Jan 2002 07:14: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 HAA11118;
	Thu, 31 Jan 2002 07:00: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 HAA11083
	for ; Thu, 31 Jan 2002 07:00:32 -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 HAA23919;
	Thu, 31 Jan 2002 07:00:28 -0500 (EST)
Message-Id: <200201311200.HAA23919@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, 31 Jan 2002 07:00:28 -0500
Subject: [Seamoby] I-D ACTION:draft-krishnamurthi-seamoby-car-requirements-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		: Requirements for CAR Discovery Protocols
	Author(s)	: G. Krishnamurthi
	Filename	: draft-krishnamurthi-seamoby-car-requirements-00.txt
	Pages		: 5
	Date		: 30-Jan-02
	
The pre-requisite for IP based seamless mobility protocols is the
knowledge of the access router (AR) to which a mobile node can be
handed over to. Further, a handoff can be optimized if the capabilities
of the AR being considered for handoff are known. The protocol which
discovers ARs for potential handoff along with their capabilities is
called the CAR discovery protocol. In this draft we list the
requirements which are to be met by CAR discovery protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-krishnamurthi-seamoby-car-requirements-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-krishnamurthi-seamoby-car-requirements-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-krishnamurthi-seamoby-car-requirements-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:	<20020130093708.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-krishnamurthi-seamoby-car-requirements-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-krishnamurthi-seamoby-car-requirements-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



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