From mailman-owner@ietf.org Thu Aug 1 06:08: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 GAA17309 for ; Thu, 1 Aug 2002 06:08:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01344 for ; Thu, 1 Aug 2002 06:09:31 -0400 (EDT) Date: Thu, 1 Aug 2002 06:09:31 -0400 (EDT) Message-Id: <200208011009.GAA01344@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. ****************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ****************************************************************** 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 seamoby-admin@ietf.org Thu Aug 1 12:48: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 MAA06746 for ; Thu, 1 Aug 2002 12:48:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09019; Thu, 1 Aug 2002 12:46:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08990 for ; Thu, 1 Aug 2002 12:46:51 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06545 for ; Thu, 1 Aug 2002 12:45:41 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id JAA02437 for ; Thu, 1 Aug 2002 09:45:34 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA17797 for ; Thu, 1 Aug 2002 09:46:50 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 1 Aug 2002 11:46:49 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD567C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , "'Rajeev Koodli'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Thu, 1 Aug 2002 11:46:49 -0500 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 Hi James, Below is a crack at the transport section, I have tried to accomodate all parties. Except the use of UDP and Acks, if that is important the following can be added under X.X.1 (with the risk of opening the Pandora's box :( ) Specific feature context transfers MAY allow the embedding very simple reliability mechanisms such as Acks in conjunction with use of UDP. Care, must be taken to adhere with X.X.2 (not redesign a transport protocol). Hope it helps, Regards, Madjid =================start================================= X.X Context transfer protocol in its generic form MUST be designed independent of the underlying transport protocol. X.X.1 A generic context transfer protocol MUST accommodate scenarios that do not require or can not accept the complexity of all transport protocols. X.X.2 Context Transfer MUST allow the use of more complex transport protocols (such as those providing reliability) for transferring specific features that require complex transport functionalities. The context transfer MUST however avoid introducing redundancy in transport mechanisms (such as retransmissions). In other words, in cases, where such functionality can be provided by an underlying standard transport protocol, the context transport protocol MUST NOT embed such functionalities in its design. Instead the context transfer protocol MUST seek to utilize a "standard" transport protocol instead. Context transfer protocol design SHOULD employ IETF transport protocols such as SCTP/TCP for such cases. Note that for such protocols, it is advised to perform the association/ session message exchange between context transfer peers (ARs) in anticipation of handovers (if possible) to accomodate transfer of time-critical feature contexts. I picked part of this one from earlier emails: X.X.3 A feature context specification MUST define the transport to be used. If the feature context is transferred using an IETF transport layer protocol , then the feature context specification MUST include the full details of how the transport layer protocol is used. However, One must note that employing different transport mechanisms for different feature context might lead to limited possibility of multiplexing various feature contexts. Therefore, such details NEED NOT be included in a generic context transfer protocol design. X.X.4 In case a specific functionality (such as sending updates) is not provided by an IETF transport protocol, such functionality MAY be added as an OPTIONAL element to the specific feature context transfer specification. ===================End ======================================= -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, July 31, 2002 3:15 PM To: Nakhjiri Madjid-MNAKHJI1; 'Rajeev Koodli' Cc: seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Madjid, Do you have some specific text you would like to propose regarding the transport? jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'Rajeev Koodli'" Cc: "James Kempf" ; Sent: Wednesday, July 24, 2002 4:20 PM Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications > Rajeev, > > sorry for the delay. see below. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Tuesday, July 23, 2002 4:24 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: James Kempf; seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > - regarding the transport text, if a particular feature indicates UDP/TCP > > or SCTP, isn't that sufficient ? Even if it can provide more information, > > how > > is that going to be useful if it is not supported by the underlying > > transport > > protocol ? > > > > Madjid>> First of all, not everybody and every feature need an advanced > > transport and I know we agree on this. > > However, say in 6 months we are debating an specific feature that does need > > reliability. This text is to protect us from sloppy design. > > If you remember Jeff Schiller saying: Don't come and say use > > IPSec if you want security, you need to work on the security details. > > > > Example of a case which even SCTP is not going to cut it (this is > > answer to your next question as well): say you are sending a very > > dynamic context (packet count or HC context) and you want reliability > > (and you got time to resend stuff...). > > You send the context, but due to do channel conditions don't get it through, > > next time, you have to send updates. This has to come from the feature unit > > and not from transport layer. If had just said use SCTP for reliability that > > would not be a robust design. > > > > When you have to send an update, you do it whether or not SCTP failed to > get it through in the first case, right ? What SCTP or a reliable transport > protocol will offer you is the ability to send a message reliably. When you > have a new message or an update, I agree the feature code has to supply it > (and SCTP has to get to the destination reliably)! > > Madjid>> True, furthermore, if you use a reliable protocol like > SCTP, you need to take extra care with CT, so the receiver doesn't mix up > updates from app. layer, with retx from transport. > > > I hope you are not indicating that each feature has to design its own reliable > transmission protocol. The way each feature uses SCTP or UDP is internal > to the feature, and is not a function of the CT protocol itself. The > CT protocol > should define a set of messages that can be carried over different transport > protocols. > > Madjid>> No, No, however, If we add a set of minimal support (like > what I mentioned above) to the generic protocol, then provide the option > for the feature to use it or not we are covered. > If we completely ignore reliability > completely, we will write off CT as a useful protocol, I think! > > BR, > > Madjid > > Regards, > > -Rajeev > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Aug 1 12:48: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 MAA06755 for ; Thu, 1 Aug 2002 12:48:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09196 for seamoby-archive@odin.ietf.org; Thu, 1 Aug 2002 12:49:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09019; Thu, 1 Aug 2002 12:46:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08990 for ; Thu, 1 Aug 2002 12:46:51 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06545 for ; Thu, 1 Aug 2002 12:45:41 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id JAA02437 for ; Thu, 1 Aug 2002 09:45:34 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA17797 for ; Thu, 1 Aug 2002 09:46:50 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 1 Aug 2002 11:46:49 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD567C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , "'Rajeev Koodli'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Thu, 1 Aug 2002 11:46:49 -0500 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 Hi James, Below is a crack at the transport section, I have tried to accomodate all parties. Except the use of UDP and Acks, if that is important the following can be added under X.X.1 (with the risk of opening the Pandora's box :( ) Specific feature context transfers MAY allow the embedding very simple reliability mechanisms such as Acks in conjunction with use of UDP. Care, must be taken to adhere with X.X.2 (not redesign a transport protocol). Hope it helps, Regards, Madjid =================start================================= X.X Context transfer protocol in its generic form MUST be designed independent of the underlying transport protocol. X.X.1 A generic context transfer protocol MUST accommodate scenarios that do not require or can not accept the complexity of all transport protocols. X.X.2 Context Transfer MUST allow the use of more complex transport protocols (such as those providing reliability) for transferring specific features that require complex transport functionalities. The context transfer MUST however avoid introducing redundancy in transport mechanisms (such as retransmissions). In other words, in cases, where such functionality can be provided by an underlying standard transport protocol, the context transport protocol MUST NOT embed such functionalities in its design. Instead the context transfer protocol MUST seek to utilize a "standard" transport protocol instead. Context transfer protocol design SHOULD employ IETF transport protocols such as SCTP/TCP for such cases. Note that for such protocols, it is advised to perform the association/ session message exchange between context transfer peers (ARs) in anticipation of handovers (if possible) to accomodate transfer of time-critical feature contexts. I picked part of this one from earlier emails: X.X.3 A feature context specification MUST define the transport to be used. If the feature context is transferred using an IETF transport layer protocol , then the feature context specification MUST include the full details of how the transport layer protocol is used. However, One must note that employing different transport mechanisms for different feature context might lead to limited possibility of multiplexing various feature contexts. Therefore, such details NEED NOT be included in a generic context transfer protocol design. X.X.4 In case a specific functionality (such as sending updates) is not provided by an IETF transport protocol, such functionality MAY be added as an OPTIONAL element to the specific feature context transfer specification. ===================End ======================================= -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, July 31, 2002 3:15 PM To: Nakhjiri Madjid-MNAKHJI1; 'Rajeev Koodli' Cc: seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Madjid, Do you have some specific text you would like to propose regarding the transport? jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'Rajeev Koodli'" Cc: "James Kempf" ; Sent: Wednesday, July 24, 2002 4:20 PM Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications > Rajeev, > > sorry for the delay. see below. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Tuesday, July 23, 2002 4:24 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: James Kempf; seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > - regarding the transport text, if a particular feature indicates UDP/TCP > > or SCTP, isn't that sufficient ? Even if it can provide more information, > > how > > is that going to be useful if it is not supported by the underlying > > transport > > protocol ? > > > > Madjid>> First of all, not everybody and every feature need an advanced > > transport and I know we agree on this. > > However, say in 6 months we are debating an specific feature that does need > > reliability. This text is to protect us from sloppy design. > > If you remember Jeff Schiller saying: Don't come and say use > > IPSec if you want security, you need to work on the security details. > > > > Example of a case which even SCTP is not going to cut it (this is > > answer to your next question as well): say you are sending a very > > dynamic context (packet count or HC context) and you want reliability > > (and you got time to resend stuff...). > > You send the context, but due to do channel conditions don't get it through, > > next time, you have to send updates. This has to come from the feature unit > > and not from transport layer. If had just said use SCTP for reliability that > > would not be a robust design. > > > > When you have to send an update, you do it whether or not SCTP failed to > get it through in the first case, right ? What SCTP or a reliable transport > protocol will offer you is the ability to send a message reliably. When you > have a new message or an update, I agree the feature code has to supply it > (and SCTP has to get to the destination reliably)! > > Madjid>> True, furthermore, if you use a reliable protocol like > SCTP, you need to take extra care with CT, so the receiver doesn't mix up > updates from app. layer, with retx from transport. > > > I hope you are not indicating that each feature has to design its own reliable > transmission protocol. The way each feature uses SCTP or UDP is internal > to the feature, and is not a function of the CT protocol itself. The > CT protocol > should define a set of messages that can be carried over different transport > protocols. > > Madjid>> No, No, however, If we add a set of minimal support (like > what I mentioned above) to the generic protocol, then provide the option > for the feature to use it or not we are covered. > If we completely ignore reliability > completely, we will write off CT as a useful protocol, I think! > > BR, > > Madjid > > Regards, > > -Rajeev > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 2 01:59: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 BAA29978 for ; Fri, 2 Aug 2002 01:59:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24086; Fri, 2 Aug 2002 01:57:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24044 for ; Fri, 2 Aug 2002 01:57:24 -0400 (EDT) Received: from nycsmtp1out.rdc-nyc.rr.com (nycsmtp1out.rdc-nyc.rr.com [24.29.99.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29939 for ; Fri, 2 Aug 2002 01:56:12 -0400 (EDT) Received: from R2D2 (24-90-220-88.nyc.rr.com [24.90.220.88]) by nycsmtp1out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with ESMTP id g725uIZd021736 for ; Fri, 2 Aug 2002 01:56:19 -0400 (EDT) Message-ID: <413-220028525572042@R2D2> From: "LGPro1" To: seamoby@ietf.org Date: Fri, 2 Aug 2002 01:57:20 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA24045 Subject: [Seamoby] Time Share Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Interested in Renting or Selling your Timeshare or Vacation Membership? We can help! For a FREE consultation, simply reply with your name and telephone number. Also include the name of your resort. We will be in touch with you shortly! Have a great day! Removal instructions: ************************* To be removed from this list please reply with "remove" in the subject. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Aug 2 01: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 BAA29989 for ; Fri, 2 Aug 2002 01:59:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA24667 for seamoby-archive@odin.ietf.org; Fri, 2 Aug 2002 02:01:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24086; Fri, 2 Aug 2002 01:57:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24044 for ; Fri, 2 Aug 2002 01:57:24 -0400 (EDT) Received: from nycsmtp1out.rdc-nyc.rr.com (nycsmtp1out.rdc-nyc.rr.com [24.29.99.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29939 for ; Fri, 2 Aug 2002 01:56:12 -0400 (EDT) Received: from R2D2 (24-90-220-88.nyc.rr.com [24.90.220.88]) by nycsmtp1out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with ESMTP id g725uIZd021736 for ; Fri, 2 Aug 2002 01:56:19 -0400 (EDT) Message-ID: <413-220028525572042@R2D2> From: "LGPro1" To: seamoby@ietf.org Date: Fri, 2 Aug 2002 01:57:20 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA24045 Subject: [Seamoby] Time Share Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Interested in Renting or Selling your Timeshare or Vacation Membership? We can help! For a FREE consultation, simply reply with your name and telephone number. Also include the name of your resort. We will be in touch with you shortly! Have a great day! Removal instructions: ************************* To be removed from this list please reply with "remove" in the subject. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Aug 4 17:32: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 RAA13140 for ; Sun, 4 Aug 2002 17:32:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10364; Sun, 4 Aug 2002 17:31:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10321 for ; Sun, 4 Aug 2002 17:31:15 -0400 (EDT) Received: from XP (host213-1-38-118.webport.bt.net [213.1.38.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13085 for ; Sun, 4 Aug 2002 17:29:56 -0400 (EDT) From: worldsubmit@freeuk.com Message-Id: <200208042129.RAA13085@ietf.org> To: seamoby@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_2rfkindysadvnqw3nerasdf"; charset="US-ASCII" MIME-Version: 1.0 Reply-To: worldsubmit@freeuk.com Date: Sun, 4 Aug 2002 22:31:14 +0100 X-Priority: 1 X-Library: Indy 9.0.3-B X-Mailer: XMailer-2002 Subject: [Seamoby] Drive Traffic to Your Website NOW ! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_2rfkindysadvnqw3nerasdf Content-Type: text/html Content-Transfer-Encoding: quoted-printable Global Services : Priority Search Engine Submission</= TITLE> <META http-equiv=3DContent-Language content=3Den-gb> <META content=3D"Microsoft FrontPage 5.0" name=3DGENERATOR> <META content=3DFrontPage.Editor.Document name=3DProgId> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-= 1252"></HEAD> <BODY vLink=3D#0000ff aLink=3D#0000ff link=3D#0000ff bgColor=3D#ffffff> = <DIV align=3Dcenter> <CENTER> <TABLE height=3D89 cellPadding=3D4 width=3D775 border=3D0> <TBODY> <TR> <TD width=3D"100%" background=3Dhttp://www.secure-siteserver.com/wor= ldsubmit/map.gif height=3D87> <table border=3D"0" cellpadding=3D"5" cellspacing=3D"1" width=3D"1= 00%" height=3D"90"> <tr> <td width=3D"50%" height=3D"79" valign=3D"top"><i><b> <font face=3D"Arial" size=3D"7" color=3D"#FFFF00">World Submit= </font></b></i></td> <td width=3D"50%" height=3D"79" valign=3D"bottom"> <p align=3D"right"><b><font face=3D"Arial" color=3D"#FFFFFF">P= riority Search=20 Engine Submission</font></b></td> </tr> </table> =20 </TD></TR></TBODY></TABLE></CENTER></DIV> <DIV align=3Dcenter> <CENTER> <TABLE cellPadding=3D4 width=3D775 border=3D0> <TBODY> <TR> <TD vAlign=3Dtop width=3D"100%"> <p align=3D"right"><font face=3D"Arial"><span class=3D"subnavitem"= > <a href=3D"https://www.secure-siteserver.com/worldsubmit/index.htm= l">Home</a> | <a href=3D"https://www.secure-siteserver.com/worldsubmit/facts.htm= l">Facts</a></span>=20 | <a href=3D"https://www.secure-siteserver.com/worldsubmit/faq.htm= l">FAQ</a> <span class=3D"selected_subnavitem"> | </span> <a target=3D"_top" href=3D"https://www.secure-siteserver.com/world= submit/tos.html">Terms=20 of Service</a></font> <P align=3Dleft><B><FONT face=3DArial color=3D#800000 size=3D5>Dri= ve Traffic to=20 Your Web Site</FONT></B></P><FONT face=3DArial> <TABLE> <TBODY> <TR> <TD vAlign=3Dtop width=3D"1%"> <IMG height=3D100=20 src=3D"http://www.secure-siteserver.com/worldsubmit/rollover= 3.gif" width=3D100 border=3D0></TD> <TD vAlign=3Dtop> <UL> <TABLE> <TBODY> <TR> <TD><FONT face=3DArial size=3D4>48 Hour Inclusion to A= OL, MSN,=20 Overture (formerly GoTo), HotBot, iWon and Other Ink= tomi=20 Search Partners. </FONT></TD></TR> <TR> <TD><FONT face=3DArial color=3D#000060 size=3D2><B>Pow= ered by=20 Inktomi Search=20 Submit</B></FONT></TD></TR></TBODY></TABLE></UL></TD></TR></TBOD= Y></TABLE> <P> <IMG height=3D265 alt=3D"Inktomi Partners" src=3D"http://www.secur= e-siteserver.com/worldsubmit/sesshots.gif"=20 width=3D220 align=3Dright border=3D0><B><FONT color=3D#000080>Mass= =20 Exposure</FONT><FONT face=3DArial color=3D#000080><BR></FONT></B>S= erving over=20 82 million search requests a day, a listing with Inktomi can drama= tically=20 increase your website traffic, by ensuring your web pages are list= ed in=20 the search results of all engines using the Inktomi index. This in= cludes=20 portals such as AOL, MSN, Overture (formerly GoTo), iWON, HotBot,=20= About.com, Anzwers, chello, c|net, Eoexchange, Espotting.com, Goo,= =20 LookSmart, MobilCom,  NBCi  and many others. </P> <P><B><FONT face=3DArial color=3D#000080>Rapid Inclusion<BR></FONT= ></B>This=20 priority service ensures that your URL is added to the Inktomi ind= ex=20 within 5 working days. The link will be added to all Inktomi index= es and=20 reflected across all Inktomi portal sites. (excluding non-English = regional=20 portals). URL's submitted via other free URL submission services c= an take=20 up to 3 - 6 months to be indexed without any guarantees. </P> <P><B><FONT face=3DArial color=3D#000080>Frequent Updates<BR></FON= T></B>Your=20 web pages will be refreshed every 48 hours. This means that any ch= ange you=20 make to your web page, will be reflected in the search index withi= n two=20 days. You can thus modify your page to fine tune the relevancy and= improve=20 your search engine ranking. All without the need to re-submit your= URL all=20 the time. </P> <P><B><FONT face=3DArial color=3D#000080>No Dropouts<BR></FONT></B= >Due to the=20 48 hour re-indexing, your website URL will remain in the index for= the=20 whole 12 month subscription period. This means that there is no ne= ed to=20 worry about having your URL dropped from the search engines, which= can=20 happen regularly with other search engine placement services. </P>= <P><B><FONT face=3DArial color=3D#000080>Cost Savings<BR></FONT></= B>Search=20 engine placement is the most cost effective way to attract new vis= itors to=20 your web site. Companies spend thousands of dollars in online adve= rtising=20 to attract new customers to their web sites. A well placed search = engine=20 listing can be thousand times more cost effective in comparison to= =20 traditional banner advertising. <BR> </P> <P><B>Price</B></P> <TABLE cellPadding=3D4> <TBODY> <TR class=3Dstitle> <TD><B>Quantity</B></TD> <TD><B>Price per URL</B></TD></TR> <TR class=3Dslist> <TD>Each URL </TD> <TD><FONT color=3D#ff0000=20 size=3D4><B>=A379.97</B>(GBP)</FONT><B>/year</B></TD></TR></TB= ODY></TABLE> <P><B>Add URL</B></P> <P><B><A=20 href=3D"https://www.secure-siteserver.com/worldsubmit/order-form.h= tml"> <font size=3D"4">CLICK=20 HERE</font></A></B><font size=3D"4"> to ADD your URL now!</font><B= R> </P></FONT> <P align=3Dright><FONT class=3Dsmall face=3DArial><A=20 href=3D"https://www.secure-siteserver.com/worldsubmit/#top">Back t= o=20 Top</A></FONT></P></TD></TR> <TR> <TD vAlign=3Dtop width=3D"100%"> <HR color=3D#000000 SIZE=3D1> </TD></TR> <TR> <TD vAlign=3Dtop width=3D"100%"> <table border=3D"0" cellspacing=3D"1" width=3D"100%"> <tr> <td width=3D"50%" valign=3D"top"><font face=3D"Arial">Email: <a href=3D"mailto:worldsubmit@freeuk.com">worldsubmit@freeuk.com</a>= <br> Fax: + 44 (0)8704 602504 (24hrs)</font></td> <td width=3D"50%" valign=3D"top"> <p align=3D"right"><font face=3D"Arial" size=3D"2"> <img src=3D"http://www.secure-siteserver.com/worldsubmit/multi= -cards.jpg" border=3D"0" alt=3D"We Accept All Major Credit/Debit Cards">= </font></td> </tr> </table> </TD></TR></TBODY></TABLE></CENTER></DIV></BODY></HTML> --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ................................... --=_NextPart_2rfkindysadvnqw3nerasdf-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Aug 4 18:24: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 RAA13148 for <seamoby-archive@odin.ietf.org>; Sun, 4 Aug 2002 17:32:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA10444 for seamoby-archive@odin.ietf.org; Sun, 4 Aug 2002 17:33:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10364; Sun, 4 Aug 2002 17:31:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10321 for <seamoby@optimus.ietf.org>; Sun, 4 Aug 2002 17:31:15 -0400 (EDT) Received: from XP (host213-1-38-118.webport.bt.net [213.1.38.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13085 for <seamoby@ietf.org>; Sun, 4 Aug 2002 17:29:56 -0400 (EDT) From: worldsubmit@freeuk.com Message-Id: <200208042129.RAA13085@ietf.org> To: seamoby@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_2rfkindysadvnqw3nerasdf"; charset="US-ASCII" MIME-Version: 1.0 Reply-To: worldsubmit@freeuk.com Date: Sun, 4 Aug 2002 22:31:14 +0100 X-Priority: 1 X-Library: Indy 9.0.3-B X-Mailer: XMailer-2002 Subject: [Seamoby] Drive Traffic to Your Website NOW ! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org> X-BeenThere: seamoby@ietf.org This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <!-- saved from url=3D(0046)https://www.secure-siteserver.com/worldsubmi= t/ --> <HTML><HEAD><TITLE>Global Services : Priority Search Engine Submission</= TITLE> <META http-equiv=3DContent-Language content=3Den-gb> <META content=3D"Microsoft FrontPage 5.0" name=3DGENERATOR> <META content=3DFrontPage.Editor.Document name=3DProgId> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-= 1252"></HEAD> <BODY vLink=3D#0000ff aLink=3D#0000ff link=3D#0000ff bgColor=3D#ffffff> = <DIV align=3Dcenter> <CENTER> <TABLE height=3D89 cellPadding=3D4 width=3D775 border=3D0> <TBODY> <TR> <TD width=3D"100%" background=3Dhttp://www.secure-siteserver.com/wor= ldsubmit/map.gif height=3D87> <table border=3D"0" cellpadding=3D"5" cellspacing=3D"1" width=3D"1= 00%" height=3D"90"> <tr> <td width=3D"50%" height=3D"79" valign=3D"top"><i><b> <font face=3D"Arial" size=3D"7" color=3D"#FFFF00">World Submit= </font></b></i></td> <td width=3D"50%" height=3D"79" valign=3D"bottom"> <p align=3D"right"><b><font face=3D"Arial" color=3D"#FFFFFF">P= riority Search=20 Engine Submission</font></b></td> </tr> </table> =20 </TD></TR></TBODY></TABLE></CENTER></DIV> <DIV align=3Dcenter> <CENTER> <TABLE cellPadding=3D4 width=3D775 border=3D0> <TBODY> <TR> <TD vAlign=3Dtop width=3D"100%"> <p align=3D"right"><font face=3D"Arial"><span class=3D"subnavitem"= > <a href=3D"https://www.secure-siteserver.com/worldsubmit/index.htm= l">Home</a> | <a href=3D"https://www.secure-siteserver.com/worldsubmit/facts.htm= l">Facts</a></span>=20 | <a href=3D"https://www.secure-siteserver.com/worldsubmit/faq.htm= l">FAQ</a> <span class=3D"selected_subnavitem"> | </span> <a target=3D"_top" href=3D"https://www.secure-siteserver.com/world= submit/tos.html">Terms=20 of Service</a></font> <P align=3Dleft><B><FONT face=3DArial color=3D#800000 size=3D5>Dri= ve Traffic to=20 Your Web Site</FONT></B></P><FONT face=3DArial> <TABLE> <TBODY> <TR> <TD vAlign=3Dtop width=3D"1%"> <IMG height=3D100=20 src=3D"http://www.secure-siteserver.com/worldsubmit/rollover= 3.gif" width=3D100 border=3D0></TD> <TD vAlign=3Dtop> <UL> <TABLE> <TBODY> <TR> <TD><FONT face=3DArial size=3D4>48 Hour Inclusion to A= OL, MSN,=20 Overture (formerly GoTo), HotBot, iWon and Other Ink= tomi=20 Search Partners. </FONT></TD></TR> <TR> <TD><FONT face=3DArial color=3D#000060 size=3D2><B>Pow= ered by=20 Inktomi Search=20 Submit</B></FONT></TD></TR></TBODY></TABLE></UL></TD></TR></TBOD= Y></TABLE> <P> <IMG height=3D265 alt=3D"Inktomi Partners" src=3D"http://www.secur= e-siteserver.com/worldsubmit/sesshots.gif"=20 width=3D220 align=3Dright border=3D0><B><FONT color=3D#000080>Mass= =20 Exposure</FONT><FONT face=3DArial color=3D#000080><BR></FONT></B>S= erving over=20 82 million search requests a day, a listing with Inktomi can drama= tically=20 increase your website traffic, by ensuring your web pages are list= ed in=20 the search results of all engines using the Inktomi index. This in= cludes=20 portals such as AOL, MSN, Overture (formerly GoTo), iWON, HotBot,=20= About.com, Anzwers, chello, c|net, Eoexchange, Espotting.com, Goo,= =20 LookSmart, MobilCom,  NBCi  and many others. </P> <P><B><FONT face=3DArial color=3D#000080>Rapid Inclusion<BR></FONT= ></B>This=20 priority service ensures that your URL is added to the Inktomi ind= ex=20 within 5 working days. The link will be added to all Inktomi index= es and=20 reflected across all Inktomi portal sites. (excluding non-English = regional=20 portals). URL's submitted via other free URL submission services c= an take=20 up to 3 - 6 months to be indexed without any guarantees. </P> <P><B><FONT face=3DArial color=3D#000080>Frequent Updates<BR></FON= T></B>Your=20 web pages will be refreshed every 48 hours. This means that any ch= ange you=20 make to your web page, will be reflected in the search index withi= n two=20 days. You can thus modify your page to fine tune the relevancy and= improve=20 your search engine ranking. All without the need to re-submit your= URL all=20 the time. </P> <P><B><FONT face=3DArial color=3D#000080>No Dropouts<BR></FONT></B= >Due to the=20 48 hour re-indexing, your website URL will remain in the index for= the=20 whole 12 month subscription period. This means that there is no ne= ed to=20 worry about having your URL dropped from the search engines, which= can=20 happen regularly with other search engine placement services. </P>= <P><B><FONT face=3DArial color=3D#000080>Cost Savings<BR></FONT></= B>Search=20 engine placement is the most cost effective way to attract new vis= itors to=20 your web site. Companies spend thousands of dollars in online adve= rtising=20 to attract new customers to their web sites. A well placed search = engine=20 listing can be thousand times more cost effective in comparison to= =20 traditional banner advertising. <BR> </P> <P><B>Price</B></P> <TABLE cellPadding=3D4> <TBODY> <TR class=3Dstitle> <TD><B>Quantity</B></TD> <TD><B>Price per URL</B></TD></TR> <TR class=3Dslist> <TD>Each URL </TD> <TD><FONT color=3D#ff0000=20 size=3D4><B>=A379.97</B>(GBP)</FONT><B>/year</B></TD></TR></TB= ODY></TABLE> <P><B>Add URL</B></P> <P><B><A=20 href=3D"https://www.secure-siteserver.com/worldsubmit/order-form.h= tml"> <font size=3D"4">CLICK=20 HERE</font></A></B><font size=3D"4"> to ADD your URL now!</font><B= R> </P></FONT> <P align=3Dright><FONT class=3Dsmall face=3DArial><A=20 href=3D"https://www.secure-siteserver.com/worldsubmit/#top">Back t= o=20 Top</A></FONT></P></TD></TR> <TR> <TD vAlign=3Dtop width=3D"100%"> <HR color=3D#000000 SIZE=3D1> </TD></TR> <TR> <TD vAlign=3Dtop width=3D"100%"> <table border=3D"0" cellspacing=3D"1" width=3D"100%"> <tr> <td width=3D"50%" valign=3D"top"><font face=3D"Arial">Email: <a href=3D"mailto:worldsubmit@freeuk.com">worldsubmit@freeuk.com</a>= <br> Fax: + 44 (0)8704 602504 (24hrs)</font></td> <td width=3D"50%" valign=3D"top"> <p align=3D"right"><font face=3D"Arial" size=3D"2"> <img src=3D"http://www.secure-siteserver.com/worldsubmit/multi= -cards.jpg" border=3D"0" alt=3D"We Accept All Major Credit/Debit Cards">= </font></td> </tr> </table> </TD></TR></TBODY></TABLE></CENTER></DIV></BODY></HTML> --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ................................... --=_NextPart_2rfkindysadvnqw3nerasdf-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Aug 4 22:53: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 WAA19636 for <seamoby-archive@odin.ietf.org>; Sun, 4 Aug 2002 22:53:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23348; Sun, 4 Aug 2002 22:48:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23315 for <seamoby@optimus.ietf.org>; Sun, 4 Aug 2002 22:47:59 -0400 (EDT) Received: from freeuk.com (host213-1-6-194.webport.bt.net [213.1.6.194]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19362 for <seamoby@ietf.org>; Sun, 4 Aug 2002 22:46:35 -0400 (EDT) From: "World Submit" <worldsubmit@freeuk.com> To: "Seamoby" <seamoby@ietf.org> Date: Mon, 5 Aug 2002 03:47:41 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <340495117651288@freeuk.com> Reply-To: "World Submit" <worldsubmit@freeuk.com> Organization: World Submit X-Mailer: Internet Mail Service Content-Type: multipart/alternative; boundary="----_NextPart_811255073173136" Subject: [Seamoby] Drive Traffic To Your Website NOW ! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org> X-BeenThere: seamoby@ietf.org This is a multi-part message in MIME format. ------_NextPart_811255073173136 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE Your Email Client does not support MIME encoding. Please upgrade to MIME-enabled Email Client (almost every modern Email Client is MIME-capable). ------_NextPart_811255073173136 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <!-- saved from url=3D(0046)https://www.secure-siteserver.com/worldsubmit/ --> <HTML><HEAD><TITLE>Global Services : Priority Search Engine Submission
World Submit

Priority Search Engine Submission

Home | Facts | FAQ | Terms of Service

Drive Traffic to Your Web Site

    48 Hour Inclusion to AOL, MSN, Overture (formerly GoTo), HotBot, iWon and Other Inktomi Search Partners.
    Powered by Inktomi Search Submit

3D"InktomiMass Exposure
Serving over 82 million search requests a day, a listing with Inktomi can dramatically increase your website traffic, by ensuring your web pages are listed in the search results of all engines using the Inktomi index. This includes portals such as AOL, MSN, Overture (formerly GoTo), iWON, HotBot, About.com, Anzwers, chello, c|net, Eoexchange, Espotting.com, Goo, LookSmart, MobilCom,  NBCi  and many others.

Rapid Inclusion
This priority service ensures that your URL is added to the Inktomi index within 5 working days. The link will be added to all Inktomi indexes and reflected across all Inktomi portal sites. (excluding non-English regional portals). URL's submitted via other free URL submission services can take up to 3 - 6 months to be indexed without any guarantees.

Frequent Updates
Your web pages will be refreshed every 48 hours. This means that any change you make to your web page, will be reflected in the search index within two days. You can thus modify your page to fine tune the relevancy and improve your search engine ranking. All without the need to re-submit your URL all the time.

No Dropouts
Due to the 48 hour re-indexing, your website URL will remain in the index for the whole 12 month subscription period. This means that there is no need to worry about having your URL dropped from the search engines, which can happen regularly with other search engine placement services.

Cost Savings
Search engine placement is the most cost effective way to attract new visitors to your web site. Companies spend thousands of dollars in online advertising to attract new customers to their web sites. A well placed search engine listing can be thousand times more cost effective in comparison to traditional banner advertising.
 

Price

Quantity Price per URL
Each URL =A379.97(GBP)/year

Add URL

CLICK HERE to ADD your URL now!
 

Back to Top

Email: worldsubmit@freeuk.com
Fax: + 44 (0)8704 602504 (24hrs)

3D"We
------_NextPart_811255073173136-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Aug 4 22:53: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 WAA19643 for ; Sun, 4 Aug 2002 22:53:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA23527 for seamoby-archive@odin.ietf.org; Sun, 4 Aug 2002 22:54:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23348; Sun, 4 Aug 2002 22:48:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23315 for ; Sun, 4 Aug 2002 22:47:59 -0400 (EDT) Received: from freeuk.com (host213-1-6-194.webport.bt.net [213.1.6.194]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19362 for ; Sun, 4 Aug 2002 22:46:35 -0400 (EDT) From: "World Submit" To: "Seamoby" Date: Mon, 5 Aug 2002 03:47:41 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <340495117651288@freeuk.com> Reply-To: "World Submit" Organization: World Submit X-Mailer: Internet Mail Service Content-Type: multipart/alternative; boundary="----_NextPart_811255073173136" Subject: [Seamoby] Drive Traffic To Your Website NOW ! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_811255073173136 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE Your Email Client does not support MIME encoding. Please upgrade to MIME-enabled Email Client (almost every modern Email Client is MIME-capable). ------_NextPart_811255073173136 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE Global Services : Priority Search Engine Submission
World Submit

Priority Search Engine Submission

Home | Facts | FAQ | Terms of Service

Drive Traffic to Your Web Site

    48 Hour Inclusion to AOL, MSN, Overture (formerly GoTo), HotBot, iWon and Other Inktomi Search Partners.
    Powered by Inktomi Search Submit

3D"InktomiMass Exposure
Serving over 82 million search requests a day, a listing with Inktomi can dramatically increase your website traffic, by ensuring your web pages are listed in the search results of all engines using the Inktomi index. This includes portals such as AOL, MSN, Overture (formerly GoTo), iWON, HotBot, About.com, Anzwers, chello, c|net, Eoexchange, Espotting.com, Goo, LookSmart, MobilCom,  NBCi  and many others.

Rapid Inclusion
This priority service ensures that your URL is added to the Inktomi index within 5 working days. The link will be added to all Inktomi indexes and reflected across all Inktomi portal sites. (excluding non-English regional portals). URL's submitted via other free URL submission services can take up to 3 - 6 months to be indexed without any guarantees.

Frequent Updates
Your web pages will be refreshed every 48 hours. This means that any change you make to your web page, will be reflected in the search index within two days. You can thus modify your page to fine tune the relevancy and improve your search engine ranking. All without the need to re-submit your URL all the time.

No Dropouts
Due to the 48 hour re-indexing, your website URL will remain in the index for the whole 12 month subscription period. This means that there is no need to worry about having your URL dropped from the search engines, which can happen regularly with other search engine placement services.

Cost Savings
Search engine placement is the most cost effective way to attract new visitors to your web site. Companies spend thousands of dollars in online advertising to attract new customers to their web sites. A well placed search engine listing can be thousand times more cost effective in comparison to traditional banner advertising.
 

Price

Quantity Price per URL
Each URL =A379.97(GBP)/year

Add URL

CLICK HERE to ADD your URL now!
 

Back to Top

Email: worldsubmit@freeuk.com
Fax: + 44 (0)8704 602504 (24hrs)

3D"We
------_NextPart_811255073173136-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 5 07:50: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 HAA08662 for ; Mon, 5 Aug 2002 07:50:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27128; Mon, 5 Aug 2002 07:44:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27098 for ; Mon, 5 Aug 2002 07:44:33 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08255; Mon, 5 Aug 2002 07:43:19 -0400 (EDT) Message-Id: <200208051143.HAA08255@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, 05 Aug 2002 07:43:19 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-card-requirements-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Requirements for CAR Discovery Protocols Author(s) : G. Krishnamurthi Filename : draft-ietf-seamoby-card-requirements-01.txt Pages : 6 Date : 02-Aug-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 any solution for CAR Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-requirements-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-card-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-card-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020802150821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-card-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-card-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020802150821.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 5 07:50: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 HAA08669 for ; Mon, 5 Aug 2002 07:50:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA27352 for seamoby-archive@odin.ietf.org; Mon, 5 Aug 2002 07:51:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27128; Mon, 5 Aug 2002 07:44:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27098 for ; Mon, 5 Aug 2002 07:44:33 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08255; Mon, 5 Aug 2002 07:43:19 -0400 (EDT) Message-Id: <200208051143.HAA08255@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, 05 Aug 2002 07:43:19 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-card-requirements-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Requirements for CAR Discovery Protocols Author(s) : G. Krishnamurthi Filename : draft-ietf-seamoby-card-requirements-01.txt Pages : 6 Date : 02-Aug-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 any solution for CAR Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-requirements-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-card-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-card-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020802150821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-card-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-card-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020802150821.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 6 07:29: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 HAA05305 for ; Tue, 6 Aug 2002 07:29:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25567; Tue, 6 Aug 2002 07:25:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25404 for ; Tue, 6 Aug 2002 07:25:13 -0400 (EDT) Received: from africamail.com (66-178-46-224.newskies.net [66.178.46.224] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04842 for ; Tue, 6 Aug 2002 07:23:30 -0400 (EDT) Message-Id: <200208061123.HAA04842@ietf.org> From: "DR GARUBA UMAR" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 6 Aug 2002 12:25:28 +0100 Content-Transfer-Encoding: 8bit Subject: [Seamoby] SEEKING IMMIDIATE ASSISTANCE AND PARTHNERSHIP Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Fro m the de sk of: DR . GAR BA UMA R Tel No : You r Int l. Acc ess Co de + 234 9 272 720 1 E-F AX : +17 752 561 718 +1 77 5-2 69- 702 8 Ema il: um arg aru ba@ ade xec .co m gar uba uma r@a fri cam ail .co m gar uba uma r@a dex ec. com Lag os, Ni ger ia. Dea r Sir , REQ UES T FOR AN UR GEN T CON FID ENT IAL BU SIN ESS RE LAT ION SHI P Aft er due de lib era tio n wit h my col lea gue s, I hav e dec ide d to for war d to you th is bus ine ss pro pos al. We wa nt a rel iab le per son wh o cou ld ass ist us to tr ans fer th e sum of Tw ent y Mil lio n Fiv e Hun dre d Tho usa nd Uni ted St ate s Dol lar s ($2 0,5 00, 000 ) int o his / her ac cou nt. Thi s fun d res ult ed fro m an ove r-i nvo ice d bil l fro m con tra cts aw ard ed by us und er the bu dge t all oca tio n to my Min ist ry and th is bil l has be en app rov ed for pa yme nt by the co nce rne d aut hor iti es. Th e con tra ct has si nce be en exe cut ed, co mmi ssi one d and th e con tra cto r was pa id the ac tua l cos t of the co ntr act . We are le ft wit h the ba lan ce US$ 20. 5M as par t of the ov er- inv oic ed amo unt wh ich we ha ve del ibe rat ely ov er est ima ted fo r our ow n use . But un der ou r pro toc ol div isi on, ci vil se rva nts ar e for bid den to op era te or own fo rei gn acc oun ts. Thi s is why I am con tac tin g you to be ou r cus tod ian fo r thi s fun d. As you ma y wan t to kno w and to ma ke you le ss cur iou s, I got yo ur add res s fro m a sit e in the in ter net th at por tra yed yo u (yo ur est abl ish men t) in goo d lig ht. I am the Ch ief Ac cou nta nt/ Int ern al Aud ito r of the Co ntr act Aw ard Co mmi tte e (C. A.C .) of the Ni ger ian Na tio nal Pe tro leu mCo rpo rat ion (NN PC) . Thi s tra nsa cti on is ver y muc h fre e fro m all so rts of RI SKS an d TRO UBL E fro m my Gov ern men t. We the N. N.P .C. Of fic ial s inv olv ed in thi s dea l hav e put in ma ny yea rs in ser vic e to thi s Min ist ry. We ha ve bee n exe rci sin g pat ien ce for th is opp ort uni ty for so lo ng and to us , thi s is a lif e tim e opp ort uni ty we can not af for d to mis s. You ne ed not to wo rry ab out th e res pon sib ili tie s of tra nsf err ing th is fun d int o you r acc oun t, bec aus e all th e adm ini str ati ve ste p nee ded fo r the tr ans fer of th is fun d int o you r des ign ate d ban kac cou nt wil l be don e by me. We hav e agr eed to CO MPE NSA TE you du ly ifa gre eme nt is rea che d by bot h of us. My col lea gue an d I wil l com e to you r cou ntr y to arr ang e for ou r sha re, upo n the co nfi rma tio n fro m you th at the mo ney ha s bee n cre dit ed int o you r nom ina ted ba nk acc oun t. Con seq uen t upo n you r acc ept anc e of thi s pro pos al, ki ndl y con fir m you r int ere st by sen din g me a rev ert em ail vi a the ema il acc oun ts bel ow (ga rub aum ar@ afr ica mai l.c om) Yo ur ind ica tio n by rev ert em ail to me of yo ur sin cer e and se rio us int ere st wil l ena ble me sen d you th e PRO CED URE FO R OPE RAT ION . NOT E: In the ev ent of yo ur ina bil ity to ha ndl e thi s tra nsa cti on ple ase in for m us so tha t we can lo ok for an oth er rel iab le per son wh o can ass ist in th is res pec t. It mig ht sur pri se you wh y we cho ose yo u and tr ust ed you fo r thi s tra nsa cti on. Ye s, we bel iev e tha t goo d fri end s can be di sco ver ed and bus ine ss lik e thi s can no t be exe cut ed wit hou t tru st. Th is is why we hav e dec ide d to tru st you fo r thi s tra nsa cti on. We ar e loo kin g for war d to doi ng thi s tra nsa cti on wit h you . Be fur the r inf orm ed tha t eve ryb ody ÷Õ int ere st and se cur ity ha d bee n con sid ere d bef ore yo u wer e con tac ted , so be res t ass ure d and fe el fre e to go int o thi s tra nsa cti on wit h us. Bu t let Ho nes tya nd Tru st be our wa tch wor d thr oug hou t thi s tra nsa cti on and yo ur pro mpt re ply wi ll be hig hly ap pre cia ted . Tha nk you an d God bl ess . Bes t Reg ard s, DR. GA RUB A UMA R. Ple ase re ply th is mai l via th e abo ve lis ted e- mai l add res ses (ga rub aum ar@ afr ica mai l.c om) for co nfi den tia l rea son s. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 6 07:29: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 HAA05314 for ; Tue, 6 Aug 2002 07:29:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA27122 for seamoby-archive@odin.ietf.org; Tue, 6 Aug 2002 07:31:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25567; Tue, 6 Aug 2002 07:25:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25404 for ; Tue, 6 Aug 2002 07:25:13 -0400 (EDT) Received: from africamail.com (66-178-46-224.newskies.net [66.178.46.224] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04842 for ; Tue, 6 Aug 2002 07:23:30 -0400 (EDT) Message-Id: <200208061123.HAA04842@ietf.org> From: "DR GARUBA UMAR" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 6 Aug 2002 12:25:28 +0100 Content-Transfer-Encoding: 8bit Subject: [Seamoby] SEEKING IMMIDIATE ASSISTANCE AND PARTHNERSHIP Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Fro m the de sk of: DR . GAR BA UMA R Tel No : You r Int l. Acc ess Co de + 234 9 272 720 1 E-F AX : +17 752 561 718 +1 77 5-2 69- 702 8 Ema il: um arg aru ba@ ade xec .co m gar uba uma r@a fri cam ail .co m gar uba uma r@a dex ec. com Lag os, Ni ger ia. Dea r Sir , REQ UES T FOR AN UR GEN T CON FID ENT IAL BU SIN ESS RE LAT ION SHI P Aft er due de lib era tio n wit h my col lea gue s, I hav e dec ide d to for war d to you th is bus ine ss pro pos al. We wa nt a rel iab le per son wh o cou ld ass ist us to tr ans fer th e sum of Tw ent y Mil lio n Fiv e Hun dre d Tho usa nd Uni ted St ate s Dol lar s ($2 0,5 00, 000 ) int o his / her ac cou nt. Thi s fun d res ult ed fro m an ove r-i nvo ice d bil l fro m con tra cts aw ard ed by us und er the bu dge t all oca tio n to my Min ist ry and th is bil l has be en app rov ed for pa yme nt by the co nce rne d aut hor iti es. Th e con tra ct has si nce be en exe cut ed, co mmi ssi one d and th e con tra cto r was pa id the ac tua l cos t of the co ntr act . We are le ft wit h the ba lan ce US$ 20. 5M as par t of the ov er- inv oic ed amo unt wh ich we ha ve del ibe rat ely ov er est ima ted fo r our ow n use . But un der ou r pro toc ol div isi on, ci vil se rva nts ar e for bid den to op era te or own fo rei gn acc oun ts. Thi s is why I am con tac tin g you to be ou r cus tod ian fo r thi s fun d. As you ma y wan t to kno w and to ma ke you le ss cur iou s, I got yo ur add res s fro m a sit e in the in ter net th at por tra yed yo u (yo ur est abl ish men t) in goo d lig ht. I am the Ch ief Ac cou nta nt/ Int ern al Aud ito r of the Co ntr act Aw ard Co mmi tte e (C. A.C .) of the Ni ger ian Na tio nal Pe tro leu mCo rpo rat ion (NN PC) . Thi s tra nsa cti on is ver y muc h fre e fro m all so rts of RI SKS an d TRO UBL E fro m my Gov ern men t. We the N. N.P .C. Of fic ial s inv olv ed in thi s dea l hav e put in ma ny yea rs in ser vic e to thi s Min ist ry. We ha ve bee n exe rci sin g pat ien ce for th is opp ort uni ty for so lo ng and to us , thi s is a lif e tim e opp ort uni ty we can not af for d to mis s. You ne ed not to wo rry ab out th e res pon sib ili tie s of tra nsf err ing th is fun d int o you r acc oun t, bec aus e all th e adm ini str ati ve ste p nee ded fo r the tr ans fer of th is fun d int o you r des ign ate d ban kac cou nt wil l be don e by me. We hav e agr eed to CO MPE NSA TE you du ly ifa gre eme nt is rea che d by bot h of us. My col lea gue an d I wil l com e to you r cou ntr y to arr ang e for ou r sha re, upo n the co nfi rma tio n fro m you th at the mo ney ha s bee n cre dit ed int o you r nom ina ted ba nk acc oun t. Con seq uen t upo n you r acc ept anc e of thi s pro pos al, ki ndl y con fir m you r int ere st by sen din g me a rev ert em ail vi a the ema il acc oun ts bel ow (ga rub aum ar@ afr ica mai l.c om) Yo ur ind ica tio n by rev ert em ail to me of yo ur sin cer e and se rio us int ere st wil l ena ble me sen d you th e PRO CED URE FO R OPE RAT ION . NOT E: In the ev ent of yo ur ina bil ity to ha ndl e thi s tra nsa cti on ple ase in for m us so tha t we can lo ok for an oth er rel iab le per son wh o can ass ist in th is res pec t. It mig ht sur pri se you wh y we cho ose yo u and tr ust ed you fo r thi s tra nsa cti on. Ye s, we bel iev e tha t goo d fri end s can be di sco ver ed and bus ine ss lik e thi s can no t be exe cut ed wit hou t tru st. Th is is why we hav e dec ide d to tru st you fo r thi s tra nsa cti on. We ar e loo kin g for war d to doi ng thi s tra nsa cti on wit h you . Be fur the r inf orm ed tha t eve ryb ody ÷Õ int ere st and se cur ity ha d bee n con sid ere d bef ore yo u wer e con tac ted , so be res t ass ure d and fe el fre e to go int o thi s tra nsa cti on wit h us. Bu t let Ho nes tya nd Tru st be our wa tch wor d thr oug hou t thi s tra nsa cti on and yo ur pro mpt re ply wi ll be hig hly ap pre cia ted . Tha nk you an d God bl ess . Bes t Reg ard s, DR. GA RUB A UMA R. Ple ase re ply th is mai l via th e abo ve lis ted e- mai l add res ses (ga rub aum ar@ afr ica mai l.c om) for co nfi den tia l rea son s. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 6 12:17: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 MAA16730 for ; Tue, 6 Aug 2002 12:17:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14876; Tue, 6 Aug 2002 12:14:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14847 for ; Tue, 6 Aug 2002 12:14:08 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16583 for ; Tue, 6 Aug 2002 12:12:56 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76GDCo25925; Tue, 6 Aug 2002 12:13:13 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 12:13:13 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C52@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Date: Tue, 6 Aug 2002 12:13:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D64.273587DE" Subject: [Seamoby] RE: Section 5.5 Modifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23D64.273587DE Content-Type: text/plain; charset="iso-8859-1" Madjid: Fine, replace "before" with "proactive". I still use the term "proactive" because I never associated it with the triggers (and neither did the original wording in the draft). To sum up, the whole purpose of CT is to attempt to prepare the destination AR *before* a handover occurs and the destination AR has to forward it's first packet to/from the roaming MN. Performing CT *during* or *after* a handover has been initiated, particularly after the MN's packets have begun arriving at the destination AR is a necessary capability, but the potential performance improvements are not as great. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: July 22, 2002 11:37 > To: 'James Kempf'; Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri > Madjid-MNAKHJI1; seamoby@ietf.org > Subject: RE: Section 5.5 Modifications > > > Well, I am maybe not as good of a boy scout as some others > but, I remember 3 weeks of debate, followed by a period > of 2 months of silence and then a 90 minute discussion in London > (not to mention the 3$K trip expense :) ) > that lead to us not making reactive > or proactive CT as a basis for the CT usefulness debate. > Lets not open that barrel of snakes (certainly bigger than > worms) again. > > If you want to mention proactive a byproduct, or use case, > that is fine. > But I think we should be careful about making a byproduct a > primary goal. > > > Regards, > > Madjid > > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, July 19, 2002 7:47 PM > To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; seamoby@ietf.org > Subject: Section 5.5 Modifications > > > Hi Gary, > > > I get the impression that either everyone has forgotten > about proactive > > CT, or does > > not care. Which is too bad, for the boy scouts are right on > when they say > > "be prepared". > > > > Thanx for reminding me, being an old Boy Scout myself I should have > remembered. > :-) > > How about if we modify the text I sent out as below? In > addition, I think we > need an additional section, which I will post on a separate > thread, that > describes the steps needed to standardize a feature context. > This text will > include a requirement for update on feature contexts that are > not tightly > synchronized with external events. > > jak > > ------------------------------------------------------------ > > 5.5 Context Update and Synchronization > > 5.5.1 The base context transfer protocol SHOULD NOT provide > direct support > for > synchronization with outside events, since synchronization is not a > requirement > for all or even most feature contexts. > > 5.5.2 The base context transfer protocol MUST allow individual feature > context > specifications to define their own synchronization with > external events. > > 5.5.3 The base context transfer protocol SHOULD NOT provide > support for > updating > context after it is transfered, since individual feature contexts will > differ in > their > need for update. > > 5.5.4 The base context transfer protocol MUST allow individual feature > context > specifications to define their own update procedures if required. > > Most feature contexts will not require > synchronization, however > there > are a few that may. Header compression, for example, > may require > that > the header compressor on the old access router cease and the > compressor > on the new router start in synchrony with hand over > of routing to > the > new router; otherwise, the compressor on the new > router will not be > properly synchronized. Since most contexts don't need > synchronization > support, the general CT solution need not support it, > but it should > not > provide a hinderance to those feature contexts that do. > > Feature contexts will differ in whether or not they > require update. > A feature context such as QoS parameters for the service level > agreement > with a user may not involve dynamically changing > information, but it > may > change during or after context transfer. Such feature > contexts may > benefit > from allowing the context to change after the transfer > is completed. > Other > feature contexts, such as header compression, may be tightly > synchronized > with external events and changes on the old router need to be > discarded > since the new router's state may already have been modified. > > > ------_=_NextPart_001_01C23D64.273587DE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Section 5.5 Modifications

Madjid:

  Fine, replace "before" with = "proactive". I still use the term = "proactive"
because I never associated it with the triggers (and = neither did the original
wording in the draft).

  To sum up, the whole purpose of CT is to = attempt to prepare the destination
AR *before* a handover occurs and the destination AR = has to forward it's first
packet to/from the roaming MN. Performing CT = *during* or *after* a handover has
been initiated, particularly after the MN's packets = have begun arriving at the
destination AR is a necessary capability, but the = potential performance
improvements are not as great.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: July 22, 2002 11:37
> To: 'James Kempf'; Kenward, Gary = [WDLN2:AN10:EXCH]; Nakhjiri
> Madjid-MNAKHJI1; seamoby@ietf.org
> Subject: RE: Section 5.5 Modifications
>
>
> Well, I am maybe not as good of a boy scout as = some others
> but, I remember 3 weeks of debate, followed by = a period
> of  2 months of silence and then a 90 = minute discussion in London
> (not to mention the 3$K trip expense :) ) =
> that lead to us not making reactive
> or proactive CT as a basis for the CT = usefulness debate.
> Lets not open that barrel of snakes (certainly = bigger than
> worms) again.
>
> If you want to mention proactive a byproduct, = or use case,
> that is fine.
> But I think we should be careful about making a = byproduct a
> primary goal.
>
>
> Regards,
>
> Madjid
>
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: Friday, July 19, 2002 7:47 PM
> To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; = seamoby@ietf.org
> Subject: Section 5.5 Modifications
>
>
> Hi Gary,
>
> >   I get the impression that = either everyone has forgotten
> about proactive
> > CT, or does
> > not care. Which is too bad, for the boy = scouts are right on
> when they say
> > "be prepared".
> >
>
> Thanx for reminding me, being an old Boy Scout = myself I should have
> remembered.
> :-)
>
> How about if we modify the text I sent out as = below? In
> addition, I think we
> need an additional section, which I will post = on a separate
> thread, that
> describes the steps needed to standardize a = feature context.
> This text will
> include a requirement for update on feature = contexts that are
> not tightly
> synchronized with external events.
>
>          = ;       jak
>
> = ------------------------------------------------------------
>
> 5.5 Context Update and Synchronization
>
> 5.5.1 The base context transfer protocol SHOULD = NOT provide
> direct support
> for
> synchronization with outside events, since = synchronization is not a
> requirement
> for all or even most feature contexts.
>
> 5.5.2 The base context transfer protocol MUST = allow individual feature
> context
> specifications to define their own = synchronization with
> external events.
>
> 5.5.3 The base context transfer protocol SHOULD = NOT provide
> support for
> updating
> context after it is transfered, since = individual feature contexts will
> differ in
> their
> need for update.
>
> 5.5.4 The base context transfer protocol MUST = allow individual feature
> context
> specifications to define their own update = procedures if required.
>
>         = Most feature contexts will not require
> synchronization, however
> there
>         = are a few that may. Header compression, for example,
> may require
> that
>         = the header compressor on the old access router cease and the
> compressor
>         = on the new router start in synchrony with hand over
> of routing to
> the
>         = new router; otherwise, the compressor on the new
> router will not be
>        = properly synchronized. Since most contexts don't need
> synchronization
>        = support, the general CT solution need not support it,
> but it should
> not
>        = provide a hinderance to those feature contexts that do.
>
>        = Feature contexts will differ in whether or not they
> require update.
>        A = feature context such as QoS parameters for the service level
> agreement
>        with = a user may not involve dynamically changing
> information, but it
> may
>        = change during or after context transfer. Such feature
> contexts may
> benefit
>        from = allowing the context to change after the transfer
> is completed.
> Other
>        = feature contexts, such as header compression, may be tightly
> synchronized
>        with = external events and changes on the old router need to be
> discarded
>        since = the new router's state may already have been modified.
>
>
>

------_=_NextPart_001_01C23D64.273587DE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 6 12:17: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 MAA16744 for ; Tue, 6 Aug 2002 12:17:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15189 for seamoby-archive@odin.ietf.org; Tue, 6 Aug 2002 12:18:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14876; Tue, 6 Aug 2002 12:14:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14847 for ; Tue, 6 Aug 2002 12:14:08 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16583 for ; Tue, 6 Aug 2002 12:12:56 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76GDCo25925; Tue, 6 Aug 2002 12:13:13 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 12:13:13 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C52@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Date: Tue, 6 Aug 2002 12:13:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D64.273587DE" Subject: [Seamoby] RE: Section 5.5 Modifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23D64.273587DE Content-Type: text/plain; charset="iso-8859-1" Madjid: Fine, replace "before" with "proactive". I still use the term "proactive" because I never associated it with the triggers (and neither did the original wording in the draft). To sum up, the whole purpose of CT is to attempt to prepare the destination AR *before* a handover occurs and the destination AR has to forward it's first packet to/from the roaming MN. Performing CT *during* or *after* a handover has been initiated, particularly after the MN's packets have begun arriving at the destination AR is a necessary capability, but the potential performance improvements are not as great. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: July 22, 2002 11:37 > To: 'James Kempf'; Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri > Madjid-MNAKHJI1; seamoby@ietf.org > Subject: RE: Section 5.5 Modifications > > > Well, I am maybe not as good of a boy scout as some others > but, I remember 3 weeks of debate, followed by a period > of 2 months of silence and then a 90 minute discussion in London > (not to mention the 3$K trip expense :) ) > that lead to us not making reactive > or proactive CT as a basis for the CT usefulness debate. > Lets not open that barrel of snakes (certainly bigger than > worms) again. > > If you want to mention proactive a byproduct, or use case, > that is fine. > But I think we should be careful about making a byproduct a > primary goal. > > > Regards, > > Madjid > > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, July 19, 2002 7:47 PM > To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; seamoby@ietf.org > Subject: Section 5.5 Modifications > > > Hi Gary, > > > I get the impression that either everyone has forgotten > about proactive > > CT, or does > > not care. Which is too bad, for the boy scouts are right on > when they say > > "be prepared". > > > > Thanx for reminding me, being an old Boy Scout myself I should have > remembered. > :-) > > How about if we modify the text I sent out as below? In > addition, I think we > need an additional section, which I will post on a separate > thread, that > describes the steps needed to standardize a feature context. > This text will > include a requirement for update on feature contexts that are > not tightly > synchronized with external events. > > jak > > ------------------------------------------------------------ > > 5.5 Context Update and Synchronization > > 5.5.1 The base context transfer protocol SHOULD NOT provide > direct support > for > synchronization with outside events, since synchronization is not a > requirement > for all or even most feature contexts. > > 5.5.2 The base context transfer protocol MUST allow individual feature > context > specifications to define their own synchronization with > external events. > > 5.5.3 The base context transfer protocol SHOULD NOT provide > support for > updating > context after it is transfered, since individual feature contexts will > differ in > their > need for update. > > 5.5.4 The base context transfer protocol MUST allow individual feature > context > specifications to define their own update procedures if required. > > Most feature contexts will not require > synchronization, however > there > are a few that may. Header compression, for example, > may require > that > the header compressor on the old access router cease and the > compressor > on the new router start in synchrony with hand over > of routing to > the > new router; otherwise, the compressor on the new > router will not be > properly synchronized. Since most contexts don't need > synchronization > support, the general CT solution need not support it, > but it should > not > provide a hinderance to those feature contexts that do. > > Feature contexts will differ in whether or not they > require update. > A feature context such as QoS parameters for the service level > agreement > with a user may not involve dynamically changing > information, but it > may > change during or after context transfer. Such feature > contexts may > benefit > from allowing the context to change after the transfer > is completed. > Other > feature contexts, such as header compression, may be tightly > synchronized > with external events and changes on the old router need to be > discarded > since the new router's state may already have been modified. > > > ------_=_NextPart_001_01C23D64.273587DE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Section 5.5 Modifications

Madjid:

  Fine, replace "before" with = "proactive". I still use the term = "proactive"
because I never associated it with the triggers (and = neither did the original
wording in the draft).

  To sum up, the whole purpose of CT is to = attempt to prepare the destination
AR *before* a handover occurs and the destination AR = has to forward it's first
packet to/from the roaming MN. Performing CT = *during* or *after* a handover has
been initiated, particularly after the MN's packets = have begun arriving at the
destination AR is a necessary capability, but the = potential performance
improvements are not as great.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: July 22, 2002 11:37
> To: 'James Kempf'; Kenward, Gary = [WDLN2:AN10:EXCH]; Nakhjiri
> Madjid-MNAKHJI1; seamoby@ietf.org
> Subject: RE: Section 5.5 Modifications
>
>
> Well, I am maybe not as good of a boy scout as = some others
> but, I remember 3 weeks of debate, followed by = a period
> of  2 months of silence and then a 90 = minute discussion in London
> (not to mention the 3$K trip expense :) ) =
> that lead to us not making reactive
> or proactive CT as a basis for the CT = usefulness debate.
> Lets not open that barrel of snakes (certainly = bigger than
> worms) again.
>
> If you want to mention proactive a byproduct, = or use case,
> that is fine.
> But I think we should be careful about making a = byproduct a
> primary goal.
>
>
> Regards,
>
> Madjid
>
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: Friday, July 19, 2002 7:47 PM
> To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; = seamoby@ietf.org
> Subject: Section 5.5 Modifications
>
>
> Hi Gary,
>
> >   I get the impression that = either everyone has forgotten
> about proactive
> > CT, or does
> > not care. Which is too bad, for the boy = scouts are right on
> when they say
> > "be prepared".
> >
>
> Thanx for reminding me, being an old Boy Scout = myself I should have
> remembered.
> :-)
>
> How about if we modify the text I sent out as = below? In
> addition, I think we
> need an additional section, which I will post = on a separate
> thread, that
> describes the steps needed to standardize a = feature context.
> This text will
> include a requirement for update on feature = contexts that are
> not tightly
> synchronized with external events.
>
>          = ;       jak
>
> = ------------------------------------------------------------
>
> 5.5 Context Update and Synchronization
>
> 5.5.1 The base context transfer protocol SHOULD = NOT provide
> direct support
> for
> synchronization with outside events, since = synchronization is not a
> requirement
> for all or even most feature contexts.
>
> 5.5.2 The base context transfer protocol MUST = allow individual feature
> context
> specifications to define their own = synchronization with
> external events.
>
> 5.5.3 The base context transfer protocol SHOULD = NOT provide
> support for
> updating
> context after it is transfered, since = individual feature contexts will
> differ in
> their
> need for update.
>
> 5.5.4 The base context transfer protocol MUST = allow individual feature
> context
> specifications to define their own update = procedures if required.
>
>         = Most feature contexts will not require
> synchronization, however
> there
>         = are a few that may. Header compression, for example,
> may require
> that
>         = the header compressor on the old access router cease and the
> compressor
>         = on the new router start in synchrony with hand over
> of routing to
> the
>         = new router; otherwise, the compressor on the new
> router will not be
>        = properly synchronized. Since most contexts don't need
> synchronization
>        = support, the general CT solution need not support it,
> but it should
> not
>        = provide a hinderance to those feature contexts that do.
>
>        = Feature contexts will differ in whether or not they
> require update.
>        A = feature context such as QoS parameters for the service level
> agreement
>        with = a user may not involve dynamically changing
> information, but it
> may
>        = change during or after context transfer. Such feature
> contexts may
> benefit
>        from = allowing the context to change after the transfer
> is completed.
> Other
>        = feature contexts, such as header compression, may be tightly
> synchronized
>        with = external events and changes on the old router need to be
> discarded
>        since = the new router's state may already have been modified.
>
>
>

------_=_NextPart_001_01C23D64.273587DE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 6 13:26: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 NAA19651 for ; Tue, 6 Aug 2002 13:26:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19503; Tue, 6 Aug 2002 13:21:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19475 for ; Tue, 6 Aug 2002 13:21:30 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19276 for ; Tue, 6 Aug 2002 13:20:17 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76HKPo05052; Tue, 6 Aug 2002 13:20:25 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 13:20:25 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C53@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S pecifications Date: Tue, 6 Aug 2002 13:20:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D6D.8D1A13C2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23D6D.8D1A13C2 Content-Type: text/plain; charset="iso-8859-1" James: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 19, 2002 21:26 > To: seamoby@ietf.org > Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > I'd like to propose the following new section for the CT > requirments listing > requirements on feature context specifications. Note that > this section does not > place requirements on the feature context protocols > themselves, but only on > their specifications. > > jak > > ------------------------------------------ > > 5.8 Feature Context Specifications > > The context transfer protocol provides a basic framework in > which feature > contexts of varying types can be transfered. Recognizing that > the particular > feature contexts may have very different needs with regard to update, > synchronization, and transport, this section contains > requirements on the > feature context specifications. Note that these requirements > do not constrain > the actual feature context protocols themselves, but only > their specification. > > 5.8.1 A feature context specification MUST contain an IANA > assigned type code > for the particular feature context. If an experimental > feature context protocol > is being developed, a type code from the context transfer protocol's > experimental range SHOULD be used. The type code is used in > the context transfer > container to identify the feature context. > > 5.8.2 A feature context specification MUST define the byte > layout of the > individual elements of the feature context, and how those map > into the context > transfer protocol's container. The byte layout SHOULD obey > standard IETF > conventions with regard to mapping of data into on the wire format. What is "wire format"? > > 5.8.3 A feature context specification MUST define the > transport to be used. If > the feature context is transferred using an IETF transport > layer protocol , then > the feature context specification MUST include the full > details of how the > transport layer protocol is used. If the feature context is > transferred as an > option on another IETF protocol, then the feature context > specification MUST > define the mapping of the context transfer container into the > other protocol's > standard option format. If the feature context is transferred > through a non-IETF > protocol (such as IAPP [4]), then the feature context > protocol specification > MUST define how the standard context transfer container is > mapped into the > non-IETF transport. > > 5.8.4 A feature context specification MUST indicate whether > update to context > information is allowed if changes in the source occur after > the context is > transferred. If such changes are allowed, the feature context > specification MUST > define the change protocol message format using the standard > context transfer > container, and MUST include details of how the update is accomplished. Does this mean that the fcs must describe how the ARs perform the update? Doesn't this address router functionality? > > 5.8.5 A feature context specification MUST indicate whether > the context transfer > is tightly synchronized with external events, such as > handover. The freature > context specification MUST indicate what event or events > trigger transfer. For what purpose? The fcs should define the context information that the destination is to expect. What would the destination router do with this information? It is apparent what the source router might do with this information, but why does it need to be standardized? E.g. if a router manufacturer wishes to update context every 10,000 clock ticks, what concern is this to the IETF? Gary > > 6.0 References > > [4] "Recommended Practice for Multi-vendor Interaccess Point > Interoperability > via an Inter-access Point Protocol Across Distribution > Systems Supporting IEEE > 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. Looks good. > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C23D6D.8D1A13C2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

James:

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 19, 2002 21:26
> To: seamoby@ietf.org
> Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context
> Specifications
>
>
> I'd like to propose the following new section for the CT
> requirments listing
> requirements on feature context specifications. Note that
> this section does not
> place requirements on the feature context protocols
> themselves, but only on
> their specifications.
>
>             jak
>
> ------------------------------------------
>
> 5.8 Feature Context Specifications
>
> The context transfer protocol provides a basic framework in
> which feature
> contexts of varying types can be transfered. Recognizing that
> the particular
> feature contexts may have very different needs with regard to update,
> synchronization, and transport, this section contains
> requirements on the
> feature context specifications. Note that these requirements
> do not constrain
> the actual feature context protocols themselves, but only
> their specification.
>
> 5.8.1 A feature context specification MUST contain an IANA
> assigned type code
> for the particular feature context. If an experimental
> feature context protocol
> is being developed, a type code from the context transfer protocol's
> experimental range SHOULD be used. The type code is used in
> the context transfer
> container to identify the feature context.
>
> 5.8.2 A feature context specification MUST define the byte
> layout of the
> individual elements of the feature context, and how those map
> into the context
> transfer protocol's container. The byte layout SHOULD obey
> standard IETF
> conventions with regard to mapping of data into on the wire format.

What is "wire format"?

>
> 5.8.3 A feature context specification MUST define the
> transport to be used. If
> the feature context is transferred using an IETF transport
> layer protocol , then
> the feature context specification MUST include the full
> details of how the
> transport layer protocol is used. If the feature context is
> transferred as an
> option on another IETF protocol, then the feature context
> specification MUST
> define the mapping of the context transfer container into the
> other protocol's
> standard option format. If the feature context is transferred
> through a non-IETF
> protocol (such as IAPP [4]), then the feature context
> protocol specification
> MUST define how the standard context transfer container is
> mapped into the
> non-IETF transport.
>
> 5.8.4 A feature context specification MUST indicate whether
> update to context
> information is allowed if changes in the source occur after
> the context is
> transferred. If such changes are allowed, the feature context
> specification MUST
> define the change protocol message format using the standard
> context transfer
> container, and MUST include details of how the update is accomplished.

Does this mean that the fcs must describe how the ARs perform the update?
Doesn't this address router functionality?

>
> 5.8.5 A feature context specification MUST indicate whether
> the context transfer
> is tightly synchronized with external events, such as
> handover. The freature
> context specification MUST indicate what event or events
> trigger transfer.

For what purpose? The fcs should define the context information
that the destination is to expect. What would the destination
router do with this information?

It is apparent what the source router might do with this information,
but why does it need to be standardized? E.g. if a router manufacturer
wishes to update context every 10,000 clock ticks, what concern is
this to the IETF?

Gary

>
> 6.0 References
>
> [4]  "Recommended Practice for Multi-vendor Interaccess Point
> Interoperability
> via an Inter-access Point Protocol Across Distribution
> Systems Supporting IEEE
> 802.11 Operation," IEEE Std. 802.11f/D3,  January, 2002.


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

------_=_NextPart_001_01C23D6D.8D1A13C2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 6 13:31: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 NAA19962 for ; Tue, 6 Aug 2002 13:31:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19707; Tue, 6 Aug 2002 13:26:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19640 for ; Tue, 6 Aug 2002 13:26:40 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19481 for ; Tue, 6 Aug 2002 13:25:27 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76HQ4o05531; Tue, 6 Aug 2002 13:26:04 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 13:26:04 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C54@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Tue, 6 Aug 2002 13:26:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D6D.C202A2FC" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23D6D.C202A2FC Content-Type: text/plain; charset="iso-8859-1" James: All well and good, but the requirement basically states that CT should run over a transport protocol, reliable or unreliable, IETF or non-IETF...hmmm, not really a requirement, except that it implies that CT does not include transport capabilities. BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned with L3, with transfer of L2 as an option. Since we are already talking about separate transport protocols for different features, I do not see the rationalization for using CT to carry, or to replace, IAPP. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 22, 2002 12:31 > To: john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > John, > > > I disagree with your requirement, because I don't see a lot > of meaning > > and/or use in it. > > > > I think that different context may have different need. > Timelyness & > > reliability are 2 different and opposing needs. This is directly > > relatable to the earlier discussion on dynamicisity of context. > > A situation could occur where a context goes stale during > re-transmission > > when running over a reliable protocol. Some other context, > such as security > > may not time out, unless the end-user completely times out of the > user-session. > > > > Besides going stale, it is entirely possible that some context may > > be superceded. As this issue is fairly complex and > intertwined with the > > context being transfered, I suggest we don't have a > reliability requirement, > > but rather we try to do an analysis of the reliability > needs and then > > take this into the solution. > > > > Additionally, I don't think that we want to get into defining new > > transport protocols or behaviors. > > > > > That is exactly why I proposed this requirement. The intent > of this requirement, > together with the newly proposed Section 5.8, is that it > would be up to the > particular feature context profile to specify the transport. > > Here's an example of why I think the requirement is needed. > 802.11 specifies > its own context transfer protocol, namely IAPP. If we specify > that, for example, > SCTP is required for transport, vendors on 802.11 would have > to implement two > context transfer protocols, IAPP and the Seamoby SCTP-based > protocol. IMHO, it > makes sense to only have one context transfer protocol and > leverage a particular > transport for the feature contexts that need it. > > Does this make sense? > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C23D6D.C202A2FC Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

James:

  All well and good, but the requirement basically states that CT
should run over a transport protocol, reliable or unreliable, IETF
or non-IETF...hmmm, not really a requirement, except that it implies
that CT does not include transport capabilities.

  BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned
with L3, with transfer of L2 as an option. Since we are already talking
about separate transport protocols for different features, I do not see
the rationalization for using CT to carry, or to replace, IAPP.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 22, 2002 12:31
> To: john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> John,
>
> > I disagree with your requirement, because I don't see a lot
> of meaning
> > and/or use in it.
> >
> > I think that different context may have different need. 
> Timelyness &
> > reliability are 2 different and opposing needs.  This is directly
> > relatable to the earlier discussion on dynamicisity of context.
> > A situation could occur where a context goes stale during
> re-transmission
> > when running over a reliable protocol.  Some other context,
> such as security
> > may not time out, unless the end-user completely times out of the
> user-session.
> >
> > Besides going stale, it is entirely possible that some context may
> > be superceded.  As this issue is fairly complex and
> intertwined with the
> > context being transfered, I suggest we don't have a
> reliability requirement,
> > but rather we try to do an analysis of the reliability
> needs and then
> > take this into the solution.
> >
> > Additionally, I don't think that we want to get into defining new
> > transport protocols or behaviors.
> >
>
>
> That is exactly why I proposed this requirement. The intent
> of this requirement,
> together with the newly proposed Section 5.8, is that it
> would be up to the
> particular feature context profile to specify the transport.
>
> Here's an example of why I think the requirement is needed. 
> 802.11 specifies
> its own context transfer protocol, namely IAPP. If we specify
> that, for example,
> SCTP is required for transport, vendors on 802.11 would have
> to implement two
> context transfer protocols, IAPP and the Seamoby SCTP-based
> protocol. IMHO, it
> makes sense to only have one context transfer protocol and
> leverage a particular
> transport for the feature contexts that need it.
>
> Does this make sense?
>
>             jak
>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C23D6D.C202A2FC-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 6 13: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 NAA19970 for ; Tue, 6 Aug 2002 13:31:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20428 for seamoby-archive@odin.ietf.org; Tue, 6 Aug 2002 13:32:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19707; Tue, 6 Aug 2002 13:26:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19640 for ; Tue, 6 Aug 2002 13:26:40 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19481 for ; Tue, 6 Aug 2002 13:25:27 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76HQ4o05531; Tue, 6 Aug 2002 13:26:04 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 13:26:04 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C54@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Tue, 6 Aug 2002 13:26:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D6D.C202A2FC" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23D6D.C202A2FC Content-Type: text/plain; charset="iso-8859-1" James: All well and good, but the requirement basically states that CT should run over a transport protocol, reliable or unreliable, IETF or non-IETF...hmmm, not really a requirement, except that it implies that CT does not include transport capabilities. BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned with L3, with transfer of L2 as an option. Since we are already talking about separate transport protocols for different features, I do not see the rationalization for using CT to carry, or to replace, IAPP. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 22, 2002 12:31 > To: john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > John, > > > I disagree with your requirement, because I don't see a lot > of meaning > > and/or use in it. > > > > I think that different context may have different need. > Timelyness & > > reliability are 2 different and opposing needs. This is directly > > relatable to the earlier discussion on dynamicisity of context. > > A situation could occur where a context goes stale during > re-transmission > > when running over a reliable protocol. Some other context, > such as security > > may not time out, unless the end-user completely times out of the > user-session. > > > > Besides going stale, it is entirely possible that some context may > > be superceded. As this issue is fairly complex and > intertwined with the > > context being transfered, I suggest we don't have a > reliability requirement, > > but rather we try to do an analysis of the reliability > needs and then > > take this into the solution. > > > > Additionally, I don't think that we want to get into defining new > > transport protocols or behaviors. > > > > > That is exactly why I proposed this requirement. The intent > of this requirement, > together with the newly proposed Section 5.8, is that it > would be up to the > particular feature context profile to specify the transport. > > Here's an example of why I think the requirement is needed. > 802.11 specifies > its own context transfer protocol, namely IAPP. If we specify > that, for example, > SCTP is required for transport, vendors on 802.11 would have > to implement two > context transfer protocols, IAPP and the Seamoby SCTP-based > protocol. IMHO, it > makes sense to only have one context transfer protocol and > leverage a particular > transport for the feature contexts that need it. > > Does this make sense? > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C23D6D.C202A2FC Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

James:

  All well and good, but the requirement basically states that CT
should run over a transport protocol, reliable or unreliable, IETF
or non-IETF...hmmm, not really a requirement, except that it implies
that CT does not include transport capabilities.

  BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned
with L3, with transfer of L2 as an option. Since we are already talking
about separate transport protocols for different features, I do not see
the rationalization for using CT to carry, or to replace, IAPP.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 22, 2002 12:31
> To: john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> John,
>
> > I disagree with your requirement, because I don't see a lot
> of meaning
> > and/or use in it.
> >
> > I think that different context may have different need. 
> Timelyness &
> > reliability are 2 different and opposing needs.  This is directly
> > relatable to the earlier discussion on dynamicisity of context.
> > A situation could occur where a context goes stale during
> re-transmission
> > when running over a reliable protocol.  Some other context,
> such as security
> > may not time out, unless the end-user completely times out of the
> user-session.
> >
> > Besides going stale, it is entirely possible that some context may
> > be superceded.  As this issue is fairly complex and
> intertwined with the
> > context being transfered, I suggest we don't have a
> reliability requirement,
> > but rather we try to do an analysis of the reliability
> needs and then
> > take this into the solution.
> >
> > Additionally, I don't think that we want to get into defining new
> > transport protocols or behaviors.
> >
>
>
> That is exactly why I proposed this requirement. The intent
> of this requirement,
> together with the newly proposed Section 5.8, is that it
> would be up to the
> particular feature context profile to specify the transport.
>
> Here's an example of why I think the requirement is needed. 
> 802.11 specifies
> its own context transfer protocol, namely IAPP. If we specify
> that, for example,
> SCTP is required for transport, vendors on 802.11 would have
> to implement two
> context transfer protocols, IAPP and the Seamoby SCTP-based
> protocol. IMHO, it
> makes sense to only have one context transfer protocol and
> leverage a particular
> transport for the feature contexts that need it.
>
> Does this make sense?
>
>             jak
>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C23D6D.C202A2FC-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 6 13:36: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 NAA20219 for ; Tue, 6 Aug 2002 13:36:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20413; Tue, 6 Aug 2002 13:32:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20385 for ; Tue, 6 Aug 2002 13:32:20 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19957 for ; Tue, 6 Aug 2002 13:31:07 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76HVjo06024; Tue, 6 Aug 2002 13:31:45 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 13:31:45 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C55@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S pecifications Date: Tue, 6 Aug 2002 13:31:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D6E.CA6E708C" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23D6E.CA6E708C Content-Type: text/plain; charset="iso-8859-1" Madjid: > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: July 22, 2002 18:56 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > Feature Context > S pecifications > > *snip* > > If the feature context is transferred as an > option on another IETF protocol, then the feature context > specification MUST > define the mapping of the context transfer container into the > other protocol's > standard option format. If the feature context is transferred What did you mean by "standard option format"? CT, as we have been discussing it, is a container protocol, defined around context "chunks". Are you implying that it should also allow for encoding of context into the option fields of other protocols??? Gary *snip* ------_=_NextPart_001_01C23D6E.CA6E708C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] New Section 5.8 - Requirements on Feature Context = S pecifications

Madjid:

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: July 22, 2002 18:56
> To: 'James Kempf'; seamoby@ietf.org
> Subject: RE: [Seamoby] New Section 5.8 - = Requirements on
> Feature Context
> S pecifications
>
>

*snip*

>
> If the feature context is transferred as = an
> option on another IETF protocol, then the = feature context
> specification MUST
> define the mapping of the context transfer = container into the
> other protocol's
> standard option format. If the feature context = is transferred

What did you mean by "standard option = format"? CT, as we have
been discussing it, is a container protocol, defined = around
context "chunks". Are you implying that it = should also allow
for encoding of context into the option fields of = other protocols???

Gary

*snip*

------_=_NextPart_001_01C23D6E.CA6E708C-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 6 13:36: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 NAA20227 for ; Tue, 6 Aug 2002 13:36:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20587 for seamoby-archive@odin.ietf.org; Tue, 6 Aug 2002 13:38:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20413; Tue, 6 Aug 2002 13:32:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20385 for ; Tue, 6 Aug 2002 13:32:20 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19957 for ; Tue, 6 Aug 2002 13:31:07 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76HVjo06024; Tue, 6 Aug 2002 13:31:45 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 13:31:45 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C55@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S pecifications Date: Tue, 6 Aug 2002 13:31:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D6E.CA6E708C" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23D6E.CA6E708C Content-Type: text/plain; charset="iso-8859-1" Madjid: > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: July 22, 2002 18:56 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > Feature Context > S pecifications > > *snip* > > If the feature context is transferred as an > option on another IETF protocol, then the feature context > specification MUST > define the mapping of the context transfer container into the > other protocol's > standard option format. If the feature context is transferred What did you mean by "standard option format"? CT, as we have been discussing it, is a container protocol, defined around context "chunks". Are you implying that it should also allow for encoding of context into the option fields of other protocols??? Gary *snip* ------_=_NextPart_001_01C23D6E.CA6E708C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] New Section 5.8 - Requirements on Feature Context = S pecifications

Madjid:

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: July 22, 2002 18:56
> To: 'James Kempf'; seamoby@ietf.org
> Subject: RE: [Seamoby] New Section 5.8 - = Requirements on
> Feature Context
> S pecifications
>
>

*snip*

>
> If the feature context is transferred as = an
> option on another IETF protocol, then the = feature context
> specification MUST
> define the mapping of the context transfer = container into the
> other protocol's
> standard option format. If the feature context = is transferred

What did you mean by "standard option = format"? CT, as we have
been discussing it, is a container protocol, defined = around
context "chunks". Are you implying that it = should also allow
for encoding of context into the option fields of = other protocols???

Gary

*snip*

------_=_NextPart_001_01C23D6E.CA6E708C-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 6 14:25: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 NAA19659 for ; Tue, 6 Aug 2002 13:26:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19748 for seamoby-archive@odin.ietf.org; Tue, 6 Aug 2002 13:27:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19503; Tue, 6 Aug 2002 13:21:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19475 for ; Tue, 6 Aug 2002 13:21:30 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19276 for ; Tue, 6 Aug 2002 13:20:17 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76HKPo05052; Tue, 6 Aug 2002 13:20:25 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 13:20:25 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C53@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S pecifications Date: Tue, 6 Aug 2002 13:20:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D6D.8D1A13C2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23D6D.8D1A13C2 Content-Type: text/plain; charset="iso-8859-1" James: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 19, 2002 21:26 > To: seamoby@ietf.org > Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > I'd like to propose the following new section for the CT > requirments listing > requirements on feature context specifications. Note that > this section does not > place requirements on the feature context protocols > themselves, but only on > their specifications. > > jak > > ------------------------------------------ > > 5.8 Feature Context Specifications > > The context transfer protocol provides a basic framework in > which feature > contexts of varying types can be transfered. Recognizing that > the particular > feature contexts may have very different needs with regard to update, > synchronization, and transport, this section contains > requirements on the > feature context specifications. Note that these requirements > do not constrain > the actual feature context protocols themselves, but only > their specification. > > 5.8.1 A feature context specification MUST contain an IANA > assigned type code > for the particular feature context. If an experimental > feature context protocol > is being developed, a type code from the context transfer protocol's > experimental range SHOULD be used. The type code is used in > the context transfer > container to identify the feature context. > > 5.8.2 A feature context specification MUST define the byte > layout of the > individual elements of the feature context, and how those map > into the context > transfer protocol's container. The byte layout SHOULD obey > standard IETF > conventions with regard to mapping of data into on the wire format. What is "wire format"? > > 5.8.3 A feature context specification MUST define the > transport to be used. If > the feature context is transferred using an IETF transport > layer protocol , then > the feature context specification MUST include the full > details of how the > transport layer protocol is used. If the feature context is > transferred as an > option on another IETF protocol, then the feature context > specification MUST > define the mapping of the context transfer container into the > other protocol's > standard option format. If the feature context is transferred > through a non-IETF > protocol (such as IAPP [4]), then the feature context > protocol specification > MUST define how the standard context transfer container is > mapped into the > non-IETF transport. > > 5.8.4 A feature context specification MUST indicate whether > update to context > information is allowed if changes in the source occur after > the context is > transferred. If such changes are allowed, the feature context > specification MUST > define the change protocol message format using the standard > context transfer > container, and MUST include details of how the update is accomplished. Does this mean that the fcs must describe how the ARs perform the update? Doesn't this address router functionality? > > 5.8.5 A feature context specification MUST indicate whether > the context transfer > is tightly synchronized with external events, such as > handover. The freature > context specification MUST indicate what event or events > trigger transfer. For what purpose? The fcs should define the context information that the destination is to expect. What would the destination router do with this information? It is apparent what the source router might do with this information, but why does it need to be standardized? E.g. if a router manufacturer wishes to update context every 10,000 clock ticks, what concern is this to the IETF? Gary > > 6.0 References > > [4] "Recommended Practice for Multi-vendor Interaccess Point > Interoperability > via an Inter-access Point Protocol Across Distribution > Systems Supporting IEEE > 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. Looks good. > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C23D6D.8D1A13C2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

James:

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 19, 2002 21:26
> To: seamoby@ietf.org
> Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context
> Specifications
>
>
> I'd like to propose the following new section for the CT
> requirments listing
> requirements on feature context specifications. Note that
> this section does not
> place requirements on the feature context protocols
> themselves, but only on
> their specifications.
>
>             jak
>
> ------------------------------------------
>
> 5.8 Feature Context Specifications
>
> The context transfer protocol provides a basic framework in
> which feature
> contexts of varying types can be transfered. Recognizing that
> the particular
> feature contexts may have very different needs with regard to update,
> synchronization, and transport, this section contains
> requirements on the
> feature context specifications. Note that these requirements
> do not constrain
> the actual feature context protocols themselves, but only
> their specification.
>
> 5.8.1 A feature context specification MUST contain an IANA
> assigned type code
> for the particular feature context. If an experimental
> feature context protocol
> is being developed, a type code from the context transfer protocol's
> experimental range SHOULD be used. The type code is used in
> the context transfer
> container to identify the feature context.
>
> 5.8.2 A feature context specification MUST define the byte
> layout of the
> individual elements of the feature context, and how those map
> into the context
> transfer protocol's container. The byte layout SHOULD obey
> standard IETF
> conventions with regard to mapping of data into on the wire format.

What is "wire format"?

>
> 5.8.3 A feature context specification MUST define the
> transport to be used. If
> the feature context is transferred using an IETF transport
> layer protocol , then
> the feature context specification MUST include the full
> details of how the
> transport layer protocol is used. If the feature context is
> transferred as an
> option on another IETF protocol, then the feature context
> specification MUST
> define the mapping of the context transfer container into the
> other protocol's
> standard option format. If the feature context is transferred
> through a non-IETF
> protocol (such as IAPP [4]), then the feature context
> protocol specification
> MUST define how the standard context transfer container is
> mapped into the
> non-IETF transport.
>
> 5.8.4 A feature context specification MUST indicate whether
> update to context
> information is allowed if changes in the source occur after
> the context is
> transferred. If such changes are allowed, the feature context
> specification MUST
> define the change protocol message format using the standard
> context transfer
> container, and MUST include details of how the update is accomplished.

Does this mean that the fcs must describe how the ARs perform the update?
Doesn't this address router functionality?

>
> 5.8.5 A feature context specification MUST indicate whether
> the context transfer
> is tightly synchronized with external events, such as
> handover. The freature
> context specification MUST indicate what event or events
> trigger transfer.

For what purpose? The fcs should define the context information
that the destination is to expect. What would the destination
router do with this information?

It is apparent what the source router might do with this information,
but why does it need to be standardized? E.g. if a router manufacturer
wishes to update context every 10,000 clock ticks, what concern is
this to the IETF?

Gary

>
> 6.0 References
>
> [4]  "Recommended Practice for Multi-vendor Interaccess Point
> Interoperability
> via an Inter-access Point Protocol Across Distribution
> Systems Supporting IEEE
> 802.11 Operation," IEEE Std. 802.11f/D3,  January, 2002.


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

------_=_NextPart_001_01C23D6D.8D1A13C2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Aug 7 12:09:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25866 for ; Wed, 7 Aug 2002 12:09:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20858; Wed, 7 Aug 2002 12:04:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20830 for ; Wed, 7 Aug 2002 12:04:41 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25505 for ; Wed, 7 Aug 2002 12:03:26 -0400 (EDT) Message-ID: <006c01c23e2b$ea15ac80$296015ac@T23KEMPF> From: "James Kempf" To: Date: Wed, 7 Aug 2002 09:03:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Last Call for draft-ietf-seamoby-card-requirements-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Working Group Last Call for draft-ietf-seamoby-card-requirements-01.txt, the CAR discovery protocol requirements, starts today and runs through Aug. 24. Please read the draft carefully and post comments. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Aug 7 12:09: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 MAA25873 for ; Wed, 7 Aug 2002 12:09:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21117 for seamoby-archive@odin.ietf.org; Wed, 7 Aug 2002 12:10:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20858; Wed, 7 Aug 2002 12:04:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20830 for ; Wed, 7 Aug 2002 12:04:41 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25505 for ; Wed, 7 Aug 2002 12:03:26 -0400 (EDT) Message-ID: <006c01c23e2b$ea15ac80$296015ac@T23KEMPF> From: "James Kempf" To: Date: Wed, 7 Aug 2002 09:03:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Last Call for draft-ietf-seamoby-card-requirements-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Working Group Last Call for draft-ietf-seamoby-card-requirements-01.txt, the CAR discovery protocol requirements, starts today and runs through Aug. 24. Please read the draft carefully and post comments. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Aug 8 17:02:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26779 for ; Thu, 8 Aug 2002 17:02:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00411; Thu, 8 Aug 2002 17:01:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00367 for ; Thu, 8 Aug 2002 17:01:03 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26705 for ; Thu, 8 Aug 2002 16:59:47 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA02101 for ; Thu, 8 Aug 2002 14:01:02 -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 NAA25805 for ; Thu, 8 Aug 2002 13:59:12 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 8 Aug 2002 16:00:55 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56E6@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Thu, 8 Aug 2002 16:00:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23F1E.AC19DCA0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23F1E.AC19DCA0 Content-Type: text/plain; charset="iso-8859-1" I keep hearing IAPP as a contender for CT. IAPP only carries one context and that is Radius and that is because authentications taking place in a WLAN depends on RADIUS and its servers. IAPP does not offer a generic context transfer solution and it is not at layer 3 and it is L2 and L2 technology specific. Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, August 06, 2002 12:26 PM To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements James: All well and good, but the requirement basically states that CT should run over a transport protocol, reliable or unreliable, IETF or non-IETF...hmmm, not really a requirement, except that it implies that CT does not include transport capabilities. BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned with L3, with transfer of L2 as an option. Since we are already talking about separate transport protocols for different features, I do not see the rationalization for using CT to carry, or to replace, IAPP. Gary > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: July 22, 2002 12:31 > To: john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > John, > > > I disagree with your requirement, because I don't see a lot > of meaning > > and/or use in it. > > > > I think that different context may have different need. > Timelyness & > > reliability are 2 different and opposing needs. This is directly > > relatable to the earlier discussion on dynamicisity of context. > > A situation could occur where a context goes stale during > re-transmission > > when running over a reliable protocol. Some other context, > such as security > > may not time out, unless the end-user completely times out of the > user-session. > > > > Besides going stale, it is entirely possible that some context may > > be superceded. As this issue is fairly complex and > intertwined with the > > context being transfered, I suggest we don't have a > reliability requirement, > > but rather we try to do an analysis of the reliability > needs and then > > take this into the solution. > > > > Additionally, I don't think that we want to get into defining new > > transport protocols or behaviors. > > > > > That is exactly why I proposed this requirement. The intent > of this requirement, > together with the newly proposed Section 5.8, is that it > would be up to the > particular feature context profile to specify the transport. > > Here's an example of why I think the requirement is needed. > 802.11 specifies > its own context transfer protocol, namely IAPP. If we specify > that, for example, > SCTP is required for transport, vendors on 802.11 would have > to implement two > context transfer protocols, IAPP and the Seamoby SCTP-based > protocol. IMHO, it > makes sense to only have one context transfer protocol and > leverage a particular > transport for the feature contexts that need it. > > Does this make sense? > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C23F1E.AC19DCA0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements
I keep hearing IAPP  as a contender for CT.
IAPP only carries one context and that is Radius and that is because authentications
taking place in a WLAN depends on RADIUS and its servers. IAPP does not offer a generic
context transfer solution and it is not at layer 3 and it is L2 and L2 technology specific.
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, August 06, 2002 12:26 PM
To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org
Subject: RE: [Seamoby] Section 5.2 in CT Requirements

James:

  All well and good, but the requirement basically states that CT
should run over a transport protocol, reliable or unreliable, IETF
or non-IETF...hmmm, not really a requirement, except that it implies
that CT does not include transport capabilities.

  BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned
with L3, with transfer of L2 as an option. Since we are already talking
about separate transport protocols for different features, I do not see
the rationalization for using CT to carry, or to replace, IAPP.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 22, 2002 12:31
> To: john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> John,
>
> > I disagree with your requirement, because I don't see a lot
> of meaning
> > and/or use in it.
> >
> > I think that different context may have different need. 
> Timelyness &
> > reliability are 2 different and opposing needs.  This is directly
> > relatable to the earlier discussion on dynamicisity of context.
> > A situation could occur where a context goes stale during
> re-transmission
> > when running over a reliable protocol.  Some other context,
> such as security
> > may not time out, unless the end-user completely times out of the
> user-session.
> >
> > Besides going stale, it is entirely possible that some context may
> > be superceded.  As this issue is fairly complex and
> intertwined with the
> > context being transfered, I suggest we don't have a
> reliability requirement,
> > but rather we try to do an analysis of the reliability
> needs and then
> > take this into the solution.
> >
> > Additionally, I don't think that we want to get into defining new
> > transport protocols or behaviors.
> >
>
>
> That is exactly why I proposed this requirement. The intent
> of this requirement,
> together with the newly proposed Section 5.8, is that it
> would be up to the
> particular feature context profile to specify the transport.
>
> Here's an example of why I think the requirement is needed. 
> 802.11 specifies
> its own context transfer protocol, namely IAPP. If we specify
> that, for example,
> SCTP is required for transport, vendors on 802.11 would have
> to implement two
> context transfer protocols, IAPP and the Seamoby SCTP-based
> protocol. IMHO, it
> makes sense to only have one context transfer protocol and
> leverage a particular
> transport for the feature contexts that need it.
>
> Does this make sense?
>
>             jak
>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C23F1E.AC19DCA0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Aug 8 17:02:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26787 for ; Thu, 8 Aug 2002 17:02:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00708 for seamoby-archive@odin.ietf.org; Thu, 8 Aug 2002 17:03:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00411; Thu, 8 Aug 2002 17:01:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00367 for ; Thu, 8 Aug 2002 17:01:03 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26705 for ; Thu, 8 Aug 2002 16:59:47 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA02101 for ; Thu, 8 Aug 2002 14:01:02 -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 NAA25805 for ; Thu, 8 Aug 2002 13:59:12 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 8 Aug 2002 16:00:55 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56E6@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Thu, 8 Aug 2002 16:00:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23F1E.AC19DCA0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23F1E.AC19DCA0 Content-Type: text/plain; charset="iso-8859-1" I keep hearing IAPP as a contender for CT. IAPP only carries one context and that is Radius and that is because authentications taking place in a WLAN depends on RADIUS and its servers. IAPP does not offer a generic context transfer solution and it is not at layer 3 and it is L2 and L2 technology specific. Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, August 06, 2002 12:26 PM To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements James: All well and good, but the requirement basically states that CT should run over a transport protocol, reliable or unreliable, IETF or non-IETF...hmmm, not really a requirement, except that it implies that CT does not include transport capabilities. BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned with L3, with transfer of L2 as an option. Since we are already talking about separate transport protocols for different features, I do not see the rationalization for using CT to carry, or to replace, IAPP. Gary > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: July 22, 2002 12:31 > To: john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > John, > > > I disagree with your requirement, because I don't see a lot > of meaning > > and/or use in it. > > > > I think that different context may have different need. > Timelyness & > > reliability are 2 different and opposing needs. This is directly > > relatable to the earlier discussion on dynamicisity of context. > > A situation could occur where a context goes stale during > re-transmission > > when running over a reliable protocol. Some other context, > such as security > > may not time out, unless the end-user completely times out of the > user-session. > > > > Besides going stale, it is entirely possible that some context may > > be superceded. As this issue is fairly complex and > intertwined with the > > context being transfered, I suggest we don't have a > reliability requirement, > > but rather we try to do an analysis of the reliability > needs and then > > take this into the solution. > > > > Additionally, I don't think that we want to get into defining new > > transport protocols or behaviors. > > > > > That is exactly why I proposed this requirement. The intent > of this requirement, > together with the newly proposed Section 5.8, is that it > would be up to the > particular feature context profile to specify the transport. > > Here's an example of why I think the requirement is needed. > 802.11 specifies > its own context transfer protocol, namely IAPP. If we specify > that, for example, > SCTP is required for transport, vendors on 802.11 would have > to implement two > context transfer protocols, IAPP and the Seamoby SCTP-based > protocol. IMHO, it > makes sense to only have one context transfer protocol and > leverage a particular > transport for the feature contexts that need it. > > Does this make sense? > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C23F1E.AC19DCA0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements
I keep hearing IAPP  as a contender for CT.
IAPP only carries one context and that is Radius and that is because authentications
taking place in a WLAN depends on RADIUS and its servers. IAPP does not offer a generic
context transfer solution and it is not at layer 3 and it is L2 and L2 technology specific.
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, August 06, 2002 12:26 PM
To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org
Subject: RE: [Seamoby] Section 5.2 in CT Requirements

James:

  All well and good, but the requirement basically states that CT
should run over a transport protocol, reliable or unreliable, IETF
or non-IETF...hmmm, not really a requirement, except that it implies
that CT does not include transport capabilities.

  BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned
with L3, with transfer of L2 as an option. Since we are already talking
about separate transport protocols for different features, I do not see
the rationalization for using CT to carry, or to replace, IAPP.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 22, 2002 12:31
> To: john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> John,
>
> > I disagree with your requirement, because I don't see a lot
> of meaning
> > and/or use in it.
> >
> > I think that different context may have different need. 
> Timelyness &
> > reliability are 2 different and opposing needs.  This is directly
> > relatable to the earlier discussion on dynamicisity of context.
> > A situation could occur where a context goes stale during
> re-transmission
> > when running over a reliable protocol.  Some other context,
> such as security
> > may not time out, unless the end-user completely times out of the
> user-session.
> >
> > Besides going stale, it is entirely possible that some context may
> > be superceded.  As this issue is fairly complex and
> intertwined with the
> > context being transfered, I suggest we don't have a
> reliability requirement,
> > but rather we try to do an analysis of the reliability
> needs and then
> > take this into the solution.
> >
> > Additionally, I don't think that we want to get into defining new
> > transport protocols or behaviors.
> >
>
>
> That is exactly why I proposed this requirement. The intent
> of this requirement,
> together with the newly proposed Section 5.8, is that it
> would be up to the
> particular feature context profile to specify the transport.
>
> Here's an example of why I think the requirement is needed. 
> 802.11 specifies
> its own context transfer protocol, namely IAPP. If we specify
> that, for example,
> SCTP is required for transport, vendors on 802.11 would have
> to implement two
> context transfer protocols, IAPP and the Seamoby SCTP-based
> protocol. IMHO, it
> makes sense to only have one context transfer protocol and
> leverage a particular
> transport for the feature contexts that need it.
>
> Does this make sense?
>
>             jak
>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C23F1E.AC19DCA0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Aug 8 17:04: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 RAA26894 for ; Thu, 8 Aug 2002 17:04:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29294; Thu, 8 Aug 2002 16:57:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29264 for ; Thu, 8 Aug 2002 16:57:33 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26625 for ; Thu, 8 Aug 2002 16:56:17 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA11034 for ; Thu, 8 Aug 2002 13:57:30 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA06187 for ; Thu, 8 Aug 2002 13:57:30 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 8 Aug 2002 15:57:27 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56E5@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S pecifications Date: Thu, 8 Aug 2002 15:57:27 -0500 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 Gary, I am sorry, I think you took the "context" out of the discussion by snipping the rest of the comments :) The following text suggested by James captures the issue: Madjid > 5.8.1 A feature context specification MUST contain an IANA assigned type code > for the particular feature context. If an experimental feature context protocol > is being developed, a type code from the context transfer protocol's > experimental range SHOULD be used. The type code is used in the context transfer > container to identify the feature context. -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, August 06, 2002 12:32 PM To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S pecifications Madjid: > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: July 22, 2002 18:56 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > Feature Context > S pecifications > > *snip* > > If the feature context is transferred as an > option on another IETF protocol, then the feature context > specification MUST > define the mapping of the context transfer container into the > other protocol's > standard option format. If the feature context is transferred What did you mean by "standard option format"? CT, as we have been discussing it, is a container protocol, defined around context "chunks". Are you implying that it should also allow for encoding of context into the option fields of other protocols??? Gary *snip* _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Aug 8 17:04: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 RAA26901 for ; Thu, 8 Aug 2002 17:04:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00887 for seamoby-archive@odin.ietf.org; Thu, 8 Aug 2002 17:06:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29294; Thu, 8 Aug 2002 16:57:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29264 for ; Thu, 8 Aug 2002 16:57:33 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26625 for ; Thu, 8 Aug 2002 16:56:17 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA11034 for ; Thu, 8 Aug 2002 13:57:30 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA06187 for ; Thu, 8 Aug 2002 13:57:30 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 8 Aug 2002 15:57:27 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56E5@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S pecifications Date: Thu, 8 Aug 2002 15:57:27 -0500 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 Gary, I am sorry, I think you took the "context" out of the discussion by snipping the rest of the comments :) The following text suggested by James captures the issue: Madjid > 5.8.1 A feature context specification MUST contain an IANA assigned type code > for the particular feature context. If an experimental feature context protocol > is being developed, a type code from the context transfer protocol's > experimental range SHOULD be used. The type code is used in the context transfer > container to identify the feature context. -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, August 06, 2002 12:32 PM To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S pecifications Madjid: > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: July 22, 2002 18:56 > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > Feature Context > S pecifications > > *snip* > > If the feature context is transferred as an > option on another IETF protocol, then the feature context > specification MUST > define the mapping of the context transfer container into the > other protocol's > standard option format. If the feature context is transferred What did you mean by "standard option format"? CT, as we have been discussing it, is a container protocol, defined around context "chunks". Are you implying that it should also allow for encoding of context into the option fields of other protocols??? Gary *snip* _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Aug 8 18:04: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 SAA28812 for ; Thu, 8 Aug 2002 18:04:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03832; Thu, 8 Aug 2002 17:58:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03803 for ; Thu, 8 Aug 2002 17:57:59 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28567 for ; Thu, 8 Aug 2002 17:56:42 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g78Lv2E25311; Thu, 8 Aug 2002 17:57:02 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 17:57:03 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C71@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S specifications Date: Thu, 8 Aug 2002 17:57:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23F25.A5B64B44" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23F25.A5B64B44 Content-Type: text/plain; charset="iso-8859-1" Madjid: I snip because the back and forth replies become long, and the email rejects messages over 40K (which is not as big as it might seem). The text you quote does not address my concern. James used the particular phrase "standard option format" in a paragraph discussing context transport, not type codes. It is possible I misinterpreted his intent, but that is why I asked the question. Even so, I would question the rationale of standardizing the mapping of type codes into option format fields of specific transport protocols. It implies that each transport protocol could have different mappings. I see no advantage, and much risk in such an approach. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: August 8, 2002 16:57 > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James > Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > Feature Context > S pecifications > > > Gary, > > I am sorry, I think you took the "context" out of the > discussion by snipping > the rest of the comments :) > The following text suggested by James captures the issue: > > Madjid > > > 5.8.1 A feature context specification MUST contain an IANA > assigned type > code > > for the particular feature context. If an experimental > feature context > protocol > > is being developed, a type code from the context transfer protocol's > > experimental range SHOULD be used. The type code is used in > the context > transfer > > container to identify the feature context. > > > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Tuesday, August 06, 2002 12:32 PM > To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > Feature Context S > pecifications > > > Madjid: > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: July 22, 2002 18:56 > > To: 'James Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > Feature Context > > S pecifications > > > > > *snip* > > > > If the feature context is transferred as an > > option on another IETF protocol, then the feature context > > specification MUST > > define the mapping of the context transfer container into the > > other protocol's > > standard option format. If the feature context is transferred > What did you mean by "standard option format"? CT, as we have > been discussing it, is a container protocol, defined around > context "chunks". Are you implying that it should also allow > for encoding of context into the option fields of other protocols??? > Gary > *snip* > ------_=_NextPart_001_01C23F25.A5B64B44 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] New Section 5.8 - Requirements on Feature Context = S specifications

Madjid:

 I snip because the back and forth replies = become long, and the email
rejects messages over 40K (which is not as big as it = might seem).

 The text you quote does not address my concern. = James used the particular
phrase "standard option format" in a = paragraph discussing context transport,
not type codes. It is possible I misinterpreted his = intent, but that is
why I asked the question.

 Even so, I would question the rationale of = standardizing the mapping
of type codes into option format fields of specific = transport protocols.
It implies that each transport protocol could have = different mappings.
I see no advantage, and much risk in such an = approach.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: August 8, 2002 16:57
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri = Madjid-MNAKHJI1; 'James
> Kempf'; seamoby@ietf.org
> Subject: RE: [Seamoby] New Section 5.8 - = Requirements on
> Feature Context
> S pecifications
>
>
> Gary,
>
> I am sorry, I think you took the = "context" out of the
> discussion by snipping
> the rest of the comments :)
> The following text suggested by James captures = the issue:
>
> Madjid
>
> > 5.8.1 A feature context specification MUST = contain an IANA
> assigned type
> code
> > for the particular feature context. If an = experimental
> feature context
> protocol
> > is being developed, a type code from the = context transfer protocol's
> > experimental range SHOULD be used. The = type code is used in
> the context
> transfer
> > container to identify the feature = context.
>
>
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> Sent: Tuesday, August 06, 2002 12:32 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; = seamoby@ietf.org
> Subject: RE: [Seamoby] New Section 5.8 - = Requirements on
> Feature Context S
> pecifications
>
>
> Madjid:
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1
> [mailto:Madjid.Nakhjiri@moto= rola.com]
> > Sent: July 22, 2002 18:56
> > To: 'James Kempf'; seamoby@ietf.org =
> > Subject: RE: [Seamoby] New Section 5.8 - = Requirements on
> > Feature Context
> > S pecifications
> >
> >
> *snip*
> >
> > If the feature context is transferred as = an
> > option on another IETF protocol, then the = feature context
> > specification MUST
> > define the mapping of the context transfer = container into the
> > other protocol's
> > standard option format. If the feature = context is transferred
> What did you mean by "standard option = format"? CT, as we have
> been discussing it, is a container protocol, = defined around
> context "chunks". Are you implying = that it should also allow
> for encoding of context into the option fields = of other protocols???
> Gary
> *snip*
>

------_=_NextPart_001_01C23F25.A5B64B44-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Aug 8 18:04: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 SAA28818 for ; Thu, 8 Aug 2002 18:04:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04733 for seamoby-archive@odin.ietf.org; Thu, 8 Aug 2002 18:06:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03832; Thu, 8 Aug 2002 17:58:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03803 for ; Thu, 8 Aug 2002 17:57:59 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28567 for ; Thu, 8 Aug 2002 17:56:42 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g78Lv2E25311; Thu, 8 Aug 2002 17:57:02 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 17:57:03 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C71@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S specifications Date: Thu, 8 Aug 2002 17:57:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23F25.A5B64B44" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23F25.A5B64B44 Content-Type: text/plain; charset="iso-8859-1" Madjid: I snip because the back and forth replies become long, and the email rejects messages over 40K (which is not as big as it might seem). The text you quote does not address my concern. James used the particular phrase "standard option format" in a paragraph discussing context transport, not type codes. It is possible I misinterpreted his intent, but that is why I asked the question. Even so, I would question the rationale of standardizing the mapping of type codes into option format fields of specific transport protocols. It implies that each transport protocol could have different mappings. I see no advantage, and much risk in such an approach. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: August 8, 2002 16:57 > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James > Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > Feature Context > S pecifications > > > Gary, > > I am sorry, I think you took the "context" out of the > discussion by snipping > the rest of the comments :) > The following text suggested by James captures the issue: > > Madjid > > > 5.8.1 A feature context specification MUST contain an IANA > assigned type > code > > for the particular feature context. If an experimental > feature context > protocol > > is being developed, a type code from the context transfer protocol's > > experimental range SHOULD be used. The type code is used in > the context > transfer > > container to identify the feature context. > > > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Tuesday, August 06, 2002 12:32 PM > To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > Feature Context S > pecifications > > > Madjid: > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: July 22, 2002 18:56 > > To: 'James Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > Feature Context > > S pecifications > > > > > *snip* > > > > If the feature context is transferred as an > > option on another IETF protocol, then the feature context > > specification MUST > > define the mapping of the context transfer container into the > > other protocol's > > standard option format. If the feature context is transferred > What did you mean by "standard option format"? CT, as we have > been discussing it, is a container protocol, defined around > context "chunks". Are you implying that it should also allow > for encoding of context into the option fields of other protocols??? > Gary > *snip* > ------_=_NextPart_001_01C23F25.A5B64B44 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] New Section 5.8 - Requirements on Feature Context = S specifications

Madjid:

 I snip because the back and forth replies = become long, and the email
rejects messages over 40K (which is not as big as it = might seem).

 The text you quote does not address my concern. = James used the particular
phrase "standard option format" in a = paragraph discussing context transport,
not type codes. It is possible I misinterpreted his = intent, but that is
why I asked the question.

 Even so, I would question the rationale of = standardizing the mapping
of type codes into option format fields of specific = transport protocols.
It implies that each transport protocol could have = different mappings.
I see no advantage, and much risk in such an = approach.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: August 8, 2002 16:57
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri = Madjid-MNAKHJI1; 'James
> Kempf'; seamoby@ietf.org
> Subject: RE: [Seamoby] New Section 5.8 - = Requirements on
> Feature Context
> S pecifications
>
>
> Gary,
>
> I am sorry, I think you took the = "context" out of the
> discussion by snipping
> the rest of the comments :)
> The following text suggested by James captures = the issue:
>
> Madjid
>
> > 5.8.1 A feature context specification MUST = contain an IANA
> assigned type
> code
> > for the particular feature context. If an = experimental
> feature context
> protocol
> > is being developed, a type code from the = context transfer protocol's
> > experimental range SHOULD be used. The = type code is used in
> the context
> transfer
> > container to identify the feature = context.
>
>
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> Sent: Tuesday, August 06, 2002 12:32 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; = seamoby@ietf.org
> Subject: RE: [Seamoby] New Section 5.8 - = Requirements on
> Feature Context S
> pecifications
>
>
> Madjid:
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1
> [mailto:Madjid.Nakhjiri@moto= rola.com]
> > Sent: July 22, 2002 18:56
> > To: 'James Kempf'; seamoby@ietf.org =
> > Subject: RE: [Seamoby] New Section 5.8 - = Requirements on
> > Feature Context
> > S pecifications
> >
> >
> *snip*
> >
> > If the feature context is transferred as = an
> > option on another IETF protocol, then the = feature context
> > specification MUST
> > define the mapping of the context transfer = container into the
> > other protocol's
> > standard option format. If the feature = context is transferred
> What did you mean by "standard option = format"? CT, as we have
> been discussing it, is a container protocol, = defined around
> context "chunks". Are you implying = that it should also allow
> for encoding of context into the option fields = of other protocols???
> Gary
> *snip*
>

------_=_NextPart_001_01C23F25.A5B64B44-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Aug 8 18:53: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 SAA29888 for ; Thu, 8 Aug 2002 18:53:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07357; Thu, 8 Aug 2002 18:49:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07328 for ; Thu, 8 Aug 2002 18:49:03 -0400 (EDT) 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 SAA29775 for ; Thu, 8 Aug 2002 18:47:46 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA18756; Thu, 8 Aug 2002 15:48:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g78MmTu14718; Thu, 8 Aug 2002 15:48:29 -0700 X-mProtect: <200208082248> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJAdOBt; Thu, 08 Aug 2002 15:48:27 PDT Message-ID: <3D52F53B.A6E2D323@iprg.nokia.com> Date: Thu, 08 Aug 2002 15:48:27 -0700 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: Gary Kenward CC: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications References: <9FBD322B7824D511B36900508BF93C9C01AA4C71@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 don't know if we are debating James' intent or the text in 5.81. I hope it is the latter, with no disrespect intended. And, I think the text is fine. I see no coupling to specific transport protocols or option formats as Gary seems to be referring to. The purpose of the IANA types is to uniquely identify each feature context, which facilitates inter-operability (for instance, a receiver knows before it begins parsing the data fields _what_ context it is looking at, and _how_ to process it). So, I am in favor of text in 5.8.1. Regards, -Rajeev Gary Kenward wrote: > > > Madjid: > > I snip because the back and forth replies become long, and the email > rejects messages over 40K (which is not as big as it might seem). > > The text you quote does not address my concern. James used the > particular > phrase "standard option format" in a paragraph discussing context > transport, > not type codes. It is possible I misinterpreted his intent, but that > is > why I asked the question. > > Even so, I would question the rationale of standardizing the mapping > of type codes into option format fields of specific transport > protocols. > It implies that each transport protocol could have different mappings. > > I see no advantage, and much risk in such an approach. > > Gary > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: August 8, 2002 16:57 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; > 'James > > Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > Feature Context > > S pecifications > > > > > > Gary, > > > > I am sorry, I think you took the "context" out of the > > discussion by snipping > > the rest of the comments :) > > The following text suggested by James captures the issue: > > > > Madjid > > > > > 5.8.1 A feature context specification MUST contain an IANA > > assigned type > > code > > > for the particular feature context. If an experimental > > feature context > > protocol > > > is being developed, a type code from the context transfer > protocol's > > > experimental range SHOULD be used. The type code is used in > > the context > > transfer > > > container to identify the feature context. > > > > > > > > -----Original Message----- > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Tuesday, August 06, 2002 12:32 PM > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > Feature Context S > > pecifications > > > > > > Madjid: > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: July 22, 2002 18:56 > > > To: 'James Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > Feature Context > > > S pecifications > > > > > > > > *snip* > > > > > > If the feature context is transferred as an > > > option on another IETF protocol, then the feature context > > > specification MUST > > > define the mapping of the context transfer container into the > > > other protocol's > > > standard option format. If the feature context is transferred > > What did you mean by "standard option format"? CT, as we have > > been discussing it, is a container protocol, defined around > > context "chunks". Are you implying that it should also allow > > for encoding of context into the option fields of other protocols??? > > > Gary > > *snip* > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Aug 8 18:53: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 SAA29895 for ; Thu, 8 Aug 2002 18:53:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA07520 for seamoby-archive@odin.ietf.org; Thu, 8 Aug 2002 18:54:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07357; Thu, 8 Aug 2002 18:49:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07328 for ; Thu, 8 Aug 2002 18:49:03 -0400 (EDT) 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 SAA29775 for ; Thu, 8 Aug 2002 18:47:46 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA18756; Thu, 8 Aug 2002 15:48:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g78MmTu14718; Thu, 8 Aug 2002 15:48:29 -0700 X-mProtect: <200208082248> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJAdOBt; Thu, 08 Aug 2002 15:48:27 PDT Message-ID: <3D52F53B.A6E2D323@iprg.nokia.com> Date: Thu, 08 Aug 2002 15:48:27 -0700 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: Gary Kenward CC: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications References: <9FBD322B7824D511B36900508BF93C9C01AA4C71@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 don't know if we are debating James' intent or the text in 5.81. I hope it is the latter, with no disrespect intended. And, I think the text is fine. I see no coupling to specific transport protocols or option formats as Gary seems to be referring to. The purpose of the IANA types is to uniquely identify each feature context, which facilitates inter-operability (for instance, a receiver knows before it begins parsing the data fields _what_ context it is looking at, and _how_ to process it). So, I am in favor of text in 5.8.1. Regards, -Rajeev Gary Kenward wrote: > > > Madjid: > > I snip because the back and forth replies become long, and the email > rejects messages over 40K (which is not as big as it might seem). > > The text you quote does not address my concern. James used the > particular > phrase "standard option format" in a paragraph discussing context > transport, > not type codes. It is possible I misinterpreted his intent, but that > is > why I asked the question. > > Even so, I would question the rationale of standardizing the mapping > of type codes into option format fields of specific transport > protocols. > It implies that each transport protocol could have different mappings. > > I see no advantage, and much risk in such an approach. > > Gary > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: August 8, 2002 16:57 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; > 'James > > Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > Feature Context > > S pecifications > > > > > > Gary, > > > > I am sorry, I think you took the "context" out of the > > discussion by snipping > > the rest of the comments :) > > The following text suggested by James captures the issue: > > > > Madjid > > > > > 5.8.1 A feature context specification MUST contain an IANA > > assigned type > > code > > > for the particular feature context. If an experimental > > feature context > > protocol > > > is being developed, a type code from the context transfer > protocol's > > > experimental range SHOULD be used. The type code is used in > > the context > > transfer > > > container to identify the feature context. > > > > > > > > -----Original Message----- > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Tuesday, August 06, 2002 12:32 PM > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > Feature Context S > > pecifications > > > > > > Madjid: > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: July 22, 2002 18:56 > > > To: 'James Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > Feature Context > > > S pecifications > > > > > > > > *snip* > > > > > > If the feature context is transferred as an > > > option on another IETF protocol, then the feature context > > > specification MUST > > > define the mapping of the context transfer container into the > > > other protocol's > > > standard option format. If the feature context is transferred > > What did you mean by "standard option format"? CT, as we have > > been discussing it, is a container protocol, defined around > > context "chunks". Are you implying that it should also allow > > for encoding of context into the option fields of other protocols??? > > > Gary > > *snip* > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 06:09: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 GAA21346 for ; Fri, 9 Aug 2002 06:09:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15532; Fri, 9 Aug 2002 06:01:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15503 for ; Fri, 9 Aug 2002 06:01:21 -0400 (EDT) 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 GAA21208 for ; Fri, 9 Aug 2002 06:00:04 -0400 (EDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmb3d539627; Fri, 9 Aug 2002 10:01:13 -0000 Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm33d4ed774; Mon, 5 Aug 2002 15:59:32 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26582 for ietf-123-outbound.01@ietf.org; Mon, 5 Aug 2002 07:55:00 -0400 (EDT) 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 HAA26409 for ; Mon, 5 Aug 2002 07:44:31 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08255; Mon, 5 Aug 2002 07:43:19 -0400 (EDT) Message-Id: <200208051143.HAA08255@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, 05 Aug 2002 07:43:19 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-card-requirements-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Requirements for CAR Discovery Protocols Author(s) : G. Krishnamurthi Filename : draft-ietf-seamoby-card-requirements-01.txt Pages : 6 Date : 02-Aug-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 any solution for CAR Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-requirements-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-card-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-card-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020802150821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-card-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-card-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020802150821.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 06:09: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 GAA21352 for ; Fri, 9 Aug 2002 06:09:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA15844 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 06:10:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15532; Fri, 9 Aug 2002 06:01:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15503 for ; Fri, 9 Aug 2002 06:01:21 -0400 (EDT) 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 GAA21208 for ; Fri, 9 Aug 2002 06:00:04 -0400 (EDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmb3d539627; Fri, 9 Aug 2002 10:01:13 -0000 Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm33d4ed774; Mon, 5 Aug 2002 15:59:32 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26582 for ietf-123-outbound.01@ietf.org; Mon, 5 Aug 2002 07:55:00 -0400 (EDT) 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 HAA26409 for ; Mon, 5 Aug 2002 07:44:31 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08255; Mon, 5 Aug 2002 07:43:19 -0400 (EDT) Message-Id: <200208051143.HAA08255@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, 05 Aug 2002 07:43:19 -0400 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-card-requirements-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Requirements for CAR Discovery Protocols Author(s) : G. Krishnamurthi Filename : draft-ietf-seamoby-card-requirements-01.txt Pages : 6 Date : 02-Aug-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 any solution for CAR Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-requirements-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-card-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-card-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020802150821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-card-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-card-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020802150821.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 Aug 9 10:39: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 KAA28472 for ; Fri, 9 Aug 2002 10:39:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29468; Fri, 9 Aug 2002 10:34:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29399 for ; Fri, 9 Aug 2002 10:34:16 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28312 for ; Fri, 9 Aug 2002 10:33:00 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g79EXJk20784; Fri, 9 Aug 2002 10:33:20 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 10:33:20 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C75@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications Date: Fri, 9 Aug 2002 10:33:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FB1.B4BFDFB0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FB1.B4BFDFB0 Content-Type: text/plain; charset="iso-8859-1" Rajeev: Actually, I my point had nothing to do with the text, which I have no problem with. I do have problems with some of the transport protocol statements and requirements that have been put forth. The main issue is that I see a tendency towards having a different transport for every feature context, with potentially different mappings for each combination of context and transport protocol combination. Admittedly, this is a worse case scenario, but entropy is strong force in the internet, and if we adopt James' view of the feature context specifications as it is written, we open up the opportunity for CT to drift towards the worst case. I understand what James was trying to do, I think, but in reading over the proposed 5.8 requirements, I came to realize that there would be little to the actual CT protocol except for a specification of the feature context encapsulation format, and possibly the rules for multiplexing multiple feature contexts onto a give transport frame. This *may* be the best approach, but this would mean that CT is actually a suit of protocols, one for each feature. Designing and standardizing on a collection of protocols will be more difficult, and fraught with risk, then designing and standardizing one protocol, at least for CT. Implementation of a collection of protocols, feature CT and each associated transport protocol, would also be problematical. Obviously, I believe that it is possible to convey all feature contexts with one CT protocol, running over one (to be determined) transport. It may be that people will want the option to chose the transport protocol, but there still only should be one transport per network (obviously, this impacts the interworking capability of CT, but the wg seems to have very diverse opinions on the appropriate transport, and so be it). Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: August 8, 2002 18:48 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Sspecifications > > > > Hello, > > I don't know if we are debating James' intent or > the text in 5.81. I hope it is the latter, with no disrespect > intended. And, I think the text is fine. I see no coupling to > specific transport protocols or option formats as Gary seems > to be referring to. The purpose of the IANA types > is to uniquely identify each feature context, which > facilitates inter-operability (for instance, a receiver > knows before it begins parsing the data fields _what_ > context it is looking at, and _how_ to process it). > So, I am in favor of text in 5.8.1. > > Regards, > > -Rajeev > > > > Gary Kenward wrote: > > > > > > > Madjid: > > > > I snip because the back and forth replies become long, and > the email > > rejects messages over 40K (which is not as big as it might seem). > > > > The text you quote does not address my concern. James used the > > particular > > phrase "standard option format" in a paragraph discussing context > > transport, > > not type codes. It is possible I misinterpreted his intent, but that > > is > > why I asked the question. > > > > Even so, I would question the rationale of standardizing > the mapping > > of type codes into option format fields of specific transport > > protocols. > > It implies that each transport protocol could have > different mappings. > > > > I see no advantage, and much risk in such an approach. > > > > Gary > > > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: August 8, 2002 16:57 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; > > 'James > > > Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > Feature Context > > > S pecifications > > > > > > > > > Gary, > > > > > > I am sorry, I think you took the "context" out of the > > > discussion by snipping > > > the rest of the comments :) > > > The following text suggested by James captures the issue: > > > > > > Madjid > > > > > > > 5.8.1 A feature context specification MUST contain an IANA > > > assigned type > > > code > > > > for the particular feature context. If an experimental > > > feature context > > > protocol > > > > is being developed, a type code from the context transfer > > protocol's > > > > experimental range SHOULD be used. The type code is used in > > > the context > > > transfer > > > > container to identify the feature context. > > > > > > > > > > > > -----Original Message----- > > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > Sent: Tuesday, August 06, 2002 12:32 PM > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > Feature Context S > > > pecifications > > > > > > > > > Madjid: > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: July 22, 2002 18:56 > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > > Feature Context > > > > S pecifications > > > > > > > > > > > *snip* > > > > > > > > If the feature context is transferred as an > > > > option on another IETF protocol, then the feature context > > > > specification MUST > > > > define the mapping of the context transfer container into the > > > > other protocol's > > > > standard option format. If the feature context is transferred > > > What did you mean by "standard option format"? CT, as we have > > > been discussing it, is a container protocol, defined around > > > context "chunks". Are you implying that it should also allow > > > for encoding of context into the option fields of other > protocols??? > > > > > Gary > > > *snip* > > > > > ------_=_NextPart_001_01C23FB1.B4BFDFB0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications

Rajeev:

  Actually, I my point had nothing to do with the text, which I have
no problem with. I do have problems with some of the transport protocol
statements and requirements that have been put forth. The main issue is
that I see a tendency towards having a different transport for every
feature context, with potentially different mappings for each combination
of context and transport protocol combination. Admittedly, this is a worse
case scenario, but entropy is strong force in the internet, and if we adopt
James' view of the feature context specifications as it is written, we open
up the opportunity for CT to drift towards the worst case.

 I understand what James was trying to do, I think, but in reading over the
proposed 5.8 requirements, I came to realize that there would be little to the
actual CT protocol except for a specification of the feature context encapsulation
format, and possibly the rules for multiplexing multiple feature contexts onto
a give transport frame. This *may* be the best approach, but this would mean
that CT is actually a suit of protocols, one for each feature. Designing and
standardizing on a collection of protocols will be more difficult, and fraught
with risk, then designing and standardizing one protocol, at least for CT.
Implementation of a collection of protocols, feature CT and each associated transport
protocol, would also be problematical.

  Obviously, I believe that it is possible to convey all feature contexts with
one CT protocol, running over one (to be determined) transport. It may be that
people will want the option to chose the transport protocol, but there still only
should be one transport per network (obviously, this impacts the interworking
capability of CT, but the wg seems to have very diverse opinions on the appropriate
transport, and so be it).

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: August 8, 2002 18:48
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Sspecifications
>
>
>
> Hello,
>
> I don't know if we are debating James' intent or
> the text in 5.81. I hope it is the latter, with no disrespect
> intended. And, I think the text is fine. I see no coupling to
> specific transport protocols or option formats as Gary seems
> to be referring to. The purpose of the IANA types
> is to uniquely identify each feature context, which
> facilitates inter-operability (for instance, a receiver
> knows before it begins parsing the data fields _what_
> context it is looking at, and _how_ to process it).
> So, I am in favor of text in 5.8.1.
>
> Regards,
>
> -Rajeev
>
>
>
> Gary Kenward wrote:
>
> >
> >
> > Madjid:
> >
> >  I snip because the back and forth replies become long, and
> the email
> > rejects messages over 40K (which is not as big as it might seem).
> >
> >  The text you quote does not address my concern. James used the
> > particular
> > phrase "standard option format" in a paragraph discussing context
> > transport,
> > not type codes. It is possible I misinterpreted his intent, but that
> > is
> > why I asked the question.
> >
> >  Even so, I would question the rationale of standardizing
> the mapping
> > of type codes into option format fields of specific transport
> > protocols.
> > It implies that each transport protocol could have
> different mappings.
> >
> > I see no advantage, and much risk in such an approach.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Nakhjiri Madjid-MNAKHJI1
> [mailto:Madjid.Nakhjiri@motorola.com]
> >
> > > Sent: August 8, 2002 16:57
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1;
> > 'James
> > > Kempf'; seamoby@ietf.org
> > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> > > Feature Context
> > > S pecifications
> > >
> > >
> > > Gary,
> > >
> > > I am sorry, I think you took the "context" out of the
> > > discussion by snipping
> > > the rest of the comments :)
> > > The following text suggested by James captures the issue:
> > >
> > > Madjid
> > >
> > > > 5.8.1 A feature context specification MUST contain an IANA
> > > assigned type
> > > code
> > > > for the particular feature context. If an experimental
> > > feature context
> > > protocol
> > > > is being developed, a type code from the context transfer
> > protocol's
> > > > experimental range SHOULD be used. The type code is used in
> > > the context
> > > transfer
> > > > container to identify the feature context.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > Sent: Tuesday, August 06, 2002 12:32 PM
> > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org
> > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> > > Feature Context S
> > > pecifications
> > >
> > >
> > > Madjid:
> > > > -----Original Message-----
> > > > From: Nakhjiri Madjid-MNAKHJI1
> > > [mailto:Madjid.Nakhjiri@motorola.com]
> > > > Sent: July 22, 2002 18:56
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> > > > Feature Context
> > > > S pecifications
> > > >
> > > >
> > > *snip*
> > > >
> > > > If the feature context is transferred as an
> > > > option on another IETF protocol, then the feature context
> > > > specification MUST
> > > > define the mapping of the context transfer container into the
> > > > other protocol's
> > > > standard option format. If the feature context is transferred
> > > What did you mean by "standard option format"? CT, as we have
> > > been discussing it, is a container protocol, defined around
> > > context "chunks". Are you implying that it should also allow
> > > for encoding of context into the option fields of other
> protocols???
> >
> > > Gary
> > > *snip*
> > >
>
>

------_=_NextPart_001_01C23FB1.B4BFDFB0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 10:39: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 KAA28479 for ; Fri, 9 Aug 2002 10:39:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29704 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 10:40:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29468; Fri, 9 Aug 2002 10:34:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29399 for ; Fri, 9 Aug 2002 10:34:16 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28312 for ; Fri, 9 Aug 2002 10:33:00 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g79EXJk20784; Fri, 9 Aug 2002 10:33:20 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 10:33:20 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C75@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications Date: Fri, 9 Aug 2002 10:33:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FB1.B4BFDFB0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FB1.B4BFDFB0 Content-Type: text/plain; charset="iso-8859-1" Rajeev: Actually, I my point had nothing to do with the text, which I have no problem with. I do have problems with some of the transport protocol statements and requirements that have been put forth. The main issue is that I see a tendency towards having a different transport for every feature context, with potentially different mappings for each combination of context and transport protocol combination. Admittedly, this is a worse case scenario, but entropy is strong force in the internet, and if we adopt James' view of the feature context specifications as it is written, we open up the opportunity for CT to drift towards the worst case. I understand what James was trying to do, I think, but in reading over the proposed 5.8 requirements, I came to realize that there would be little to the actual CT protocol except for a specification of the feature context encapsulation format, and possibly the rules for multiplexing multiple feature contexts onto a give transport frame. This *may* be the best approach, but this would mean that CT is actually a suit of protocols, one for each feature. Designing and standardizing on a collection of protocols will be more difficult, and fraught with risk, then designing and standardizing one protocol, at least for CT. Implementation of a collection of protocols, feature CT and each associated transport protocol, would also be problematical. Obviously, I believe that it is possible to convey all feature contexts with one CT protocol, running over one (to be determined) transport. It may be that people will want the option to chose the transport protocol, but there still only should be one transport per network (obviously, this impacts the interworking capability of CT, but the wg seems to have very diverse opinions on the appropriate transport, and so be it). Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: August 8, 2002 18:48 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Sspecifications > > > > Hello, > > I don't know if we are debating James' intent or > the text in 5.81. I hope it is the latter, with no disrespect > intended. And, I think the text is fine. I see no coupling to > specific transport protocols or option formats as Gary seems > to be referring to. The purpose of the IANA types > is to uniquely identify each feature context, which > facilitates inter-operability (for instance, a receiver > knows before it begins parsing the data fields _what_ > context it is looking at, and _how_ to process it). > So, I am in favor of text in 5.8.1. > > Regards, > > -Rajeev > > > > Gary Kenward wrote: > > > > > > > Madjid: > > > > I snip because the back and forth replies become long, and > the email > > rejects messages over 40K (which is not as big as it might seem). > > > > The text you quote does not address my concern. James used the > > particular > > phrase "standard option format" in a paragraph discussing context > > transport, > > not type codes. It is possible I misinterpreted his intent, but that > > is > > why I asked the question. > > > > Even so, I would question the rationale of standardizing > the mapping > > of type codes into option format fields of specific transport > > protocols. > > It implies that each transport protocol could have > different mappings. > > > > I see no advantage, and much risk in such an approach. > > > > Gary > > > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: August 8, 2002 16:57 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; > > 'James > > > Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > Feature Context > > > S pecifications > > > > > > > > > Gary, > > > > > > I am sorry, I think you took the "context" out of the > > > discussion by snipping > > > the rest of the comments :) > > > The following text suggested by James captures the issue: > > > > > > Madjid > > > > > > > 5.8.1 A feature context specification MUST contain an IANA > > > assigned type > > > code > > > > for the particular feature context. If an experimental > > > feature context > > > protocol > > > > is being developed, a type code from the context transfer > > protocol's > > > > experimental range SHOULD be used. The type code is used in > > > the context > > > transfer > > > > container to identify the feature context. > > > > > > > > > > > > -----Original Message----- > > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > Sent: Tuesday, August 06, 2002 12:32 PM > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > Feature Context S > > > pecifications > > > > > > > > > Madjid: > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: July 22, 2002 18:56 > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > > Feature Context > > > > S pecifications > > > > > > > > > > > *snip* > > > > > > > > If the feature context is transferred as an > > > > option on another IETF protocol, then the feature context > > > > specification MUST > > > > define the mapping of the context transfer container into the > > > > other protocol's > > > > standard option format. If the feature context is transferred > > > What did you mean by "standard option format"? CT, as we have > > > been discussing it, is a container protocol, defined around > > > context "chunks". Are you implying that it should also allow > > > for encoding of context into the option fields of other > protocols??? > > > > > Gary > > > *snip* > > > > > ------_=_NextPart_001_01C23FB1.B4BFDFB0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications

Rajeev:

  Actually, I my point had nothing to do with the text, which I have
no problem with. I do have problems with some of the transport protocol
statements and requirements that have been put forth. The main issue is
that I see a tendency towards having a different transport for every
feature context, with potentially different mappings for each combination
of context and transport protocol combination. Admittedly, this is a worse
case scenario, but entropy is strong force in the internet, and if we adopt
James' view of the feature context specifications as it is written, we open
up the opportunity for CT to drift towards the worst case.

 I understand what James was trying to do, I think, but in reading over the
proposed 5.8 requirements, I came to realize that there would be little to the
actual CT protocol except for a specification of the feature context encapsulation
format, and possibly the rules for multiplexing multiple feature contexts onto
a give transport frame. This *may* be the best approach, but this would mean
that CT is actually a suit of protocols, one for each feature. Designing and
standardizing on a collection of protocols will be more difficult, and fraught
with risk, then designing and standardizing one protocol, at least for CT.
Implementation of a collection of protocols, feature CT and each associated transport
protocol, would also be problematical.

  Obviously, I believe that it is possible to convey all feature contexts with
one CT protocol, running over one (to be determined) transport. It may be that
people will want the option to chose the transport protocol, but there still only
should be one transport per network (obviously, this impacts the interworking
capability of CT, but the wg seems to have very diverse opinions on the appropriate
transport, and so be it).

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: August 8, 2002 18:48
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Sspecifications
>
>
>
> Hello,
>
> I don't know if we are debating James' intent or
> the text in 5.81. I hope it is the latter, with no disrespect
> intended. And, I think the text is fine. I see no coupling to
> specific transport protocols or option formats as Gary seems
> to be referring to. The purpose of the IANA types
> is to uniquely identify each feature context, which
> facilitates inter-operability (for instance, a receiver
> knows before it begins parsing the data fields _what_
> context it is looking at, and _how_ to process it).
> So, I am in favor of text in 5.8.1.
>
> Regards,
>
> -Rajeev
>
>
>
> Gary Kenward wrote:
>
> >
> >
> > Madjid:
> >
> >  I snip because the back and forth replies become long, and
> the email
> > rejects messages over 40K (which is not as big as it might seem).
> >
> >  The text you quote does not address my concern. James used the
> > particular
> > phrase "standard option format" in a paragraph discussing context
> > transport,
> > not type codes. It is possible I misinterpreted his intent, but that
> > is
> > why I asked the question.
> >
> >  Even so, I would question the rationale of standardizing
> the mapping
> > of type codes into option format fields of specific transport
> > protocols.
> > It implies that each transport protocol could have
> different mappings.
> >
> > I see no advantage, and much risk in such an approach.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Nakhjiri Madjid-MNAKHJI1
> [mailto:Madjid.Nakhjiri@motorola.com]
> >
> > > Sent: August 8, 2002 16:57
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1;
> > 'James
> > > Kempf'; seamoby@ietf.org
> > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> > > Feature Context
> > > S pecifications
> > >
> > >
> > > Gary,
> > >
> > > I am sorry, I think you took the "context" out of the
> > > discussion by snipping
> > > the rest of the comments :)
> > > The following text suggested by James captures the issue:
> > >
> > > Madjid
> > >
> > > > 5.8.1 A feature context specification MUST contain an IANA
> > > assigned type
> > > code
> > > > for the particular feature context. If an experimental
> > > feature context
> > > protocol
> > > > is being developed, a type code from the context transfer
> > protocol's
> > > > experimental range SHOULD be used. The type code is used in
> > > the context
> > > transfer
> > > > container to identify the feature context.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > Sent: Tuesday, August 06, 2002 12:32 PM
> > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org
> > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> > > Feature Context S
> > > pecifications
> > >
> > >
> > > Madjid:
> > > > -----Original Message-----
> > > > From: Nakhjiri Madjid-MNAKHJI1
> > > [mailto:Madjid.Nakhjiri@motorola.com]
> > > > Sent: July 22, 2002 18:56
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> > > > Feature Context
> > > > S pecifications
> > > >
> > > >
> > > *snip*
> > > >
> > > > If the feature context is transferred as an
> > > > option on another IETF protocol, then the feature context
> > > > specification MUST
> > > > define the mapping of the context transfer container into the
> > > > other protocol's
> > > > standard option format. If the feature context is transferred
> > > What did you mean by "standard option format"? CT, as we have
> > > been discussing it, is a container protocol, defined around
> > > context "chunks". Are you implying that it should also allow
> > > for encoding of context into the option fields of other
> protocols???
> >
> > > Gary
> > > *snip*
> > >
>
>

------_=_NextPart_001_01C23FB1.B4BFDFB0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 12:12: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 MAA01984 for ; Fri, 9 Aug 2002 12:12:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05551; Fri, 9 Aug 2002 12:07:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05523 for ; Fri, 9 Aug 2002 12:07:36 -0400 (EDT) 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 MAA01690 for ; Fri, 9 Aug 2002 12:06:19 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA28245; Fri, 9 Aug 2002 09:07:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g79G72U21815; Fri, 9 Aug 2002 09:07:02 -0700 X-mProtect: <200208091607> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdit1RBU; Fri, 09 Aug 2002 09:07:00 PDT Message-ID: <3D53E8A5.11D457B8@iprg.nokia.com> Date: Fri, 09 Aug 2002 09:07:01 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications References: <9FBD322B7824D511B36900508BF93C9C01AA4C75@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, I'd like to represent another viewpoint. > Gary Kenward wrote: > The main issue is > that I see a tendency towards having a different transport for every > feature context, How about a mapping of feature contexts into a small number of transport protocols (e.g., UDP, TCP, SCTP, ICMP)? > with potentially different mappings for each combination > of context and transport protocol combination. Can you be more specific about what you mean here? > ........ there would be little to the > actual CT protocol except for a specification of the feature context > encapsulation format, and possibly the rules for multiplexing multiple > feature contexts onto a give transport frame. But that would already be quite valuable, from my perspective. > Implementation of a collection of protocols, feature CT and each associated > transport protocol, would also be problematical. If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't much problem with implementation. Or maybe I missed your point... I think that HI and HAck from [mobile-ip] fast handovers would be a very suitable transport for some contexts that do not require rock-solid reliability, for those cases where they are available. I think that TCP or SCTP would be just fine for a lot of contexts that do require high reliability. If we don't have HI and HAck available, but we have contexts with requirement for very low latency, then we can decide whether the contexts should be encapsulated in ICMP, UDP, or some IP-level option. > Obviously, I believe that it is possible to convey all feature contexts with > one CT protocol, running over one (to be determined) transport. I can't see this. Some contexts have to be transferred with very low latency, and have low reliability requirement. Some contexts have much more relaxed latency requirements, but have high reliability requirements. The same transport protocol is unlikely to work for both. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 12:12: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 MAA01989 for ; Fri, 9 Aug 2002 12:12:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05796 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 12:13:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05551; Fri, 9 Aug 2002 12:07:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05523 for ; Fri, 9 Aug 2002 12:07:36 -0400 (EDT) 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 MAA01690 for ; Fri, 9 Aug 2002 12:06:19 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA28245; Fri, 9 Aug 2002 09:07:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g79G72U21815; Fri, 9 Aug 2002 09:07:02 -0700 X-mProtect: <200208091607> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdit1RBU; Fri, 09 Aug 2002 09:07:00 PDT Message-ID: <3D53E8A5.11D457B8@iprg.nokia.com> Date: Fri, 09 Aug 2002 09:07:01 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications References: <9FBD322B7824D511B36900508BF93C9C01AA4C75@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, I'd like to represent another viewpoint. > Gary Kenward wrote: > The main issue is > that I see a tendency towards having a different transport for every > feature context, How about a mapping of feature contexts into a small number of transport protocols (e.g., UDP, TCP, SCTP, ICMP)? > with potentially different mappings for each combination > of context and transport protocol combination. Can you be more specific about what you mean here? > ........ there would be little to the > actual CT protocol except for a specification of the feature context > encapsulation format, and possibly the rules for multiplexing multiple > feature contexts onto a give transport frame. But that would already be quite valuable, from my perspective. > Implementation of a collection of protocols, feature CT and each associated > transport protocol, would also be problematical. If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't much problem with implementation. Or maybe I missed your point... I think that HI and HAck from [mobile-ip] fast handovers would be a very suitable transport for some contexts that do not require rock-solid reliability, for those cases where they are available. I think that TCP or SCTP would be just fine for a lot of contexts that do require high reliability. If we don't have HI and HAck available, but we have contexts with requirement for very low latency, then we can decide whether the contexts should be encapsulated in ICMP, UDP, or some IP-level option. > Obviously, I believe that it is possible to convey all feature contexts with > one CT protocol, running over one (to be determined) transport. I can't see this. Some contexts have to be transferred with very low latency, and have low reliability requirement. Some contexts have much more relaxed latency requirements, but have high reliability requirements. The same transport protocol is unlikely to work for both. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 13:06: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 NAA03455 for ; Fri, 9 Aug 2002 13:06:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08887; Fri, 9 Aug 2002 13:03:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08862 for ; Fri, 9 Aug 2002 13:03:49 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03342 for ; Fri, 9 Aug 2002 13:02:33 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g79GxLM15082; Fri, 9 Aug 2002 12:59:21 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 12:59:22 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C7B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Fri, 9 Aug 2002 12:59:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FC6.1830C3DE" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FC6.1830C3DE Content-Type: text/plain; charset="iso-8859-1" Charlie: > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: August 9, 2002 12:07 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > I'd like to represent another viewpoint. Certainly. > > > Gary Kenward wrote: > > > The main issue is > > that I see a tendency towards having a different transport for every > > feature context, > > How about a mapping of feature contexts into a small number of > transport protocols (e.g., UDP, TCP, SCTP, ICMP)? May happen. Why make it a requirement, or imply that this is the best solution within the requirements document? There is a debate to take place over this issue, and we should have it, when the we start discussing solutions. But let us not presume that it is part of the solution. > > > with potentially different mappings for > each combination > > of context and transport protocol combination. > > Can you be more specific about what you mean here? If all context is transfer as data chunks in the payload, then there really isn't a problem. However, if one starts mapping ct information into option fields of various protocols, the mappings will very likely change due to the differences in protocol syntax. IPv4 vs. IPv6 seems to be the most pronounced example. > > > ........ there would be little to the > > actual CT protocol except for a specification of the feature context > > encapsulation format, and possibly the rules for > multiplexing multiple > > feature contexts onto a give transport frame. > > But that would already be quite valuable, from my perspective. A necessary component of the total solution for CT, but definitely only part of the answer. The real issue here is whether the CT capability is fulfilled with a single protocol or a suite of protocols. I believe the former is a preferable solution, if the protocol complexity is manageable, which I believe it is. We have pretty well decided that CT capability involves at least two protocols (above IP): a CT containerizing protocol, and a transport protocol. Two is still better then a gaggle of protocols, IMHO. > > > Implementation of a collection of protocols, feature CT and > each associated > > transport protocol, would also be problematical. > > If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't > much problem with implementation. Or maybe I missed your point... Well, this assumes that the ARs have end-point stacks for all of the transport protocols, and management interfaces, etc. Most routers have ICMP/UDP support. Not sure about TCP, and I doubt SCTP. Technically, supporting 4+/- protocols is perhaps not that big of a deal...but where's the value? > > I think that HI and HAck from [mobile-ip] fast handovers would be > a very suitable transport for some contexts that do not require > rock-solid reliability, for those cases where they are available. > I think that TCP or SCTP would be just fine for a lot of contexts > that do require high reliability. If we don't have HI and HAck > available, but we have contexts with requirement for very low > latency, then we can decide whether the contexts should be > encapsulated > in ICMP, UDP, or some IP-level option. Again, I have no problem ( at least at this point) with saying that the designer can run CT over one of a number of protocols, say they are UDP, SCTP, ICMP, TCP - I do have a problem with the idea that each feature CT will run over different protocols. Now, instead of one context transfer, you have at least one for each transport protocol used (assuming feature CTs that use the same transport can be multiplexed onto one frame). This exacerbates many issues such as transfer delay, ordering, updates synchronization, etc. > > > Obviously, I believe that it is possible to convey all > feature contexts with > > one CT protocol, running over one (to be determined) transport. > > I can't see this. Some contexts have to be transferred with very > low latency, and have low reliability requirement. Some contexts > have much more relaxed latency requirements, but have high reliability > requirements. The same transport protocol is unlikely to work for > both. The only reason you would separate the transports in this case is if there was an advantage to optimizing for the "low performance" requirements. That is, what is the problem with delivering a feature context with a lower latency or higher reliability? There is certainly more overhead in adding a second, higher latency or lower reliability exchange then there is in putting all the context on a transport that met the most demanding requirements. Usually, achieving low latency is in opposition to high reliability either because of the processing overhead with FEC, or the loop response latency of a BEC (backward error control). The total context is relatively small in terms of the number of bytes, and the latency requirements are not sensitive to the microseconds required to encode and decode FEC (particularly if for proactive CT). A number of ideas kicked around lately almost seem imply the use of CT for state synchronization between ARs. I really hope this is not the case. If so, it really does not jibe with the vision I have of what CT is trying to accomplish, with is a loose, best effort approach to improving the seamlessness of handover. State synchronization can be done much more effectively below L3, without the overheads of IP+transport. Gary > > > Regards, > Charlie P. > ------_=_NextPart_001_01C23FC6.1830C3DE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] New Section 5.8 - Requirements on Feature Context = Specifications

Charlie:

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 9, 2002 12:07
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - = Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> I'd like to represent another viewpoint.

Certainly.

>
> > Gary Kenward wrote:
>
> = >           &n= bsp;           &n= bsp;           &n= bsp;            = The main issue is
> > that I see a tendency towards having a = different transport for every
> > feature context,
>
> How about a mapping of feature contexts into a = small number of
> transport protocols (e.g., UDP, TCP, SCTP, = ICMP)?

May happen. Why make it a requirement, or imply that = this is the best
solution within the requirements document? There is = a debate to take
place over this issue, and we should have it, when = the we start discussing
solutions. But let us not presume that it is part of = the solution.

>
> = >           &n= bsp;       with potentially different = mappings for
> each combination
> > of context and transport protocol = combination.
>
> Can you be more specific about what you mean = here?

If all context is transfer as data chunks in the = payload, then there really isn't
a problem. However, if one starts mapping ct = information into option fields of various
protocols, the mappings will very likely change due = to the differences in protocol
syntax. IPv4 vs. IPv6 seems to be the most = pronounced example.

>
> = >          = ........          &nb= sp;            = there would be little to the
> > actual CT protocol except for a = specification of the feature context
> > encapsulation format, and possibly the = rules for
> multiplexing multiple
> > feature contexts onto a give transport = frame.
>
> But that would already be quite valuable, from = my perspective.

A necessary component of the total solution for CT, = but definitely
only part of the answer. The real issue here is = whether the CT capability is
fulfilled with a single protocol or a suite of = protocols. I believe the former is
a preferable solution, if the protocol complexity is = manageable, which I believe it
is.

We have pretty well decided that CT capability = involves at least two protocols (above IP):
a CT containerizing protocol, and a transport = protocol. Two is still better then a gaggle
of protocols, IMHO.

>
> > Implementation of a collection of = protocols, feature CT and
> each associated
> > transport protocol, would also be = problematical.
>
> If the transport protocols are UDP, TCP, SCTP, = and ICMP, there isn't
> much problem with implementation.  Or = maybe I missed your point...

Well, this assumes that the ARs have end-point stacks = for all of the transport
protocols, and management interfaces, etc. Most = routers have ICMP/UDP support.
Not sure about TCP, and I doubt SCTP.

Technically, supporting 4+/- protocols is perhaps not = that big of a deal...but
where's the value?

>
> I think that HI and HAck from [mobile-ip] fast = handovers would be
> a very suitable transport for some contexts = that do not require
> rock-solid reliability, for those cases where = they are available.
> I think that TCP or SCTP would be just fine for = a lot of contexts
> that do require high reliability.  If we = don't have HI and HAck
> available, but we have contexts with = requirement for very low
> latency, then we can decide whether the = contexts should be
> encapsulated
> in ICMP, UDP, or some IP-level option.

Again, I have no problem ( at least at this point) = with saying that the
designer can run CT over one of a number of = protocols, say they are UDP,
SCTP, ICMP, TCP - I do have a problem with the idea = that each feature CT will
run over different protocols. Now, instead of one = context transfer, you have
at least one for each transport protocol used = (assuming feature CTs that use
the same transport can be multiplexed onto one = frame). This exacerbates many
issues such as transfer delay, ordering, updates = synchronization, etc.

>
> >   Obviously, I believe that it = is possible to convey all
> feature contexts with
> > one CT protocol, running over one (to be = determined) transport.
>
> I can't see this.  Some contexts have to = be transferred with very
> low latency, and have low reliability = requirement.  Some contexts
> have much more relaxed latency requirements, = but have high reliability
> requirements.  The same transport protocol = is unlikely to work for
> both.

The only reason you would separate the transports in = this case is if there
was an advantage to optimizing for the "low = performance" requirements. That is,
what is the problem with delivering a feature = context with a lower latency or
higher reliability?

There is certainly more overhead in adding a second, = higher latency or lower
reliability exchange then there is in putting all = the context on a transport
that met the most demanding requirements.

Usually, achieving low latency is in opposition to = high reliability either because
of the processing overhead with FEC, or the loop = response latency of a BEC (backward
error control). The total context is relatively = small in terms of the number
of bytes, and the latency requirements are not = sensitive to the microseconds required
to encode and decode FEC (particularly if for = proactive CT).


A number of ideas kicked around lately almost seem = imply the use of CT for state
synchronization between ARs. I really hope this is = not the case. If so, it really
does not jibe with the vision I have of what CT is = trying to accomplish, with is a
loose, best effort approach to improving the = seamlessness of handover.

State synchronization can be done much more = effectively below L3, without the overheads
of IP+transport.

Gary

>
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C23FC6.1830C3DE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 13:06: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 NAA03464 for ; Fri, 9 Aug 2002 13:06:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09079 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 13:07:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08887; Fri, 9 Aug 2002 13:03:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08862 for ; Fri, 9 Aug 2002 13:03:49 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03342 for ; Fri, 9 Aug 2002 13:02:33 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g79GxLM15082; Fri, 9 Aug 2002 12:59:21 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 12:59:22 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C7B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Fri, 9 Aug 2002 12:59:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FC6.1830C3DE" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FC6.1830C3DE Content-Type: text/plain; charset="iso-8859-1" Charlie: > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: August 9, 2002 12:07 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > I'd like to represent another viewpoint. Certainly. > > > Gary Kenward wrote: > > > The main issue is > > that I see a tendency towards having a different transport for every > > feature context, > > How about a mapping of feature contexts into a small number of > transport protocols (e.g., UDP, TCP, SCTP, ICMP)? May happen. Why make it a requirement, or imply that this is the best solution within the requirements document? There is a debate to take place over this issue, and we should have it, when the we start discussing solutions. But let us not presume that it is part of the solution. > > > with potentially different mappings for > each combination > > of context and transport protocol combination. > > Can you be more specific about what you mean here? If all context is transfer as data chunks in the payload, then there really isn't a problem. However, if one starts mapping ct information into option fields of various protocols, the mappings will very likely change due to the differences in protocol syntax. IPv4 vs. IPv6 seems to be the most pronounced example. > > > ........ there would be little to the > > actual CT protocol except for a specification of the feature context > > encapsulation format, and possibly the rules for > multiplexing multiple > > feature contexts onto a give transport frame. > > But that would already be quite valuable, from my perspective. A necessary component of the total solution for CT, but definitely only part of the answer. The real issue here is whether the CT capability is fulfilled with a single protocol or a suite of protocols. I believe the former is a preferable solution, if the protocol complexity is manageable, which I believe it is. We have pretty well decided that CT capability involves at least two protocols (above IP): a CT containerizing protocol, and a transport protocol. Two is still better then a gaggle of protocols, IMHO. > > > Implementation of a collection of protocols, feature CT and > each associated > > transport protocol, would also be problematical. > > If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't > much problem with implementation. Or maybe I missed your point... Well, this assumes that the ARs have end-point stacks for all of the transport protocols, and management interfaces, etc. Most routers have ICMP/UDP support. Not sure about TCP, and I doubt SCTP. Technically, supporting 4+/- protocols is perhaps not that big of a deal...but where's the value? > > I think that HI and HAck from [mobile-ip] fast handovers would be > a very suitable transport for some contexts that do not require > rock-solid reliability, for those cases where they are available. > I think that TCP or SCTP would be just fine for a lot of contexts > that do require high reliability. If we don't have HI and HAck > available, but we have contexts with requirement for very low > latency, then we can decide whether the contexts should be > encapsulated > in ICMP, UDP, or some IP-level option. Again, I have no problem ( at least at this point) with saying that the designer can run CT over one of a number of protocols, say they are UDP, SCTP, ICMP, TCP - I do have a problem with the idea that each feature CT will run over different protocols. Now, instead of one context transfer, you have at least one for each transport protocol used (assuming feature CTs that use the same transport can be multiplexed onto one frame). This exacerbates many issues such as transfer delay, ordering, updates synchronization, etc. > > > Obviously, I believe that it is possible to convey all > feature contexts with > > one CT protocol, running over one (to be determined) transport. > > I can't see this. Some contexts have to be transferred with very > low latency, and have low reliability requirement. Some contexts > have much more relaxed latency requirements, but have high reliability > requirements. The same transport protocol is unlikely to work for > both. The only reason you would separate the transports in this case is if there was an advantage to optimizing for the "low performance" requirements. That is, what is the problem with delivering a feature context with a lower latency or higher reliability? There is certainly more overhead in adding a second, higher latency or lower reliability exchange then there is in putting all the context on a transport that met the most demanding requirements. Usually, achieving low latency is in opposition to high reliability either because of the processing overhead with FEC, or the loop response latency of a BEC (backward error control). The total context is relatively small in terms of the number of bytes, and the latency requirements are not sensitive to the microseconds required to encode and decode FEC (particularly if for proactive CT). A number of ideas kicked around lately almost seem imply the use of CT for state synchronization between ARs. I really hope this is not the case. If so, it really does not jibe with the vision I have of what CT is trying to accomplish, with is a loose, best effort approach to improving the seamlessness of handover. State synchronization can be done much more effectively below L3, without the overheads of IP+transport. Gary > > > Regards, > Charlie P. > ------_=_NextPart_001_01C23FC6.1830C3DE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] New Section 5.8 - Requirements on Feature Context = Specifications

Charlie:

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 9, 2002 12:07
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - = Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> I'd like to represent another viewpoint.

Certainly.

>
> > Gary Kenward wrote:
>
> = >           &n= bsp;           &n= bsp;           &n= bsp;            = The main issue is
> > that I see a tendency towards having a = different transport for every
> > feature context,
>
> How about a mapping of feature contexts into a = small number of
> transport protocols (e.g., UDP, TCP, SCTP, = ICMP)?

May happen. Why make it a requirement, or imply that = this is the best
solution within the requirements document? There is = a debate to take
place over this issue, and we should have it, when = the we start discussing
solutions. But let us not presume that it is part of = the solution.

>
> = >           &n= bsp;       with potentially different = mappings for
> each combination
> > of context and transport protocol = combination.
>
> Can you be more specific about what you mean = here?

If all context is transfer as data chunks in the = payload, then there really isn't
a problem. However, if one starts mapping ct = information into option fields of various
protocols, the mappings will very likely change due = to the differences in protocol
syntax. IPv4 vs. IPv6 seems to be the most = pronounced example.

>
> = >          = ........          &nb= sp;            = there would be little to the
> > actual CT protocol except for a = specification of the feature context
> > encapsulation format, and possibly the = rules for
> multiplexing multiple
> > feature contexts onto a give transport = frame.
>
> But that would already be quite valuable, from = my perspective.

A necessary component of the total solution for CT, = but definitely
only part of the answer. The real issue here is = whether the CT capability is
fulfilled with a single protocol or a suite of = protocols. I believe the former is
a preferable solution, if the protocol complexity is = manageable, which I believe it
is.

We have pretty well decided that CT capability = involves at least two protocols (above IP):
a CT containerizing protocol, and a transport = protocol. Two is still better then a gaggle
of protocols, IMHO.

>
> > Implementation of a collection of = protocols, feature CT and
> each associated
> > transport protocol, would also be = problematical.
>
> If the transport protocols are UDP, TCP, SCTP, = and ICMP, there isn't
> much problem with implementation.  Or = maybe I missed your point...

Well, this assumes that the ARs have end-point stacks = for all of the transport
protocols, and management interfaces, etc. Most = routers have ICMP/UDP support.
Not sure about TCP, and I doubt SCTP.

Technically, supporting 4+/- protocols is perhaps not = that big of a deal...but
where's the value?

>
> I think that HI and HAck from [mobile-ip] fast = handovers would be
> a very suitable transport for some contexts = that do not require
> rock-solid reliability, for those cases where = they are available.
> I think that TCP or SCTP would be just fine for = a lot of contexts
> that do require high reliability.  If we = don't have HI and HAck
> available, but we have contexts with = requirement for very low
> latency, then we can decide whether the = contexts should be
> encapsulated
> in ICMP, UDP, or some IP-level option.

Again, I have no problem ( at least at this point) = with saying that the
designer can run CT over one of a number of = protocols, say they are UDP,
SCTP, ICMP, TCP - I do have a problem with the idea = that each feature CT will
run over different protocols. Now, instead of one = context transfer, you have
at least one for each transport protocol used = (assuming feature CTs that use
the same transport can be multiplexed onto one = frame). This exacerbates many
issues such as transfer delay, ordering, updates = synchronization, etc.

>
> >   Obviously, I believe that it = is possible to convey all
> feature contexts with
> > one CT protocol, running over one (to be = determined) transport.
>
> I can't see this.  Some contexts have to = be transferred with very
> low latency, and have low reliability = requirement.  Some contexts
> have much more relaxed latency requirements, = but have high reliability
> requirements.  The same transport protocol = is unlikely to work for
> both.

The only reason you would separate the transports in = this case is if there
was an advantage to optimizing for the "low = performance" requirements. That is,
what is the problem with delivering a feature = context with a lower latency or
higher reliability?

There is certainly more overhead in adding a second, = higher latency or lower
reliability exchange then there is in putting all = the context on a transport
that met the most demanding requirements.

Usually, achieving low latency is in opposition to = high reliability either because
of the processing overhead with FEC, or the loop = response latency of a BEC (backward
error control). The total context is relatively = small in terms of the number
of bytes, and the latency requirements are not = sensitive to the microseconds required
to encode and decode FEC (particularly if for = proactive CT).


A number of ideas kicked around lately almost seem = imply the use of CT for state
synchronization between ARs. I really hope this is = not the case. If so, it really
does not jibe with the vision I have of what CT is = trying to accomplish, with is a
loose, best effort approach to improving the = seamlessness of handover.

State synchronization can be done much more = effectively below L3, without the overheads
of IP+transport.

Gary

>
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C23FC6.1830C3DE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 16:47: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 QAA10493 for ; Fri, 9 Aug 2002 16:47:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19423; Fri, 9 Aug 2002 16:39:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19392 for ; Fri, 9 Aug 2002 16:39:03 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09940 for ; Fri, 9 Aug 2002 16:37:47 -0400 (EDT) Message-ID: <014701c23fe4$86a35660$296015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "'Gary Kenward'" , , References: <35DBB8B7AC89D4118E98009027B1009B08AD56E6@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 9 Aug 2002 13:37:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Madjid/Gary, IAPP does not run at Layer 2, it is an IP protocol. Runs over UDP. It currently only support RADIUS contexts. ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'Gary Kenward'" ; "'James Kempf'" ; ; Sent: Thursday, August 08, 2002 2:00 PM Subject: RE: [Seamoby] Section 5.2 in CT Requirements > I keep hearing IAPP as a contender for CT. > IAPP only carries one context and that is Radius and that is because authentications > taking place in a WLAN depends on RADIUS and its servers. IAPP does not offer a generic > context transfer solution and it is not at layer 3 and it is L2 and L2 technology specific. > > Madjid > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Tuesday, August 06, 2002 12:26 PM > To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > James: > > All well and good, but the requirement basically states that CT > should run over a transport protocol, reliable or unreliable, IETF > or non-IETF...hmmm, not really a requirement, except that it implies > that CT does not include transport capabilities. > > BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned > with L3, with transfer of L2 as an option. Since we are already talking > about separate transport protocols for different features, I do not see > the rationalization for using CT to carry, or to replace, IAPP. > > Gary > > > -----Original Message----- > > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > > Sent: July 22, 2002 12:31 > > To: john.loughney@nokia.com; seamoby@ietf.org > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > > > John, > > > > > I disagree with your requirement, because I don't see a lot > > of meaning > > > and/or use in it. > > > > > > I think that different context may have different need. > > Timelyness & > > > reliability are 2 different and opposing needs. This is directly > > > relatable to the earlier discussion on dynamicisity of context. > > > A situation could occur where a context goes stale during > > re-transmission > > > when running over a reliable protocol. Some other context, > > such as security > > > may not time out, unless the end-user completely times out of the > > user-session. > > > > > > Besides going stale, it is entirely possible that some context may > > > be superceded. As this issue is fairly complex and > > intertwined with the > > > context being transfered, I suggest we don't have a > > reliability requirement, > > > but rather we try to do an analysis of the reliability > > needs and then > > > take this into the solution. > > > > > > Additionally, I don't think that we want to get into defining new > > > transport protocols or behaviors. > > > > > > > > > That is exactly why I proposed this requirement. The intent > > of this requirement, > > together with the newly proposed Section 5.8, is that it > > would be up to the > > particular feature context profile to specify the transport. > > > > Here's an example of why I think the requirement is needed. > > 802.11 specifies > > its own context transfer protocol, namely IAPP. If we specify > > that, for example, > > SCTP is required for transport, vendors on 802.11 would have > > to implement two > > context transfer protocols, IAPP and the Seamoby SCTP-based > > protocol. IMHO, it > > makes sense to only have one context transfer protocol and > > leverage a particular > > transport for the feature contexts that need it. > > > > Does this make sense? > > > > 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 Aug 9 16: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 QAA10753 for ; Fri, 9 Aug 2002 16:52:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19780; Fri, 9 Aug 2002 16:51:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19713 for ; Fri, 9 Aug 2002 16:51:22 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10671 for ; Fri, 9 Aug 2002 16:50:06 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g79Kogk18730; Fri, 9 Aug 2002 16:50:43 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 16:50:43 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C83@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 9 Aug 2002 16:50:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FE6.6CB487D6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FE6.6CB487D6 Content-Type: text/plain; charset="iso-8859-1" James: Please correct me if I am wrong, but 802.11 APs are layer 2 devices. The protocols used for IAPP may be L3 protocols, but the context is relevant to L2 only. Therefore, IAPP is an L2 context transfer solution, not an L3 ct solution. Layering is a model, not an implementation, so it is dangerous to get too hung up on the distinctions. L3 CT should be able to transfer L2 context, as long as the performance of the L3 CT solution meets the requirements of the L2 context. Said another way: we do not want L2 requirements for synchronization, latency, bandwidth, reliability, etc. driving the Seamoby L3 CT design. Transferring Radius context is possible with an L3 CT due to the nature of the Radius context. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: August 9, 2002 16:37 > To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH]; > john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Madjid/Gary, > > IAPP does not run at Layer 2, it is an IP protocol. Runs over > UDP. It currently > only support RADIUS contexts. > > > > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'Gary Kenward'" ; "'James Kempf'" > ; ; > > Sent: Thursday, August 08, 2002 2:00 PM > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > I keep hearing IAPP as a contender for CT. > > IAPP only carries one context and that is Radius and that is because > authentications > > taking place in a WLAN depends on RADIUS and its servers. > IAPP does not offer > a generic > > context transfer solution and it is not at layer 3 and it > is L2 and L2 > technology specific. > > > > Madjid > > -----Original Message----- > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Tuesday, August 06, 2002 12:26 PM > > To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org > > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > James: > > > > All well and good, but the requirement basically states that CT > > should run over a transport protocol, reliable or unreliable, IETF > > or non-IETF...hmmm, not really a requirement, except that it implies > > that CT does not include transport capabilities. > > > > BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned > > with L3, with transfer of L2 as an option. Since we are > already talking > > about separate transport protocols for different features, > I do not see > > the rationalization for using CT to carry, or to replace, IAPP. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > ] > > > Sent: July 22, 2002 12:31 > > > To: john.loughney@nokia.com; seamoby@ietf.org > > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > > John, > > > > > > > I disagree with your requirement, because I don't see a lot > > > of meaning > > > > and/or use in it. > > > > > > > > I think that different context may have different need. > > > Timelyness & > > > > reliability are 2 different and opposing needs. This > is directly > > > > relatable to the earlier discussion on dynamicisity of context. > > > > A situation could occur where a context goes stale during > > > re-transmission > > > > when running over a reliable protocol. Some other context, > > > such as security > > > > may not time out, unless the end-user completely times > out of the > > > user-session. > > > > > > > > Besides going stale, it is entirely possible that some > context may > > > > be superceded. As this issue is fairly complex and > > > intertwined with the > > > > context being transfered, I suggest we don't have a > > > reliability requirement, > > > > but rather we try to do an analysis of the reliability > > > needs and then > > > > take this into the solution. > > > > > > > > Additionally, I don't think that we want to get into > defining new > > > > transport protocols or behaviors. > > > > > > > > > > > > > That is exactly why I proposed this requirement. The intent > > > of this requirement, > > > together with the newly proposed Section 5.8, is that it > > > would be up to the > > > particular feature context profile to specify the transport. > > > > > > Here's an example of why I think the requirement is needed. > > > 802.11 specifies > > > its own context transfer protocol, namely IAPP. If we specify > > > that, for example, > > > SCTP is required for transport, vendors on 802.11 would have > > > to implement two > > > context transfer protocols, IAPP and the Seamoby SCTP-based > > > protocol. IMHO, it > > > makes sense to only have one context transfer protocol and > > > leverage a particular > > > transport for the feature contexts that need it. > > > > > > Does this make sense? > > > > > > jak > > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > ------_=_NextPart_001_01C23FE6.6CB487D6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

James:

Please correct me if I am wrong, but 802.11 APs are layer 2 devices.
The protocols used for IAPP may be L3 protocols, but the context is
relevant to L2 only. Therefore, IAPP is an L2 context transfer solution,
not an L3 ct solution.

Layering is a model, not an implementation, so it is dangerous to get too
hung up on the distinctions. L3 CT should be able to transfer L2 context,
as long as the performance of the L3 CT solution meets the requirements of
the L2 context. Said another way: we do not want L2 requirements for
synchronization, latency, bandwidth, reliability, etc. driving the Seamoby
L3 CT design.

Transferring Radius context is possible with an L3 CT due to the nature of
the Radius context.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: August 9, 2002 16:37
> To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH];
> john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Madjid/Gary,
>
> IAPP does not run at Layer 2, it is an IP protocol. Runs over
> UDP. It currently
> only support RADIUS contexts.
>
>
>
>
> ----- Original Message -----
> From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> To: "'Gary Kenward'" <gkenward@nortelnetworks.com>; "'James Kempf'"
> <kempf@docomolabs-usa.com>; <john.loughney@nokia.com>;
> <seamoby@ietf.org>
> Sent: Thursday, August 08, 2002 2:00 PM
> Subject: RE: [Seamoby] Section 5.2 in CT Requirements
>
>
> > I keep hearing IAPP  as a contender for CT.
> > IAPP only carries one context and that is Radius and that is because
> authentications
> > taking place in a WLAN depends on RADIUS and its servers.
> IAPP does not offer
> a generic
> > context transfer solution and it is not at layer 3 and it
> is L2 and L2
> technology specific.
> >
> > Madjid
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Tuesday, August 06, 2002 12:26 PM
> > To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org
> > Subject: RE: [Seamoby] Section 5.2 in CT Requirements
> >
> >
> >
> > James:
> >
> >   All well and good, but the requirement basically states that CT
> > should run over a transport protocol, reliable or unreliable, IETF
> > or non-IETF...hmmm, not really a requirement, except that it implies
> > that CT does not include transport capabilities.
> >
> >   BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned
> > with L3, with transfer of L2 as an option. Since we are
> already talking
> > about separate transport protocols for different features,
> I do not see
> > the rationalization for using CT to carry, or to replace, IAPP.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> <mailto:kempf@docomolabs-usa.com> ]
> > > Sent: July 22, 2002 12:31
> > > To: john.loughney@nokia.com; seamoby@ietf.org
> > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements
> > >
> > >
> > > John,
> > >
> > > > I disagree with your requirement, because I don't see a lot
> > > of meaning
> > > > and/or use in it.
> > > >
> > > > I think that different context may have different need.
> > > Timelyness &
> > > > reliability are 2 different and opposing needs.  This
> is directly
> > > > relatable to the earlier discussion on dynamicisity of context.
> > > > A situation could occur where a context goes stale during
> > > re-transmission
> > > > when running over a reliable protocol.  Some other context,
> > > such as security
> > > > may not time out, unless the end-user completely times
> out of the
> > > user-session.
> > > >
> > > > Besides going stale, it is entirely possible that some
> context may
> > > > be superceded.  As this issue is fairly complex and
> > > intertwined with the
> > > > context being transfered, I suggest we don't have a
> > > reliability requirement,
> > > > but rather we try to do an analysis of the reliability
> > > needs and then
> > > > take this into the solution.
> > > >
> > > > Additionally, I don't think that we want to get into
> defining new
> > > > transport protocols or behaviors.
> > > >
> > >
> > >
> > > That is exactly why I proposed this requirement. The intent
> > > of this requirement,
> > > together with the newly proposed Section 5.8, is that it
> > > would be up to the
> > > particular feature context profile to specify the transport.
> > >
> > > Here's an example of why I think the requirement is needed.
> > > 802.11 specifies
> > > its own context transfer protocol, namely IAPP. If we specify
> > > that, for example,
> > > SCTP is required for transport, vendors on 802.11 would have
> > > to implement two
> > > context transfer protocols, IAPP and the Seamoby SCTP-based
> > > protocol. IMHO, it
> > > makes sense to only have one context transfer protocol and
> > > leverage a particular
> > > transport for the feature contexts that need it.
> > >
> > > Does this make sense?
> > >
> > >             jak
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> <https://www1.ietf.org/mailman/listinfo/seamoby>
> > >
> >
> >
>
>

------_=_NextPart_001_01C23FE6.6CB487D6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 16:52: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 QAA10763 for ; Fri, 9 Aug 2002 16:52:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19809 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 16:53:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19780; Fri, 9 Aug 2002 16:51:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19713 for ; Fri, 9 Aug 2002 16:51:22 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10671 for ; Fri, 9 Aug 2002 16:50:06 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g79Kogk18730; Fri, 9 Aug 2002 16:50:43 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 16:50:43 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C83@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 9 Aug 2002 16:50:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FE6.6CB487D6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FE6.6CB487D6 Content-Type: text/plain; charset="iso-8859-1" James: Please correct me if I am wrong, but 802.11 APs are layer 2 devices. The protocols used for IAPP may be L3 protocols, but the context is relevant to L2 only. Therefore, IAPP is an L2 context transfer solution, not an L3 ct solution. Layering is a model, not an implementation, so it is dangerous to get too hung up on the distinctions. L3 CT should be able to transfer L2 context, as long as the performance of the L3 CT solution meets the requirements of the L2 context. Said another way: we do not want L2 requirements for synchronization, latency, bandwidth, reliability, etc. driving the Seamoby L3 CT design. Transferring Radius context is possible with an L3 CT due to the nature of the Radius context. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: August 9, 2002 16:37 > To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH]; > john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Madjid/Gary, > > IAPP does not run at Layer 2, it is an IP protocol. Runs over > UDP. It currently > only support RADIUS contexts. > > > > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'Gary Kenward'" ; "'James Kempf'" > ; ; > > Sent: Thursday, August 08, 2002 2:00 PM > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > I keep hearing IAPP as a contender for CT. > > IAPP only carries one context and that is Radius and that is because > authentications > > taking place in a WLAN depends on RADIUS and its servers. > IAPP does not offer > a generic > > context transfer solution and it is not at layer 3 and it > is L2 and L2 > technology specific. > > > > Madjid > > -----Original Message----- > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Tuesday, August 06, 2002 12:26 PM > > To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org > > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > James: > > > > All well and good, but the requirement basically states that CT > > should run over a transport protocol, reliable or unreliable, IETF > > or non-IETF...hmmm, not really a requirement, except that it implies > > that CT does not include transport capabilities. > > > > BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned > > with L3, with transfer of L2 as an option. Since we are > already talking > > about separate transport protocols for different features, > I do not see > > the rationalization for using CT to carry, or to replace, IAPP. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > ] > > > Sent: July 22, 2002 12:31 > > > To: john.loughney@nokia.com; seamoby@ietf.org > > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > > John, > > > > > > > I disagree with your requirement, because I don't see a lot > > > of meaning > > > > and/or use in it. > > > > > > > > I think that different context may have different need. > > > Timelyness & > > > > reliability are 2 different and opposing needs. This > is directly > > > > relatable to the earlier discussion on dynamicisity of context. > > > > A situation could occur where a context goes stale during > > > re-transmission > > > > when running over a reliable protocol. Some other context, > > > such as security > > > > may not time out, unless the end-user completely times > out of the > > > user-session. > > > > > > > > Besides going stale, it is entirely possible that some > context may > > > > be superceded. As this issue is fairly complex and > > > intertwined with the > > > > context being transfered, I suggest we don't have a > > > reliability requirement, > > > > but rather we try to do an analysis of the reliability > > > needs and then > > > > take this into the solution. > > > > > > > > Additionally, I don't think that we want to get into > defining new > > > > transport protocols or behaviors. > > > > > > > > > > > > > That is exactly why I proposed this requirement. The intent > > > of this requirement, > > > together with the newly proposed Section 5.8, is that it > > > would be up to the > > > particular feature context profile to specify the transport. > > > > > > Here's an example of why I think the requirement is needed. > > > 802.11 specifies > > > its own context transfer protocol, namely IAPP. If we specify > > > that, for example, > > > SCTP is required for transport, vendors on 802.11 would have > > > to implement two > > > context transfer protocols, IAPP and the Seamoby SCTP-based > > > protocol. IMHO, it > > > makes sense to only have one context transfer protocol and > > > leverage a particular > > > transport for the feature contexts that need it. > > > > > > Does this make sense? > > > > > > jak > > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > ------_=_NextPart_001_01C23FE6.6CB487D6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

James:

Please correct me if I am wrong, but 802.11 APs are layer 2 devices.
The protocols used for IAPP may be L3 protocols, but the context is
relevant to L2 only. Therefore, IAPP is an L2 context transfer solution,
not an L3 ct solution.

Layering is a model, not an implementation, so it is dangerous to get too
hung up on the distinctions. L3 CT should be able to transfer L2 context,
as long as the performance of the L3 CT solution meets the requirements of
the L2 context. Said another way: we do not want L2 requirements for
synchronization, latency, bandwidth, reliability, etc. driving the Seamoby
L3 CT design.

Transferring Radius context is possible with an L3 CT due to the nature of
the Radius context.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: August 9, 2002 16:37
> To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH];
> john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Madjid/Gary,
>
> IAPP does not run at Layer 2, it is an IP protocol. Runs over
> UDP. It currently
> only support RADIUS contexts.
>
>
>
>
> ----- Original Message -----
> From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> To: "'Gary Kenward'" <gkenward@nortelnetworks.com>; "'James Kempf'"
> <kempf@docomolabs-usa.com>; <john.loughney@nokia.com>;
> <seamoby@ietf.org>
> Sent: Thursday, August 08, 2002 2:00 PM
> Subject: RE: [Seamoby] Section 5.2 in CT Requirements
>
>
> > I keep hearing IAPP  as a contender for CT.
> > IAPP only carries one context and that is Radius and that is because
> authentications
> > taking place in a WLAN depends on RADIUS and its servers.
> IAPP does not offer
> a generic
> > context transfer solution and it is not at layer 3 and it
> is L2 and L2
> technology specific.
> >
> > Madjid
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Tuesday, August 06, 2002 12:26 PM
> > To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org
> > Subject: RE: [Seamoby] Section 5.2 in CT Requirements
> >
> >
> >
> > James:
> >
> >   All well and good, but the requirement basically states that CT
> > should run over a transport protocol, reliable or unreliable, IETF
> > or non-IETF...hmmm, not really a requirement, except that it implies
> > that CT does not include transport capabilities.
> >
> >   BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned
> > with L3, with transfer of L2 as an option. Since we are
> already talking
> > about separate transport protocols for different features,
> I do not see
> > the rationalization for using CT to carry, or to replace, IAPP.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> <mailto:kempf@docomolabs-usa.com> ]
> > > Sent: July 22, 2002 12:31
> > > To: john.loughney@nokia.com; seamoby@ietf.org
> > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements
> > >
> > >
> > > John,
> > >
> > > > I disagree with your requirement, because I don't see a lot
> > > of meaning
> > > > and/or use in it.
> > > >
> > > > I think that different context may have different need.
> > > Timelyness &
> > > > reliability are 2 different and opposing needs.  This
> is directly
> > > > relatable to the earlier discussion on dynamicisity of context.
> > > > A situation could occur where a context goes stale during
> > > re-transmission
> > > > when running over a reliable protocol.  Some other context,
> > > such as security
> > > > may not time out, unless the end-user completely times
> out of the
> > > user-session.
> > > >
> > > > Besides going stale, it is entirely possible that some
> context may
> > > > be superceded.  As this issue is fairly complex and
> > > intertwined with the
> > > > context being transfered, I suggest we don't have a
> > > reliability requirement,
> > > > but rather we try to do an analysis of the reliability
> > > needs and then
> > > > take this into the solution.
> > > >
> > > > Additionally, I don't think that we want to get into
> defining new
> > > > transport protocols or behaviors.
> > > >
> > >
> > >
> > > That is exactly why I proposed this requirement. The intent
> > > of this requirement,
> > > together with the newly proposed Section 5.8, is that it
> > > would be up to the
> > > particular feature context profile to specify the transport.
> > >
> > > Here's an example of why I think the requirement is needed.
> > > 802.11 specifies
> > > its own context transfer protocol, namely IAPP. If we specify
> > > that, for example,
> > > SCTP is required for transport, vendors on 802.11 would have
> > > to implement two
> > > context transfer protocols, IAPP and the Seamoby SCTP-based
> > > protocol. IMHO, it
> > > makes sense to only have one context transfer protocol and
> > > leverage a particular
> > > transport for the feature contexts that need it.
> > >
> > > Does this make sense?
> > >
> > >             jak
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> <https://www1.ietf.org/mailman/listinfo/seamoby>
> > >
> >
> >
>
>

------_=_NextPart_001_01C23FE6.6CB487D6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 17:19: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 RAA11618 for ; Fri, 9 Aug 2002 17:19:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21318; Fri, 9 Aug 2002 17:11:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21292 for ; Fri, 9 Aug 2002 17:11:40 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11290 for ; Fri, 9 Aug 2002 17:10:24 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g79LB7k19687; Fri, 9 Aug 2002 17:11:08 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 17:11:08 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C87@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby@ietf.org'" , "'monet@seamoby.org'" Date: Fri, 9 Aug 2002 17:11:07 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FE8.F188C952" Subject: [Seamoby] HighWLAN: A Driving Wireless Network Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FE8.F188C952 Content-Type: text/plain; charset="iso-8859-1" This is perhaps pushing the purpose of the email list a bit, but just for those who think mobile subnets are not real: http://www.oreillynet.com/pub/a/wireless/2002/08/01/highway_lan.html Hey, it's Friday. Gary Kenward ------_=_NextPart_001_01C23FE8.F188C952 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HighWLAN: A Driving Wireless Network

This is perhaps pushing the purpose of the email list = a bit, but just for
those who think mobile subnets are not real:

http://www.oreillynet.com/pub/a/wireless/2002/08/01/hi= ghway_lan.html


Hey, it's Friday.

Gary Kenward

------_=_NextPart_001_01C23FE8.F188C952-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 17:19: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 RAA11629 for ; Fri, 9 Aug 2002 17:19:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21522 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 17:20:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21318; Fri, 9 Aug 2002 17:11:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21292 for ; Fri, 9 Aug 2002 17:11:40 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11290 for ; Fri, 9 Aug 2002 17:10:24 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g79LB7k19687; Fri, 9 Aug 2002 17:11:08 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 17:11:08 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C87@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby@ietf.org'" , "'monet@seamoby.org'" Date: Fri, 9 Aug 2002 17:11:07 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FE8.F188C952" Subject: [Seamoby] HighWLAN: A Driving Wireless Network Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FE8.F188C952 Content-Type: text/plain; charset="iso-8859-1" This is perhaps pushing the purpose of the email list a bit, but just for those who think mobile subnets are not real: http://www.oreillynet.com/pub/a/wireless/2002/08/01/highway_lan.html Hey, it's Friday. Gary Kenward ------_=_NextPart_001_01C23FE8.F188C952 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HighWLAN: A Driving Wireless Network

This is perhaps pushing the purpose of the email list = a bit, but just for
those who think mobile subnets are not real:

http://www.oreillynet.com/pub/a/wireless/2002/08/01/hi= ghway_lan.html


Hey, it's Friday.

Gary Kenward

------_=_NextPart_001_01C23FE8.F188C952-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 17:25: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 RAA11985 for ; Fri, 9 Aug 2002 17:25:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21563; Fri, 9 Aug 2002 17:21:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21535 for ; Fri, 9 Aug 2002 17:21:15 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11687 for ; Fri, 9 Aug 2002 17:19:58 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA26808 for ; Fri, 9 Aug 2002 14:21:15 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA23360 for ; Fri, 9 Aug 2002 14:21:13 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 9 Aug 2002 16:21:13 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56EC@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 9 Aug 2002 16:21:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FEA.AE203A40" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FEA.AE203A40 Content-Type: text/plain; charset="iso-8859-1" Agreed to some extent. To be precise: context has to be present at layer 2 devices. by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP itself is below IP on the stack. CT on the other hand as of today is AR-AR. Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, August 09, 2002 3:51 PM To: 'James Kempf'; Nakhjiri Madjid-MNAKHJI1; john.loughney@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements James: Please correct me if I am wrong, but 802.11 APs are layer 2 devices. The protocols used for IAPP may be L3 protocols, but the context is relevant to L2 only. Therefore, IAPP is an L2 context transfer solution, not an L3 ct solution. Layering is a model, not an implementation, so it is dangerous to get too hung up on the distinctions. L3 CT should be able to transfer L2 context, as long as the performance of the L3 CT solution meets the requirements of the L2 context. Said another way: we do not want L2 requirements for synchronization, latency, bandwidth, reliability, etc. driving the Seamoby L3 CT design. Transferring Radius context is possible with an L3 CT due to the nature of the Radius context. Gary > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: August 9, 2002 16:37 > To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH]; > john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Madjid/Gary, > > IAPP does not run at Layer 2, it is an IP protocol. Runs over > UDP. It currently > only support RADIUS contexts. > > > > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'Gary Kenward'" ; "'James Kempf'" > ; ; > > Sent: Thursday, August 08, 2002 2:00 PM > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > I keep hearing IAPP as a contender for CT. > > IAPP only carries one context and that is Radius and that is because > authentications > > taking place in a WLAN depends on RADIUS and its servers. > IAPP does not offer > a generic > > context transfer solution and it is not at layer 3 and it > is L2 and L2 > technology specific. > > > > Madjid > > -----Original Message----- > > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > Sent: Tuesday, August 06, 2002 12:26 PM > > To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org > > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > James: > > > > All well and good, but the requirement basically states that CT > > should run over a transport protocol, reliable or unreliable, IETF > > or non-IETF...hmmm, not really a requirement, except that it implies > > that CT does not include transport capabilities. > > > > BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned > > with L3, with transfer of L2 as an option. Since we are > already talking > > about separate transport protocols for different features, > I do not see > > the rationalization for using CT to carry, or to replace, IAPP. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > < mailto:kempf@docomolabs-usa.com > ] > > > Sent: July 22, 2002 12:31 > > > To: john.loughney@nokia.com; seamoby@ietf.org > > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > > John, > > > > > > > I disagree with your requirement, because I don't see a lot > > > of meaning > > > > and/or use in it. > > > > > > > > I think that different context may have different need. > > > Timelyness & > > > > reliability are 2 different and opposing needs. This > is directly > > > > relatable to the earlier discussion on dynamicisity of context. > > > > A situation could occur where a context goes stale during > > > re-transmission > > > > when running over a reliable protocol. Some other context, > > > such as security > > > > may not time out, unless the end-user completely times > out of the > > > user-session. > > > > > > > > Besides going stale, it is entirely possible that some > context may > > > > be superceded. As this issue is fairly complex and > > > intertwined with the > > > > context being transfered, I suggest we don't have a > > > reliability requirement, > > > > but rather we try to do an analysis of the reliability > > > needs and then > > > > take this into the solution. > > > > > > > > Additionally, I don't think that we want to get into > defining new > > > > transport protocols or behaviors. > > > > > > > > > > > > > That is exactly why I proposed this requirement. The intent > > > of this requirement, > > > together with the newly proposed Section 5.8, is that it > > > would be up to the > > > particular feature context profile to specify the transport. > > > > > > Here's an example of why I think the requirement is needed. > > > 802.11 specifies > > > its own context transfer protocol, namely IAPP. If we specify > > > that, for example, > > > SCTP is required for transport, vendors on 802.11 would have > > > to implement two > > > context transfer protocols, IAPP and the Seamoby SCTP-based > > > protocol. IMHO, it > > > makes sense to only have one context transfer protocol and > > > leverage a particular > > > transport for the feature contexts that need it. > > > > > > Does this make sense? > > > > > > jak > > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > < https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > ------_=_NextPart_001_01C23FEA.AE203A40 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements
Agreed to some extent. To be precise: context has to be present at layer 2 devices. 
 
by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP itself is below IP on the stack.
CT on the other hand as of today is AR-AR.
 
Madjid 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, August 09, 2002 3:51 PM
To: 'James Kempf'; Nakhjiri Madjid-MNAKHJI1; john.loughney@nokia.com; seamoby@ietf.org
Subject: RE: [Seamoby] Section 5.2 in CT Requirements

James:

Please correct me if I am wrong, but 802.11 APs are layer 2 devices.
The protocols used for IAPP may be L3 protocols, but the context is
relevant to L2 only. Therefore, IAPP is an L2 context transfer solution,
not an L3 ct solution.

Layering is a model, not an implementation, so it is dangerous to get too
hung up on the distinctions. L3 CT should be able to transfer L2 context,
as long as the performance of the L3 CT solution meets the requirements of
the L2 context. Said another way: we do not want L2 requirements for
synchronization, latency, bandwidth, reliability, etc. driving the Seamoby
L3 CT design.

Transferring Radius context is possible with an L3 CT due to the nature of
the Radius context.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: August 9, 2002 16:37
> To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH];
> john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Madjid/Gary,
>
> IAPP does not run at Layer 2, it is an IP protocol. Runs over
> UDP. It currently
> only support RADIUS contexts.
>
>
>
>
> ----- Original Message -----
> From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> To: "'Gary Kenward'" <gkenward@nortelnetworks.com>; "'James Kempf'"
> <kempf@docomolabs-usa.com>; <john.loughney@nokia.com>;
> <seamoby@ietf.org>
> Sent: Thursday, August 08, 2002 2:00 PM
> Subject: RE: [Seamoby] Section 5.2 in CT Requirements
>
>
> > I keep hearing IAPP  as a contender for CT.
> > IAPP only carries one context and that is Radius and that is because
> authentications
> > taking place in a WLAN depends on RADIUS and its servers.
> IAPP does not offer
> a generic
> > context transfer solution and it is not at layer 3 and it
> is L2 and L2
> technology specific.
> >
> > Madjid
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Tuesday, August 06, 2002 12:26 PM
> > To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org
> > Subject: RE: [Seamoby] Section 5.2 in CT Requirements
> >
> >
> >
> > James:
> >
> >   All well and good, but the requirement basically states that CT
> > should run over a transport protocol, reliable or unreliable, IETF
> > or non-IETF...hmmm, not really a requirement, except that it implies
> > that CT does not include transport capabilities.
> >
> >   BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned
> > with L3, with transfer of L2 as an option. Since we are
> already talking
> > about separate transport protocols for different features,
> I do not see
> > the rationalization for using CT to carry, or to replace, IAPP.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> <mailto:kempf@docomolabs-usa.com> ]
> > > Sent: July 22, 2002 12:31
> > > To: john.loughney@nokia.com; seamoby@ietf.org
> > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements
> > >
> > >
> > > John,
> > >
> > > > I disagree with your requirement, because I don't see a lot
> > > of meaning
> > > > and/or use in it.
> > > >
> > > > I think that different context may have different need.
> > > Timelyness &
> > > > reliability are 2 different and opposing needs.  This
> is directly
> > > > relatable to the earlier discussion on dynamicisity of context.
> > > > A situation could occur where a context goes stale during
> > > re-transmission
> > > > when running over a reliable protocol.  Some other context,
> > > such as security
> > > > may not time out, unless the end-user completely times
> out of the
> > > user-session.
> > > >
> > > > Besides going stale, it is entirely possible that some
> context may
> > > > be superceded.  As this issue is fairly complex and
> > > intertwined with the
> > > > context being transfered, I suggest we don't have a
> > > reliability requirement,
> > > > but rather we try to do an analysis of the reliability
> > > needs and then
> > > > take this into the solution.
> > > >
> > > > Additionally, I don't think that we want to get into
> defining new
> > > > transport protocols or behaviors.
> > > >
> > >
> > >
> > > That is exactly why I proposed this requirement. The intent
> > > of this requirement,
> > > together with the newly proposed Section 5.8, is that it
> > > would be up to the
> > > particular feature context profile to specify the transport.
> > >
> > > Here's an example of why I think the requirement is needed.
> > > 802.11 specifies
> > > its own context transfer protocol, namely IAPP. If we specify
> > > that, for example,
> > > SCTP is required for transport, vendors on 802.11 would have
> > > to implement two
> > > context transfer protocols, IAPP and the Seamoby SCTP-based
> > > protocol. IMHO, it
> > > makes sense to only have one context transfer protocol and
> > > leverage a particular
> > > transport for the feature contexts that need it.
> > >
> > > Does this make sense?
> > >
> > >             jak
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> <https://www1.ietf.org/mailman/listinfo/seamoby>
> > >
> >
> >
>
>

------_=_NextPart_001_01C23FEA.AE203A40-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 17:25: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 RAA11995 for ; Fri, 9 Aug 2002 17:25:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21640 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 17:26:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21563; Fri, 9 Aug 2002 17:21:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21535 for ; Fri, 9 Aug 2002 17:21:15 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11687 for ; Fri, 9 Aug 2002 17:19:58 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA26808 for ; Fri, 9 Aug 2002 14:21:15 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA23360 for ; Fri, 9 Aug 2002 14:21:13 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 9 Aug 2002 16:21:13 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56EC@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 9 Aug 2002 16:21:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FEA.AE203A40" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FEA.AE203A40 Content-Type: text/plain; charset="iso-8859-1" Agreed to some extent. To be precise: context has to be present at layer 2 devices. by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP itself is below IP on the stack. CT on the other hand as of today is AR-AR. Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, August 09, 2002 3:51 PM To: 'James Kempf'; Nakhjiri Madjid-MNAKHJI1; john.loughney@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements James: Please correct me if I am wrong, but 802.11 APs are layer 2 devices. The protocols used for IAPP may be L3 protocols, but the context is relevant to L2 only. Therefore, IAPP is an L2 context transfer solution, not an L3 ct solution. Layering is a model, not an implementation, so it is dangerous to get too hung up on the distinctions. L3 CT should be able to transfer L2 context, as long as the performance of the L3 CT solution meets the requirements of the L2 context. Said another way: we do not want L2 requirements for synchronization, latency, bandwidth, reliability, etc. driving the Seamoby L3 CT design. Transferring Radius context is possible with an L3 CT due to the nature of the Radius context. Gary > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: August 9, 2002 16:37 > To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH]; > john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Madjid/Gary, > > IAPP does not run at Layer 2, it is an IP protocol. Runs over > UDP. It currently > only support RADIUS contexts. > > > > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'Gary Kenward'" ; "'James Kempf'" > ; ; > > Sent: Thursday, August 08, 2002 2:00 PM > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > I keep hearing IAPP as a contender for CT. > > IAPP only carries one context and that is Radius and that is because > authentications > > taking place in a WLAN depends on RADIUS and its servers. > IAPP does not offer > a generic > > context transfer solution and it is not at layer 3 and it > is L2 and L2 > technology specific. > > > > Madjid > > -----Original Message----- > > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > Sent: Tuesday, August 06, 2002 12:26 PM > > To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org > > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > James: > > > > All well and good, but the requirement basically states that CT > > should run over a transport protocol, reliable or unreliable, IETF > > or non-IETF...hmmm, not really a requirement, except that it implies > > that CT does not include transport capabilities. > > > > BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned > > with L3, with transfer of L2 as an option. Since we are > already talking > > about separate transport protocols for different features, > I do not see > > the rationalization for using CT to carry, or to replace, IAPP. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > < mailto:kempf@docomolabs-usa.com > ] > > > Sent: July 22, 2002 12:31 > > > To: john.loughney@nokia.com; seamoby@ietf.org > > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > > John, > > > > > > > I disagree with your requirement, because I don't see a lot > > > of meaning > > > > and/or use in it. > > > > > > > > I think that different context may have different need. > > > Timelyness & > > > > reliability are 2 different and opposing needs. This > is directly > > > > relatable to the earlier discussion on dynamicisity of context. > > > > A situation could occur where a context goes stale during > > > re-transmission > > > > when running over a reliable protocol. Some other context, > > > such as security > > > > may not time out, unless the end-user completely times > out of the > > > user-session. > > > > > > > > Besides going stale, it is entirely possible that some > context may > > > > be superceded. As this issue is fairly complex and > > > intertwined with the > > > > context being transfered, I suggest we don't have a > > > reliability requirement, > > > > but rather we try to do an analysis of the reliability > > > needs and then > > > > take this into the solution. > > > > > > > > Additionally, I don't think that we want to get into > defining new > > > > transport protocols or behaviors. > > > > > > > > > > > > > That is exactly why I proposed this requirement. The intent > > > of this requirement, > > > together with the newly proposed Section 5.8, is that it > > > would be up to the > > > particular feature context profile to specify the transport. > > > > > > Here's an example of why I think the requirement is needed. > > > 802.11 specifies > > > its own context transfer protocol, namely IAPP. If we specify > > > that, for example, > > > SCTP is required for transport, vendors on 802.11 would have > > > to implement two > > > context transfer protocols, IAPP and the Seamoby SCTP-based > > > protocol. IMHO, it > > > makes sense to only have one context transfer protocol and > > > leverage a particular > > > transport for the feature contexts that need it. > > > > > > Does this make sense? > > > > > > jak > > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > < https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > ------_=_NextPart_001_01C23FEA.AE203A40 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements
Agreed to some extent. To be precise: context has to be present at layer 2 devices. 
 
by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP itself is below IP on the stack.
CT on the other hand as of today is AR-AR.
 
Madjid 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, August 09, 2002 3:51 PM
To: 'James Kempf'; Nakhjiri Madjid-MNAKHJI1; john.loughney@nokia.com; seamoby@ietf.org
Subject: RE: [Seamoby] Section 5.2 in CT Requirements

James:

Please correct me if I am wrong, but 802.11 APs are layer 2 devices.
The protocols used for IAPP may be L3 protocols, but the context is
relevant to L2 only. Therefore, IAPP is an L2 context transfer solution,
not an L3 ct solution.

Layering is a model, not an implementation, so it is dangerous to get too
hung up on the distinctions. L3 CT should be able to transfer L2 context,
as long as the performance of the L3 CT solution meets the requirements of
the L2 context. Said another way: we do not want L2 requirements for
synchronization, latency, bandwidth, reliability, etc. driving the Seamoby
L3 CT design.

Transferring Radius context is possible with an L3 CT due to the nature of
the Radius context.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: August 9, 2002 16:37
> To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH];
> john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Madjid/Gary,
>
> IAPP does not run at Layer 2, it is an IP protocol. Runs over
> UDP. It currently
> only support RADIUS contexts.
>
>
>
>
> ----- Original Message -----
> From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> To: "'Gary Kenward'" <gkenward@nortelnetworks.com>; "'James Kempf'"
> <kempf@docomolabs-usa.com>; <john.loughney@nokia.com>;
> <seamoby@ietf.org>
> Sent: Thursday, August 08, 2002 2:00 PM
> Subject: RE: [Seamoby] Section 5.2 in CT Requirements
>
>
> > I keep hearing IAPP  as a contender for CT.
> > IAPP only carries one context and that is Radius and that is because
> authentications
> > taking place in a WLAN depends on RADIUS and its servers.
> IAPP does not offer
> a generic
> > context transfer solution and it is not at layer 3 and it
> is L2 and L2
> technology specific.
> >
> > Madjid
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Tuesday, August 06, 2002 12:26 PM
> > To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org
> > Subject: RE: [Seamoby] Section 5.2 in CT Requirements
> >
> >
> >
> > James:
> >
> >   All well and good, but the requirement basically states that CT
> > should run over a transport protocol, reliable or unreliable, IETF
> > or non-IETF...hmmm, not really a requirement, except that it implies
> > that CT does not include transport capabilities.
> >
> >   BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned
> > with L3, with transfer of L2 as an option. Since we are
> already talking
> > about separate transport protocols for different features,
> I do not see
> > the rationalization for using CT to carry, or to replace, IAPP.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> <mailto:kempf@docomolabs-usa.com> ]
> > > Sent: July 22, 2002 12:31
> > > To: john.loughney@nokia.com; seamoby@ietf.org
> > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements
> > >
> > >
> > > John,
> > >
> > > > I disagree with your requirement, because I don't see a lot
> > > of meaning
> > > > and/or use in it.
> > > >
> > > > I think that different context may have different need.
> > > Timelyness &
> > > > reliability are 2 different and opposing needs.  This
> is directly
> > > > relatable to the earlier discussion on dynamicisity of context.
> > > > A situation could occur where a context goes stale during
> > > re-transmission
> > > > when running over a reliable protocol.  Some other context,
> > > such as security
> > > > may not time out, unless the end-user completely times
> out of the
> > > user-session.
> > > >
> > > > Besides going stale, it is entirely possible that some
> context may
> > > > be superceded.  As this issue is fairly complex and
> > > intertwined with the
> > > > context being transfered, I suggest we don't have a
> > > reliability requirement,
> > > > but rather we try to do an analysis of the reliability
> > > needs and then
> > > > take this into the solution.
> > > >
> > > > Additionally, I don't think that we want to get into
> defining new
> > > > transport protocols or behaviors.
> > > >
> > >
> > >
> > > That is exactly why I proposed this requirement. The intent
> > > of this requirement,
> > > together with the newly proposed Section 5.8, is that it
> > > would be up to the
> > > particular feature context profile to specify the transport.
> > >
> > > Here's an example of why I think the requirement is needed.
> > > 802.11 specifies
> > > its own context transfer protocol, namely IAPP. If we specify
> > > that, for example,
> > > SCTP is required for transport, vendors on 802.11 would have
> > > to implement two
> > > context transfer protocols, IAPP and the Seamoby SCTP-based
> > > protocol. IMHO, it
> > > makes sense to only have one context transfer protocol and
> > > leverage a particular
> > > transport for the feature contexts that need it.
> > >
> > > Does this make sense?
> > >
> > >             jak
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> <https://www1.ietf.org/mailman/listinfo/seamoby>
> > >
> >
> >
>
>

------_=_NextPart_001_01C23FEA.AE203A40-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 17:33: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 RAA12252 for ; Fri, 9 Aug 2002 17:33:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21694; Fri, 9 Aug 2002 17:28:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21666 for ; Fri, 9 Aug 2002 17:28:36 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12058 for ; Fri, 9 Aug 2002 17:27:19 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA04579 for ; Fri, 9 Aug 2002 14:28:34 -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 OAA14442 for ; Fri, 9 Aug 2002 14:26:47 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 9 Aug 2002 16:28:32 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56ED@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Gary Kenward Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications Date: Fri, 9 Aug 2002 16:28:31 -0500 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 I agree with both of the following responses. I don't think multiplexing all context is main design criterion for CT. Different contexts can have different transport and reliability needs. Everybody agrees that we should have one generic CT protocol with minimal functionality to accomodate those features that require simplicity. Other features on the other hand may need additional functionality, but that does not mean the more complex extension has to become part of the generic protocol. Madjid -> ........ there would be little to the > actual CT protocol except for a specification of the feature context > encapsulation format, and possibly the rules for multiplexing multiple > feature contexts onto a give transport frame. But that would already be quite valuable, from my perspective. > Obviously, I believe that it is possible to convey all feature contexts with > one CT protocol, running over one (to be determined) transport. I can't see this. Some contexts have to be transferred with very low latency, and have low reliability requirement. Some contexts have much more relaxed latency requirements, but have high reliability requirements. The same transport protocol is unlikely to work for both. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 17:33: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 RAA12260 for ; Fri, 9 Aug 2002 17:33:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22408 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 17:35:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21694; Fri, 9 Aug 2002 17:28:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21666 for ; Fri, 9 Aug 2002 17:28:36 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12058 for ; Fri, 9 Aug 2002 17:27:19 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA04579 for ; Fri, 9 Aug 2002 14:28:34 -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 OAA14442 for ; Fri, 9 Aug 2002 14:26:47 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 9 Aug 2002 16:28:32 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56ED@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Gary Kenward Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications Date: Fri, 9 Aug 2002 16:28:31 -0500 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 I agree with both of the following responses. I don't think multiplexing all context is main design criterion for CT. Different contexts can have different transport and reliability needs. Everybody agrees that we should have one generic CT protocol with minimal functionality to accomodate those features that require simplicity. Other features on the other hand may need additional functionality, but that does not mean the more complex extension has to become part of the generic protocol. Madjid -> ........ there would be little to the > actual CT protocol except for a specification of the feature context > encapsulation format, and possibly the rules for multiplexing multiple > feature contexts onto a give transport frame. But that would already be quite valuable, from my perspective. > Obviously, I believe that it is possible to convey all feature contexts with > one CT protocol, running over one (to be determined) transport. I can't see this. Some contexts have to be transferred with very low latency, and have low reliability requirement. Some contexts have much more relaxed latency requirements, but have high reliability requirements. The same transport protocol is unlikely to work for both. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 17:40: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 QAA10501 for ; Fri, 9 Aug 2002 16:47:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19608 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 16:49:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19423; Fri, 9 Aug 2002 16:39:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19392 for ; Fri, 9 Aug 2002 16:39:03 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09940 for ; Fri, 9 Aug 2002 16:37:47 -0400 (EDT) Message-ID: <014701c23fe4$86a35660$296015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "'Gary Kenward'" , , References: <35DBB8B7AC89D4118E98009027B1009B08AD56E6@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 9 Aug 2002 13:37:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Madjid/Gary, IAPP does not run at Layer 2, it is an IP protocol. Runs over UDP. It currently only support RADIUS contexts. ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'Gary Kenward'" ; "'James Kempf'" ; ; Sent: Thursday, August 08, 2002 2:00 PM Subject: RE: [Seamoby] Section 5.2 in CT Requirements > I keep hearing IAPP as a contender for CT. > IAPP only carries one context and that is Radius and that is because authentications > taking place in a WLAN depends on RADIUS and its servers. IAPP does not offer a generic > context transfer solution and it is not at layer 3 and it is L2 and L2 technology specific. > > Madjid > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Tuesday, August 06, 2002 12:26 PM > To: 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > James: > > All well and good, but the requirement basically states that CT > should run over a transport protocol, reliable or unreliable, IETF > or non-IETF...hmmm, not really a requirement, except that it implies > that CT does not include transport capabilities. > > BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned > with L3, with transfer of L2 as an option. Since we are already talking > about separate transport protocols for different features, I do not see > the rationalization for using CT to carry, or to replace, IAPP. > > Gary > > > -----Original Message----- > > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > > Sent: July 22, 2002 12:31 > > To: john.loughney@nokia.com; seamoby@ietf.org > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > > > John, > > > > > I disagree with your requirement, because I don't see a lot > > of meaning > > > and/or use in it. > > > > > > I think that different context may have different need. > > Timelyness & > > > reliability are 2 different and opposing needs. This is directly > > > relatable to the earlier discussion on dynamicisity of context. > > > A situation could occur where a context goes stale during > > re-transmission > > > when running over a reliable protocol. Some other context, > > such as security > > > may not time out, unless the end-user completely times out of the > > user-session. > > > > > > Besides going stale, it is entirely possible that some context may > > > be superceded. As this issue is fairly complex and > > intertwined with the > > > context being transfered, I suggest we don't have a > > reliability requirement, > > > but rather we try to do an analysis of the reliability > > needs and then > > > take this into the solution. > > > > > > Additionally, I don't think that we want to get into defining new > > > transport protocols or behaviors. > > > > > > > > > That is exactly why I proposed this requirement. The intent > > of this requirement, > > together with the newly proposed Section 5.8, is that it > > would be up to the > > particular feature context profile to specify the transport. > > > > Here's an example of why I think the requirement is needed. > > 802.11 specifies > > its own context transfer protocol, namely IAPP. If we specify > > that, for example, > > SCTP is required for transport, vendors on 802.11 would have > > to implement two > > context transfer protocols, IAPP and the Seamoby SCTP-based > > protocol. IMHO, it > > makes sense to only have one context transfer protocol and > > leverage a particular > > transport for the feature contexts that need it. > > > > Does this make sense? > > > > 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 Aug 9 17:48: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 RAA12668 for ; Fri, 9 Aug 2002 17:48:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22634; Fri, 9 Aug 2002 17:44:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22569 for ; Fri, 9 Aug 2002 17:44:35 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12462 for ; Fri, 9 Aug 2002 17:43:18 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA00572 for ; Fri, 9 Aug 2002 14:44:32 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA21608 for ; Fri, 9 Aug 2002 14:44:54 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 9 Aug 2002 16:44:32 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56EE@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Fri, 9 Aug 2002 16:44:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FED.F1C3B850" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FED.F1C3B850 Content-Type: text/plain; charset="ISO-8859-1" As far as AR not supporting TCP or SCTP, I don't think anybody is designing CT to an arbitrary node across internet. I will only do CT with some network I know and have some kind of relationship with, but that is another issues. the point is, if somebody wants to use CT for their feature and wants to use TCP or SCTP for reliability for that feature context transfer then, that designer has to make sure TCP/ SCTP are presented on those AR' s stacks. I think the point here is that CT is designed to be independent of transport protocol and it is already stated in the suggested text. No transport protocol is suggested or mandated. CT is not making the use of those protocols a must, From the last year's experience, we know that trying to mandate one specific transport protocol for CT for all features won't lead to a consensus. Lets drop the discussion on transport layer of choice... I think transport protocol discussion for each feature, has to be diverted to the group that handles that feature. -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, August 09, 2002 11:59 AM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Charlie: > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@iprg.nokia.com ] > Sent: August 9, 2002 12:07 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > I'd like to represent another viewpoint. Certainly. > > > Gary Kenward wrote: > > > The main issue is > > that I see a tendency towards having a different transport for every > > feature context, > > How about a mapping of feature contexts into a small number of > transport protocols (e.g., UDP, TCP, SCTP, ICMP)? May happen. Why make it a requirement, or imply that this is the best solution within the requirements document? There is a debate to take place over this issue, and we should have it, when the we start discussing solutions. But let us not presume that it is part of the solution. > > > with potentially different mappings for > each combination > > of context and transport protocol combination. > > Can you be more specific about what you mean here? If all context is transfer as data chunks in the payload, then there really isn't a problem. However, if one starts mapping ct information into option fields of various protocols, the mappings will very likely change due to the differences in protocol syntax. IPv4 vs. IPv6 seems to be the most pronounced example. > > > ........ there would be little to the > > actual CT protocol except for a specification of the feature context > > encapsulation format, and possibly the rules for > multiplexing multiple > > feature contexts onto a give transport frame. > > But that would already be quite valuable, from my perspective. A necessary component of the total solution for CT, but definitely only part of the answer. The real issue here is whether the CT capability is fulfilled with a single protocol or a suite of protocols. I believe the former is a preferable solution, if the protocol complexity is manageable, which I believe it is. We have pretty well decided that CT capability involves at least two protocols (above IP): a CT containerizing protocol, and a transport protocol. Two is still better then a gaggle of protocols, IMHO. > > > Implementation of a collection of protocols, feature CT and > each associated > > transport protocol, would also be problematical. > > If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't > much problem with implementation. Or maybe I missed your point... Well, this assumes that the ARs have end-point stacks for all of the transport protocols, and management interfaces, etc. Most routers have ICMP/UDP support. Not sure about TCP, and I doubt SCTP. Technically, supporting 4+/- protocols is perhaps not that big of a deal...but where's the value? > > I think that HI and HAck from [mobile-ip] fast handovers would be > a very suitable transport for some contexts that do not require > rock-solid reliability, for those cases where they are available. > I think that TCP or SCTP would be just fine for a lot of contexts > that do require high reliability. If we don't have HI and HAck > available, but we have contexts with requirement for very low > latency, then we can decide whether the contexts should be > encapsulated > in ICMP, UDP, or some IP-level option. Again, I have no problem ( at least at this point) with saying that the designer can run CT over one of a number of protocols, say they are UDP, SCTP, ICMP, TCP - I do have a problem with the idea that each feature CT will run over different protocols. Now, instead of one context transfer, you have at least one for each transport protocol used (assuming feature CTs that use the same transport can be multiplexed onto one frame). This exacerbates many issues such as transfer delay, ordering, updates synchronization, etc. > > > Obviously, I believe that it is possible to convey all > feature contexts with > > one CT protocol, running over one (to be determined) transport. > > I can't see this. Some contexts have to be transferred with very > low latency, and have low reliability requirement. Some contexts > have much more relaxed latency requirements, but have high reliability > requirements. The same transport protocol is unlikely to work for > both. The only reason you would separate the transports in this case is if there was an advantage to optimizing for the "low performance" requirements. That is, what is the problem with delivering a feature context with a lower latency or higher reliability? There is certainly more overhead in adding a second, higher latency or lower reliability exchange then there is in putting all the context on a transport that met the most demanding requirements. Usually, achieving low latency is in opposition to high reliability either because of the processing overhead with FEC, or the loop response latency of a BEC (backward error control). The total context is relatively small in terms of the number of bytes, and the latency requirements are not sensitive to the microseconds required to encode and decode FEC (particularly if for proactive CT). A number of ideas kicked around lately almost seem imply the use of CT for state synchronization between ARs. I really hope this is not the case. If so, it really does not jibe with the vision I have of what CT is trying to accomplish, with is a loose, best effort approach to improving the seamlessness of handover. State synchronization can be done much more effectively below L3, without the overheads of IP+transport. Gary > > > Regards, > Charlie P. > ------_=_NextPart_001_01C23FED.F1C3B850 Content-Type: text/html; charset="ISO-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications
As far as AR not supporting TCP or SCTP, I don't think anybody is designing CT to an arbitrary node across internet.
I will only do CT with some network I know and have some kind of relationship with, but that is another issues.
 
the point is, if somebody wants to use CT for their feature and wants to use TCP or SCTP for reliability for that feature context transfer then, that designer has to make sure TCP/ SCTP are presented on those AR' s stacks.
 
I think the point here is that CT is designed to be independent of transport protocol and it is already stated in the suggested text. No transport protocol is suggested or mandated. CT is not making the use of those protocols a must,
From the last year's experience, we know that trying to mandate one specific transport protocol for CT for all features won't lead to a consensus. Lets drop the discussion on transport layer of choice...
I think transport protocol discussion for each feature, has to be diverted to the group that handles that feature.
 
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, August 09, 2002 11:59 AM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

Charlie:

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 9, 2002 12:07
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> I'd like to represent another viewpoint.

Certainly.

>
> > Gary Kenward wrote:
>
> >                                                The main issue is
> > that I see a tendency towards having a different transport for every
> > feature context,
>
> How about a mapping of feature contexts into a small number of
> transport protocols (e.g., UDP, TCP, SCTP, ICMP)?

May happen. Why make it a requirement, or imply that this is the best
solution within the requirements document? There is a debate to take
place over this issue, and we should have it, when the we start discussing
solutions. But let us not presume that it is part of the solution.

>
> >                   with potentially different mappings for
> each combination
> > of context and transport protocol combination.
>
> Can you be more specific about what you mean here?

If all context is transfer as data chunks in the payload, then there really isn't
a problem. However, if one starts mapping ct information into option fields of various
protocols, the mappings will very likely change due to the differences in protocol
syntax. IPv4 vs. IPv6 seems to be the most pronounced example.

>
> >          ........                       there would be little to the
> > actual CT protocol except for a specification of the feature context
> > encapsulation format, and possibly the rules for
> multiplexing multiple
> > feature contexts onto a give transport frame.
>
> But that would already be quite valuable, from my perspective.

A necessary component of the total solution for CT, but definitely
only part of the answer. The real issue here is whether the CT capability is
fulfilled with a single protocol or a suite of protocols. I believe the former is
a preferable solution, if the protocol complexity is manageable, which I believe it
is.

We have pretty well decided that CT capability involves at least two protocols (above IP):
a CT containerizing protocol, and a transport protocol. Two is still better then a gaggle
of protocols, IMHO.

>
> > Implementation of a collection of protocols, feature CT and
> each associated
> > transport protocol, would also be problematical.
>
> If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't
> much problem with implementation.  Or maybe I missed your point...

Well, this assumes that the ARs have end-point stacks for all of the transport
protocols, and management interfaces, etc. Most routers have ICMP/UDP support.
Not sure about TCP, and I doubt SCTP.

Technically, supporting 4+/- protocols is perhaps not that big of a deal...but
where's the value?

>
> I think that HI and HAck from [mobile-ip] fast handovers would be
> a very suitable transport for some contexts that do not require
> rock-solid reliability, for those cases where they are available.
> I think that TCP or SCTP would be just fine for a lot of contexts
> that do require high reliability.  If we don't have HI and HAck
> available, but we have contexts with requirement for very low
> latency, then we can decide whether the contexts should be
> encapsulated
> in ICMP, UDP, or some IP-level option.

Again, I have no problem ( at least at this point) with saying that the
designer can run CT over one of a number of protocols, say they are UDP,
SCTP, ICMP, TCP - I do have a problem with the idea that each feature CT will
run over different protocols. Now, instead of one context transfer, you have
at least one for each transport protocol used (assuming feature CTs that use
the same transport can be multiplexed onto one frame). This exacerbates many
issues such as transfer delay, ordering, updates synchronization, etc.

>
> >   Obviously, I believe that it is possible to convey all
> feature contexts with
> > one CT protocol, running over one (to be determined) transport.
>
> I can't see this.  Some contexts have to be transferred with very
> low latency, and have low reliability requirement.  Some contexts
> have much more relaxed latency requirements, but have high reliability
> requirements.  The same transport protocol is unlikely to work for
> both.

The only reason you would separate the transports in this case is if there
was an advantage to optimizing for the "low performance" requirements. That is,
what is the problem with delivering a feature context with a lower latency or
higher reliability?

There is certainly more overhead in adding a second, higher latency or lower
reliability exchange then there is in putting all the context on a transport
that met the most demanding requirements.

Usually, achieving low latency is in opposition to high reliability either because
of the processing overhead with FEC, or the loop response latency of a BEC (backward
error control). The total context is relatively small in terms of the number
of bytes, and the latency requirements are not sensitive to the microseconds required
to encode and decode FEC (particularly if for proactive CT).


A number of ideas kicked around lately almost seem imply the use of CT for state
synchronization between ARs. I really hope this is not the case. If so, it really
does not jibe with the vision I have of what CT is trying to accomplish, with is a
loose, best effort approach to improving the seamlessness of handover.

State synchronization can be done much more effectively below L3, without the overheads
of IP+transport.

Gary

>
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C23FED.F1C3B850-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 17:48: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 RAA12682 for ; Fri, 9 Aug 2002 17:48:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22784 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 17:50:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22634; Fri, 9 Aug 2002 17:44:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22569 for ; Fri, 9 Aug 2002 17:44:35 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12462 for ; Fri, 9 Aug 2002 17:43:18 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA00572 for ; Fri, 9 Aug 2002 14:44:32 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA21608 for ; Fri, 9 Aug 2002 14:44:54 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 9 Aug 2002 16:44:32 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56EE@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Fri, 9 Aug 2002 16:44:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FED.F1C3B850" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C23FED.F1C3B850 Content-Type: text/plain; charset="ISO-8859-1" As far as AR not supporting TCP or SCTP, I don't think anybody is designing CT to an arbitrary node across internet. I will only do CT with some network I know and have some kind of relationship with, but that is another issues. the point is, if somebody wants to use CT for their feature and wants to use TCP or SCTP for reliability for that feature context transfer then, that designer has to make sure TCP/ SCTP are presented on those AR' s stacks. I think the point here is that CT is designed to be independent of transport protocol and it is already stated in the suggested text. No transport protocol is suggested or mandated. CT is not making the use of those protocols a must, From the last year's experience, we know that trying to mandate one specific transport protocol for CT for all features won't lead to a consensus. Lets drop the discussion on transport layer of choice... I think transport protocol discussion for each feature, has to be diverted to the group that handles that feature. -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, August 09, 2002 11:59 AM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Charlie: > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@iprg.nokia.com ] > Sent: August 9, 2002 12:07 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > I'd like to represent another viewpoint. Certainly. > > > Gary Kenward wrote: > > > The main issue is > > that I see a tendency towards having a different transport for every > > feature context, > > How about a mapping of feature contexts into a small number of > transport protocols (e.g., UDP, TCP, SCTP, ICMP)? May happen. Why make it a requirement, or imply that this is the best solution within the requirements document? There is a debate to take place over this issue, and we should have it, when the we start discussing solutions. But let us not presume that it is part of the solution. > > > with potentially different mappings for > each combination > > of context and transport protocol combination. > > Can you be more specific about what you mean here? If all context is transfer as data chunks in the payload, then there really isn't a problem. However, if one starts mapping ct information into option fields of various protocols, the mappings will very likely change due to the differences in protocol syntax. IPv4 vs. IPv6 seems to be the most pronounced example. > > > ........ there would be little to the > > actual CT protocol except for a specification of the feature context > > encapsulation format, and possibly the rules for > multiplexing multiple > > feature contexts onto a give transport frame. > > But that would already be quite valuable, from my perspective. A necessary component of the total solution for CT, but definitely only part of the answer. The real issue here is whether the CT capability is fulfilled with a single protocol or a suite of protocols. I believe the former is a preferable solution, if the protocol complexity is manageable, which I believe it is. We have pretty well decided that CT capability involves at least two protocols (above IP): a CT containerizing protocol, and a transport protocol. Two is still better then a gaggle of protocols, IMHO. > > > Implementation of a collection of protocols, feature CT and > each associated > > transport protocol, would also be problematical. > > If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't > much problem with implementation. Or maybe I missed your point... Well, this assumes that the ARs have end-point stacks for all of the transport protocols, and management interfaces, etc. Most routers have ICMP/UDP support. Not sure about TCP, and I doubt SCTP. Technically, supporting 4+/- protocols is perhaps not that big of a deal...but where's the value? > > I think that HI and HAck from [mobile-ip] fast handovers would be > a very suitable transport for some contexts that do not require > rock-solid reliability, for those cases where they are available. > I think that TCP or SCTP would be just fine for a lot of contexts > that do require high reliability. If we don't have HI and HAck > available, but we have contexts with requirement for very low > latency, then we can decide whether the contexts should be > encapsulated > in ICMP, UDP, or some IP-level option. Again, I have no problem ( at least at this point) with saying that the designer can run CT over one of a number of protocols, say they are UDP, SCTP, ICMP, TCP - I do have a problem with the idea that each feature CT will run over different protocols. Now, instead of one context transfer, you have at least one for each transport protocol used (assuming feature CTs that use the same transport can be multiplexed onto one frame). This exacerbates many issues such as transfer delay, ordering, updates synchronization, etc. > > > Obviously, I believe that it is possible to convey all > feature contexts with > > one CT protocol, running over one (to be determined) transport. > > I can't see this. Some contexts have to be transferred with very > low latency, and have low reliability requirement. Some contexts > have much more relaxed latency requirements, but have high reliability > requirements. The same transport protocol is unlikely to work for > both. The only reason you would separate the transports in this case is if there was an advantage to optimizing for the "low performance" requirements. That is, what is the problem with delivering a feature context with a lower latency or higher reliability? There is certainly more overhead in adding a second, higher latency or lower reliability exchange then there is in putting all the context on a transport that met the most demanding requirements. Usually, achieving low latency is in opposition to high reliability either because of the processing overhead with FEC, or the loop response latency of a BEC (backward error control). The total context is relatively small in terms of the number of bytes, and the latency requirements are not sensitive to the microseconds required to encode and decode FEC (particularly if for proactive CT). A number of ideas kicked around lately almost seem imply the use of CT for state synchronization between ARs. I really hope this is not the case. If so, it really does not jibe with the vision I have of what CT is trying to accomplish, with is a loose, best effort approach to improving the seamlessness of handover. State synchronization can be done much more effectively below L3, without the overheads of IP+transport. Gary > > > Regards, > Charlie P. > ------_=_NextPart_001_01C23FED.F1C3B850 Content-Type: text/html; charset="ISO-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications
As far as AR not supporting TCP or SCTP, I don't think anybody is designing CT to an arbitrary node across internet.
I will only do CT with some network I know and have some kind of relationship with, but that is another issues.
 
the point is, if somebody wants to use CT for their feature and wants to use TCP or SCTP for reliability for that feature context transfer then, that designer has to make sure TCP/ SCTP are presented on those AR' s stacks.
 
I think the point here is that CT is designed to be independent of transport protocol and it is already stated in the suggested text. No transport protocol is suggested or mandated. CT is not making the use of those protocols a must,
From the last year's experience, we know that trying to mandate one specific transport protocol for CT for all features won't lead to a consensus. Lets drop the discussion on transport layer of choice...
I think transport protocol discussion for each feature, has to be diverted to the group that handles that feature.
 
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, August 09, 2002 11:59 AM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

Charlie:

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 9, 2002 12:07
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> I'd like to represent another viewpoint.

Certainly.

>
> > Gary Kenward wrote:
>
> >                                                The main issue is
> > that I see a tendency towards having a different transport for every
> > feature context,
>
> How about a mapping of feature contexts into a small number of
> transport protocols (e.g., UDP, TCP, SCTP, ICMP)?

May happen. Why make it a requirement, or imply that this is the best
solution within the requirements document? There is a debate to take
place over this issue, and we should have it, when the we start discussing
solutions. But let us not presume that it is part of the solution.

>
> >                   with potentially different mappings for
> each combination
> > of context and transport protocol combination.
>
> Can you be more specific about what you mean here?

If all context is transfer as data chunks in the payload, then there really isn't
a problem. However, if one starts mapping ct information into option fields of various
protocols, the mappings will very likely change due to the differences in protocol
syntax. IPv4 vs. IPv6 seems to be the most pronounced example.

>
> >          ........                       there would be little to the
> > actual CT protocol except for a specification of the feature context
> > encapsulation format, and possibly the rules for
> multiplexing multiple
> > feature contexts onto a give transport frame.
>
> But that would already be quite valuable, from my perspective.

A necessary component of the total solution for CT, but definitely
only part of the answer. The real issue here is whether the CT capability is
fulfilled with a single protocol or a suite of protocols. I believe the former is
a preferable solution, if the protocol complexity is manageable, which I believe it
is.

We have pretty well decided that CT capability involves at least two protocols (above IP):
a CT containerizing protocol, and a transport protocol. Two is still better then a gaggle
of protocols, IMHO.

>
> > Implementation of a collection of protocols, feature CT and
> each associated
> > transport protocol, would also be problematical.
>
> If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't
> much problem with implementation.  Or maybe I missed your point...

Well, this assumes that the ARs have end-point stacks for all of the transport
protocols, and management interfaces, etc. Most routers have ICMP/UDP support.
Not sure about TCP, and I doubt SCTP.

Technically, supporting 4+/- protocols is perhaps not that big of a deal...but
where's the value?

>
> I think that HI and HAck from [mobile-ip] fast handovers would be
> a very suitable transport for some contexts that do not require
> rock-solid reliability, for those cases where they are available.
> I think that TCP or SCTP would be just fine for a lot of contexts
> that do require high reliability.  If we don't have HI and HAck
> available, but we have contexts with requirement for very low
> latency, then we can decide whether the contexts should be
> encapsulated
> in ICMP, UDP, or some IP-level option.

Again, I have no problem ( at least at this point) with saying that the
designer can run CT over one of a number of protocols, say they are UDP,
SCTP, ICMP, TCP - I do have a problem with the idea that each feature CT will
run over different protocols. Now, instead of one context transfer, you have
at least one for each transport protocol used (assuming feature CTs that use
the same transport can be multiplexed onto one frame). This exacerbates many
issues such as transfer delay, ordering, updates synchronization, etc.

>
> >   Obviously, I believe that it is possible to convey all
> feature contexts with
> > one CT protocol, running over one (to be determined) transport.
>
> I can't see this.  Some contexts have to be transferred with very
> low latency, and have low reliability requirement.  Some contexts
> have much more relaxed latency requirements, but have high reliability
> requirements.  The same transport protocol is unlikely to work for
> both.

The only reason you would separate the transports in this case is if there
was an advantage to optimizing for the "low performance" requirements. That is,
what is the problem with delivering a feature context with a lower latency or
higher reliability?

There is certainly more overhead in adding a second, higher latency or lower
reliability exchange then there is in putting all the context on a transport
that met the most demanding requirements.

Usually, achieving low latency is in opposition to high reliability either because
of the processing overhead with FEC, or the loop response latency of a BEC (backward
error control). The total context is relatively small in terms of the number
of bytes, and the latency requirements are not sensitive to the microseconds required
to encode and decode FEC (particularly if for proactive CT).


A number of ideas kicked around lately almost seem imply the use of CT for state
synchronization between ARs. I really hope this is not the case. If so, it really
does not jibe with the vision I have of what CT is trying to accomplish, with is a
loose, best effort approach to improving the seamlessness of handover.

State synchronization can be done much more effectively below L3, without the overheads
of IP+transport.

Gary

>
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C23FED.F1C3B850-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 17:52: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 RAA12783 for ; Fri, 9 Aug 2002 17:52:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22730; Fri, 9 Aug 2002 17:48:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22700 for ; Fri, 9 Aug 2002 17:48:12 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12566 for ; Fri, 9 Aug 2002 17:46:55 -0400 (EDT) Message-ID: <018201c23fed$aaa5d930$296015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "'Gary Kenward'" , , References: <35DBB8B7AC89D4118E98009027B1009B08AD56EC@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 9 Aug 2002 14:42:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 > Agreed to some extent. To be precise: context has to be present at layer 2 devices. > > by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP itself is below IP on the stack. > CT on the other hand as of today is AR-AR. > So suppose I'm developing a 802.11 AP that also contains AR functionality. Are you saying that I have to use two context transfers, one with IAPP and one with an IP CT protocol, in order to be able to get Radius context between the devices? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 17:52: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 RAA12791 for ; Fri, 9 Aug 2002 17:52:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22882 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 17:53:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22730; Fri, 9 Aug 2002 17:48:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22700 for ; Fri, 9 Aug 2002 17:48:12 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12566 for ; Fri, 9 Aug 2002 17:46:55 -0400 (EDT) Message-ID: <018201c23fed$aaa5d930$296015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "'Gary Kenward'" , , References: <35DBB8B7AC89D4118E98009027B1009B08AD56EC@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 9 Aug 2002 14:42:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 > Agreed to some extent. To be precise: context has to be present at layer 2 devices. > > by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP itself is below IP on the stack. > CT on the other hand as of today is AR-AR. > So suppose I'm developing a 802.11 AP that also contains AR functionality. Are you saying that I have to use two context transfers, one with IAPP and one with an IP CT protocol, in order to be able to get Radius context between the devices? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 17: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 RAA12930 for ; Fri, 9 Aug 2002 17:58:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22981; Fri, 9 Aug 2002 17:55:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22954 for ; Fri, 9 Aug 2002 17:55:18 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12832 for ; Fri, 9 Aug 2002 17:54:01 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA22128 for ; Fri, 9 Aug 2002 14:55:16 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA23821 for ; Fri, 9 Aug 2002 14:55:38 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 9 Aug 2002 16:55:15 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56EF@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , "'Gary Kenward'" , john.loughney@nokia.com, seamoby@ietf.org Subject: IAPP v.s. CT was:RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 9 Aug 2002 16:55:14 -0500 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 No that is not what I am saying, you can use IAPP for transfering RADIUS context, as IAPP is designed for, but beyond RADIUS you are on your own. IAPP does not have support for generic context. In the appendix for the April 2002 doc, the limitations of IAPP as a context trasnfer protocol are explained. Basically IAPP relies on the using the same message exchange that led to the context in the first place as a context transfer mechanism, this is fundamentally different from our CT where you just take the chuck and transfer it. IAPP's approach would be very useful, when you have context that is upgrade by deltas based on intermediate messages (like header compression), or it is not very economic, if you need to do many messages to arrive at the final state in the state machine.... CT is more generic than IAPP. But that means we should work faster on CT's standardization and not make it too complex, otherwise, every access technology will come up with its own methods. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, August 09, 2002 4:43 PM To: Nakhjiri Madjid-MNAKHJI1; 'Gary Kenward'; john.loughney@nokia.com; seamoby@ietf.org Subject: Re: [Seamoby] Section 5.2 in CT Requirements > Agreed to some extent. To be precise: context has to be present at layer 2 devices. > > by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP itself is below IP on the stack. > CT on the other hand as of today is AR-AR. > So suppose I'm developing a 802.11 AP that also contains AR functionality. Are you saying that I have to use two context transfers, one with IAPP and one with an IP CT protocol, in order to be able to get Radius context between the devices? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 17:59: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 RAA12938 for ; Fri, 9 Aug 2002 17:59:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23248 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 18:00:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22981; Fri, 9 Aug 2002 17:55:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22954 for ; Fri, 9 Aug 2002 17:55:18 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12832 for ; Fri, 9 Aug 2002 17:54:01 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA22128 for ; Fri, 9 Aug 2002 14:55:16 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA23821 for ; Fri, 9 Aug 2002 14:55:38 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 9 Aug 2002 16:55:15 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD56EF@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , "'Gary Kenward'" , john.loughney@nokia.com, seamoby@ietf.org Subject: IAPP v.s. CT was:RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 9 Aug 2002 16:55:14 -0500 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 No that is not what I am saying, you can use IAPP for transfering RADIUS context, as IAPP is designed for, but beyond RADIUS you are on your own. IAPP does not have support for generic context. In the appendix for the April 2002 doc, the limitations of IAPP as a context trasnfer protocol are explained. Basically IAPP relies on the using the same message exchange that led to the context in the first place as a context transfer mechanism, this is fundamentally different from our CT where you just take the chuck and transfer it. IAPP's approach would be very useful, when you have context that is upgrade by deltas based on intermediate messages (like header compression), or it is not very economic, if you need to do many messages to arrive at the final state in the state machine.... CT is more generic than IAPP. But that means we should work faster on CT's standardization and not make it too complex, otherwise, every access technology will come up with its own methods. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, August 09, 2002 4:43 PM To: Nakhjiri Madjid-MNAKHJI1; 'Gary Kenward'; john.loughney@nokia.com; seamoby@ietf.org Subject: Re: [Seamoby] Section 5.2 in CT Requirements > Agreed to some extent. To be precise: context has to be present at layer 2 devices. > > by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP itself is below IP on the stack. > CT on the other hand as of today is AR-AR. > So suppose I'm developing a 802.11 AP that also contains AR functionality. Are you saying that I have to use two context transfers, one with IAPP and one with an IP CT protocol, in order to be able to get Radius context between the devices? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 18: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 SAA13593 for ; Fri, 9 Aug 2002 18:26:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24033; Fri, 9 Aug 2002 18:18:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24005 for ; Fri, 9 Aug 2002 18:18:46 -0400 (EDT) Received: from worldsubmit.biz (host213-123-44-171.in-addr.btopenworld.com [213.123.44.171]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13458 for ; Fri, 9 Aug 2002 18:16:39 -0400 (EDT) From: "World Submit" To: "Seamoby" Date: Fri, 9 Aug 2002 23:17:01 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <783135814073141@worldsubmit.biz> Reply-To: "World Submit" Organization: World Submit X-Mailer: Internet Mail Service Content-Type: multipart/alternative; boundary="----_NextPart_917232537915492" Subject: [Seamoby] Drive Traffic to Your Website NOW ! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_917232537915492 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE Your Email Client does not support MIME encoding. Please upgrade to MIME-enabled Email Client (almost every modern Email Client is MIME-capable). ------_NextPart_917232537915492 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE Global Services : Priority Search Engine Submission
World Submit

Priority Search Engine Submission

Home | FAQ | Facts | Terms of Service | Contact Us | Order Now

Drive Traffic to Your Web Site

    48 Hour Inclusion to AOL, MSN, Overture (formerly GoTo), HotBot, iWon and Other Inktomi Search Partners.
    Powered by Inktomi Search Submit

3D"InktomiMass Exposure
Inktomi is a trusted OEM partner for many of the world's leading technology companies. Inktomi powers the search box found on the world's top portal sites, reaching more than 80% of the internet population. Eight of the top ten Fortune 500 companies, along with 2500 others, have deployed Inktomi Search on their corporate intranets and public web sites.

With over 82 million daily search requests, Inktomi is one of the largest search engines networks on the internet. The Inktomi search technology is used to power hundreds of Search Engines world wide including: About, Chello, MSN, iWON, Overture (GOTO), HotBot, LookSmart and many more....

Rapid Inclusion
This priority service ensures that your URL is added to the Inktomi index within 5 working days. The link will be added to all Inktomi indexes and reflected across all Inktomi portal sites. (excluding non-English regional portals). URL's submitted via other free URL submission services can take up to 3 - 6 months to be indexed without any guarantees.

Frequent Updates
Your web pages will be refreshed every 48 hours. This means that any change you make to your web page, will be reflected in the search index within two days. You can thus modify your page to fine tune the relevancy and improve your search engine ranking. All without the need to re-submit your URL all the time.

No Dropouts
Due to the 48 hour re-indexing, your website URL will remain in the index for the whole 12 month subscription period. This means that there is no need to worry about having your URL dropped from the search engines, which can happen regularly with other search engine placement services.

Cost Savings
Search engine placement is the most cost effective way to attract new visitors to your web site. Companies spend thousands of dollars in online advertising to attract new customers to their web sites. A well placed search engine listing can be thousand times more cost effective in comparison to traditional banner advertising.
 

Price

Quantity Price per URL
Each URL =A379.97/year

Add URL

CLICK HERE to ADD your URL now!

Back to Top

Email: sales@worldsubmit.biz
Fax: + 44 (0)8704 602504 (24hrs)

3D"We
------_NextPart_917232537915492-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 18: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 SAA13599 for ; Fri, 9 Aug 2002 18:26:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24165 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 18:27:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24033; Fri, 9 Aug 2002 18:18:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24005 for ; Fri, 9 Aug 2002 18:18:46 -0400 (EDT) Received: from worldsubmit.biz (host213-123-44-171.in-addr.btopenworld.com [213.123.44.171]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13458 for ; Fri, 9 Aug 2002 18:16:39 -0400 (EDT) From: "World Submit" To: "Seamoby" Date: Fri, 9 Aug 2002 23:17:01 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <783135814073141@worldsubmit.biz> Reply-To: "World Submit" Organization: World Submit X-Mailer: Internet Mail Service Content-Type: multipart/alternative; boundary="----_NextPart_917232537915492" Subject: [Seamoby] Drive Traffic to Your Website NOW ! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_917232537915492 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE Your Email Client does not support MIME encoding. Please upgrade to MIME-enabled Email Client (almost every modern Email Client is MIME-capable). ------_NextPart_917232537915492 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE Global Services : Priority Search Engine Submission
World Submit

Priority Search Engine Submission

Home | FAQ | Facts | Terms of Service | Contact Us | Order Now

Drive Traffic to Your Web Site

    48 Hour Inclusion to AOL, MSN, Overture (formerly GoTo), HotBot, iWon and Other Inktomi Search Partners.
    Powered by Inktomi Search Submit

3D"InktomiMass Exposure
Inktomi is a trusted OEM partner for many of the world's leading technology companies. Inktomi powers the search box found on the world's top portal sites, reaching more than 80% of the internet population. Eight of the top ten Fortune 500 companies, along with 2500 others, have deployed Inktomi Search on their corporate intranets and public web sites.

With over 82 million daily search requests, Inktomi is one of the largest search engines networks on the internet. The Inktomi search technology is used to power hundreds of Search Engines world wide including: About, Chello, MSN, iWON, Overture (GOTO), HotBot, LookSmart and many more....

Rapid Inclusion
This priority service ensures that your URL is added to the Inktomi index within 5 working days. The link will be added to all Inktomi indexes and reflected across all Inktomi portal sites. (excluding non-English regional portals). URL's submitted via other free URL submission services can take up to 3 - 6 months to be indexed without any guarantees.

Frequent Updates
Your web pages will be refreshed every 48 hours. This means that any change you make to your web page, will be reflected in the search index within two days. You can thus modify your page to fine tune the relevancy and improve your search engine ranking. All without the need to re-submit your URL all the time.

No Dropouts
Due to the 48 hour re-indexing, your website URL will remain in the index for the whole 12 month subscription period. This means that there is no need to worry about having your URL dropped from the search engines, which can happen regularly with other search engine placement services.

Cost Savings
Search engine placement is the most cost effective way to attract new visitors to your web site. Companies spend thousands of dollars in online advertising to attract new customers to their web sites. A well placed search engine listing can be thousand times more cost effective in comparison to traditional banner advertising.
 

Price

Quantity Price per URL
Each URL =A379.97/year

Add URL

CLICK HERE to ADD your URL now!

Back to Top

Email: sales@worldsubmit.biz
Fax: + 44 (0)8704 602504 (24hrs)

3D"We
------_NextPart_917232537915492-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 19:58: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 TAA15344 for ; Fri, 9 Aug 2002 19:58:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27257; Fri, 9 Aug 2002 19:49:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27228 for ; Fri, 9 Aug 2002 19:49:38 -0400 (EDT) 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 TAA15178 for ; Fri, 9 Aug 2002 19:48:20 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA25843; Fri, 9 Aug 2002 16:49:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g79Nn4I06682; Fri, 9 Aug 2002 16:49:04 -0700 X-mProtect: <200208092349> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCwK0AL; Fri, 09 Aug 2002 16:49:02 PDT Message-ID: <3D5454EF.EF407FCF@iprg.nokia.com> Date: Fri, 09 Aug 2002 16:49:03 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <9FBD322B7824D511B36900508BF93C9C01AA4C7B@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > Gary Kenward wrote: > > How about a mapping of feature contexts into a small number of > > transport protocols (e.g., UDP, TCP, SCTP, ICMP)? > > May happen. Why make it a requirement, or imply that this is the best > solution within the requirements document? O.K. I agree that it's not a requirement to use those protocols. But I think that we should _expect_ that the eventual solution may require that we make use of multiple transport protocols. >> Can you be more specific about what you mean here? > > If all context is transfer as data chunks in the payload, then there really > isn't a problem. However, if one starts mapping ct information into option > fields of various protocols, the mappings will very likely change due to the > differences in protocol syntax. IPv4 vs. IPv6 seems to be the most pronounced > example. I'm happy to model context as data, not option fields. However, it could be (e.g., in the case of QoS) that the context affects the fields of various protocols. In fact, taken abstractly, all the cases I care about can be modeled as affecting some fields of some protocol's data fields. This is even true for buffering, and security contexts, right? > The real issue here is whether the CT capability is > fulfilled with a single protocol or a suite of protocols. I believe the former > is a preferable solution, if the protocol complexity is manageable, which I > believe it is. Again, I'm happy if there can be a single solution. But, if I were given the choice of ICMP for some contexts, and TCP for others, vs. waiting two more years for XCTTP (unknown context transfer transport protocol), I'd go for using two transports. > We have pretty well decided that CT capability involves at least two protocols > (above IP): a CT containerizing protocol, and a transport protocol. > Two is still better then a gaggle of protocols, IMHO. What's a containerizing protocol? Can't we just have data formats without having to do distributing processing to collect the data? Gaggle is, by the way, a great word. Is ICMP plus TCP approximately equal to, or less than, a gaggle? >> If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't >> much problem with implementation. Or maybe I missed your point... > > Well, this assumes that the ARs have end-point stacks for all of the transport > protocols, and management interfaces, etc. Most routers have ICMP/UDP support. > Technically, supporting 4+/- protocols is perhaps not that big of a deal...but > where's the value? As I mentioned above, if you can make a single protocol do it, I'll be happy (still wondering about that containerizing, though). >> I think that HI and HAck from [mobile-ip] fast handovers would be >> a very suitable transport for some contexts that do not require >> rock-solid reliability, for those cases where they are available. >> I think that TCP or SCTP would be just fine for a lot of contexts >> that do require high reliability. If we don't have HI and HAck >> available, but we have contexts with requirement for very low >> latency, then we can decide whether the contexts should be >> encapsulated in ICMP, UDP, or some IP-level option. > > Again, I have no problem ( at least at this point) with saying that the > designer can run CT over one of a number of protocols, say they are UDP, > SCTP, ICMP, TCP - I do have a problem with the idea that each feature CT will > run over different protocols. Now, instead of one context transfer, you have > at least one for each transport protocol used (assuming feature CTs that use > the same transport can be multiplexed onto one frame). This exacerbates many > issues such as transfer delay, ordering, updates synchronization, etc. I can see a simple solution for this: 1. Find the most urgent context. Encapsulate it using the transport it specifies (which won't be TCP, I reckon, for extremely urgent contexts). Fill the rest of the context feature data structure with the most urgent other contexts that will fit, and which are compatible with the chosen transport. If the chosen transport is not a reliable transport, schedule a retransmission if any context transfer requires acknowledgement. 2. If there are any contexts left, goto (1). timeout(retransmission_timer) { retransmit the packet; if (not-enough-retries-yet) { schedule_another_retransmission(); } } process_ack { delete_retransmission_timeout(); } > The only reason you would separate the transports in this case is if there > was an advantage to optimizing for the "low performance" requirements. That > is, what is the problem with delivering a feature context with a lower > latency or higher reliability? How do you like my high-level example above? It's an example, not an attempt to enforce a particular solution. Of course there are a huge number of details omitted, like what the receving AR does with the various kinds of features, but those are straightforward details. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 19:58: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 TAA15352 for ; Fri, 9 Aug 2002 19:58:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA27569 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 20:00:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27257; Fri, 9 Aug 2002 19:49:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27228 for ; Fri, 9 Aug 2002 19:49:38 -0400 (EDT) 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 TAA15178 for ; Fri, 9 Aug 2002 19:48:20 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA25843; Fri, 9 Aug 2002 16:49:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g79Nn4I06682; Fri, 9 Aug 2002 16:49:04 -0700 X-mProtect: <200208092349> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCwK0AL; Fri, 09 Aug 2002 16:49:02 PDT Message-ID: <3D5454EF.EF407FCF@iprg.nokia.com> Date: Fri, 09 Aug 2002 16:49:03 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <9FBD322B7824D511B36900508BF93C9C01AA4C7B@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > Gary Kenward wrote: > > How about a mapping of feature contexts into a small number of > > transport protocols (e.g., UDP, TCP, SCTP, ICMP)? > > May happen. Why make it a requirement, or imply that this is the best > solution within the requirements document? O.K. I agree that it's not a requirement to use those protocols. But I think that we should _expect_ that the eventual solution may require that we make use of multiple transport protocols. >> Can you be more specific about what you mean here? > > If all context is transfer as data chunks in the payload, then there really > isn't a problem. However, if one starts mapping ct information into option > fields of various protocols, the mappings will very likely change due to the > differences in protocol syntax. IPv4 vs. IPv6 seems to be the most pronounced > example. I'm happy to model context as data, not option fields. However, it could be (e.g., in the case of QoS) that the context affects the fields of various protocols. In fact, taken abstractly, all the cases I care about can be modeled as affecting some fields of some protocol's data fields. This is even true for buffering, and security contexts, right? > The real issue here is whether the CT capability is > fulfilled with a single protocol or a suite of protocols. I believe the former > is a preferable solution, if the protocol complexity is manageable, which I > believe it is. Again, I'm happy if there can be a single solution. But, if I were given the choice of ICMP for some contexts, and TCP for others, vs. waiting two more years for XCTTP (unknown context transfer transport protocol), I'd go for using two transports. > We have pretty well decided that CT capability involves at least two protocols > (above IP): a CT containerizing protocol, and a transport protocol. > Two is still better then a gaggle of protocols, IMHO. What's a containerizing protocol? Can't we just have data formats without having to do distributing processing to collect the data? Gaggle is, by the way, a great word. Is ICMP plus TCP approximately equal to, or less than, a gaggle? >> If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't >> much problem with implementation. Or maybe I missed your point... > > Well, this assumes that the ARs have end-point stacks for all of the transport > protocols, and management interfaces, etc. Most routers have ICMP/UDP support. > Technically, supporting 4+/- protocols is perhaps not that big of a deal...but > where's the value? As I mentioned above, if you can make a single protocol do it, I'll be happy (still wondering about that containerizing, though). >> I think that HI and HAck from [mobile-ip] fast handovers would be >> a very suitable transport for some contexts that do not require >> rock-solid reliability, for those cases where they are available. >> I think that TCP or SCTP would be just fine for a lot of contexts >> that do require high reliability. If we don't have HI and HAck >> available, but we have contexts with requirement for very low >> latency, then we can decide whether the contexts should be >> encapsulated in ICMP, UDP, or some IP-level option. > > Again, I have no problem ( at least at this point) with saying that the > designer can run CT over one of a number of protocols, say they are UDP, > SCTP, ICMP, TCP - I do have a problem with the idea that each feature CT will > run over different protocols. Now, instead of one context transfer, you have > at least one for each transport protocol used (assuming feature CTs that use > the same transport can be multiplexed onto one frame). This exacerbates many > issues such as transfer delay, ordering, updates synchronization, etc. I can see a simple solution for this: 1. Find the most urgent context. Encapsulate it using the transport it specifies (which won't be TCP, I reckon, for extremely urgent contexts). Fill the rest of the context feature data structure with the most urgent other contexts that will fit, and which are compatible with the chosen transport. If the chosen transport is not a reliable transport, schedule a retransmission if any context transfer requires acknowledgement. 2. If there are any contexts left, goto (1). timeout(retransmission_timer) { retransmit the packet; if (not-enough-retries-yet) { schedule_another_retransmission(); } } process_ack { delete_retransmission_timeout(); } > The only reason you would separate the transports in this case is if there > was an advantage to optimizing for the "low performance" requirements. That > is, what is the problem with delivering a feature context with a lower > latency or higher reliability? How do you like my high-level example above? It's an example, not an attempt to enforce a particular solution. Of course there are a huge number of details omitted, like what the receving AR does with the various kinds of features, but those are straightforward details. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 9 20:24: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 UAA15759 for ; Fri, 9 Aug 2002 20:24:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28676; Fri, 9 Aug 2002 20:24:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28632 for ; Fri, 9 Aug 2002 20:24:19 -0400 (EDT) Received: from worldsubmit.biz (host213-122-156-103.in-addr.btopenworld.com [213.122.156.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15725 for ; Fri, 9 Aug 2002 20:21:54 -0400 (EDT) From: "World Submit" To: "Seamoby" Date: Sat, 10 Aug 2002 01:21:33 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <279465353473240@worldsubmit.biz> Reply-To: "World Submit" Organization: World Submit X-Mailer: Internet Mail Service Content-Type: multipart/alternative; boundary="----_NextPart_044836178856767" Subject: [Seamoby] Drive Traffic to Your Website NOW ! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_044836178856767 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE Your Email Client does not support MIME encoding. Please upgrade to MIME-enabled Email Client (almost every modern Email Client is MIME-capable). ------_NextPart_044836178856767 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE Global Services : Priority Search Engine Submission
World Submit

Priority Search Engine Submission

Home | FAQ | Facts | Terms of Service | Contact Us | Order Now

Drive Traffic to Your Web Site

    48 Hour Inclusion to AOL, MSN, Overture (formerly GoTo), HotBot, iWon and Other Inktomi Search Partners.
    Powered by Inktomi Search Submit

3D"InktomiMass Exposure
Inktomi is a trusted OEM partner for many of the world's leading technology companies. Inktomi powers the search box found on the world's top portal sites, reaching more than 80% of the internet population. Eight of the top ten Fortune 500 companies, along with 2500 others, have deployed Inktomi Search on their corporate intranets and public web sites.

With over 82 million daily search requests, Inktomi is one of the largest search engines networks on the internet. The Inktomi search technology is used to power hundreds of Search Engines world wide including: About, Chello, MSN, iWON, Overture (GOTO), HotBot, LookSmart and many more....

Rapid Inclusion
This priority service ensures that your URL is added to the Inktomi index within 5 working days. The link will be added to all Inktomi indexes and reflected across all Inktomi portal sites. (excluding non-English regional portals). URL's submitted via other free URL submission services can take up to 3 - 6 months to be indexed without any guarantees.

Frequent Updates
Your web pages will be refreshed every 48 hours. This means that any change you make to your web page, will be reflected in the search index within two days. You can thus modify your page to fine tune the relevancy and improve your search engine ranking. All without the need to re-submit your URL all the time.

No Dropouts
Due to the 48 hour re-indexing, your website URL will remain in the index for the whole 12 month subscription period. This means that there is no need to worry about having your URL dropped from the search engines, which can happen regularly with other search engine placement services.

Cost Savings
Search engine placement is the most cost effective way to attract new visitors to your web site. Companies spend thousands of dollars in online advertising to attract new customers to their web sites. A well placed search engine listing can be thousand times more cost effective in comparison to traditional banner advertising.
 

Price

Quantity Price per URL
Each URL =A379.97/year

Add URL

CLICK HERE to ADD your URL now!

Back to Top

Email: sales@worldsubmit.biz
Fax: + 44 (0)8704 602504 (24hrs)

3D"We
------_NextPart_044836178856767-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 9 20:24: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 UAA15765 for ; Fri, 9 Aug 2002 20:24:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28704 for seamoby-archive@odin.ietf.org; Fri, 9 Aug 2002 20:26:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28676; Fri, 9 Aug 2002 20:24:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28632 for ; Fri, 9 Aug 2002 20:24:19 -0400 (EDT) Received: from worldsubmit.biz (host213-122-156-103.in-addr.btopenworld.com [213.122.156.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15725 for ; Fri, 9 Aug 2002 20:21:54 -0400 (EDT) From: "World Submit" To: "Seamoby" Date: Sat, 10 Aug 2002 01:21:33 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <279465353473240@worldsubmit.biz> Reply-To: "World Submit" Organization: World Submit X-Mailer: Internet Mail Service Content-Type: multipart/alternative; boundary="----_NextPart_044836178856767" Subject: [Seamoby] Drive Traffic to Your Website NOW ! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_044836178856767 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE Your Email Client does not support MIME encoding. Please upgrade to MIME-enabled Email Client (almost every modern Email Client is MIME-capable). ------_NextPart_044836178856767 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE Global Services : Priority Search Engine Submission
World Submit

Priority Search Engine Submission

Home | FAQ | Facts | Terms of Service | Contact Us | Order Now

Drive Traffic to Your Web Site

    48 Hour Inclusion to AOL, MSN, Overture (formerly GoTo), HotBot, iWon and Other Inktomi Search Partners.
    Powered by Inktomi Search Submit

3D"InktomiMass Exposure
Inktomi is a trusted OEM partner for many of the world's leading technology companies. Inktomi powers the search box found on the world's top portal sites, reaching more than 80% of the internet population. Eight of the top ten Fortune 500 companies, along with 2500 others, have deployed Inktomi Search on their corporate intranets and public web sites.

With over 82 million daily search requests, Inktomi is one of the largest search engines networks on the internet. The Inktomi search technology is used to power hundreds of Search Engines world wide including: About, Chello, MSN, iWON, Overture (GOTO), HotBot, LookSmart and many more....

Rapid Inclusion
This priority service ensures that your URL is added to the Inktomi index within 5 working days. The link will be added to all Inktomi indexes and reflected across all Inktomi portal sites. (excluding non-English regional portals). URL's submitted via other free URL submission services can take up to 3 - 6 months to be indexed without any guarantees.

Frequent Updates
Your web pages will be refreshed every 48 hours. This means that any change you make to your web page, will be reflected in the search index within two days. You can thus modify your page to fine tune the relevancy and improve your search engine ranking. All without the need to re-submit your URL all the time.

No Dropouts
Due to the 48 hour re-indexing, your website URL will remain in the index for the whole 12 month subscription period. This means that there is no need to worry about having your URL dropped from the search engines, which can happen regularly with other search engine placement services.

Cost Savings
Search engine placement is the most cost effective way to attract new visitors to your web site. Companies spend thousands of dollars in online advertising to attract new customers to their web sites. A well placed search engine listing can be thousand times more cost effective in comparison to traditional banner advertising.
 

Price

Quantity Price per URL
Each URL =A379.97/year

Add URL

CLICK HERE to ADD your URL now!

Back to Top

Email: sales@worldsubmit.biz
Fax: + 44 (0)8704 602504 (24hrs)

3D"We
------_NextPart_044836178856767-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Aug 11 10:20: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 KAA14305 for ; Sun, 11 Aug 2002 10:20:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02222; Sun, 11 Aug 2002 10:19:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02191 for ; Sun, 11 Aug 2002 10:19:42 -0400 (EDT) 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 KAA14276 for ; Sun, 11 Aug 2002 10:18:25 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7BELwW09672 for ; Sun, 11 Aug 2002 17:21:58 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 11 Aug 2002 17:19:39 +0300 Received: from [172.18.5.222] ([172.18.5.222]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 11 Aug 2002 17:19:27 +0300 Reply-to: john.loughney@nokia.com To: "ext Gary Kenward" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications Date: Sun, 11 Aug 2002 10:19:57 -0500 Message-ID: X-Mailer: EPOC Email Version 2.00 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=ISO-8859-1 X-OriginalArrivalTime: 11 Aug 2002 14:19:30.0313 (UTC) FILETIME=[1B664790:01C24142] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA02192 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, I smell a rathole. Could we remove discussion of transport protocols from the requirements, and just state: Feature contexts SHOULD be able to state their reliability needs. After my vacation, I'm going to write up a draft on some transport issues & scenarios. John _____________Original message ____________ Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications Sender: ext Gary Kenward Date: Sun, 11 Aug 2002 10:15:23 -0500 Rajeev: Actually, I my point had nothing to do with the text, which I have no problem with. I do have problems with some of the transport protocol statements and requirements that have been put forth. The main issue is that I see a tendency towards having a different transport for every feature context, with potentially different mappings for each combination of context and transport protocol combination. Admittedly, this is a worse case scenario, but entropy is strong force in the internet, and if we adopt James' view of the feature context specifications as it is written, we open up the opportunity for CT to drift towards the worst case. I understand what James was trying to do, I think, but in reading over the proposed 5.8 requirements, I came to realize that there would be little to the actual CT protocol except for a specification of the feature context encapsulation format, and possibly the rules for multiplexing multiple feature contexts onto a give transport frame. This *may* be the best approach, but this would mean that CT is actually a suit of protocols, one for each feature. Designing and standardizing on a collection of protocols will be more difficult, and fraught with risk, then designing and standardizing one protocol, at least for CT. Implementation of a collection of protocols, feature CT and each associated transport protocol, would also be problematical. Obviously, I believe that it is possible to convey all feature contexts with one CT protocol, running over one (to be determined) transport. It may be that people will want the option to chose the transport protocol, but there still only should be one transport per network (obviously, this impacts the interworking capability of CT, but the wg seems to have very diverse opinions on the appropriate transport, and so be it). Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: August 8, 2002 18:48 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Sspecifications > > > > Hello, > > I don't know if we are debating James' intent or > the text in 5.81. I hope it is the latter, with no disrespect > intended. And, I think the text is fine. I see no coupling to > specific transport protocols or option formats as Gary seems > to be referring to. The purpose of the IANA types > is to uniquely identify each feature context, which > facilitates inter-operability (for instance, a receiver > knows before it begins parsing the data fields _what_ > context it is looking at, and _how_ to process it). > So, I am in favor of text in 5.8.1. > > Regards, > > -Rajeev > > > > Gary Kenward wrote: > > > > > > > Madjid: > > > > I snip because the back and forth replies become long, and > the email > > rejects messages over 40K (which is not as big as it might seem). > > > > The text you quote does not address my concern. James used the > > particular > > phrase "standard option format" in a paragraph discussing context > > transport, > > not type codes. It is possible I misinterpreted his intent, but that > > is > > why I asked the question. > > > > Even so, I would question the rationale of standardizing > the mapping > > of type codes into option format fields of specific transport > > protocols. > > It implies that each transport protocol could have > different mappings. > > > > I see no advantage, and much risk in such an approach. > > > > Gary > > > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: August 8, 2002 16:57 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; > > 'James > > > Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > Feature Context > > > S pecifications > > > > > > > > > Gary, > > > > > > I am sorry, I think you took the "context" out of the > > > discussion by snipping > > > the rest of the comments :) > > > The following text suggested by James captures the issue: > > > > > > Madjid > > > > > > > 5.8.1 A feature context specification MUST contain an IANA > > > assigned type > > > code > > > > for the particular feature context. If an experimental > > > feature context > > > protocol > > > > is being developed, a type code from the context transfer > > protocol's > > > > experimental range SHOULD be used. The type code is used in > > > the context > > > transfer > > > > container to identify the feature context. > > > > > > > > > > > > -----Original Message----- > > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > Sent: Tuesday, August 06, 2002 12:32 PM > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > Feature Context S > > > pecifications > > > > > > > > > Madjid: > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: July 22, 2002 18:56 > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > > Feature Context > > > > S pecifications > > > > > > > > > > > *snip* > > > > > > > > If the feature context is transferred as an > > > > option on another IETF protocol, then the feature context > > > > specification MUST > > > > define the mapping of the context transfer container into the > > > > other protocol's > > > > standard option format. If the feature context is transferred > > > What did you mean by "standard option format"? CT, as we have > > > been discussing it, is a container protocol, defined around > > > context "chunks". Are you implying that it should also allow > > > for encoding of context into the option fields of other > protocols??? > > > > > Gary > > > *snip* > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Aug 11 11:10: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 KAA14314 for ; Sun, 11 Aug 2002 10:20:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02245 for seamoby-archive@odin.ietf.org; Sun, 11 Aug 2002 10:22:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02222; Sun, 11 Aug 2002 10:19:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02191 for ; Sun, 11 Aug 2002 10:19:42 -0400 (EDT) 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 KAA14276 for ; Sun, 11 Aug 2002 10:18:25 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7BELwW09672 for ; Sun, 11 Aug 2002 17:21:58 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 11 Aug 2002 17:19:39 +0300 Received: from [172.18.5.222] ([172.18.5.222]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 11 Aug 2002 17:19:27 +0300 Reply-to: john.loughney@nokia.com To: "ext Gary Kenward" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications Date: Sun, 11 Aug 2002 10:19:57 -0500 Message-ID: X-Mailer: EPOC Email Version 2.00 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=ISO-8859-1 X-OriginalArrivalTime: 11 Aug 2002 14:19:30.0313 (UTC) FILETIME=[1B664790:01C24142] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA02192 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, I smell a rathole. Could we remove discussion of transport protocols from the requirements, and just state: Feature contexts SHOULD be able to state their reliability needs. After my vacation, I'm going to write up a draft on some transport issues & scenarios. John _____________Original message ____________ Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Sspecifications Sender: ext Gary Kenward Date: Sun, 11 Aug 2002 10:15:23 -0500 Rajeev: Actually, I my point had nothing to do with the text, which I have no problem with. I do have problems with some of the transport protocol statements and requirements that have been put forth. The main issue is that I see a tendency towards having a different transport for every feature context, with potentially different mappings for each combination of context and transport protocol combination. Admittedly, this is a worse case scenario, but entropy is strong force in the internet, and if we adopt James' view of the feature context specifications as it is written, we open up the opportunity for CT to drift towards the worst case. I understand what James was trying to do, I think, but in reading over the proposed 5.8 requirements, I came to realize that there would be little to the actual CT protocol except for a specification of the feature context encapsulation format, and possibly the rules for multiplexing multiple feature contexts onto a give transport frame. This *may* be the best approach, but this would mean that CT is actually a suit of protocols, one for each feature. Designing and standardizing on a collection of protocols will be more difficult, and fraught with risk, then designing and standardizing one protocol, at least for CT. Implementation of a collection of protocols, feature CT and each associated transport protocol, would also be problematical. Obviously, I believe that it is possible to convey all feature contexts with one CT protocol, running over one (to be determined) transport. It may be that people will want the option to chose the transport protocol, but there still only should be one transport per network (obviously, this impacts the interworking capability of CT, but the wg seems to have very diverse opinions on the appropriate transport, and so be it). Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: August 8, 2002 18:48 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Sspecifications > > > > Hello, > > I don't know if we are debating James' intent or > the text in 5.81. I hope it is the latter, with no disrespect > intended. And, I think the text is fine. I see no coupling to > specific transport protocols or option formats as Gary seems > to be referring to. The purpose of the IANA types > is to uniquely identify each feature context, which > facilitates inter-operability (for instance, a receiver > knows before it begins parsing the data fields _what_ > context it is looking at, and _how_ to process it). > So, I am in favor of text in 5.8.1. > > Regards, > > -Rajeev > > > > Gary Kenward wrote: > > > > > > > Madjid: > > > > I snip because the back and forth replies become long, and > the email > > rejects messages over 40K (which is not as big as it might seem). > > > > The text you quote does not address my concern. James used the > > particular > > phrase "standard option format" in a paragraph discussing context > > transport, > > not type codes. It is possible I misinterpreted his intent, but that > > is > > why I asked the question. > > > > Even so, I would question the rationale of standardizing > the mapping > > of type codes into option format fields of specific transport > > protocols. > > It implies that each transport protocol could have > different mappings. > > > > I see no advantage, and much risk in such an approach. > > > > Gary > > > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: August 8, 2002 16:57 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; > > 'James > > > Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > Feature Context > > > S pecifications > > > > > > > > > Gary, > > > > > > I am sorry, I think you took the "context" out of the > > > discussion by snipping > > > the rest of the comments :) > > > The following text suggested by James captures the issue: > > > > > > Madjid > > > > > > > 5.8.1 A feature context specification MUST contain an IANA > > > assigned type > > > code > > > > for the particular feature context. If an experimental > > > feature context > > > protocol > > > > is being developed, a type code from the context transfer > > protocol's > > > > experimental range SHOULD be used. The type code is used in > > > the context > > > transfer > > > > container to identify the feature context. > > > > > > > > > > > > -----Original Message----- > > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > Sent: Tuesday, August 06, 2002 12:32 PM > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > Feature Context S > > > pecifications > > > > > > > > > Madjid: > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: July 22, 2002 18:56 > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on > > > > Feature Context > > > > S pecifications > > > > > > > > > > > *snip* > > > > > > > > If the feature context is transferred as an > > > > option on another IETF protocol, then the feature context > > > > specification MUST > > > > define the mapping of the context transfer container into the > > > > other protocol's > > > > standard option format. If the feature context is transferred > > > What did you mean by "standard option format"? CT, as we have > > > been discussing it, is a container protocol, defined around > > > context "chunks". Are you implying that it should also allow > > > for encoding of context into the option fields of other > protocols??? > > > > > Gary > > > *snip* > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Aug 11 20:30: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 UAA25340 for ; Sun, 11 Aug 2002 20:30:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26738; Sun, 11 Aug 2002 20:24:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26709 for ; Sun, 11 Aug 2002 20:23:59 -0400 (EDT) Received: from odin.ietf.org ([216.139.170.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25036 for ; Sun, 11 Aug 2002 20:22:29 -0400 (EDT) Message-Id: <200208120022.UAA25036@ietf.org> From: "Malik Abacha" Date: Sun, 02 Jan 2000 16:39:04 To: seamoby@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] REPLY AS SOON AS POSSIBLE Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 ATTN:SIR, My wish at its peak is that you're in good health because health is wealth. I know you dont know me so I have to introduce myself to you. My name is Muhameed Abacha, a second cousin to the late Nigerian Head of state Gen.Sani Abacha who rule between 1993 and 1998. For more reference to me I would love you to know more about my uncle. Please view this site and read it contents carefully; http://news.bbc.co.uk/hi/english/world/africa/newsid_741000/741506.stm During the 4th year of his rule, he gave me a sum of US$23M to boost my business which I just opened in Ogba area of Lagos. Unfortunately, the complex which I was using as a ware-house got burnt by a very ragious inferno. I decided to keep the money until the next year when I would start importing new goods from a contractor in Germany which I had signed earlier before the incident. My uncle died the next year and everything blew up, the new government started probing the whole family members and freezed most of the family accounts. To cut the long story short, they have not detected the money which I secured in a Security company in Holland. Please, I would need you to assist me in retrieving the fund from the company because if I want to retrieve it and they know my identity they would definitely freeze the money in their account. What you have to do is very simple, you will claim the fund as a beneficiary from a contract which was executed by an uncle of yours. All paper works would be put in place for you to claim the money for me. The total amount involved is US$16.5M. 10% would be for any expenses incured during the transaction, 30% would be for your support, while the remaining 60% remains mine. I'm an African who believes in divine direction and you have been divinely chosen to handle this transaction. I hope to hear from you soon. Thanks. Yours Muhameed Abacha. Alternate e-mail address:m_abacha@sify.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Aug 11 20:30: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 UAA25350 for ; Sun, 11 Aug 2002 20:30:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA27617 for seamoby-archive@odin.ietf.org; Sun, 11 Aug 2002 20:31:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26738; Sun, 11 Aug 2002 20:24:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26709 for ; Sun, 11 Aug 2002 20:23:59 -0400 (EDT) Received: from odin.ietf.org ([216.139.170.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25036 for ; Sun, 11 Aug 2002 20:22:29 -0400 (EDT) Message-Id: <200208120022.UAA25036@ietf.org> From: "Malik Abacha" Date: Sun, 02 Jan 2000 16:39:04 To: seamoby@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] REPLY AS SOON AS POSSIBLE Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 ATTN:SIR, My wish at its peak is that you're in good health because health is wealth. I know you dont know me so I have to introduce myself to you. My name is Muhameed Abacha, a second cousin to the late Nigerian Head of state Gen.Sani Abacha who rule between 1993 and 1998. For more reference to me I would love you to know more about my uncle. Please view this site and read it contents carefully; http://news.bbc.co.uk/hi/english/world/africa/newsid_741000/741506.stm During the 4th year of his rule, he gave me a sum of US$23M to boost my business which I just opened in Ogba area of Lagos. Unfortunately, the complex which I was using as a ware-house got burnt by a very ragious inferno. I decided to keep the money until the next year when I would start importing new goods from a contractor in Germany which I had signed earlier before the incident. My uncle died the next year and everything blew up, the new government started probing the whole family members and freezed most of the family accounts. To cut the long story short, they have not detected the money which I secured in a Security company in Holland. Please, I would need you to assist me in retrieving the fund from the company because if I want to retrieve it and they know my identity they would definitely freeze the money in their account. What you have to do is very simple, you will claim the fund as a beneficiary from a contract which was executed by an uncle of yours. All paper works would be put in place for you to claim the money for me. The total amount involved is US$16.5M. 10% would be for any expenses incured during the transaction, 30% would be for your support, while the remaining 60% remains mine. I'm an African who believes in divine direction and you have been divinely chosen to handle this transaction. I hope to hear from you soon. Thanks. Yours Muhameed Abacha. Alternate e-mail address:m_abacha@sify.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 12 11:29: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 LAA26147 for ; Mon, 12 Aug 2002 11:29:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17637; Mon, 12 Aug 2002 11:24:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17612 for ; Mon, 12 Aug 2002 11:23:59 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25848 for ; Mon, 12 Aug 2002 11:22:42 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7CFJP528879; Mon, 12 Aug 2002 11:19:26 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 11:19:26 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C8B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Mon, 12 Aug 2002 11:19:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24213.A219330C" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24213.A219330C Content-Type: text/plain; charset="iso-8859-1" Charlie: First of all, thanks again for your thoughtful replies. > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: August 9, 2002 19:49 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > > Gary Kenward wrote: > > > > How about a mapping of feature contexts into a small number of > > > transport protocols (e.g., UDP, TCP, SCTP, ICMP)? > > > > May happen. Why make it a requirement, or imply that this > is the best > > solution within the requirements document? > > O.K. I agree that it's not a requirement to use those protocols. > But I think that we should _expect_ that the eventual solution may > require that we make use of multiple transport protocols. > > >> Can you be more specific about what you mean here? > > > > If all context is transfer as data chunks in the payload, > then there really > > isn't a problem. However, if one starts mapping ct > information into option > > fields of various protocols, the mappings will very likely > change due to the > > differences in protocol syntax. IPv4 vs. IPv6 seems to be > the most pronounced > > example. > > I'm happy to model context as data, not option fields. > However, it could be (e.g., in the case of QoS) that the > context affects the fields of various protocols. In fact, > taken abstractly, all the cases I care about can be modeled > as affecting some fields of some protocol's data fields. > This is even true for buffering, and security contexts, right? You lost me a bit here. I was referring to the idea that the context would be embedded into option fields of the transport protocol. This would be the same as saying, for example, that SIP messages would be encoded into the header of an IPv4 packet. Whether you can or not, I believe it is simply bad design. The options of a transport protocol may be changed to select particular transport characteristics. This completely different from encoding the context into the transport options. > > > The real issue here is whether the CT > capability is > > fulfilled with a single protocol or a suite of protocols. I > believe the former > > is a preferable solution, if the protocol complexity is > manageable, which I > > believe it is. > > Again, I'm happy if there can be a single solution. But, if I were > given the choice of ICMP for some contexts, and TCP for others, vs. > waiting two more years for XCTTP (unknown context transfer transport > protocol), I'd go for using two transports. I do not really believe that there is much to be gained in creating yet another transport protocol. My point is that if you are going to transfer come of the context with TCP, for example, then you might as well transfer all of the context with TCP. We had a discussion, way back, about whether all the context can fit into one IP packet. Since the context was, and is still pretty much undefined, we could not reach a definitive solution. However, there doesn't seem to be any compelling reason to believe that context will typically exceed even 1500 bytes. Regardless, even if the context data does exceed the capacity of a single IP frame, we are not talking about megabytes of data. The benefit of splitting the context between different transport protocols just does not out weigh the detriments. At this point, may I suggest that we clarify the requirements to remove the implication that each feature context must have a separate transport protocol. I think that each feature context analysis should outline the ideal and adequate transport requirements, and choice of one or more then one transport should be left to the network designer. > > > We have pretty well decided that CT capability involves at > least two protocols > > (above IP): a CT containerizing protocol, and a transport protocol. > > Two is still better then a gaggle of protocols, IMHO. > > What's a containerizing protocol? Can't we just have data formats > without having to do distributing processing to collect the data? Not sure how you segued into distributed processing. I think the idea that CT is a container protocol has been discussed in the wg for some time now (ok, perhaps "containerizing" is a poor choice of words). Basically, what I believe has been discussed are encapsulated chunks of feature context (the context is "containerized") that are ferried about by a transport protocol. > Gaggle is, by the way, a great word. Is ICMP plus TCP approximately Thanks. > equal to, or less than, a gaggle? Well, two geese is still a gaggle, as far as I know. Nonetheless, what's the criteria/requirement that prevents each feature context from having it's own transport protocol? At this point, I still see ICMP plus TCP as being one too many protocols. > > >> If the transport protocols are UDP, TCP, SCTP, and ICMP, > there isn't > >> much problem with implementation. Or maybe I missed your point... > > > > Well, this assumes that the ARs have end-point stacks for > all of the transport > > protocols, and management interfaces, etc. Most routers > have ICMP/UDP support. > > > Technically, supporting 4+/- protocols is perhaps not that > big of a deal...but > > where's the value? > > As I mentioned above, if you can make a single protocol do it, I'll > be happy (still wondering about that containerizing, though). Yes, as I said, bad choice of word. The "containerizing" would be something that the CT protocol would "do" - e.g. CTP needs to define the format of the container, with type codes, length fields, etc. - whatever is decided is necessary to ensure that the feature context is opaque to the transport, but still can be extracted at the receiver. > > >> I think that HI and HAck from [mobile-ip] fast handovers would be > >> a very suitable transport for some contexts that do not require > >> rock-solid reliability, for those cases where they are available. > >> I think that TCP or SCTP would be just fine for a lot of contexts > >> that do require high reliability. If we don't have HI and HAck > >> available, but we have contexts with requirement for very low > >> latency, then we can decide whether the contexts should be > >> encapsulated in ICMP, UDP, or some IP-level option. > > > > Again, I have no problem ( at least at this point) with > saying that the > > designer can run CT over one of a number of protocols, say > they are UDP, > > SCTP, ICMP, TCP - I do have a problem with the idea that > each feature CT will > > run over different protocols. Now, instead of one context > transfer, you have > > at least one for each transport protocol used (assuming > feature CTs that use > > the same transport can be multiplexed onto one frame). This > exacerbates many > > issues such as transfer delay, ordering, updates > synchronization, etc. > > I can see a simple solution for this: > > 1. Find the most urgent context. Encapsulate it using the transport > it specifies (which won't be TCP, I reckon, for extremely urgent > contexts). Fill the rest of the context feature data structure Why not? I agree if the intent were to set up a TCP connection every time you wanted to perform CT, but at least for networks where the ARs are wired together, a single TCP connection between two ARs can be established and kept open, can it not, to handle all CTs. > with the most urgent other contexts that will fit, and which are > compatible with the chosen transport. If the chosen transport > is not a reliable transport, schedule a retransmission if any > context transfer requires acknowledgement. I seem to sense a proposal here to layer an ACK/retransmission protocol on top of ICMP. Seems like you are really back to creating XCTCP, but with the (possible erroneous) assumption that ICMP is an appropriate starting point. > > 2. If there are any contexts left, goto (1). > > timeout(retransmission_timer) { > retransmit the packet; > if (not-enough-retries-yet) { > schedule_another_retransmission(); > } > } Curious. Are you suggesting one exchange per feature context (i.e. with each feature context to be transferred you initiate a new transport exchange, which requires one or more IP packets)? If so, I would say that you have already lost the battle to enhance seamlessness. Why not simply put all feature contexts into one transport exchange? Which hopefully means, one IP packet. BTW: if the goal here is to merge CT with the HI/HACK mechanism for MobileIP, then the intent is misguided. CT is supposed to work in scenarios where MobileIP is not present. Certainly requiring the network to implement HI/HACK simply to allow part of the CT to occur is wrong. > > process_ack { > delete_retransmission_timeout(); > } > > > The only reason you would separate the transports in this > case is if there > > was an advantage to optimizing for the "low performance" > requirements. That > > is, what is the problem with delivering a feature context > with a lower > > latency or higher reliability? > > How do you like my high-level example above? It's an example, not an > attempt to enforce a particular solution. Of course there are a huge > number of details omitted, like what the receving AR does with the > various kinds of features, but those are straightforward details. See comments. I am beginning to believe that this debate is more around trying to incorporate HI/HACK into CT then it is about what transport protocol CT needs. Please tell me why am mistaken. Cheers, Gary > > Regards, > Charlie P. > ------_=_NextPart_001_01C24213.A219330C Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

Charlie:

  First of all, thanks again for your thoughtful replies.

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 9, 2002 19:49
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> > Gary Kenward wrote:
>
> > > How about a mapping of feature contexts into a small number of
> > > transport protocols (e.g., UDP, TCP, SCTP, ICMP)?
> >
> > May happen. Why make it a requirement, or imply that this
> is the best
> > solution within the requirements document?
>
> O.K.  I agree that it's not a requirement to use those protocols.
> But I think that we should _expect_ that the eventual solution may
> require that we make use of multiple transport protocols.
>
> >> Can you be more specific about what you mean here?
> >
> > If all context is transfer as data chunks in the payload,
> then there really
> > isn't a problem. However, if one starts mapping ct
> information into option
> > fields of various protocols, the mappings will very likely
> change due to the
> > differences in protocol syntax. IPv4 vs. IPv6 seems to be
> the most pronounced
> > example.
>
> I'm happy to model context as data, not option fields.
> However, it could be (e.g., in the case of QoS) that the
> context affects the fields of various protocols.  In fact,
> taken abstractly, all the cases I care about can be modeled
> as affecting some fields of some protocol's data fields.
> This is even true for buffering, and security contexts, right?

You lost me a bit here. I was referring to the idea that the context
would be embedded into option fields of the transport protocol. This
would be the same as saying, for example, that SIP messages would be
encoded into the header of an IPv4 packet. Whether you can or not,
I believe it is simply bad design.

The options of a transport protocol may be changed to select particular
transport characteristics. This completely different from encoding the
context into the transport options.

>
> >                     The real issue here is whether the CT
> capability is
> > fulfilled with a single protocol or a suite of protocols. I
> believe the former
> > is a preferable solution, if the protocol complexity is
> manageable, which I
> > believe it is.
>
> Again, I'm happy if there can be a single solution.  But, if I were
> given the choice of ICMP for some contexts, and TCP for others, vs.
> waiting two more years for XCTTP (unknown context transfer transport
> protocol), I'd go for using two transports.

I do not really believe that there is much to be gained in creating yet
another transport protocol. My point is that if you are going to transfer
come of the context with TCP, for example, then you might as well transfer
all of the context with TCP.

We had a discussion, way back, about whether all the context can fit into
one IP packet. Since the context was, and is still pretty much undefined,
we could not reach a definitive solution. However, there doesn't seem to
be any compelling reason to believe that context will typically exceed even
1500 bytes. Regardless, even if the context data does exceed the capacity of
a single IP frame, we are not talking about megabytes of data. The benefit
of splitting the context between different transport protocols just does not
out weigh the detriments.

At this point, may I suggest that we clarify the requirements to remove the
implication that each feature context must have a separate transport protocol.
I think that each feature context analysis should outline the ideal and
adequate transport requirements, and choice of one or more then one transport
should be left to the network designer.

>
> > We have pretty well decided that CT capability involves at
> least two protocols
> > (above IP): a CT containerizing protocol, and a transport protocol.
> > Two is still better then a gaggle of protocols, IMHO.
>
> What's a containerizing protocol?  Can't we just have data formats
> without having to do distributing processing to collect the data?

Not sure how you segued into distributed processing. I think the idea
that CT is a container protocol has been discussed in the wg for some
time now (ok, perhaps "containerizing" is a poor choice of words).
Basically, what I believe has been discussed are encapsulated chunks
of feature context (the context is "containerized") that are ferried
about by a transport protocol.

> Gaggle is, by the way, a great word.  Is ICMP plus TCP approximately

Thanks.

> equal to, or less than, a gaggle?

Well, two geese is still a gaggle, as far as I know. Nonetheless, what's
the criteria/requirement that prevents each feature context from having
it's own transport protocol?

At this point, I still see ICMP plus TCP as being one too many protocols.

>
> >> If the transport protocols are UDP, TCP, SCTP, and ICMP,
> there isn't
> >> much problem with implementation.  Or maybe I missed your point...
> >
> > Well, this assumes that the ARs have end-point stacks for
> all of the transport
> > protocols, and management interfaces, etc. Most routers
> have ICMP/UDP support.
>
> > Technically, supporting 4+/- protocols is perhaps not that
> big of a deal...but
> > where's the value?
>
> As I mentioned above, if you can make a single protocol do it, I'll
> be happy (still wondering about that containerizing, though).

Yes, as I said, bad choice of word. The "containerizing" would be something
that the CT protocol would "do" - e.g. CTP needs to define the format of
the container, with type codes, length fields, etc. - whatever is decided
is necessary to ensure that the feature context is opaque to the transport,
but still can be extracted at the receiver.
 
>
> >> I think that HI and HAck from [mobile-ip] fast handovers would be
> >> a very suitable transport for some contexts that do not require
> >> rock-solid reliability, for those cases where they are available.
> >> I think that TCP or SCTP would be just fine for a lot of contexts
> >> that do require high reliability.  If we don't have HI and HAck
> >> available, but we have contexts with requirement for very low
> >> latency, then we can decide whether the contexts should be
> >> encapsulated in ICMP, UDP, or some IP-level option.
> >
> > Again, I have no problem ( at least at this point) with
> saying that the
> > designer can run CT over one of a number of protocols, say
> they are UDP,
> > SCTP, ICMP, TCP - I do have a problem with the idea that
> each feature CT will
> > run over different protocols. Now, instead of one context
> transfer, you have
> > at least one for each transport protocol used (assuming
> feature CTs that use
> > the same transport can be multiplexed onto one frame). This
> exacerbates many
> > issues such as transfer delay, ordering, updates
> synchronization, etc.
>
> I can see a simple solution for this:
>
> 1. Find the most urgent context.  Encapsulate it using the transport
>    it specifies (which won't be TCP, I reckon, for extremely urgent
>    contexts).   Fill the rest of the context feature data structure

Why not? I agree if the intent were to set up a TCP connection every
time you wanted to perform CT, but at least for networks where the
ARs are wired together, a single TCP connection between two ARs can be
established and kept open, can it not, to handle all CTs.

>    with the most urgent other contexts that will fit, and which are
>    compatible with the chosen transport.  If the chosen transport
>    is not a reliable transport, schedule a retransmission if any
>    context transfer requires acknowledgement.

I seem to sense a proposal here to layer an ACK/retransmission protocol
on top of ICMP. Seems like you are really back to creating XCTCP, but
with the (possible erroneous) assumption that ICMP is an appropriate
starting point.

>
> 2. If there are any contexts left, goto (1).
>
> timeout(retransmission_timer) {
>       retransmit the packet;
>       if (not-enough-retries-yet) {
>               schedule_another_retransmission();
>       }
> }

Curious. Are you suggesting one exchange per feature context (i.e.
with each feature context to be transferred you initiate a new transport
exchange, which requires one or more IP packets)? If so, I would say
that you have already lost the battle to enhance seamlessness.

Why not simply put all feature contexts into one transport exchange?
Which hopefully means, one IP packet.

BTW: if the goal here is to merge CT with the HI/HACK mechanism for
MobileIP, then the intent is misguided. CT is supposed to work in
scenarios where MobileIP is not present. Certainly requiring the
network to implement HI/HACK simply to allow part of the CT to occur
is wrong.

>
> process_ack {
>       delete_retransmission_timeout();
> }
>
> > The only reason you would separate the transports in this
> case is if there
> > was an advantage to optimizing for the "low performance"
> requirements. That
> > is, what is the problem with delivering a feature context
> with a lower
> > latency or higher reliability?
>
> How do you like my high-level example above?   It's an example, not an
> attempt to enforce a particular solution.  Of course there are a huge
> number of details omitted, like what the receving AR does with the
> various kinds of features, but those are straightforward details.

See comments. I am beginning to believe that this debate is more around
trying to incorporate HI/HACK into CT then it is about what transport
protocol CT needs. Please tell me why am mistaken.

Cheers,
Gary
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C24213.A219330C-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 11:29: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 LAA26154 for ; Mon, 12 Aug 2002 11:29:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18409 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 11:31:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17637; Mon, 12 Aug 2002 11:24:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17612 for ; Mon, 12 Aug 2002 11:23:59 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25848 for ; Mon, 12 Aug 2002 11:22:42 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7CFJP528879; Mon, 12 Aug 2002 11:19:26 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 11:19:26 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C8B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Mon, 12 Aug 2002 11:19:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24213.A219330C" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24213.A219330C Content-Type: text/plain; charset="iso-8859-1" Charlie: First of all, thanks again for your thoughtful replies. > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: August 9, 2002 19:49 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > > Gary Kenward wrote: > > > > How about a mapping of feature contexts into a small number of > > > transport protocols (e.g., UDP, TCP, SCTP, ICMP)? > > > > May happen. Why make it a requirement, or imply that this > is the best > > solution within the requirements document? > > O.K. I agree that it's not a requirement to use those protocols. > But I think that we should _expect_ that the eventual solution may > require that we make use of multiple transport protocols. > > >> Can you be more specific about what you mean here? > > > > If all context is transfer as data chunks in the payload, > then there really > > isn't a problem. However, if one starts mapping ct > information into option > > fields of various protocols, the mappings will very likely > change due to the > > differences in protocol syntax. IPv4 vs. IPv6 seems to be > the most pronounced > > example. > > I'm happy to model context as data, not option fields. > However, it could be (e.g., in the case of QoS) that the > context affects the fields of various protocols. In fact, > taken abstractly, all the cases I care about can be modeled > as affecting some fields of some protocol's data fields. > This is even true for buffering, and security contexts, right? You lost me a bit here. I was referring to the idea that the context would be embedded into option fields of the transport protocol. This would be the same as saying, for example, that SIP messages would be encoded into the header of an IPv4 packet. Whether you can or not, I believe it is simply bad design. The options of a transport protocol may be changed to select particular transport characteristics. This completely different from encoding the context into the transport options. > > > The real issue here is whether the CT > capability is > > fulfilled with a single protocol or a suite of protocols. I > believe the former > > is a preferable solution, if the protocol complexity is > manageable, which I > > believe it is. > > Again, I'm happy if there can be a single solution. But, if I were > given the choice of ICMP for some contexts, and TCP for others, vs. > waiting two more years for XCTTP (unknown context transfer transport > protocol), I'd go for using two transports. I do not really believe that there is much to be gained in creating yet another transport protocol. My point is that if you are going to transfer come of the context with TCP, for example, then you might as well transfer all of the context with TCP. We had a discussion, way back, about whether all the context can fit into one IP packet. Since the context was, and is still pretty much undefined, we could not reach a definitive solution. However, there doesn't seem to be any compelling reason to believe that context will typically exceed even 1500 bytes. Regardless, even if the context data does exceed the capacity of a single IP frame, we are not talking about megabytes of data. The benefit of splitting the context between different transport protocols just does not out weigh the detriments. At this point, may I suggest that we clarify the requirements to remove the implication that each feature context must have a separate transport protocol. I think that each feature context analysis should outline the ideal and adequate transport requirements, and choice of one or more then one transport should be left to the network designer. > > > We have pretty well decided that CT capability involves at > least two protocols > > (above IP): a CT containerizing protocol, and a transport protocol. > > Two is still better then a gaggle of protocols, IMHO. > > What's a containerizing protocol? Can't we just have data formats > without having to do distributing processing to collect the data? Not sure how you segued into distributed processing. I think the idea that CT is a container protocol has been discussed in the wg for some time now (ok, perhaps "containerizing" is a poor choice of words). Basically, what I believe has been discussed are encapsulated chunks of feature context (the context is "containerized") that are ferried about by a transport protocol. > Gaggle is, by the way, a great word. Is ICMP plus TCP approximately Thanks. > equal to, or less than, a gaggle? Well, two geese is still a gaggle, as far as I know. Nonetheless, what's the criteria/requirement that prevents each feature context from having it's own transport protocol? At this point, I still see ICMP plus TCP as being one too many protocols. > > >> If the transport protocols are UDP, TCP, SCTP, and ICMP, > there isn't > >> much problem with implementation. Or maybe I missed your point... > > > > Well, this assumes that the ARs have end-point stacks for > all of the transport > > protocols, and management interfaces, etc. Most routers > have ICMP/UDP support. > > > Technically, supporting 4+/- protocols is perhaps not that > big of a deal...but > > where's the value? > > As I mentioned above, if you can make a single protocol do it, I'll > be happy (still wondering about that containerizing, though). Yes, as I said, bad choice of word. The "containerizing" would be something that the CT protocol would "do" - e.g. CTP needs to define the format of the container, with type codes, length fields, etc. - whatever is decided is necessary to ensure that the feature context is opaque to the transport, but still can be extracted at the receiver. > > >> I think that HI and HAck from [mobile-ip] fast handovers would be > >> a very suitable transport for some contexts that do not require > >> rock-solid reliability, for those cases where they are available. > >> I think that TCP or SCTP would be just fine for a lot of contexts > >> that do require high reliability. If we don't have HI and HAck > >> available, but we have contexts with requirement for very low > >> latency, then we can decide whether the contexts should be > >> encapsulated in ICMP, UDP, or some IP-level option. > > > > Again, I have no problem ( at least at this point) with > saying that the > > designer can run CT over one of a number of protocols, say > they are UDP, > > SCTP, ICMP, TCP - I do have a problem with the idea that > each feature CT will > > run over different protocols. Now, instead of one context > transfer, you have > > at least one for each transport protocol used (assuming > feature CTs that use > > the same transport can be multiplexed onto one frame). This > exacerbates many > > issues such as transfer delay, ordering, updates > synchronization, etc. > > I can see a simple solution for this: > > 1. Find the most urgent context. Encapsulate it using the transport > it specifies (which won't be TCP, I reckon, for extremely urgent > contexts). Fill the rest of the context feature data structure Why not? I agree if the intent were to set up a TCP connection every time you wanted to perform CT, but at least for networks where the ARs are wired together, a single TCP connection between two ARs can be established and kept open, can it not, to handle all CTs. > with the most urgent other contexts that will fit, and which are > compatible with the chosen transport. If the chosen transport > is not a reliable transport, schedule a retransmission if any > context transfer requires acknowledgement. I seem to sense a proposal here to layer an ACK/retransmission protocol on top of ICMP. Seems like you are really back to creating XCTCP, but with the (possible erroneous) assumption that ICMP is an appropriate starting point. > > 2. If there are any contexts left, goto (1). > > timeout(retransmission_timer) { > retransmit the packet; > if (not-enough-retries-yet) { > schedule_another_retransmission(); > } > } Curious. Are you suggesting one exchange per feature context (i.e. with each feature context to be transferred you initiate a new transport exchange, which requires one or more IP packets)? If so, I would say that you have already lost the battle to enhance seamlessness. Why not simply put all feature contexts into one transport exchange? Which hopefully means, one IP packet. BTW: if the goal here is to merge CT with the HI/HACK mechanism for MobileIP, then the intent is misguided. CT is supposed to work in scenarios where MobileIP is not present. Certainly requiring the network to implement HI/HACK simply to allow part of the CT to occur is wrong. > > process_ack { > delete_retransmission_timeout(); > } > > > The only reason you would separate the transports in this > case is if there > > was an advantage to optimizing for the "low performance" > requirements. That > > is, what is the problem with delivering a feature context > with a lower > > latency or higher reliability? > > How do you like my high-level example above? It's an example, not an > attempt to enforce a particular solution. Of course there are a huge > number of details omitted, like what the receving AR does with the > various kinds of features, but those are straightforward details. See comments. I am beginning to believe that this debate is more around trying to incorporate HI/HACK into CT then it is about what transport protocol CT needs. Please tell me why am mistaken. Cheers, Gary > > Regards, > Charlie P. > ------_=_NextPart_001_01C24213.A219330C Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

Charlie:

  First of all, thanks again for your thoughtful replies.

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 9, 2002 19:49
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> > Gary Kenward wrote:
>
> > > How about a mapping of feature contexts into a small number of
> > > transport protocols (e.g., UDP, TCP, SCTP, ICMP)?
> >
> > May happen. Why make it a requirement, or imply that this
> is the best
> > solution within the requirements document?
>
> O.K.  I agree that it's not a requirement to use those protocols.
> But I think that we should _expect_ that the eventual solution may
> require that we make use of multiple transport protocols.
>
> >> Can you be more specific about what you mean here?
> >
> > If all context is transfer as data chunks in the payload,
> then there really
> > isn't a problem. However, if one starts mapping ct
> information into option
> > fields of various protocols, the mappings will very likely
> change due to the
> > differences in protocol syntax. IPv4 vs. IPv6 seems to be
> the most pronounced
> > example.
>
> I'm happy to model context as data, not option fields.
> However, it could be (e.g., in the case of QoS) that the
> context affects the fields of various protocols.  In fact,
> taken abstractly, all the cases I care about can be modeled
> as affecting some fields of some protocol's data fields.
> This is even true for buffering, and security contexts, right?

You lost me a bit here. I was referring to the idea that the context
would be embedded into option fields of the transport protocol. This
would be the same as saying, for example, that SIP messages would be
encoded into the header of an IPv4 packet. Whether you can or not,
I believe it is simply bad design.

The options of a transport protocol may be changed to select particular
transport characteristics. This completely different from encoding the
context into the transport options.

>
> >                     The real issue here is whether the CT
> capability is
> > fulfilled with a single protocol or a suite of protocols. I
> believe the former
> > is a preferable solution, if the protocol complexity is
> manageable, which I
> > believe it is.
>
> Again, I'm happy if there can be a single solution.  But, if I were
> given the choice of ICMP for some contexts, and TCP for others, vs.
> waiting two more years for XCTTP (unknown context transfer transport
> protocol), I'd go for using two transports.

I do not really believe that there is much to be gained in creating yet
another transport protocol. My point is that if you are going to transfer
come of the context with TCP, for example, then you might as well transfer
all of the context with TCP.

We had a discussion, way back, about whether all the context can fit into
one IP packet. Since the context was, and is still pretty much undefined,
we could not reach a definitive solution. However, there doesn't seem to
be any compelling reason to believe that context will typically exceed even
1500 bytes. Regardless, even if the context data does exceed the capacity of
a single IP frame, we are not talking about megabytes of data. The benefit
of splitting the context between different transport protocols just does not
out weigh the detriments.

At this point, may I suggest that we clarify the requirements to remove the
implication that each feature context must have a separate transport protocol.
I think that each feature context analysis should outline the ideal and
adequate transport requirements, and choice of one or more then one transport
should be left to the network designer.

>
> > We have pretty well decided that CT capability involves at
> least two protocols
> > (above IP): a CT containerizing protocol, and a transport protocol.
> > Two is still better then a gaggle of protocols, IMHO.
>
> What's a containerizing protocol?  Can't we just have data formats
> without having to do distributing processing to collect the data?

Not sure how you segued into distributed processing. I think the idea
that CT is a container protocol has been discussed in the wg for some
time now (ok, perhaps "containerizing" is a poor choice of words).
Basically, what I believe has been discussed are encapsulated chunks
of feature context (the context is "containerized") that are ferried
about by a transport protocol.

> Gaggle is, by the way, a great word.  Is ICMP plus TCP approximately

Thanks.

> equal to, or less than, a gaggle?

Well, two geese is still a gaggle, as far as I know. Nonetheless, what's
the criteria/requirement that prevents each feature context from having
it's own transport protocol?

At this point, I still see ICMP plus TCP as being one too many protocols.

>
> >> If the transport protocols are UDP, TCP, SCTP, and ICMP,
> there isn't
> >> much problem with implementation.  Or maybe I missed your point...
> >
> > Well, this assumes that the ARs have end-point stacks for
> all of the transport
> > protocols, and management interfaces, etc. Most routers
> have ICMP/UDP support.
>
> > Technically, supporting 4+/- protocols is perhaps not that
> big of a deal...but
> > where's the value?
>
> As I mentioned above, if you can make a single protocol do it, I'll
> be happy (still wondering about that containerizing, though).

Yes, as I said, bad choice of word. The "containerizing" would be something
that the CT protocol would "do" - e.g. CTP needs to define the format of
the container, with type codes, length fields, etc. - whatever is decided
is necessary to ensure that the feature context is opaque to the transport,
but still can be extracted at the receiver.
 
>
> >> I think that HI and HAck from [mobile-ip] fast handovers would be
> >> a very suitable transport for some contexts that do not require
> >> rock-solid reliability, for those cases where they are available.
> >> I think that TCP or SCTP would be just fine for a lot of contexts
> >> that do require high reliability.  If we don't have HI and HAck
> >> available, but we have contexts with requirement for very low
> >> latency, then we can decide whether the contexts should be
> >> encapsulated in ICMP, UDP, or some IP-level option.
> >
> > Again, I have no problem ( at least at this point) with
> saying that the
> > designer can run CT over one of a number of protocols, say
> they are UDP,
> > SCTP, ICMP, TCP - I do have a problem with the idea that
> each feature CT will
> > run over different protocols. Now, instead of one context
> transfer, you have
> > at least one for each transport protocol used (assuming
> feature CTs that use
> > the same transport can be multiplexed onto one frame). This
> exacerbates many
> > issues such as transfer delay, ordering, updates
> synchronization, etc.
>
> I can see a simple solution for this:
>
> 1. Find the most urgent context.  Encapsulate it using the transport
>    it specifies (which won't be TCP, I reckon, for extremely urgent
>    contexts).   Fill the rest of the context feature data structure

Why not? I agree if the intent were to set up a TCP connection every
time you wanted to perform CT, but at least for networks where the
ARs are wired together, a single TCP connection between two ARs can be
established and kept open, can it not, to handle all CTs.

>    with the most urgent other contexts that will fit, and which are
>    compatible with the chosen transport.  If the chosen transport
>    is not a reliable transport, schedule a retransmission if any
>    context transfer requires acknowledgement.

I seem to sense a proposal here to layer an ACK/retransmission protocol
on top of ICMP. Seems like you are really back to creating XCTCP, but
with the (possible erroneous) assumption that ICMP is an appropriate
starting point.

>
> 2. If there are any contexts left, goto (1).
>
> timeout(retransmission_timer) {
>       retransmit the packet;
>       if (not-enough-retries-yet) {
>               schedule_another_retransmission();
>       }
> }

Curious. Are you suggesting one exchange per feature context (i.e.
with each feature context to be transferred you initiate a new transport
exchange, which requires one or more IP packets)? If so, I would say
that you have already lost the battle to enhance seamlessness.

Why not simply put all feature contexts into one transport exchange?
Which hopefully means, one IP packet.

BTW: if the goal here is to merge CT with the HI/HACK mechanism for
MobileIP, then the intent is misguided. CT is supposed to work in
scenarios where MobileIP is not present. Certainly requiring the
network to implement HI/HACK simply to allow part of the CT to occur
is wrong.

>
> process_ack {
>       delete_retransmission_timeout();
> }
>
> > The only reason you would separate the transports in this
> case is if there
> > was an advantage to optimizing for the "low performance"
> requirements. That
> > is, what is the problem with delivering a feature context
> with a lower
> > latency or higher reliability?
>
> How do you like my high-level example above?   It's an example, not an
> attempt to enforce a particular solution.  Of course there are a huge
> number of details omitted, like what the receving AR does with the
> various kinds of features, but those are straightforward details.

See comments. I am beginning to believe that this debate is more around
trying to incorporate HI/HACK into CT then it is about what transport
protocol CT needs. Please tell me why am mistaken.

Cheers,
Gary
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C24213.A219330C-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 12 11: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 LAA26310 for ; Mon, 12 Aug 2002 11:34:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17816; Mon, 12 Aug 2002 11:28:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17749 for ; Mon, 12 Aug 2002 11:28:30 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25984 for ; Mon, 12 Aug 2002 11:27:14 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7CFRc529752; Mon, 12 Aug 2002 11:27:39 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 11:27:39 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C8C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Mon, 12 Aug 2002 11:27:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24213.B12D323A" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24213.B12D323A Content-Type: text/plain; charset="iso-8859-1" James: Well, the short answer is no, as the requirements still say that CT can convey L2 context, as long as it does not require CT to do anything special. Curiously, the concern, at least on my part, was with the idea that IAPP would be considered part of the suite of feature context transport protocols used for a context transfer. Your comment below expressing a concern about "two context transfers", would seem to contradict the requirement text you proposed that implied that each feature context would specify its own transport protocol. I am looking for CT to be light weight, relatively fast and relatively reliable, including the transport. By relatively fast I mean that it must enhance mobility, otherwise it's not worth doing. By relatively reliable, I mean it had better work most of the time, but I really do not need five nine's of reliability - that handovers fail occasionally is a reality with wireless. I cannot be more specific without talking numbers. And so, from your comments below, I take it that you also would prefer one CT exchange, implying one transport protocol? If so, would you be willing to modify your proposed text at least to indicate that this is the preferred objective for CT? Cheers, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: August 9, 2002 17:43 > To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH]; > john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > > Agreed to some extent. To be precise: context has to be > present at layer 2 > devices. > > > > by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP > itself is below IP > on the stack. > > CT on the other hand as of today is AR-AR. > > > > So suppose I'm developing a 802.11 AP that also contains AR > functionality. Are > you saying that I have to use two context transfers, one with > IAPP and one with > an IP CT protocol, in order to be able to get Radius context > between the > devices? > > jak > > ------_=_NextPart_001_01C24213.B12D323A Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

James:

  Well, the short answer is no, as the requirements still say
that CT can convey L2 context, as long as it does not require
CT to do anything special.

  Curiously, the concern, at least on my part, was with the idea
that IAPP would be considered part of the suite of feature context
transport protocols used for a context transfer.

  Your comment below expressing a concern about "two context
transfers", would seem to contradict the requirement text
you proposed that implied that each feature context would
specify its own transport protocol.

  I am looking for CT to be light weight, relatively fast and
relatively reliable, including the transport. By relatively fast
I mean that it must enhance mobility, otherwise it's not worth
doing. By relatively reliable, I mean it had better work most
of the time, but I really do not need five nine's of reliability
- that handovers fail occasionally is a reality with wireless.
I cannot be more specific without talking numbers.

  And so, from your comments below, I take it that you also would
prefer one CT exchange, implying one transport protocol? If so,
would you be willing to modify your proposed text at least to
indicate that this is the preferred objective for CT?

Cheers,
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: August 9, 2002 17:43
> To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH];
> john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
>
> > Agreed to some extent. To be precise: context has to be
> present at layer 2
> devices.
> >
> > by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP
> itself is below IP
> on the stack.
> > CT on the other hand as of today is AR-AR.
> >
>
> So suppose I'm developing a 802.11 AP that also contains AR
> functionality. Are
> you saying that I have to use two context transfers, one with
> IAPP and one with
> an IP CT protocol, in order to be able to get Radius context
> between the
> devices?
>
>             jak
>
>

------_=_NextPart_001_01C24213.B12D323A-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 11:34: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 LAA26317 for ; Mon, 12 Aug 2002 11:34:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18592 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 11:35:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17816; Mon, 12 Aug 2002 11:28:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17749 for ; Mon, 12 Aug 2002 11:28:30 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25984 for ; Mon, 12 Aug 2002 11:27:14 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7CFRc529752; Mon, 12 Aug 2002 11:27:39 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 11:27:39 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C8C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Mon, 12 Aug 2002 11:27:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24213.B12D323A" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24213.B12D323A Content-Type: text/plain; charset="iso-8859-1" James: Well, the short answer is no, as the requirements still say that CT can convey L2 context, as long as it does not require CT to do anything special. Curiously, the concern, at least on my part, was with the idea that IAPP would be considered part of the suite of feature context transport protocols used for a context transfer. Your comment below expressing a concern about "two context transfers", would seem to contradict the requirement text you proposed that implied that each feature context would specify its own transport protocol. I am looking for CT to be light weight, relatively fast and relatively reliable, including the transport. By relatively fast I mean that it must enhance mobility, otherwise it's not worth doing. By relatively reliable, I mean it had better work most of the time, but I really do not need five nine's of reliability - that handovers fail occasionally is a reality with wireless. I cannot be more specific without talking numbers. And so, from your comments below, I take it that you also would prefer one CT exchange, implying one transport protocol? If so, would you be willing to modify your proposed text at least to indicate that this is the preferred objective for CT? Cheers, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: August 9, 2002 17:43 > To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH]; > john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > > Agreed to some extent. To be precise: context has to be > present at layer 2 > devices. > > > > by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP > itself is below IP > on the stack. > > CT on the other hand as of today is AR-AR. > > > > So suppose I'm developing a 802.11 AP that also contains AR > functionality. Are > you saying that I have to use two context transfers, one with > IAPP and one with > an IP CT protocol, in order to be able to get Radius context > between the > devices? > > jak > > ------_=_NextPart_001_01C24213.B12D323A Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

James:

  Well, the short answer is no, as the requirements still say
that CT can convey L2 context, as long as it does not require
CT to do anything special.

  Curiously, the concern, at least on my part, was with the idea
that IAPP would be considered part of the suite of feature context
transport protocols used for a context transfer.

  Your comment below expressing a concern about "two context
transfers", would seem to contradict the requirement text
you proposed that implied that each feature context would
specify its own transport protocol.

  I am looking for CT to be light weight, relatively fast and
relatively reliable, including the transport. By relatively fast
I mean that it must enhance mobility, otherwise it's not worth
doing. By relatively reliable, I mean it had better work most
of the time, but I really do not need five nine's of reliability
- that handovers fail occasionally is a reality with wireless.
I cannot be more specific without talking numbers.

  And so, from your comments below, I take it that you also would
prefer one CT exchange, implying one transport protocol? If so,
would you be willing to modify your proposed text at least to
indicate that this is the preferred objective for CT?

Cheers,
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: August 9, 2002 17:43
> To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH];
> john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
>
> > Agreed to some extent. To be precise: context has to be
> present at layer 2
> devices.
> >
> > by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP
> itself is below IP
> on the stack.
> > CT on the other hand as of today is AR-AR.
> >
>
> So suppose I'm developing a 802.11 AP that also contains AR
> functionality. Are
> you saying that I have to use two context transfers, one with
> IAPP and one with
> an IP CT protocol, in order to be able to get Radius context
> between the
> devices?
>
>             jak
>
>

------_=_NextPart_001_01C24213.B12D323A-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 12 11:59: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 LAA27406 for ; Mon, 12 Aug 2002 11:59:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18944; Mon, 12 Aug 2002 11:55:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18913 for ; Mon, 12 Aug 2002 11:55:02 -0400 (EDT) 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 LAA27174 for ; Mon, 12 Aug 2002 11:53:45 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA09923; Mon, 12 Aug 2002 08:54:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7CFsTj23293; Mon, 12 Aug 2002 08:54:29 -0700 X-mProtect: <200208121554> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddWomGa; Mon, 12 Aug 2002 08:54:26 PDT Message-ID: <3D57DA2F.4DC3CA6C@iprg.nokia.com> Date: Mon, 12 Aug 2002 08:54:23 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <9FBD322B7824D511B36900508BF93C9C01AA4C8B@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, It seems to me that we're finally getting to the heart of the discussion... Gary Kenward wrote: > > > I'm happy to model context as data, not option fields. > > However, it could be (e.g., in the case of QoS) that the > > context affects the fields of various protocols. In fact, > > taken abstractly, all the cases I care about can be modeled > > as affecting some fields of some protocol's data fields. > > This is even true for buffering, and security contexts, right? > ............ > The options of a transport protocol may be changed to select > particular > transport characteristics. This completely different from encoding the > > context into the transport options. I am fine with your interpretation. > I do not really believe that there is much to be gained in creating > yet > another transport protocol. My point is that if you are going to > transfer > come of the context with TCP, for example, then you might as well > transfer > all of the context with TCP. But this either implies that one keeps TCP sessions open with "neighboring" access routers (as you mention later), or that one accepts more latency. This "nearly" places a dependency on the future "access router discovery" protocol, which I think would be a serious mistake. Otherwise, no contexts could be transferred in less time than it takes to start up TCP, which would also be a mistake, it seems to me. > We had a discussion, way back, about whether all the context can fit > into > one IP packet. Since the context was, and is still pretty much > undefined, > we could not reach a definitive solution. However, there doesn't seem > to > be any compelling reason to believe that context will typically exceed > even > 1500 bytes. Regardless, even if the context data does exceed the > capacity of > a single IP frame, we are not talking about megabytes of data. The > benefit > of splitting the context between different transport protocols just > does not > out weigh the detriments. The problem isn't MTU, it's startup latency for TCP, which could get into quite a few milliseconds. All of this detracts from the overall delay budget for real-time applications which can have quite stringent bounds. The more we push those bounds out towards longer delays, the fewer applications will experience "smooth" handovers. Even if TCP can handle voice handovers in some restricted domains, are you confident it can handle future voice/video synchronized streams? > At this point, may I suggest that we clarify the requirements to > remove the > implication that each feature context must have a separate transport > protocol. > I think that each feature context analysis should outline the ideal > and > adequate transport requirements, and choice of one or more then one > transport > should be left to the network designer. The actual requirement for some contexts is low latency, not separate transports. The other actual requirement (for other contexts) is reliability (again, not separate transports). I do not have confidence that TCP can meet _both_ requirements. > Not sure how you segued into distributed processing. I think the idea > that CT is a container protocol has been discussed in the wg for some > time now (ok, perhaps "containerizing" is a poor choice of words). > Basically, what I believe has been discussed are encapsulated chunks > of feature context (the context is "containerized") that are ferried > about by a transport protocol. Protocols "are" for "distributed processing", considered abstractly. However, I am happy with your characterization. > Well, two geese is still a gaggle, as far as I know. Nonetheless, > what's > the criteria/requirement that prevents each feature context from > having > it's own transport protocol? None that I know of?! > > > > ............ Now, instead of one context > > transfer, you have > > > at least one for each transport protocol used (assuming > > feature CTs that use > > > the same transport can be multiplexed onto one frame). This > > exacerbates many > > > issues such as transfer delay, ordering, updates > > synchronization, etc. > > > > I can see a simple solution for this: > > > > 1. Find the most urgent context. Encapsulate it using the transport > > > it specifies (which won't be TCP, I reckon, for extremely urgent > > contexts). Fill the rest of the context feature data structure > > Why not? I agree if the intent were to set up a TCP connection every > time you wanted to perform CT, but at least for networks where the > ARs are wired together, a single TCP connection between two ARs can be > > established and kept open, can it not, to handle all CTs. Are you really willing to make the restriction that [seamoby] only deals with such networks that satisfy this criterion? > > with the most urgent other contexts that will fit, and which are > > compatible with the chosen transport. If the chosen transport > > is not a reliable transport, schedule a retransmission if any > > context transfer requires acknowledgement. > > I seem to sense a proposal here to layer an ACK/retransmission > protocol > on top of ICMP. Seems like you are really back to creating XCTCP, but > with the (possible erroneous) assumption that ICMP is an appropriate > starting point. I'm not so particular as that. > > 2. If there are any contexts left, goto (1). > > > > timeout(retransmission_timer) { > > retransmit the packet; > > if (not-enough-retries-yet) { > > schedule_another_retransmission(); > > } > > } > > Curious. Are you suggesting one exchange per feature context (i.e. > with each feature context to be transferred you initiate a new > transport > exchange, which requires one or more IP packets)? If so, I would say > that you have already lost the battle to enhance seamlessness. No, the text of my pseudo-program indicates probably one packet per transport _type_, not one packet per _context_. So, if there are no contexts that require reliability, only one UDP or ICMP packet would typically be required. > Why not simply put all feature contexts into one transport exchange? > Which hopefully means, one IP packet. That's what my "program" does! Please have another look. > BTW: if the goal here is to merge CT with the HI/HACK mechanism for > MobileIP, then the intent is misguided. CT is supposed to work in > scenarios where MobileIP is not present. Certainly requiring the > network to implement HI/HACK simply to allow part of the CT to occur > is wrong. This is in no way the intention of what I wrote. However, I also believe that any reasonable solution SHOULD work with fast handovers. Otherwise, what's the point? Even so, there may be other protocols that achieve similar goals, and in those cases the CT design should still work fine. > See comments. I am beginning to believe that this debate is more > around > trying to incorporate HI/HACK into CT then it is about what transport > protocol CT needs. Please tell me why am mistaken. I hope by now it is obvious! Nothing I said should be interpreted to draw that conclusion. Do you see now? Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 11:59: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 LAA27420 for ; Mon, 12 Aug 2002 11:59:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19781 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 12:00:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18944; Mon, 12 Aug 2002 11:55:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18913 for ; Mon, 12 Aug 2002 11:55:02 -0400 (EDT) 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 LAA27174 for ; Mon, 12 Aug 2002 11:53:45 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA09923; Mon, 12 Aug 2002 08:54:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7CFsTj23293; Mon, 12 Aug 2002 08:54:29 -0700 X-mProtect: <200208121554> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddWomGa; Mon, 12 Aug 2002 08:54:26 PDT Message-ID: <3D57DA2F.4DC3CA6C@iprg.nokia.com> Date: Mon, 12 Aug 2002 08:54:23 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <9FBD322B7824D511B36900508BF93C9C01AA4C8B@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, It seems to me that we're finally getting to the heart of the discussion... Gary Kenward wrote: > > > I'm happy to model context as data, not option fields. > > However, it could be (e.g., in the case of QoS) that the > > context affects the fields of various protocols. In fact, > > taken abstractly, all the cases I care about can be modeled > > as affecting some fields of some protocol's data fields. > > This is even true for buffering, and security contexts, right? > ............ > The options of a transport protocol may be changed to select > particular > transport characteristics. This completely different from encoding the > > context into the transport options. I am fine with your interpretation. > I do not really believe that there is much to be gained in creating > yet > another transport protocol. My point is that if you are going to > transfer > come of the context with TCP, for example, then you might as well > transfer > all of the context with TCP. But this either implies that one keeps TCP sessions open with "neighboring" access routers (as you mention later), or that one accepts more latency. This "nearly" places a dependency on the future "access router discovery" protocol, which I think would be a serious mistake. Otherwise, no contexts could be transferred in less time than it takes to start up TCP, which would also be a mistake, it seems to me. > We had a discussion, way back, about whether all the context can fit > into > one IP packet. Since the context was, and is still pretty much > undefined, > we could not reach a definitive solution. However, there doesn't seem > to > be any compelling reason to believe that context will typically exceed > even > 1500 bytes. Regardless, even if the context data does exceed the > capacity of > a single IP frame, we are not talking about megabytes of data. The > benefit > of splitting the context between different transport protocols just > does not > out weigh the detriments. The problem isn't MTU, it's startup latency for TCP, which could get into quite a few milliseconds. All of this detracts from the overall delay budget for real-time applications which can have quite stringent bounds. The more we push those bounds out towards longer delays, the fewer applications will experience "smooth" handovers. Even if TCP can handle voice handovers in some restricted domains, are you confident it can handle future voice/video synchronized streams? > At this point, may I suggest that we clarify the requirements to > remove the > implication that each feature context must have a separate transport > protocol. > I think that each feature context analysis should outline the ideal > and > adequate transport requirements, and choice of one or more then one > transport > should be left to the network designer. The actual requirement for some contexts is low latency, not separate transports. The other actual requirement (for other contexts) is reliability (again, not separate transports). I do not have confidence that TCP can meet _both_ requirements. > Not sure how you segued into distributed processing. I think the idea > that CT is a container protocol has been discussed in the wg for some > time now (ok, perhaps "containerizing" is a poor choice of words). > Basically, what I believe has been discussed are encapsulated chunks > of feature context (the context is "containerized") that are ferried > about by a transport protocol. Protocols "are" for "distributed processing", considered abstractly. However, I am happy with your characterization. > Well, two geese is still a gaggle, as far as I know. Nonetheless, > what's > the criteria/requirement that prevents each feature context from > having > it's own transport protocol? None that I know of?! > > > > ............ Now, instead of one context > > transfer, you have > > > at least one for each transport protocol used (assuming > > feature CTs that use > > > the same transport can be multiplexed onto one frame). This > > exacerbates many > > > issues such as transfer delay, ordering, updates > > synchronization, etc. > > > > I can see a simple solution for this: > > > > 1. Find the most urgent context. Encapsulate it using the transport > > > it specifies (which won't be TCP, I reckon, for extremely urgent > > contexts). Fill the rest of the context feature data structure > > Why not? I agree if the intent were to set up a TCP connection every > time you wanted to perform CT, but at least for networks where the > ARs are wired together, a single TCP connection between two ARs can be > > established and kept open, can it not, to handle all CTs. Are you really willing to make the restriction that [seamoby] only deals with such networks that satisfy this criterion? > > with the most urgent other contexts that will fit, and which are > > compatible with the chosen transport. If the chosen transport > > is not a reliable transport, schedule a retransmission if any > > context transfer requires acknowledgement. > > I seem to sense a proposal here to layer an ACK/retransmission > protocol > on top of ICMP. Seems like you are really back to creating XCTCP, but > with the (possible erroneous) assumption that ICMP is an appropriate > starting point. I'm not so particular as that. > > 2. If there are any contexts left, goto (1). > > > > timeout(retransmission_timer) { > > retransmit the packet; > > if (not-enough-retries-yet) { > > schedule_another_retransmission(); > > } > > } > > Curious. Are you suggesting one exchange per feature context (i.e. > with each feature context to be transferred you initiate a new > transport > exchange, which requires one or more IP packets)? If so, I would say > that you have already lost the battle to enhance seamlessness. No, the text of my pseudo-program indicates probably one packet per transport _type_, not one packet per _context_. So, if there are no contexts that require reliability, only one UDP or ICMP packet would typically be required. > Why not simply put all feature contexts into one transport exchange? > Which hopefully means, one IP packet. That's what my "program" does! Please have another look. > BTW: if the goal here is to merge CT with the HI/HACK mechanism for > MobileIP, then the intent is misguided. CT is supposed to work in > scenarios where MobileIP is not present. Certainly requiring the > network to implement HI/HACK simply to allow part of the CT to occur > is wrong. This is in no way the intention of what I wrote. However, I also believe that any reasonable solution SHOULD work with fast handovers. Otherwise, what's the point? Even so, there may be other protocols that achieve similar goals, and in those cases the CT design should still work fine. > See comments. I am beginning to believe that this debate is more > around > trying to incorporate HI/HACK into CT then it is about what transport > protocol CT needs. Please tell me why am mistaken. I hope by now it is obvious! Nothing I said should be interpreted to draw that conclusion. Do you see now? Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 12 12:18: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 MAA28389 for ; Mon, 12 Aug 2002 12:18:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20933; Mon, 12 Aug 2002 12:17:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20902 for ; Mon, 12 Aug 2002 12:17:29 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28312 for ; Mon, 12 Aug 2002 12:16:12 -0400 (EDT) Message-ID: <009401c2421b$7748b8c0$296015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , , References: <9FBD322B7824D511B36900508BF93C9C01AA4C8C@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Mon, 12 Aug 2002 09:15:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > Well, the short answer is no, as the requirements still say > that CT can convey L2 context, as long as it does not require > CT to do anything special. > Can you explain to me why you believe that RADIUS is an L2 protocol? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 12:18: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 MAA28397 for ; Mon, 12 Aug 2002 12:18:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21008 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 12:19:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20933; Mon, 12 Aug 2002 12:17:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20902 for ; Mon, 12 Aug 2002 12:17:29 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28312 for ; Mon, 12 Aug 2002 12:16:12 -0400 (EDT) Message-ID: <009401c2421b$7748b8c0$296015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , , References: <9FBD322B7824D511B36900508BF93C9C01AA4C8C@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Mon, 12 Aug 2002 09:15:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > Well, the short answer is no, as the requirements still say > that CT can convey L2 context, as long as it does not require > CT to do anything special. > Can you explain to me why you believe that RADIUS is an L2 protocol? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 12 12:35: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 MAA28955 for ; Mon, 12 Aug 2002 12:35:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21449; Mon, 12 Aug 2002 12:29:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21422 for ; Mon, 12 Aug 2002 12:29:18 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28710 for ; Mon, 12 Aug 2002 12:28:02 -0400 (EDT) Message-ID: <009501c2421d$2f3b85b0$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 12 Aug 2002 09:27:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Proceeding Forward on Tightening Requirements Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Folks, We have been arguing about the requirements for CT for about a year and a half now. It is time to draw the latest round to a close. We are way overdue to get this done so we can start on the *real* work of designing the protocol. It's time to set aside "visions" and philosophy and get back to the practical task at hand: tightening the requirements up so the IESG will approve them. In the next day, I'm going to send out a collection of emails which will contain a summary of the proposals from the list to tighten the requirements. Each email will have the following format: 1) A Subject line like this "Issue 1: " 3) A description of changes that have been proposed on this topic to tighten the requirements. The changes are intended to be mutually exclusive. 2) A request to indicate whether you: a) APPROVE b) DISAPPROVE each of the changes. You will be requested to indicate approval for only one of the changes, since they are intended to be mutually exclusive. You are also requested not to start long discussion threads around these Subjects, but to simply indicate your preference. If you would like to start a discussion thread, then please change the Subject (for example: Discussion on Issue 1). We will run the comment period for a week, until next Tues. At that point, Pat and I will take a look at the comments and judge concensus. We will report the concensus to Gary and to the list. As WG draft editor, Gary then will put the concensus text into the document. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 12:35: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 MAA28963 for ; Mon, 12 Aug 2002 12:35:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22509 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 12:36:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21449; Mon, 12 Aug 2002 12:29:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21422 for ; Mon, 12 Aug 2002 12:29:18 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28710 for ; Mon, 12 Aug 2002 12:28:02 -0400 (EDT) Message-ID: <009501c2421d$2f3b85b0$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 12 Aug 2002 09:27:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Proceeding Forward on Tightening Requirements Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Folks, We have been arguing about the requirements for CT for about a year and a half now. It is time to draw the latest round to a close. We are way overdue to get this done so we can start on the *real* work of designing the protocol. It's time to set aside "visions" and philosophy and get back to the practical task at hand: tightening the requirements up so the IESG will approve them. In the next day, I'm going to send out a collection of emails which will contain a summary of the proposals from the list to tighten the requirements. Each email will have the following format: 1) A Subject line like this "Issue 1: " 3) A description of changes that have been proposed on this topic to tighten the requirements. The changes are intended to be mutually exclusive. 2) A request to indicate whether you: a) APPROVE b) DISAPPROVE each of the changes. You will be requested to indicate approval for only one of the changes, since they are intended to be mutually exclusive. You are also requested not to start long discussion threads around these Subjects, but to simply indicate your preference. If you would like to start a discussion thread, then please change the Subject (for example: Discussion on Issue 1). We will run the comment period for a week, until next Tues. At that point, Pat and I will take a look at the comments and judge concensus. We will report the concensus to Gary and to the list. As WG draft editor, Gary then will put the concensus text into the document. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 12 12:59: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 MAA29959 for ; Mon, 12 Aug 2002 12:59:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23519; Mon, 12 Aug 2002 12:57:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23484 for ; Mon, 12 Aug 2002 12:57:31 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29788 for ; Mon, 12 Aug 2002 12:56:13 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7CGun512431; Mon, 12 Aug 2002 12:56:49 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 12:56:50 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C8F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Mon, 12 Aug 2002 12:56:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24220.FC22D7A6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24220.FC22D7A6 Content-Type: text/plain; charset="iso-8859-1" As I said in a previous email, RADIUS is not an L2 protocol. But AP's are L2 devices, and RADIUS is being used to set up an L2 environment, hence the context is L2. Let's drop this thread. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: August 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; > john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Gary, > > > Well, the short answer is no, as the requirements still say > > that CT can convey L2 context, as long as it does not require > > CT to do anything special. > > > > Can you explain to me why you believe that RADIUS is an L2 protocol? > > jak > > > > ------_=_NextPart_001_01C24220.FC22D7A6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

As I said in a previous email, RADIUS is not an L2 protocol.
But AP's are L2 devices, and RADIUS is being used to set up
an L2 environment, hence the context is L2.


Let's drop this thread.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: August 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1;
> john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Gary,
>
>  >   Well, the short answer is no, as the requirements still say
> > that CT can convey L2 context, as long as it does not require
> > CT to do anything special.
> >
>
> Can you explain to me why you believe that RADIUS is an L2 protocol?
>
>             jak
>
>
>
>

------_=_NextPart_001_01C24220.FC22D7A6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 12:59: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 MAA29966 for ; Mon, 12 Aug 2002 12:59:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24025 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 13:00:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23519; Mon, 12 Aug 2002 12:57:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23484 for ; Mon, 12 Aug 2002 12:57:31 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29788 for ; Mon, 12 Aug 2002 12:56:13 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7CGun512431; Mon, 12 Aug 2002 12:56:49 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 12:56:50 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C8F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Mon, 12 Aug 2002 12:56:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24220.FC22D7A6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24220.FC22D7A6 Content-Type: text/plain; charset="iso-8859-1" As I said in a previous email, RADIUS is not an L2 protocol. But AP's are L2 devices, and RADIUS is being used to set up an L2 environment, hence the context is L2. Let's drop this thread. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: August 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; > john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Gary, > > > Well, the short answer is no, as the requirements still say > > that CT can convey L2 context, as long as it does not require > > CT to do anything special. > > > > Can you explain to me why you believe that RADIUS is an L2 protocol? > > jak > > > > ------_=_NextPart_001_01C24220.FC22D7A6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

As I said in a previous email, RADIUS is not an L2 protocol.
But AP's are L2 devices, and RADIUS is being used to set up
an L2 environment, hence the context is L2.


Let's drop this thread.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: August 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1;
> john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Gary,
>
>  >   Well, the short answer is no, as the requirements still say
> > that CT can convey L2 context, as long as it does not require
> > CT to do anything special.
> >
>
> Can you explain to me why you believe that RADIUS is an L2 protocol?
>
>             jak
>
>
>
>

------_=_NextPart_001_01C24220.FC22D7A6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 12 14:28: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 OAA04716 for ; Mon, 12 Aug 2002 14:28:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00338; Mon, 12 Aug 2002 14:23:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00303 for ; Mon, 12 Aug 2002 14:23:15 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04454 for ; Mon, 12 Aug 2002 14:21:57 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7CIIl528703; Mon, 12 Aug 2002 14:18:47 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 14:18:47 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C96@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Mon, 12 Aug 2002 14:18:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2422C.B0346C18" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C2422C.B0346C18 Content-Type: text/plain; charset="iso-8859-1" Hello again Charlie: > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: August 12, 2002 11:54 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > It seems to me that we're finally getting to the heart > of the discussion... > > Gary Kenward wrote: > *snip* > > > I do not really believe that there is much to be gained in creating > > yet > > another transport protocol. My point is that if you are going to > > transfer > > come of the context with TCP, for example, then you might as well > > transfer > > all of the context with TCP. > > But this either implies that one keeps TCP sessions open > with "neighbouring" access routers (as you mention later), > or that one accepts more latency. This "nearly" places a > dependency on the future "access router discovery" > protocol, which I think would be a serious mistake. > Otherwise, no contexts could be transferred in less > time than it takes to start up TCP, which would also > be a mistake, it seems to me. I agree. TCP has limitations for short bursts of traffic such as CT. *Except* for the cases of an ad-hoc network, or a network with mobile routers, I do not see any reason why a TCP connection cannot be simply opened and kept open. I have never understood the rationale for "discovering" a new wireless network and then requesting a handover and thus a transfer. I have outlined my reasons in other emails, so I won't get into it here. > *snip* > The problem isn't MTU, it's startup latency for TCP, which > could get into quite a few milliseconds. All of this detracts > from the overall delay budget for real-time applications > which can have quite stringent bounds. The more we push > those bounds out towards longer delays, the fewer applications > will experience "smooth" handovers. Even if TCP can handle > voice handovers in some restricted domains, are you confident > it can handle future voice/video synchronized streams? See above. Any overhead introduced during a handover takes us away from seamlessness. And so, following your logic, I question the rational with doing CARD => CT => handover with a video stream. > > > > At this point, may I suggest that we clarify the requirements to > > remove the > > implication that each feature context must have a separate transport > > protocol. > > I think that each feature context analysis should outline the ideal > > and > > adequate transport requirements, and choice of one or more then one > > transport > > should be left to the network designer. > > The actual requirement for some contexts is low latency, not > separate transports. The other actual requirement (for other > contexts) is reliability (again, not separate transports). I do not > have confidence that TCP can meet _both_ requirements. You are presuming here that the handover can proceed without the second context. Otherwise, the TCP based CT still has to complete before the handover can be completed (e.g. the packets can be forwarded at the new AR with the same services and service characteristics). And, if the "fast CT" completes before the "reliable CT", how does the target AR incorporate the late context, given that, by definition, the "fast CT" is being used to forward packets (if it is not being used, then it clearly didn't need to be at the destination AR so quickly). I have a feeling, a strong feeling that this is all moot. I do not know of any context that can be transferred unreliably - that is, there has to be a reasonable assurance that CT will succeed in order for it to "enhance" handover. If a CT fails as a consequence of an unrealizable transport being used, what is the result? By reasonable assurance, I go back to what I stated in reply to James: handovers will fail. However, handovers failures due to CT failures must not be relatively insignificant (e.g. <<1%). > *snip* > > > > Why not? I agree if the intent were to set up a TCP connection every > > time you wanted to perform CT, but at least for networks where the > > ARs are wired together, a single TCP connection between two > ARs can be > > > > established and kept open, can it not, to handle all CTs. > > Are you really willing to make the restriction that [seamoby] > only deals with such networks that satisfy this criterion? It would be preferable if we had a protocol that was both fast and reliable - e.g. one that optimized for very short bursts of data. However, we (seamoby) are not going to be defining that protocol, as far as I can tell. I'm still waiting for a practical description of a wired network or group of wired networks where this "restriction" is impractical. For a handover to occur seamlessly between two networks, many, many facilities have to be pre-established. It would seem to me that requiring a tunnel for CT between the two is a very small additional requirement. > > > > with the most urgent other contexts that will fit, and > which are > > > compatible with the chosen transport. If the chosen transport > > > is not a reliable transport, schedule a retransmission if any > > > context transfer requires acknowledgement. > > > > I seem to sense a proposal here to layer an ACK/retransmission > > protocol > > on top of ICMP. Seems like you are really back to creating > XCTCP, but > > with the (possible erroneous) assumption that ICMP is an appropriate > > starting point. > > I'm not so particular as that. Regardless, the idea of defining an ack/retx capability on top of UDP/ICMP is still transport protocol design. Arguably, TCP is simply UDP with ack/retx and window flow control (and a pile of other stuff designed to make it all work in various situations). > *snip again* > > Why not simply put all feature contexts into one transport exchange? > > Which hopefully means, one IP packet. > > That's what my "program" does! Please have another look. No it doesn't. It puts each context into it's own transport protocol. That's not, in my view, one transport exchange (each protocol sets up it's own exchange), and not one IP packet, in anyone's view. > > > BTW: if the goal here is to merge CT with the HI/HACK mechanism for > > MobileIP, then the intent is misguided. CT is supposed to work in > > scenarios where MobileIP is not present. Certainly requiring the > > network to implement HI/HACK simply to allow part of the CT to occur > > is wrong. > > This is in no way the intention of what I wrote. However, Good to know. But then, I am confused over the relevance of HI/HAck to the discussion. > I also believe that any reasonable solution SHOULD work > with fast handovers. Otherwise, what's the point? Even so, The critical phrase here is "work with" - CT MUST work with MobileIP (it's in the charter I believe). However, how it works is another issue. > there may be other protocols that achieve similar goals, and > in those cases the CT design should still work fine. > > > See comments. I am beginning to believe that this debate is more > > around > > trying to incorporate HI/HACK into CT then it is about what > transport > > protocol CT needs. Please tell me why am mistaken. > > I hope by now it is obvious! Nothing I said should be > interpreted to draw that conclusion. Do you see now? I guess I shall remain confused. You introduced HI/HAck as a mechanism for CT. I don't see the relevance. If the *only* context I have to transfer fits into HI/HAck and HI/HAck provides the necessary transport characteristics, then yes, it would be nice if CT could run over Hi/HAck. Does this mean that CT should be tailored so that it runs over Hi/HAck? I guess it should be shown that tailoring CT for this purpose is significantly superior then running CT in parallel (or before, as with in "proactively"). I have no idea how to proceed from here. John L. is right, we are back in the same rat-hole we were in more then a year ago. There is little agreement as to what the transport service requirements are, whether they are feature context specific, mutually exclusive, available in existing protocols, etc., etc., etc. Those that do not pay attention to history, are doomed to repeat it. Perhaps John can come up with a set of requirements for transport. How this can be done without going through the requirements for each feature context will be a challenge, for the debate always returns to the (perceived) differences in transport service requirements, and the (perceived) exclusiveness of those differences. Onwards and downwards, Gary > > Regards, > Charlie P. > > > ------_=_NextPart_001_01C2422C.B0346C18 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

Hello again Charlie:

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 12, 2002 11:54
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> It seems to me that we're finally getting to the heart
> of the discussion...
>
> Gary Kenward wrote:
>

*snip*

>
> > I do not really believe that there is much to be gained in creating
> > yet
> > another transport protocol. My point is that if you are going to
> > transfer
> > come of the context with TCP, for example, then you might as well
> > transfer
> > all of the context with TCP.
>
> But this either implies that one keeps TCP sessions open
> with "neighbouring" access routers (as you mention later),
> or that one accepts more latency.  This "nearly" places a
> dependency on the future "access router discovery"
> protocol, which I think would be a serious mistake.
> Otherwise, no contexts could be transferred in less
> time than it takes to start up TCP, which would also
> be a mistake, it seems to me.

I agree. TCP has limitations for short bursts of traffic such as CT.
*Except* for the cases of an ad-hoc network, or a network with mobile
routers, I do not see any reason why a TCP connection cannot be simply
opened and kept open.

I have never understood the rationale for "discovering" a new wireless
network and then requesting a handover and thus a transfer. I have outlined
my reasons in other emails, so I won't get into it here.

>

*snip*

> The problem isn't MTU, it's startup latency for TCP, which
> could get into quite a few milliseconds.  All of this detracts
> from the overall delay budget for real-time applications
> which can have quite stringent bounds.  The more we push
> those bounds out towards longer delays, the fewer applications
> will experience "smooth" handovers.  Even if TCP can handle
> voice handovers in some restricted domains, are you confident
> it can handle future voice/video synchronized streams?

See above. Any overhead introduced during a handover takes us away
from seamlessness.

And so, following your logic, I question the rational with doing CARD =>
CT => handover with a video stream.

>
>
> > At this point, may I suggest that we clarify the requirements to
> > remove the
> > implication that each feature context must have a separate transport
> > protocol.
> > I think that each feature context analysis should outline the ideal
> > and
> > adequate transport requirements, and choice of one or more then one
> > transport
> > should be left to the network designer.
>
> The actual requirement for some contexts is low latency, not
> separate transports.  The other actual requirement (for other
> contexts) is reliability (again, not separate transports).  I do not
> have confidence that TCP can meet _both_ requirements.

You are presuming here that the handover can proceed without the
second context. Otherwise, the TCP based CT still has to complete before
the handover can be completed (e.g. the packets can be forwarded at
the new AR with the same services and service characteristics). And,
if the "fast CT" completes before the "reliable CT", how does the
target AR incorporate the late context, given that, by definition,
the "fast CT" is being used to forward packets (if it is not
being used, then it clearly didn't need to be at the destination AR
so quickly).

I have a feeling, a strong feeling that this is all moot. I do not
know of any context that can be transferred unreliably - that is,
there has to be a reasonable assurance that CT will succeed in order
for it to "enhance" handover. If a CT fails as a consequence of an
unrealizable transport being used, what is the result?

By reasonable assurance, I go back to what I stated in reply to James:
handovers will fail. However, handovers failures due to CT failures
must not be relatively insignificant (e.g. <<1%).

>

*snip*

> >
> > Why not? I agree if the intent were to set up a TCP connection every
> > time you wanted to perform CT, but at least for networks where the
> > ARs are wired together, a single TCP connection between two
> ARs can be
> >
> > established and kept open, can it not, to handle all CTs.
>
> Are you really willing to make the restriction that [seamoby]
> only deals with such networks that satisfy this criterion?

It would be preferable if we had a protocol that was both fast
and reliable - e.g. one that optimized for very short bursts of
data. However, we (seamoby) are not going to be defining that protocol,
as far as I can tell.

I'm still waiting for a practical description of a wired network or group
of wired networks where this "restriction" is impractical. For a handover
to occur seamlessly between two networks, many, many facilities have to
be pre-established. It would seem to me that requiring a tunnel for CT
between the two is a very small additional requirement.

>
> > >    with the most urgent other contexts that will fit, and
> which are
> > >    compatible with the chosen transport.  If the chosen transport
> > >    is not a reliable transport, schedule a retransmission if any
> > >    context transfer requires acknowledgement.
> >
> > I seem to sense a proposal here to layer an ACK/retransmission
> > protocol
> > on top of ICMP. Seems like you are really back to creating
> XCTCP, but
> > with the (possible erroneous) assumption that ICMP is an appropriate
> > starting point.
>
> I'm not so particular as that.

Regardless, the idea of defining an ack/retx capability on top of UDP/ICMP
is still transport protocol design. Arguably, TCP is simply UDP with ack/retx
and window flow control (and a pile of other stuff designed to make it all
work in various situations).

>
*snip again*

> > Why not simply put all feature contexts into one transport exchange?
> > Which hopefully means, one IP packet.
>
> That's what my "program" does!  Please have another look.

No it doesn't. It puts each context into it's own transport protocol. That's
not, in my view, one transport exchange (each protocol sets up it's own
exchange), and not one IP packet, in anyone's view.
>
> > BTW: if the goal here is to merge CT with the HI/HACK mechanism for
> > MobileIP, then the intent is misguided. CT is supposed to work in
> > scenarios where MobileIP is not present. Certainly requiring the
> > network to implement HI/HACK simply to allow part of the CT to occur
> > is wrong.
>
> This is in no way the intention of what I wrote.  However,

Good to know. But then, I am confused over the relevance of HI/HAck to
the discussion.

> I also believe that any reasonable solution SHOULD work
> with fast handovers.  Otherwise, what's the point?  Even so,

The critical phrase here is "work with" - CT MUST work with
MobileIP (it's in the charter I believe). However, how it works
is another issue.

> there may be other protocols that achieve similar goals, and
> in those cases the CT design should still work fine.
>
> > See comments. I am beginning to believe that this debate is more
> > around
> > trying to incorporate HI/HACK into CT then it is about what
> transport
> > protocol CT needs. Please tell me why am mistaken.
>
> I hope by now it is obvious!  Nothing I said should be
> interpreted to draw that conclusion.  Do you see now?

I guess I shall remain confused. You introduced HI/HAck as a mechanism
for CT. I don't see the relevance. If the *only* context I have to
transfer fits into HI/HAck and HI/HAck provides the necessary transport
characteristics, then yes, it would be nice if CT could run over Hi/HAck.
Does this mean that CT should be tailored so that it runs over Hi/HAck?
I guess it should be shown that tailoring CT for this purpose is significantly
superior then running CT in parallel (or before, as with in "proactively").

I have no idea how to proceed from here.

John L. is right, we are back in the same rat-hole we were in more then a year
ago. There is little agreement as to what the transport service requirements are,
whether they are feature context specific, mutually exclusive, available in existing
protocols, etc., etc., etc. Those that do not pay attention to history, are doomed
to repeat it.

Perhaps John can come up with a set of requirements for transport. How this can be
done without going through the requirements for each feature context will be a
challenge, for the debate always returns to the (perceived) differences in transport
service requirements, and the (perceived) exclusiveness of those differences.

Onwards and downwards,
Gary

>
> Regards,
> Charlie P.
>
>
>

------_=_NextPart_001_01C2422C.B0346C18-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 14:28: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 OAA04724 for ; Mon, 12 Aug 2002 14:28:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00573 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 14:29:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00338; Mon, 12 Aug 2002 14:23:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00303 for ; Mon, 12 Aug 2002 14:23:15 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04454 for ; Mon, 12 Aug 2002 14:21:57 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7CIIl528703; Mon, 12 Aug 2002 14:18:47 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 14:18:47 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C96@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Mon, 12 Aug 2002 14:18:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2422C.B0346C18" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C2422C.B0346C18 Content-Type: text/plain; charset="iso-8859-1" Hello again Charlie: > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: August 12, 2002 11:54 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > It seems to me that we're finally getting to the heart > of the discussion... > > Gary Kenward wrote: > *snip* > > > I do not really believe that there is much to be gained in creating > > yet > > another transport protocol. My point is that if you are going to > > transfer > > come of the context with TCP, for example, then you might as well > > transfer > > all of the context with TCP. > > But this either implies that one keeps TCP sessions open > with "neighbouring" access routers (as you mention later), > or that one accepts more latency. This "nearly" places a > dependency on the future "access router discovery" > protocol, which I think would be a serious mistake. > Otherwise, no contexts could be transferred in less > time than it takes to start up TCP, which would also > be a mistake, it seems to me. I agree. TCP has limitations for short bursts of traffic such as CT. *Except* for the cases of an ad-hoc network, or a network with mobile routers, I do not see any reason why a TCP connection cannot be simply opened and kept open. I have never understood the rationale for "discovering" a new wireless network and then requesting a handover and thus a transfer. I have outlined my reasons in other emails, so I won't get into it here. > *snip* > The problem isn't MTU, it's startup latency for TCP, which > could get into quite a few milliseconds. All of this detracts > from the overall delay budget for real-time applications > which can have quite stringent bounds. The more we push > those bounds out towards longer delays, the fewer applications > will experience "smooth" handovers. Even if TCP can handle > voice handovers in some restricted domains, are you confident > it can handle future voice/video synchronized streams? See above. Any overhead introduced during a handover takes us away from seamlessness. And so, following your logic, I question the rational with doing CARD => CT => handover with a video stream. > > > > At this point, may I suggest that we clarify the requirements to > > remove the > > implication that each feature context must have a separate transport > > protocol. > > I think that each feature context analysis should outline the ideal > > and > > adequate transport requirements, and choice of one or more then one > > transport > > should be left to the network designer. > > The actual requirement for some contexts is low latency, not > separate transports. The other actual requirement (for other > contexts) is reliability (again, not separate transports). I do not > have confidence that TCP can meet _both_ requirements. You are presuming here that the handover can proceed without the second context. Otherwise, the TCP based CT still has to complete before the handover can be completed (e.g. the packets can be forwarded at the new AR with the same services and service characteristics). And, if the "fast CT" completes before the "reliable CT", how does the target AR incorporate the late context, given that, by definition, the "fast CT" is being used to forward packets (if it is not being used, then it clearly didn't need to be at the destination AR so quickly). I have a feeling, a strong feeling that this is all moot. I do not know of any context that can be transferred unreliably - that is, there has to be a reasonable assurance that CT will succeed in order for it to "enhance" handover. If a CT fails as a consequence of an unrealizable transport being used, what is the result? By reasonable assurance, I go back to what I stated in reply to James: handovers will fail. However, handovers failures due to CT failures must not be relatively insignificant (e.g. <<1%). > *snip* > > > > Why not? I agree if the intent were to set up a TCP connection every > > time you wanted to perform CT, but at least for networks where the > > ARs are wired together, a single TCP connection between two > ARs can be > > > > established and kept open, can it not, to handle all CTs. > > Are you really willing to make the restriction that [seamoby] > only deals with such networks that satisfy this criterion? It would be preferable if we had a protocol that was both fast and reliable - e.g. one that optimized for very short bursts of data. However, we (seamoby) are not going to be defining that protocol, as far as I can tell. I'm still waiting for a practical description of a wired network or group of wired networks where this "restriction" is impractical. For a handover to occur seamlessly between two networks, many, many facilities have to be pre-established. It would seem to me that requiring a tunnel for CT between the two is a very small additional requirement. > > > > with the most urgent other contexts that will fit, and > which are > > > compatible with the chosen transport. If the chosen transport > > > is not a reliable transport, schedule a retransmission if any > > > context transfer requires acknowledgement. > > > > I seem to sense a proposal here to layer an ACK/retransmission > > protocol > > on top of ICMP. Seems like you are really back to creating > XCTCP, but > > with the (possible erroneous) assumption that ICMP is an appropriate > > starting point. > > I'm not so particular as that. Regardless, the idea of defining an ack/retx capability on top of UDP/ICMP is still transport protocol design. Arguably, TCP is simply UDP with ack/retx and window flow control (and a pile of other stuff designed to make it all work in various situations). > *snip again* > > Why not simply put all feature contexts into one transport exchange? > > Which hopefully means, one IP packet. > > That's what my "program" does! Please have another look. No it doesn't. It puts each context into it's own transport protocol. That's not, in my view, one transport exchange (each protocol sets up it's own exchange), and not one IP packet, in anyone's view. > > > BTW: if the goal here is to merge CT with the HI/HACK mechanism for > > MobileIP, then the intent is misguided. CT is supposed to work in > > scenarios where MobileIP is not present. Certainly requiring the > > network to implement HI/HACK simply to allow part of the CT to occur > > is wrong. > > This is in no way the intention of what I wrote. However, Good to know. But then, I am confused over the relevance of HI/HAck to the discussion. > I also believe that any reasonable solution SHOULD work > with fast handovers. Otherwise, what's the point? Even so, The critical phrase here is "work with" - CT MUST work with MobileIP (it's in the charter I believe). However, how it works is another issue. > there may be other protocols that achieve similar goals, and > in those cases the CT design should still work fine. > > > See comments. I am beginning to believe that this debate is more > > around > > trying to incorporate HI/HACK into CT then it is about what > transport > > protocol CT needs. Please tell me why am mistaken. > > I hope by now it is obvious! Nothing I said should be > interpreted to draw that conclusion. Do you see now? I guess I shall remain confused. You introduced HI/HAck as a mechanism for CT. I don't see the relevance. If the *only* context I have to transfer fits into HI/HAck and HI/HAck provides the necessary transport characteristics, then yes, it would be nice if CT could run over Hi/HAck. Does this mean that CT should be tailored so that it runs over Hi/HAck? I guess it should be shown that tailoring CT for this purpose is significantly superior then running CT in parallel (or before, as with in "proactively"). I have no idea how to proceed from here. John L. is right, we are back in the same rat-hole we were in more then a year ago. There is little agreement as to what the transport service requirements are, whether they are feature context specific, mutually exclusive, available in existing protocols, etc., etc., etc. Those that do not pay attention to history, are doomed to repeat it. Perhaps John can come up with a set of requirements for transport. How this can be done without going through the requirements for each feature context will be a challenge, for the debate always returns to the (perceived) differences in transport service requirements, and the (perceived) exclusiveness of those differences. Onwards and downwards, Gary > > Regards, > Charlie P. > > > ------_=_NextPart_001_01C2422C.B0346C18 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

Hello again Charlie:

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 12, 2002 11:54
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> It seems to me that we're finally getting to the heart
> of the discussion...
>
> Gary Kenward wrote:
>

*snip*

>
> > I do not really believe that there is much to be gained in creating
> > yet
> > another transport protocol. My point is that if you are going to
> > transfer
> > come of the context with TCP, for example, then you might as well
> > transfer
> > all of the context with TCP.
>
> But this either implies that one keeps TCP sessions open
> with "neighbouring" access routers (as you mention later),
> or that one accepts more latency.  This "nearly" places a
> dependency on the future "access router discovery"
> protocol, which I think would be a serious mistake.
> Otherwise, no contexts could be transferred in less
> time than it takes to start up TCP, which would also
> be a mistake, it seems to me.

I agree. TCP has limitations for short bursts of traffic such as CT.
*Except* for the cases of an ad-hoc network, or a network with mobile
routers, I do not see any reason why a TCP connection cannot be simply
opened and kept open.

I have never understood the rationale for "discovering" a new wireless
network and then requesting a handover and thus a transfer. I have outlined
my reasons in other emails, so I won't get into it here.

>

*snip*

> The problem isn't MTU, it's startup latency for TCP, which
> could get into quite a few milliseconds.  All of this detracts
> from the overall delay budget for real-time applications
> which can have quite stringent bounds.  The more we push
> those bounds out towards longer delays, the fewer applications
> will experience "smooth" handovers.  Even if TCP can handle
> voice handovers in some restricted domains, are you confident
> it can handle future voice/video synchronized streams?

See above. Any overhead introduced during a handover takes us away
from seamlessness.

And so, following your logic, I question the rational with doing CARD =>
CT => handover with a video stream.

>
>
> > At this point, may I suggest that we clarify the requirements to
> > remove the
> > implication that each feature context must have a separate transport
> > protocol.
> > I think that each feature context analysis should outline the ideal
> > and
> > adequate transport requirements, and choice of one or more then one
> > transport
> > should be left to the network designer.
>
> The actual requirement for some contexts is low latency, not
> separate transports.  The other actual requirement (for other
> contexts) is reliability (again, not separate transports).  I do not
> have confidence that TCP can meet _both_ requirements.

You are presuming here that the handover can proceed without the
second context. Otherwise, the TCP based CT still has to complete before
the handover can be completed (e.g. the packets can be forwarded at
the new AR with the same services and service characteristics). And,
if the "fast CT" completes before the "reliable CT", how does the
target AR incorporate the late context, given that, by definition,
the "fast CT" is being used to forward packets (if it is not
being used, then it clearly didn't need to be at the destination AR
so quickly).

I have a feeling, a strong feeling that this is all moot. I do not
know of any context that can be transferred unreliably - that is,
there has to be a reasonable assurance that CT will succeed in order
for it to "enhance" handover. If a CT fails as a consequence of an
unrealizable transport being used, what is the result?

By reasonable assurance, I go back to what I stated in reply to James:
handovers will fail. However, handovers failures due to CT failures
must not be relatively insignificant (e.g. <<1%).

>

*snip*

> >
> > Why not? I agree if the intent were to set up a TCP connection every
> > time you wanted to perform CT, but at least for networks where the
> > ARs are wired together, a single TCP connection between two
> ARs can be
> >
> > established and kept open, can it not, to handle all CTs.
>
> Are you really willing to make the restriction that [seamoby]
> only deals with such networks that satisfy this criterion?

It would be preferable if we had a protocol that was both fast
and reliable - e.g. one that optimized for very short bursts of
data. However, we (seamoby) are not going to be defining that protocol,
as far as I can tell.

I'm still waiting for a practical description of a wired network or group
of wired networks where this "restriction" is impractical. For a handover
to occur seamlessly between two networks, many, many facilities have to
be pre-established. It would seem to me that requiring a tunnel for CT
between the two is a very small additional requirement.

>
> > >    with the most urgent other contexts that will fit, and
> which are
> > >    compatible with the chosen transport.  If the chosen transport
> > >    is not a reliable transport, schedule a retransmission if any
> > >    context transfer requires acknowledgement.
> >
> > I seem to sense a proposal here to layer an ACK/retransmission
> > protocol
> > on top of ICMP. Seems like you are really back to creating
> XCTCP, but
> > with the (possible erroneous) assumption that ICMP is an appropriate
> > starting point.
>
> I'm not so particular as that.

Regardless, the idea of defining an ack/retx capability on top of UDP/ICMP
is still transport protocol design. Arguably, TCP is simply UDP with ack/retx
and window flow control (and a pile of other stuff designed to make it all
work in various situations).

>
*snip again*

> > Why not simply put all feature contexts into one transport exchange?
> > Which hopefully means, one IP packet.
>
> That's what my "program" does!  Please have another look.

No it doesn't. It puts each context into it's own transport protocol. That's
not, in my view, one transport exchange (each protocol sets up it's own
exchange), and not one IP packet, in anyone's view.
>
> > BTW: if the goal here is to merge CT with the HI/HACK mechanism for
> > MobileIP, then the intent is misguided. CT is supposed to work in
> > scenarios where MobileIP is not present. Certainly requiring the
> > network to implement HI/HACK simply to allow part of the CT to occur
> > is wrong.
>
> This is in no way the intention of what I wrote.  However,

Good to know. But then, I am confused over the relevance of HI/HAck to
the discussion.

> I also believe that any reasonable solution SHOULD work
> with fast handovers.  Otherwise, what's the point?  Even so,

The critical phrase here is "work with" - CT MUST work with
MobileIP (it's in the charter I believe). However, how it works
is another issue.

> there may be other protocols that achieve similar goals, and
> in those cases the CT design should still work fine.
>
> > See comments. I am beginning to believe that this debate is more
> > around
> > trying to incorporate HI/HACK into CT then it is about what
> transport
> > protocol CT needs. Please tell me why am mistaken.
>
> I hope by now it is obvious!  Nothing I said should be
> interpreted to draw that conclusion.  Do you see now?

I guess I shall remain confused. You introduced HI/HAck as a mechanism
for CT. I don't see the relevance. If the *only* context I have to
transfer fits into HI/HAck and HI/HAck provides the necessary transport
characteristics, then yes, it would be nice if CT could run over Hi/HAck.
Does this mean that CT should be tailored so that it runs over Hi/HAck?
I guess it should be shown that tailoring CT for this purpose is significantly
superior then running CT in parallel (or before, as with in "proactively").

I have no idea how to proceed from here.

John L. is right, we are back in the same rat-hole we were in more then a year
ago. There is little agreement as to what the transport service requirements are,
whether they are feature context specific, mutually exclusive, available in existing
protocols, etc., etc., etc. Those that do not pay attention to history, are doomed
to repeat it.

Perhaps John can come up with a set of requirements for transport. How this can be
done without going through the requirements for each feature context will be a
challenge, for the debate always returns to the (perceived) differences in transport
service requirements, and the (perceived) exclusiveness of those differences.

Onwards and downwards,
Gary

>
> Regards,
> Charlie P.
>
>
>

------_=_NextPart_001_01C2422C.B0346C18-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 19:31: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 TAA14587 for ; Mon, 12 Aug 2002 19:31:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA17306 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 19:32:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16665; Mon, 12 Aug 2002 19:30:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16543 for ; Mon, 12 Aug 2002 19:30:02 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14514 for ; Mon, 12 Aug 2002 19:28:43 -0400 (EDT) Message-ID: <004e01c24257$d43471f0$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 12 Aug 2002 16:21:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit The following are proposals for Section 5.2. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ----------- Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the requirements. ----------- ----------- Proposal 2: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified so that it is independent of the underlying transport. Recognizing that the transport characteristics for context transfer will depend on the particular application, it should be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extension on another protocol, such as handover signaling. ----------- ----------- Proposal 3: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified to utilize a reliable transport protocol as a default, unreliable transport MAY also be optionally allowed. Recognizing that context transfer may be crucial for successful handover, the context transfer protocol must specify operation on a default reliable transport. The context transfer protocol may optionally allow transfer on unreliable transport. 5.2.2 The context transfer protocol MUST run directly on top of a transport protocol. Context transfer within another application layer protocol MUST NOT be allowed. In order to preserve the unity of context transport across all feature applications, context transfer must run directly on top of a transport protocol. Running context transfer as an option on another application layer protocol is prohibited. ----------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 12 19:34: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 TAA14644 for ; Mon, 12 Aug 2002 19:34:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16692; Mon, 12 Aug 2002 19:30:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16544 for ; Mon, 12 Aug 2002 19:30:02 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14515 for ; Mon, 12 Aug 2002 19:28:43 -0400 (EDT) Message-ID: <004f01c24257$d4b64c20$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 12 Aug 2002 16:21:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit The following are proposals for Section 5.5. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ---------- Proposal 1: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. 5.5.4 The base context transfer protocol MUST allow individual feature context specifications to define their own update procedures if required. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the general CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Feature contexts will differ in whether or not they require update. A feature context such as QoS parameters for the service level agreement with a user may not involve dynamically changing information, but it may change during or after context transfer. Such feature contexts may benefit from allowing the context to change after the transfer is completed. Other feature contexts, such as header compression, may be tightly synchronized with external events and changes on the old router need to be discarded since the new router's state may already have been modified. ---------- Proposal 2: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol MUST NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. Since the base context transfer protocol must accommodate a wide range of potential feature contexts, the base protocol design must not contain any specification concerning update and synchronization. --------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 19:34: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 TAA14660 for ; Mon, 12 Aug 2002 19:34:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA17404 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 19:35:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16640; Mon, 12 Aug 2002 19:30:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16546 for ; Mon, 12 Aug 2002 19:30:02 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14516 for ; Mon, 12 Aug 2002 19:28:43 -0400 (EDT) Message-ID: <005001c24257$d4fca3f0$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 12 Aug 2002 16:22:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Context Standardization Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit The following are proposals adding text on feature context standardization. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ------------ Proposal 1: Do not add anything on feature context standardization. ------------ ------------ Proposal 2: Add the following text: Section 6: Standardization of Feature Contexts The context transfer protocol provides a basic framework in which feature contexts of varying types can be transferred. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, the base context transfer protocol requirements are designed to not constrain how the context transfer protocol is used for particular feature contexts with respect to these points. In addition, some feature contexts may require additional processing on the target access router before they can be of use. Individual feature contexts will be standardized by the method of IETF standards action. The standardizationof a feature context should describe how a feature context utilizes the base context transfer protocol; if update, synchronization, and additional proccessing are required, and, if so, how they are achieved; and the transport used for the feature context. ------------ Proposal 3: Add the following text: 5.8 Feature Context Specifications The context transfer protocol provides a basic framework in which feature contexts of varying types can be transfered. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, this section contains requirements on the feature context specifications. Note that these requirements do not constrain the actual feature context protocols themselves, but only their specification. 5.8.1 A feature context specification MUST contain an IANA assigned type code for the particular feature context. If an experimental feature context protocol is being developed, a type code from the context transfer protocol's experimental range SHOULD be used. The type code is used in the context transfer container to identify the feature context. 5.8.2 A feature context specification MUST define the byte layout of the individual elements of the feature context, and how those map into the context transfer protocol's container. The byte layout SHOULD obey standard IETF conventions with regard to mapping of data into on the wire format. 5.8.3 If the feature context is transferred using an IETF transport layer protocol, and relying on specific mechanisms of the transport layer protocol, such as reliability or timing mechanisms, then the feature context specification MUST include the full details of how the transport layer protocol is used. One must note that employing different transport mechanisms for different feature context might lead to limited possibility of multiplexing various feature contexts If the feature context is transferred as an option on another IETF protocol, then the feature context specification MUST define the mapping of the context transfer container into the other protocol's standard option format. If the feature context is transferred through a non-IETF protocol (such as IAPP [4]), then the feature context protocol specification MUST define how the standard context transfer container is mapped into the non-IETF transport. 5.8.4 A feature context specification MUST indicate whether update to context information is allowed if changes in the source occur after the context is transferred. If such changes are allowed, the feature context specification MUST define the change protocol message format using the standard context transfer container, and MUST include details of how the update is accomplished and triggered. 5.8.5 A feature context specification MUST indicate whether the context transfer is tightly synchronized with external events, such as handover. The feature context specification MUST indicate what event or events trigger transfer. 6.0 References [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. -------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 12 20:25: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 TAA14582 for ; Mon, 12 Aug 2002 19:31:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16665; Mon, 12 Aug 2002 19:30:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16543 for ; Mon, 12 Aug 2002 19:30:02 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14514 for ; Mon, 12 Aug 2002 19:28:43 -0400 (EDT) Message-ID: <004e01c24257$d43471f0$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 12 Aug 2002 16:21:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit The following are proposals for Section 5.2. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ----------- Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the requirements. ----------- ----------- Proposal 2: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified so that it is independent of the underlying transport. Recognizing that the transport characteristics for context transfer will depend on the particular application, it should be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extension on another protocol, such as handover signaling. ----------- ----------- Proposal 3: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified to utilize a reliable transport protocol as a default, unreliable transport MAY also be optionally allowed. Recognizing that context transfer may be crucial for successful handover, the context transfer protocol must specify operation on a default reliable transport. The context transfer protocol may optionally allow transfer on unreliable transport. 5.2.2 The context transfer protocol MUST run directly on top of a transport protocol. Context transfer within another application layer protocol MUST NOT be allowed. In order to preserve the unity of context transport across all feature applications, context transfer must run directly on top of a transport protocol. Running context transfer as an option on another application layer protocol is prohibited. ----------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 20: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 TAA14654 for ; Mon, 12 Aug 2002 19:34:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA17393 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 19:35:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16692; Mon, 12 Aug 2002 19:30:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16544 for ; Mon, 12 Aug 2002 19:30:02 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14515 for ; Mon, 12 Aug 2002 19:28:43 -0400 (EDT) Message-ID: <004f01c24257$d4b64c20$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 12 Aug 2002 16:21:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit The following are proposals for Section 5.5. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ---------- Proposal 1: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. 5.5.4 The base context transfer protocol MUST allow individual feature context specifications to define their own update procedures if required. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the general CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Feature contexts will differ in whether or not they require update. A feature context such as QoS parameters for the service level agreement with a user may not involve dynamically changing information, but it may change during or after context transfer. Such feature contexts may benefit from allowing the context to change after the transfer is completed. Other feature contexts, such as header compression, may be tightly synchronized with external events and changes on the old router need to be discarded since the new router's state may already have been modified. ---------- Proposal 2: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol MUST NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. Since the base context transfer protocol must accommodate a wide range of potential feature contexts, the base protocol design must not contain any specification concerning update and synchronization. --------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 12 20:25: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 TAA14651 for ; Mon, 12 Aug 2002 19:34:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16640; Mon, 12 Aug 2002 19:30:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16546 for ; Mon, 12 Aug 2002 19:30:02 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14516 for ; Mon, 12 Aug 2002 19:28:43 -0400 (EDT) Message-ID: <005001c24257$d4fca3f0$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 12 Aug 2002 16:22:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Context Standardization Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit The following are proposals adding text on feature context standardization. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ------------ Proposal 1: Do not add anything on feature context standardization. ------------ ------------ Proposal 2: Add the following text: Section 6: Standardization of Feature Contexts The context transfer protocol provides a basic framework in which feature contexts of varying types can be transferred. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, the base context transfer protocol requirements are designed to not constrain how the context transfer protocol is used for particular feature contexts with respect to these points. In addition, some feature contexts may require additional processing on the target access router before they can be of use. Individual feature contexts will be standardized by the method of IETF standards action. The standardizationof a feature context should describe how a feature context utilizes the base context transfer protocol; if update, synchronization, and additional proccessing are required, and, if so, how they are achieved; and the transport used for the feature context. ------------ Proposal 3: Add the following text: 5.8 Feature Context Specifications The context transfer protocol provides a basic framework in which feature contexts of varying types can be transfered. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, this section contains requirements on the feature context specifications. Note that these requirements do not constrain the actual feature context protocols themselves, but only their specification. 5.8.1 A feature context specification MUST contain an IANA assigned type code for the particular feature context. If an experimental feature context protocol is being developed, a type code from the context transfer protocol's experimental range SHOULD be used. The type code is used in the context transfer container to identify the feature context. 5.8.2 A feature context specification MUST define the byte layout of the individual elements of the feature context, and how those map into the context transfer protocol's container. The byte layout SHOULD obey standard IETF conventions with regard to mapping of data into on the wire format. 5.8.3 If the feature context is transferred using an IETF transport layer protocol, and relying on specific mechanisms of the transport layer protocol, such as reliability or timing mechanisms, then the feature context specification MUST include the full details of how the transport layer protocol is used. One must note that employing different transport mechanisms for different feature context might lead to limited possibility of multiplexing various feature contexts If the feature context is transferred as an option on another IETF protocol, then the feature context specification MUST define the mapping of the context transfer container into the other protocol's standard option format. If the feature context is transferred through a non-IETF protocol (such as IAPP [4]), then the feature context protocol specification MUST define how the standard context transfer container is mapped into the non-IETF transport. 5.8.4 A feature context specification MUST indicate whether update to context information is allowed if changes in the source occur after the context is transferred. If such changes are allowed, the feature context specification MUST define the change protocol message format using the standard context transfer container, and MUST include details of how the update is accomplished and triggered. 5.8.5 A feature context specification MUST indicate whether the context transfer is tightly synchronized with external events, such as handover. The feature context specification MUST indicate what event or events trigger transfer. 6.0 References [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. -------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 12 22:33: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 WAA18423 for ; Mon, 12 Aug 2002 22:33:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25348; Mon, 12 Aug 2002 22:27:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25318 for ; Mon, 12 Aug 2002 22:27:35 -0400 (EDT) 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 WAA18110 for ; Mon, 12 Aug 2002 22:26:19 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA18616; Mon, 12 Aug 2002 19:27:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7D2R4602869; Mon, 12 Aug 2002 19:27:04 -0700 X-mProtect: <200208130227> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7qdzCc; Mon, 12 Aug 2002 19:27:02 PDT Message-ID: <3D586E7D.B81C2957@iprg.nokia.com> Date: Mon, 12 Aug 2002 19:27:09 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 References: <004e01c24257$d43471f0$296015ac@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 Hello Jim, I agree with Proposal 2. But I am also very favorable towards Proposal 1, which by the rules I cannot "also" agree with. In any case, I disagree with Proposal 3. Regards, Charlie P. James Kempf wrote: > The following are proposals for Section 5.2. Please indicate which proposal you > AGREE with (if any), and which proposals you DISAGREE with. Please *only* > indicate AGREE with only one proposal. > > ----------- > Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the > requirements. > ----------- > > ----------- > Proposal 2: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer transport. > > 5.2.1 The context transfer protocol MUST be specified so that it is > independent of the underlying transport. > > Recognizing that the transport characteristics for context transfer > will depend on the particular application, it should be possible to > transfer context directly on top of reliable transports, such as TCP > or SCTP, unreliable transports, such as UDP, or as an option or > extension on another protocol, such as handover signaling. > > ----------- > > ----------- > Proposal 3: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer transport. > > 5.2.1 The context transfer protocol MUST be specified to utilize a reliable > transport protocol as a default, unreliable transport MAY also be > optionally allowed. > > Recognizing that context transfer may be crucial for successful > handover, the context transfer protocol must specify operation > on a default reliable transport. The context transfer protocol may > optionally allow transfer on unreliable transport. > > 5.2.2 The context transfer protocol MUST run directly on top of a transport > protocol. Context transfer within another application layer > protocol MUST NOT be allowed. > > In order to preserve the unity of context transport across all > feature applications, context transfer must run directly on top of > a transport protocol. Running context transfer as an option on > another application layer protocol is prohibited. > ----------- > > _______________________________________________ > 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 Aug 12 22:50: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 WAA18987 for ; Mon, 12 Aug 2002 22:50:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27127; Mon, 12 Aug 2002 22:49:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27096 for ; Mon, 12 Aug 2002 22:49:36 -0400 (EDT) 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 WAA18940 for ; Mon, 12 Aug 2002 22:48:19 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA19185; Mon, 12 Aug 2002 19:49:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7D2n3B16291; Mon, 12 Aug 2002 19:49:03 -0700 X-mProtect: <200208130249> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdf7LFaR; Mon, 12 Aug 2002 19:49:00 PDT Message-ID: <3D5873A5.4006445F@iprg.nokia.com> Date: Mon, 12 Aug 2002 19:49:09 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <9FBD322B7824D511B36900508BF93C9C01AA4C96@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, Continuing... Gary Kenward wrote: > I agree. TCP has limitations for short bursts of traffic such as CT. > *Except* for the cases of an ad-hoc network, or a network with mobile > routers, I do not see any reason why a TCP connection cannot be simply > > opened and kept open. I agree this would be possible, and would provide reasonable performance in a lot of cases. It would penalize mobile nodes moving to "uninitialized" access routers that do not need reliable transfers, and for that reason seems to be unnecessarily heavy handed. So, I'd say it's not the best approach. > See above. Any overhead introduced during a handover takes us away > from seamlessness. > > And so, following your logic, I question the rational with doing CARD > => > CT => handover with a video stream. How about "Handover + CT"? That would work. > > The actual requirement for some contexts is low latency, not > > separate transports. The other actual requirement (for other > > contexts) is reliability (again, not separate transports). I do not > > > have confidence that TCP can meet _both_ requirements. > > You are presuming here that the handover can proceed without the > second context. Not exactly. In my opinion, we MUST arrange it so that all handovers can complete even if all context transfers fail. Successful context transfers will have the effect of improving performance. Thus, one effect of this is that, yes, the handover could complete without the second (or any other) context. > I have a feeling, a strong feeling that this is all moot. I do not > know of any context that can be transferred unreliably - that is, > there has to be a reasonable assurance that CT will succeed in order > for it to "enhance" handover. If a CT fails as a consequence of an > unrealizable transport being used, what is the result? How about header compression? If the state does not make it, then it can be re-established. How about QoS? If the state does not make it, the mobile node could renegotiate. In fact, I think this is true for _all_ contexts: if the transfer fails, the mobile node has to be robust enough to renegotiate, re-establish, or request retransmission of data. > By reasonable assurance, I go back to what I stated in reply to James: > > handovers will fail. However, handovers failures due to CT failures > must not be relatively insignificant (e.g. <<1%). It's probably a great goal, but I can't see why you would want to restrict context transfers to only those scenarios offering high reliability. > > Are you really willing to make the restriction that [seamoby] > > only deals with such networks that satisfy this criterion? > > It would be preferable if we had a protocol that was both fast > and reliable - e.g. one that optimized for very short bursts of > data. However, we (seamoby) are not going to be defining that > protocol, > as far as I can tell. > > I'm still waiting for a practical description of a wired network or > group > of wired networks where this "restriction" is impractical. For a > handover > to occur seamlessly between two networks, many, many facilities have > to > be pre-established. It would seem to me that requiring a tunnel for CT > > between the two is a very small additional requirement. Your statement is not true for the prototype implementation we have. Requiring another tunnel for CT is just not necessary, and isn't such a trivial requirement anyway. > Regardless, the idea of defining an ack/retx capability on top of > UDP/ICMP > is still transport protocol design. Arguably, TCP is simply UDP with > ack/retx > and window flow control (and a pile of other stuff designed to make it > all > work in various situations). A pile here, a pile there, and pretty soon you're talking about real protocol. > > > Why not simply put all feature contexts into one transport > exchange? > > > Which hopefully means, one IP packet. > > > > That's what my "program" does! Please have another look. > > No it doesn't. It puts each context into it's own transport protocol. > That's > not, in my view, one transport exchange (each protocol sets up it's > own > exchange), and not one IP packet, in anyone's view. Well, with apologies to others, here is what I said: > 1. Find the most urgent context. Encapsulate it using the transport > it specifies (which won't be TCP, I reckon, for extremely urgent > contexts). Fill the rest of the context feature data structure > with the most urgent other contexts that will fit, and which are > compatible with the chosen transport. If the chosen transport > is not a reliable transport, schedule a retransmission if any > context transfer requires acknowledgement. The third sentence refutes your characterization. How many transports do you think there are, anyway? Typically, there would be one packet per transport type, and that's unlikely to be more than two packets. > Good to know. But then, I am confused over the relevance of HI/HAck to > > the discussion. They are one good place to put context feature data, but not the only good place. Put another way, if the old access router is already sending HI to the new access router, there's no reason that urgent context feature data should not be included with the base handover information. > I guess I shall remain confused. You introduced HI/HAck as a mechanism > > for CT. I don't see the relevance. If the *only* context I have to > transfer fits into HI/HAck and HI/HAck provides the necessary > transport > characteristics, then yes, it would be nice if CT could run over > Hi/HAck. That's all I meant. > Does this mean that CT should be tailored so that it runs over > Hi/HAck? Of course not -- depending on what you meant by "tailored". I think it should be convenient to do it either way. > I guess it should be shown that tailoring CT for this purpose is > significantly > superior then running CT in parallel (or before, as with in > "proactively"). Two packets takes longer than one. > Onwards and downwards, > Gary Somehow that means you are unlikely to welcome this response. But I'm trying to be constructive. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 22:50: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 WAA18995 for ; Mon, 12 Aug 2002 22:50:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA27249 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 22:52:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27127; Mon, 12 Aug 2002 22:49:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27096 for ; Mon, 12 Aug 2002 22:49:36 -0400 (EDT) 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 WAA18940 for ; Mon, 12 Aug 2002 22:48:19 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA19185; Mon, 12 Aug 2002 19:49:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7D2n3B16291; Mon, 12 Aug 2002 19:49:03 -0700 X-mProtect: <200208130249> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdf7LFaR; Mon, 12 Aug 2002 19:49:00 PDT Message-ID: <3D5873A5.4006445F@iprg.nokia.com> Date: Mon, 12 Aug 2002 19:49:09 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <9FBD322B7824D511B36900508BF93C9C01AA4C96@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, Continuing... Gary Kenward wrote: > I agree. TCP has limitations for short bursts of traffic such as CT. > *Except* for the cases of an ad-hoc network, or a network with mobile > routers, I do not see any reason why a TCP connection cannot be simply > > opened and kept open. I agree this would be possible, and would provide reasonable performance in a lot of cases. It would penalize mobile nodes moving to "uninitialized" access routers that do not need reliable transfers, and for that reason seems to be unnecessarily heavy handed. So, I'd say it's not the best approach. > See above. Any overhead introduced during a handover takes us away > from seamlessness. > > And so, following your logic, I question the rational with doing CARD > => > CT => handover with a video stream. How about "Handover + CT"? That would work. > > The actual requirement for some contexts is low latency, not > > separate transports. The other actual requirement (for other > > contexts) is reliability (again, not separate transports). I do not > > > have confidence that TCP can meet _both_ requirements. > > You are presuming here that the handover can proceed without the > second context. Not exactly. In my opinion, we MUST arrange it so that all handovers can complete even if all context transfers fail. Successful context transfers will have the effect of improving performance. Thus, one effect of this is that, yes, the handover could complete without the second (or any other) context. > I have a feeling, a strong feeling that this is all moot. I do not > know of any context that can be transferred unreliably - that is, > there has to be a reasonable assurance that CT will succeed in order > for it to "enhance" handover. If a CT fails as a consequence of an > unrealizable transport being used, what is the result? How about header compression? If the state does not make it, then it can be re-established. How about QoS? If the state does not make it, the mobile node could renegotiate. In fact, I think this is true for _all_ contexts: if the transfer fails, the mobile node has to be robust enough to renegotiate, re-establish, or request retransmission of data. > By reasonable assurance, I go back to what I stated in reply to James: > > handovers will fail. However, handovers failures due to CT failures > must not be relatively insignificant (e.g. <<1%). It's probably a great goal, but I can't see why you would want to restrict context transfers to only those scenarios offering high reliability. > > Are you really willing to make the restriction that [seamoby] > > only deals with such networks that satisfy this criterion? > > It would be preferable if we had a protocol that was both fast > and reliable - e.g. one that optimized for very short bursts of > data. However, we (seamoby) are not going to be defining that > protocol, > as far as I can tell. > > I'm still waiting for a practical description of a wired network or > group > of wired networks where this "restriction" is impractical. For a > handover > to occur seamlessly between two networks, many, many facilities have > to > be pre-established. It would seem to me that requiring a tunnel for CT > > between the two is a very small additional requirement. Your statement is not true for the prototype implementation we have. Requiring another tunnel for CT is just not necessary, and isn't such a trivial requirement anyway. > Regardless, the idea of defining an ack/retx capability on top of > UDP/ICMP > is still transport protocol design. Arguably, TCP is simply UDP with > ack/retx > and window flow control (and a pile of other stuff designed to make it > all > work in various situations). A pile here, a pile there, and pretty soon you're talking about real protocol. > > > Why not simply put all feature contexts into one transport > exchange? > > > Which hopefully means, one IP packet. > > > > That's what my "program" does! Please have another look. > > No it doesn't. It puts each context into it's own transport protocol. > That's > not, in my view, one transport exchange (each protocol sets up it's > own > exchange), and not one IP packet, in anyone's view. Well, with apologies to others, here is what I said: > 1. Find the most urgent context. Encapsulate it using the transport > it specifies (which won't be TCP, I reckon, for extremely urgent > contexts). Fill the rest of the context feature data structure > with the most urgent other contexts that will fit, and which are > compatible with the chosen transport. If the chosen transport > is not a reliable transport, schedule a retransmission if any > context transfer requires acknowledgement. The third sentence refutes your characterization. How many transports do you think there are, anyway? Typically, there would be one packet per transport type, and that's unlikely to be more than two packets. > Good to know. But then, I am confused over the relevance of HI/HAck to > > the discussion. They are one good place to put context feature data, but not the only good place. Put another way, if the old access router is already sending HI to the new access router, there's no reason that urgent context feature data should not be included with the base handover information. > I guess I shall remain confused. You introduced HI/HAck as a mechanism > > for CT. I don't see the relevance. If the *only* context I have to > transfer fits into HI/HAck and HI/HAck provides the necessary > transport > characteristics, then yes, it would be nice if CT could run over > Hi/HAck. That's all I meant. > Does this mean that CT should be tailored so that it runs over > Hi/HAck? Of course not -- depending on what you meant by "tailored". I think it should be convenient to do it either way. > I guess it should be shown that tailoring CT for this purpose is > significantly > superior then running CT in parallel (or before, as with in > "proactively"). Two packets takes longer than one. > Onwards and downwards, > Gary Somehow that means you are unlikely to welcome this response. But I'm trying to be constructive. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Aug 12 23:25: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 WAA18427 for ; Mon, 12 Aug 2002 22:33:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA26064 for seamoby-archive@odin.ietf.org; Mon, 12 Aug 2002 22:34:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25348; Mon, 12 Aug 2002 22:27:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25318 for ; Mon, 12 Aug 2002 22:27:35 -0400 (EDT) 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 WAA18110 for ; Mon, 12 Aug 2002 22:26:19 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA18616; Mon, 12 Aug 2002 19:27:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7D2R4602869; Mon, 12 Aug 2002 19:27:04 -0700 X-mProtect: <200208130227> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7qdzCc; Mon, 12 Aug 2002 19:27:02 PDT Message-ID: <3D586E7D.B81C2957@iprg.nokia.com> Date: Mon, 12 Aug 2002 19:27:09 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 References: <004e01c24257$d43471f0$296015ac@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 Hello Jim, I agree with Proposal 2. But I am also very favorable towards Proposal 1, which by the rules I cannot "also" agree with. In any case, I disagree with Proposal 3. Regards, Charlie P. James Kempf wrote: > The following are proposals for Section 5.2. Please indicate which proposal you > AGREE with (if any), and which proposals you DISAGREE with. Please *only* > indicate AGREE with only one proposal. > > ----------- > Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the > requirements. > ----------- > > ----------- > Proposal 2: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer transport. > > 5.2.1 The context transfer protocol MUST be specified so that it is > independent of the underlying transport. > > Recognizing that the transport characteristics for context transfer > will depend on the particular application, it should be possible to > transfer context directly on top of reliable transports, such as TCP > or SCTP, unreliable transports, such as UDP, or as an option or > extension on another protocol, such as handover signaling. > > ----------- > > ----------- > Proposal 3: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer transport. > > 5.2.1 The context transfer protocol MUST be specified to utilize a reliable > transport protocol as a default, unreliable transport MAY also be > optionally allowed. > > Recognizing that context transfer may be crucial for successful > handover, the context transfer protocol must specify operation > on a default reliable transport. The context transfer protocol may > optionally allow transfer on unreliable transport. > > 5.2.2 The context transfer protocol MUST run directly on top of a transport > protocol. Context transfer within another application layer > protocol MUST NOT be allowed. > > In order to preserve the unity of context transport across all > feature applications, context transfer must run directly on top of > a transport protocol. Running context transfer as an option on > another application layer protocol is prohibited. > ----------- > > _______________________________________________ > 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 Aug 13 10:12: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 KAA12958 for ; Tue, 13 Aug 2002 10:12:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10484; Tue, 13 Aug 2002 10:06:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10454 for ; Tue, 13 Aug 2002 10:06:54 -0400 (EDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12603 for ; Tue, 13 Aug 2002 10:05:33 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g7DE6DV29008; Tue, 13 Aug 2002 09:06:13 -0500 (CDT) Message-ID: <3D591285.3000205@alcatel.com> Date: Tue, 13 Aug 2002 09:07:01 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Charlie Perkins CC: James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 References: <004e01c24257$d43471f0$296015ac@T23KEMPF> <3D586E7D.B81C2957@iprg.nokia.com> Content-Type: multipart/alternative; boundary="------------070807070506050609000202" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------070807070506050609000202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI, 802.11f defines the context transfer among APs over wired network using TCP. It should also be noted that this spec is still a draft. If there are compelling reasons for lifting the reliability at the expense of speed and flexibility, I would also go for it. Regards Charlie Perkins wrote: >Hello Jim, > >I agree with Proposal 2. But I am also very favorable towards >Proposal 1, which by the rules I cannot "also" agree with. >In any case, I disagree with Proposal 3. > >Regards, >Charlie P. > > >James Kempf wrote: > >>The following are proposals for Section 5.2. Please indicate which proposal you >>AGREE with (if any), and which proposals you DISAGREE with. Please *only* >>indicate AGREE with only one proposal. >> >>----------- >>Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the >>requirements. >>----------- >> >>----------- >>Proposal 2: Replace Section 5.2 with the following: >> >> 5.2 Transport Requirements >> >> This section contains requirements on the context transfer transport. >> >> 5.2.1 The context transfer protocol MUST be specified so that it is >> independent of the underlying transport. >> >> Recognizing that the transport characteristics for context transfer >> will depend on the particular application, it should be possible to >> transfer context directly on top of reliable transports, such as TCP >> or SCTP, unreliable transports, such as UDP, or as an option or >> extension on another protocol, such as handover signaling. >> >>----------- >> >>----------- >>Proposal 3: Replace Section 5.2 with the following: >> >> 5.2 Transport Requirements >> >> This section contains requirements on the context transfer transport. >> >> 5.2.1 The context transfer protocol MUST be specified to utilize a reliable >> transport protocol as a default, unreliable transport MAY also be >> optionally allowed. >> >> Recognizing that context transfer may be crucial for successful >> handover, the context transfer protocol must specify operation >> on a default reliable transport. The context transfer protocol may >> optionally allow transfer on unreliable transport. >> >> 5.2.2 The context transfer protocol MUST run directly on top of a transport >> protocol. Context transfer within another application layer >> protocol MUST NOT be allowed. >> >> In order to preserve the unity of context transport across all >> feature applications, context transfer must run directly on top of >> a transport protocol. Running context transfer as an option on >> another application layer protocol is prohibited. >>----------- >> >>_______________________________________________ >>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 --------------070807070506050609000202 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit FYI, 802.11f defines the context transfer among APs over wired network using TCP.
It should also be noted that this spec is still a draft.
If there are compelling reasons for lifting the reliability at the expense of speed and flexibility, I would also go for it.

Regards

Charlie Perkins wrote:
Hello Jim,

I agree with Proposal 2.   But I am also very favorable towards
Proposal 1, which by the rules I cannot "also" agree with.
In any case, I disagree with Proposal 3.

Regards,
Charlie P.


James Kempf wrote:

The following are proposals for Section 5.2. Please indicate which proposal you
AGREE with (if any), and which proposals you DISAGREE with. Please *only*
indicate AGREE with only one proposal.

-----------
Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the
requirements.
-----------

-----------
Proposal 2: Replace Section 5.2 with the following:

   5.2 Transport Requirements

        This section contains requirements on the context transfer transport.

    5.2.1  The context transfer protocol MUST be specified so that it is
               independent of the underlying transport.

            Recognizing that the transport characteristics for context transfer
            will depend on the particular application, it should be possible to
            transfer context directly on top of reliable transports, such as TCP
            or SCTP, unreliable transports, such as
 UDP, or as an option or
            extension on another protocol, such as handover signaling.

-----------

-----------
Proposal 3: Replace Section 5.2 with the following:

   5.2 Transport Requirements

        This section contains requirements on the context transfer transport.

    5.2.1  The context transfer protocol MUST be specified to utilize a reliable
               transport protocol as a default, unreliable transport MAY also be
               optionally allowed.

               Recognizing that context transfer may be crucial for successful
               handover, the context transfer protocol must specify operation
              on a default reliable transport. The context transfer protocol may
              optionally allow transfer on unreliable transport.

    5.2.2  The context transfer protocol MUST run directly on top of a transport
              protocol. Context transfer within another 
application layer
              protocol MUST NOT be allowed.

              In order to preserve the unity of context transport across all
              feature applications, context transfer must run directly on top of
             a transport protocol. Running context transfer as an option on
             another application layer protocol is prohibited.
-----------

_______________________________________________
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

--------------070807070506050609000202-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 13 10:12: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 KAA12973 for ; Tue, 13 Aug 2002 10:12:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11125 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 10:13:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10484; Tue, 13 Aug 2002 10:06:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10454 for ; Tue, 13 Aug 2002 10:06:54 -0400 (EDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12603 for ; Tue, 13 Aug 2002 10:05:33 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g7DE6DV29008; Tue, 13 Aug 2002 09:06:13 -0500 (CDT) Message-ID: <3D591285.3000205@alcatel.com> Date: Tue, 13 Aug 2002 09:07:01 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Charlie Perkins CC: James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 References: <004e01c24257$d43471f0$296015ac@T23KEMPF> <3D586E7D.B81C2957@iprg.nokia.com> Content-Type: multipart/alternative; boundary="------------070807070506050609000202" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------070807070506050609000202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI, 802.11f defines the context transfer among APs over wired network using TCP. It should also be noted that this spec is still a draft. If there are compelling reasons for lifting the reliability at the expense of speed and flexibility, I would also go for it. Regards Charlie Perkins wrote: >Hello Jim, > >I agree with Proposal 2. But I am also very favorable towards >Proposal 1, which by the rules I cannot "also" agree with. >In any case, I disagree with Proposal 3. > >Regards, >Charlie P. > > >James Kempf wrote: > >>The following are proposals for Section 5.2. Please indicate which proposal you >>AGREE with (if any), and which proposals you DISAGREE with. Please *only* >>indicate AGREE with only one proposal. >> >>----------- >>Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the >>requirements. >>----------- >> >>----------- >>Proposal 2: Replace Section 5.2 with the following: >> >> 5.2 Transport Requirements >> >> This section contains requirements on the context transfer transport. >> >> 5.2.1 The context transfer protocol MUST be specified so that it is >> independent of the underlying transport. >> >> Recognizing that the transport characteristics for context transfer >> will depend on the particular application, it should be possible to >> transfer context directly on top of reliable transports, such as TCP >> or SCTP, unreliable transports, such as UDP, or as an option or >> extension on another protocol, such as handover signaling. >> >>----------- >> >>----------- >>Proposal 3: Replace Section 5.2 with the following: >> >> 5.2 Transport Requirements >> >> This section contains requirements on the context transfer transport. >> >> 5.2.1 The context transfer protocol MUST be specified to utilize a reliable >> transport protocol as a default, unreliable transport MAY also be >> optionally allowed. >> >> Recognizing that context transfer may be crucial for successful >> handover, the context transfer protocol must specify operation >> on a default reliable transport. The context transfer protocol may >> optionally allow transfer on unreliable transport. >> >> 5.2.2 The context transfer protocol MUST run directly on top of a transport >> protocol. Context transfer within another application layer >> protocol MUST NOT be allowed. >> >> In order to preserve the unity of context transport across all >> feature applications, context transfer must run directly on top of >> a transport protocol. Running context transfer as an option on >> another application layer protocol is prohibited. >>----------- >> >>_______________________________________________ >>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 --------------070807070506050609000202 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit FYI, 802.11f defines the context transfer among APs over wired network using TCP.
It should also be noted that this spec is still a draft.
If there are compelling reasons for lifting the reliability at the expense of speed and flexibility, I would also go for it.

Regards

Charlie Perkins wrote:
Hello Jim,

I agree with Proposal 2.   But I am also very favorable towards
Proposal 1, which by the rules I cannot "also" agree with.
In any case, I disagree with Proposal 3.

Regards,
Charlie P.


James Kempf wrote:

The following are proposals for Section 5.2. Please indicate which proposal you
AGREE with (if any), and which proposals you DISAGREE with. Please *only*
indicate AGREE with only one proposal.

-----------
Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the
requirements.
-----------

-----------
Proposal 2: Replace Section 5.2 with the following:

   5.2 Transport Requirements

        This section contains requirements on the context transfer transport.

    5.2.1  The context transfer protocol MUST be specified so that it is
               independent of the underlying transport.

            Recognizing that the transport characteristics for context transfer
            will depend on the particular application, it should be possible to
            transfer context directly on top of reliable transports, such as TCP
            or SCTP, unreliable transports, such as
 UDP, or as an option or
            extension on another protocol, such as handover signaling.

-----------

-----------
Proposal 3: Replace Section 5.2 with the following:

   5.2 Transport Requirements

        This section contains requirements on the context transfer transport.

    5.2.1  The context transfer protocol MUST be specified to utilize a reliable
               transport protocol as a default, unreliable transport MAY also be
               optionally allowed.

               Recognizing that context transfer may be crucial for successful
               handover, the context transfer protocol must specify operation
              on a default reliable transport. The context transfer protocol may
              optionally allow transfer on unreliable transport.

    5.2.2  The context transfer protocol MUST run directly on top of a transport
              protocol. Context transfer within another 
application layer
              protocol MUST NOT be allowed.

              In order to preserve the unity of context transport across all
              feature applications, context transfer must run directly on top of
             a transport protocol. Running context transfer as an option on
             another application layer protocol is prohibited.
-----------

_______________________________________________
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

--------------070807070506050609000202-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 13 10:27: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 KAA13621 for ; Tue, 13 Aug 2002 10:27:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11770; Tue, 13 Aug 2002 10:24:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11702 for ; Tue, 13 Aug 2002 10:24:17 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13444 for ; Tue, 13 Aug 2002 10:22:58 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DEJg725367; Tue, 13 Aug 2002 10:19:42 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 10:19:42 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C9B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Tue, 13 Aug 2002 10:19:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C242D4.761012A0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C242D4.761012A0 Content-Type: text/plain; charset="iso-8859-1" Charlie: > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: August 12, 2002 22:49 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > Continuing... > > Gary Kenward wrote: > > > I agree. TCP has limitations for short bursts of traffic such as CT. > > *Except* for the cases of an ad-hoc network, or a network > with mobile > > routers, I do not see any reason why a TCP connection > cannot be simply > > > > opened and kept open. > > I agree this would be possible, and would provide > reasonable performance in a lot of cases. It would > penalize mobile nodes moving to "uninitialized" > access routers that do not need reliable transfers, > and for that reason seems to be unnecessarily heavy > handed. So, I'd say it's not the best approach. > I don't understand the concept of an "uninitialized access router". Is this a router at the north pole that few people roam within range of? Roaming happens between adjacent cells. If there is activity in a cell, there's likely to be roaming. Making it a condition that an AR have an open TCP connection to it's neighbour for it to support roaming is not burdensome. It's the same as saying that the AR have the various capabilities to support roaming. > > See above. Any overhead introduced during a handover takes us away > > from seamlessness. > > > > And so, following your logic, I question the rational with > doing CARD > > => > > CT => handover with a video stream. > > How about "Handover + CT"? That would work. How about CT => handover, that would work better :-) > > > > The actual requirement for some contexts is low latency, not > > > separate transports. The other actual requirement (for other > > > contexts) is reliability (again, not separate > transports). I do not > > > > > have confidence that TCP can meet _both_ requirements. > > > > You are presuming here that the handover can proceed without the > > second context. > > Not exactly. In my opinion, we MUST arrange it so > that all handovers can complete even if all context > transfers fail. Successful context transfers will have > the effect of improving performance. > > Thus, one effect of this is that, yes, the handover could > complete without the second (or any other) context. Agreed. But it will not be true in all cases. Consider: should security context transfer be timely or reliable? Some might have a problem with it being unreliable. However, allowing forwarding to proceed at the new AR without security ct because it is being transferred with a reliable transport is almost the same as security ct being unreliable. Note: this is the point we came to during the last transport requirements discussion. So much depends on what the feature contexts each might require, and under what conditions. Since the working group has chosen not to work on the feature context requirements, yet, no new information is available. > > > I have a feeling, a strong feeling that this is all moot. I do not > > know of any context that can be transferred unreliably - that is, > > there has to be a reasonable assurance that CT will succeed in order > > for it to "enhance" handover. If a CT fails as a consequence of an > > unrealizable transport being used, what is the result? > > How about header compression? If the state does > not make it, then it can be re-established. Sure. Not seamless though. Particularly if the compression is not ROHC. In truth, everything can be re-established. The trick for establishing seamlessness is to avoid this time consuming activities. > > How about QoS? If the state does not make it, the > mobile node could renegotiate. > > In fact, I think this is true for _all_ contexts: if the > transfer fails, the mobile node has to be robust > enough to renegotiate, re-establish, or request > retransmission of data. See above. It's all relative: performance gain relative to cost. If ct provides seamlessness 50% of the time, and the rest of the time some renegotiation goes on, then it's not worth implementing (users are typically conditioned by the exception, not the rule, and so the frequency of seamlessness may probably have to be as high as 80-90% to achieve customer satisfaction with the service. Personally, I think it can, and should be higher). > > > By reasonable assurance, I go back to what I stated in > reply to James: > > > > handovers will fail. However, handovers failures due to CT failures > > must not be relatively insignificant (e.g. <<1%). > > It's probably a great goal, but I can't see why you would > want to restrict context transfers to only those scenarios > offering high reliability. Do you mean reliability of handover? Reliability of handover is not the same as reliability of the bearer packet transport. Reliability of handover impacts customer perception of a smoothly operating, dependable, predicable service. In truth, above a lower limit, consistency in handover performance is more important then maximization (e.g. variance in performance is more noticeable and irritating to the user). From a personal perspective again (for I have not seen any human factors studies on the subject), I believe that a successful wireless offering means that the user receives a consistent, predictable communications service, and does not experience *any* handovers (but perhaps, the *rare* drop of a session). The user should not have to care about "cell boundaries" (I'm talking about real users, not techies at IETF conferences :-} ). > > > > > Are you really willing to make the restriction that [seamoby] > > > only deals with such networks that satisfy this criterion? > > > > It would be preferable if we had a protocol that was both fast > > and reliable - e.g. one that optimized for very short bursts of > > data. However, we (seamoby) are not going to be defining that > > protocol, > > as far as I can tell. > > > > I'm still waiting for a practical description of a wired network or > > group > > of wired networks where this "restriction" is impractical. For a > > handover > > to occur seamlessly between two networks, many, many facilities have > > to > > be pre-established. It would seem to me that requiring a > tunnel for CT > > > > between the two is a very small additional requirement. > > Your statement is not true for the prototype implementation > we have. Requiring another tunnel for CT is just not > necessary, and isn't such a trivial requirement anyway. Well, I guess that I cannot speak to your implementation. It might help if you explained to the wg why establishing and maintaining a TCP connection between two ARs is non-trivial for your implementation. Nothing is more useful then real implementation experience. > > > Regardless, the idea of defining an ack/retx capability on top of > > UDP/ICMP > > is still transport protocol design. Arguably, TCP is simply UDP with > > ack/retx > > and window flow control (and a pile of other stuff designed > to make it > > all > > work in various situations). > > A pile here, a pile there, and pretty soon you're talking > about real protocol. Yup. So either we are using an existing protocol, with no modifications, or we are designing a new transport protocol. Talking about putting ack/retx on UDP/ICMP is miss-leading, it would be a new transport protocol. > > > > > Why not simply put all feature contexts into one transport > > exchange? > > > > Which hopefully means, one IP packet. > > > > > > That's what my "program" does! Please have another look. > > > > No it doesn't. It puts each context into it's own transport > protocol. > > That's > > not, in my view, one transport exchange (each protocol sets up it's > > own > > exchange), and not one IP packet, in anyone's view. > > Well, with apologies to others, here is what I said: > > > 1. Find the most urgent context. Encapsulate it using the transport > > it specifies (which won't be TCP, I reckon, for extremely urgent > > contexts). Fill the rest of the context feature data structure > > with the most urgent other contexts that will fit, and which are > > compatible with the chosen transport. If the chosen transport > > is not a reliable transport, schedule a retransmission if any > > context transfer requires acknowledgement. > > The third sentence refutes your characterization. How many > transports do you think there are, anyway? "Encapsulate it using the transport it specifies". ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Note: one thing that bothers me about this discussion is that idea that TCP is inherently slow. On a good link (i.e. just about any wired link in a well engineered network) and with no congestion in any of the nodes (which is easily done using Diff Serv and traffic engineering, for example; and, just how many routers will be between two neighbouring ARs? one? two?). An established TCP connection is just as fast as UDP. > > Typically, there would be one packet per transport type, and > that's unlikely to be more than two packets. But I still do not see the advantage. In one scenario you have feature contexts being transferred over individual transports, in another (my ideal) you have all features multiplexed onto one packet, and travelling to the destination AR in one packet. With a "permanent" TCP connection to the new AR, the transit time is the same as UDP/ICMP. If the packet gets "lost" and handover is in progress, then the new AR has to decide if it should wait for the re-transmission, begin forwarding the MNs packets, re-negotiate services, or drop the session. *IF* a packet gets lost - do you think it is possible to keep the packet loss probability in a well engineered network to below 1%? If so, then the last three options are probably appropriate options (1 in 100 handovers require re-negotiation, perhaps while the forwarding proceeds with degraded service). I think that .001% packet lost probability is easy to achieve - this is not transport across the global internet. BTW: I am not a proponent of TCP for the transport. Indeed, if you follow the above argument, and loss rates of <1% are easily achievable, then UDP should be reliable enough. > > > > Good to know. But then, I am confused over the relevance of > HI/HAck to > > > > the discussion. > > They are one good place to put context feature data, but > not the only good place. Good is subjective. > > Put another way, if the old access router is already sending > HI to the new access router, there's no reason that urgent > context feature data should not be included with the base > handover information. And the reason for piggy-backing the information is to save one packet transmission per handover? At the cost of having feature ct's occur sequentially and asynchronously? It does not seem worth the trouble, honestly. > > > I guess I shall remain confused. You introduced HI/HAck as > a mechanism > > > > for CT. I don't see the relevance. If the *only* context I have to > > transfer fits into HI/HAck and HI/HAck provides the necessary > > transport > > characteristics, then yes, it would be nice if CT could run over > > Hi/HAck. > > That's all I meant. > > > Does this mean that CT should be tailored so that it runs over > > Hi/HAck? > > Of course not -- depending on what you meant by "tailored". > I think it should be convenient to do it either way. > > > I guess it should be shown that tailoring CT for this purpose is > > significantly > > superior then running CT in parallel (or before, as with in > > "proactively"). > > Two packets takes longer than one. Exactly. So you agree ct is faster sent over one transport packet. > > > Onwards and downwards, > > Gary > > Somehow that means you are unlikely to welcome this response. > But I'm trying to be constructive. No, not at all. Just being sardonic. Sorry. I think that, as with the last go round, we really need to get either a ct solution out for everyone to debate, or we need to get some feature context transport requirements analysis out for everyone to ponder and debate. All I want, is for the requirement wording to be changed to indicate that goal is to minimize the complexity of the transport, with one transport protocol for ct being a desirable objective. Cheerio, Gary > > Regards, > Charlie P. > > > ------_=_NextPart_001_01C242D4.761012A0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

Charlie:

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 12, 2002 22:49
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> Continuing...
>
> Gary Kenward wrote:
>
> > I agree. TCP has limitations for short bursts of traffic such as CT.
> > *Except* for the cases of an ad-hoc network, or a network
> with mobile
> > routers, I do not see any reason why a TCP connection
> cannot be simply
> >
> > opened and kept open.
>
> I agree this would be possible, and would provide
> reasonable performance in a lot of cases.  It would
> penalize mobile nodes moving to "uninitialized"
> access routers that do not need reliable transfers,
> and for that reason seems to be unnecessarily heavy
> handed.  So, I'd say it's not the best approach.
>

I don't understand the concept of an "uninitialized access router".
Is this a router at the north pole that few people roam within range of?

Roaming happens between adjacent cells. If there is activity in a cell,
there's likely to be roaming. Making it a condition that an AR have
an open TCP connection to it's neighbour for it to support roaming is
not burdensome. It's the same as saying that the AR have the various capabilities
to support roaming.

> > See above. Any overhead introduced during a handover takes us away
> > from seamlessness.
> >
> > And so, following your logic, I question the rational with
> doing CARD
> > =>
> > CT => handover with a video stream.
>
> How about "Handover + CT"?  That would work.

How about CT => handover, that would work better :-)

>
> > > The actual requirement for some contexts is low latency, not
> > > separate transports.  The other actual requirement (for other
> > > contexts) is reliability (again, not separate
> transports).  I do not
> >
> > > have confidence that TCP can meet _both_ requirements.
> >
> > You are presuming here that the handover can proceed without the
> > second context.
>
> Not exactly.  In my opinion, we MUST arrange it so
> that all handovers can complete even if all context
> transfers fail.  Successful context transfers will have
> the effect of improving performance.
>
> Thus, one effect of this is that, yes, the handover could
> complete without the second (or any other) context.

Agreed. But it will not be true in all cases. Consider: should security
context transfer be timely or reliable? Some might have a problem with it
being unreliable. However, allowing forwarding to proceed at the
new AR without security ct because it is being transferred with a reliable
transport is almost the same as security ct being unreliable.

Note: this is the point we came to during the last transport requirements
discussion. So much depends on what the feature contexts each might require,
and under what conditions. Since the working group has chosen not to work on
the feature context requirements, yet, no new information is available.

>
> > I have a feeling, a strong feeling that this is all moot. I do not
> > know of any context that can be transferred unreliably - that is,
> > there has to be a reasonable assurance that CT will succeed in order
> > for it to "enhance" handover. If a CT fails as a consequence of an
> > unrealizable transport being used, what is the result?
>
> How about header compression?  If the state does
> not make it, then it can be re-established.

Sure. Not seamless though. Particularly if the compression is
not ROHC. In truth, everything can be re-established. The trick
for establishing seamlessness is to avoid this time consuming
activities.

>
> How about QoS?  If the state does not make it, the
> mobile node could renegotiate.
>
> In fact, I think this is true for _all_ contexts: if the
> transfer fails, the mobile node has to be robust
> enough to renegotiate, re-establish, or request
> retransmission of data.

See above.

It's all relative: performance gain relative to cost. If ct provides
seamlessness 50% of the time, and the rest of the time some renegotiation
goes on, then it's not worth implementing (users are typically conditioned
by the exception, not the rule, and so the frequency of seamlessness may
probably have to be as high as 80-90% to achieve customer satisfaction with
the service. Personally, I think it can, and should be higher).

>
> > By reasonable assurance, I go back to what I stated in
> reply to James:
> >
> > handovers will fail. However, handovers failures due to CT failures
> > must not be relatively insignificant (e.g. <<1%).
>
> It's probably a great goal, but I can't see why you would
> want to restrict context transfers to only those scenarios
> offering high reliability.

Do you mean reliability of handover? Reliability of handover is not
the same as reliability of the bearer packet transport. Reliability of
handover impacts customer perception of a smoothly operating, dependable,
predicable service. In truth, above a lower limit, consistency in handover
performance is more important then maximization (e.g. variance in performance
is more noticeable and irritating to the user).

From a personal perspective again (for I have not seen any human factors studies
on the subject), I believe that a successful wireless offering means that the
user receives a consistent, predictable communications service, and does not
experience *any* handovers (but perhaps, the *rare* drop of a session). The
user should not have to care about "cell boundaries" (I'm talking about real
users, not techies at IETF conferences :-} ).
>
>
> > > Are you really willing to make the restriction that [seamoby]
> > > only deals with such networks that satisfy this criterion?
> >
> > It would be preferable if we had a protocol that was both fast
> > and reliable - e.g. one that optimized for very short bursts of
> > data. However, we (seamoby) are not going to be defining that
> > protocol,
> > as far as I can tell.
> >
> > I'm still waiting for a practical description of a wired network or
> > group
> > of wired networks where this "restriction" is impractical. For a
> > handover
> > to occur seamlessly between two networks, many, many facilities have
> > to
> > be pre-established. It would seem to me that requiring a
> tunnel for CT
> >
> > between the two is a very small additional requirement.
>
> Your statement is not true for the prototype implementation
> we have.  Requiring another tunnel for CT is just not
> necessary, and isn't such a trivial requirement anyway.

Well, I guess that I cannot speak to your implementation. It might help
if you explained to the wg why establishing and maintaining a TCP connection
between two ARs is non-trivial for your implementation. Nothing is more
useful then real implementation experience.

>
> > Regardless, the idea of defining an ack/retx capability on top of
> > UDP/ICMP
> > is still transport protocol design. Arguably, TCP is simply UDP with
> > ack/retx
> > and window flow control (and a pile of other stuff designed
> to make it
> > all
> > work in various situations).
>
> A pile here, a pile there, and pretty soon you're talking
> about real protocol.

Yup. So either we are using an existing protocol, with no modifications, or we
are designing a new transport protocol. Talking about putting ack/retx
on UDP/ICMP is miss-leading, it would be a new transport protocol.

>
> > > > Why not simply put all feature contexts into one transport
> > exchange?
> > > > Which hopefully means, one IP packet.
> > >
> > > That's what my "program" does!  Please have another look.
> >
> > No it doesn't. It puts each context into it's own transport
> protocol.
> > That's
> > not, in my view, one transport exchange (each protocol sets up it's
> > own
> > exchange), and not one IP packet, in anyone's view.
>
> Well, with apologies to others, here is what I said:
>
> > 1. Find the most urgent context.  Encapsulate it using the transport
> >    it specifies (which won't be TCP, I reckon, for extremely urgent
> >    contexts).   Fill the rest of the context feature data structure
> >    with the most urgent other contexts that will fit, and which are
> >    compatible with the chosen transport.  If the chosen transport
> >    is not a reliable transport, schedule a retransmission if any
> >    context transfer requires acknowledgement.
>
> The third sentence refutes your characterization.  How many
> transports do you think there are, anyway?

"Encapsulate it using the transport it specifies".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note: one thing that bothers me about this discussion is that idea that
TCP is inherently slow. On a good link (i.e. just about any
wired link in a well engineered network) and with no congestion in any
of the nodes (which is easily done using Diff Serv and traffic engineering,
for example; and, just how many routers will be between two neighbouring ARs?
one? two?). An established TCP connection is just as fast as UDP.
>
> Typically, there would be one packet per transport type, and
> that's unlikely to be more than two packets.

But I still do not see the advantage. In one scenario you have
feature contexts being transferred over individual transports,
in another (my ideal) you have all features multiplexed onto one
packet, and travelling to the destination AR in one packet. With
a "permanent" TCP connection to the new AR, the transit time is the
same as UDP/ICMP. If the packet gets "lost" and handover is in progress,
then the new AR has to decide if it should wait for the re-transmission,
begin forwarding the MNs packets, re-negotiate services, or drop the
session. *IF* a packet gets lost - do you think it is possible to
keep the packet loss probability in a well engineered network to below
1%? If so, then the last three options are probably appropriate options
(1 in 100 handovers require re-negotiation, perhaps while the forwarding
proceeds with degraded service). I think that .001% packet lost probability
is easy to achieve - this is not transport across the global internet.

BTW: I am not a proponent of TCP for the transport. Indeed, if you follow
the above argument, and loss rates of <1% are easily achievable, then
UDP should be reliable enough.

>
>
> > Good to know. But then, I am confused over the relevance of
> HI/HAck to
> >
> > the discussion.
>
> They are one good place to put context feature data, but
> not the only good place.

Good is subjective.

>
> Put another way, if the old access router is already sending
> HI to the new access router, there's no reason that urgent
> context feature data should not be included with the base
> handover information.

And the reason for piggy-backing the information is to save one
packet transmission per handover? At the cost of having feature
ct's occur sequentially and asynchronously? It does not seem
worth the trouble, honestly.

>
> > I guess I shall remain confused. You introduced HI/HAck as
> a mechanism
> >
> > for CT. I don't see the relevance. If the *only* context I have to
> > transfer fits into HI/HAck and HI/HAck provides the necessary
> > transport
> > characteristics, then yes, it would be nice if CT could run over
> > Hi/HAck.
>
> That's all I meant.
>
> > Does this mean that CT should be tailored so that it runs over
> > Hi/HAck?
>
> Of course not -- depending on what you meant by "tailored".
> I think it should be convenient to do it either way.
>
> > I guess it should be shown that tailoring CT for this purpose is
> > significantly
> > superior then running CT in parallel (or before, as with in
> > "proactively").
>
> Two packets takes longer than one.

Exactly. So you agree ct is faster sent over one transport packet.

>
> > Onwards and downwards,
> > Gary
>
> Somehow that means you are unlikely to welcome this response.
> But I'm trying to be constructive.

No, not at all. Just being sardonic. Sorry.

I think that, as with the last go round, we really need to get either
a ct solution out for everyone to debate, or we need to get some feature
context transport requirements analysis out for everyone to ponder and
debate.

All I want, is for the requirement wording to be changed to indicate that
goal is to minimize the complexity of the transport, with one transport
protocol for ct being a desirable objective.

Cheerio,
Gary

>
> Regards,
> Charlie P.
>
>
>

------_=_NextPart_001_01C242D4.761012A0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 13 10:27: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 KAA13630 for ; Tue, 13 Aug 2002 10:27:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11980 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 10:28:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11770; Tue, 13 Aug 2002 10:24:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11702 for ; Tue, 13 Aug 2002 10:24:17 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13444 for ; Tue, 13 Aug 2002 10:22:58 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DEJg725367; Tue, 13 Aug 2002 10:19:42 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 10:19:42 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C9B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Tue, 13 Aug 2002 10:19:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C242D4.761012A0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C242D4.761012A0 Content-Type: text/plain; charset="iso-8859-1" Charlie: > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: August 12, 2002 22:49 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > Continuing... > > Gary Kenward wrote: > > > I agree. TCP has limitations for short bursts of traffic such as CT. > > *Except* for the cases of an ad-hoc network, or a network > with mobile > > routers, I do not see any reason why a TCP connection > cannot be simply > > > > opened and kept open. > > I agree this would be possible, and would provide > reasonable performance in a lot of cases. It would > penalize mobile nodes moving to "uninitialized" > access routers that do not need reliable transfers, > and for that reason seems to be unnecessarily heavy > handed. So, I'd say it's not the best approach. > I don't understand the concept of an "uninitialized access router". Is this a router at the north pole that few people roam within range of? Roaming happens between adjacent cells. If there is activity in a cell, there's likely to be roaming. Making it a condition that an AR have an open TCP connection to it's neighbour for it to support roaming is not burdensome. It's the same as saying that the AR have the various capabilities to support roaming. > > See above. Any overhead introduced during a handover takes us away > > from seamlessness. > > > > And so, following your logic, I question the rational with > doing CARD > > => > > CT => handover with a video stream. > > How about "Handover + CT"? That would work. How about CT => handover, that would work better :-) > > > > The actual requirement for some contexts is low latency, not > > > separate transports. The other actual requirement (for other > > > contexts) is reliability (again, not separate > transports). I do not > > > > > have confidence that TCP can meet _both_ requirements. > > > > You are presuming here that the handover can proceed without the > > second context. > > Not exactly. In my opinion, we MUST arrange it so > that all handovers can complete even if all context > transfers fail. Successful context transfers will have > the effect of improving performance. > > Thus, one effect of this is that, yes, the handover could > complete without the second (or any other) context. Agreed. But it will not be true in all cases. Consider: should security context transfer be timely or reliable? Some might have a problem with it being unreliable. However, allowing forwarding to proceed at the new AR without security ct because it is being transferred with a reliable transport is almost the same as security ct being unreliable. Note: this is the point we came to during the last transport requirements discussion. So much depends on what the feature contexts each might require, and under what conditions. Since the working group has chosen not to work on the feature context requirements, yet, no new information is available. > > > I have a feeling, a strong feeling that this is all moot. I do not > > know of any context that can be transferred unreliably - that is, > > there has to be a reasonable assurance that CT will succeed in order > > for it to "enhance" handover. If a CT fails as a consequence of an > > unrealizable transport being used, what is the result? > > How about header compression? If the state does > not make it, then it can be re-established. Sure. Not seamless though. Particularly if the compression is not ROHC. In truth, everything can be re-established. The trick for establishing seamlessness is to avoid this time consuming activities. > > How about QoS? If the state does not make it, the > mobile node could renegotiate. > > In fact, I think this is true for _all_ contexts: if the > transfer fails, the mobile node has to be robust > enough to renegotiate, re-establish, or request > retransmission of data. See above. It's all relative: performance gain relative to cost. If ct provides seamlessness 50% of the time, and the rest of the time some renegotiation goes on, then it's not worth implementing (users are typically conditioned by the exception, not the rule, and so the frequency of seamlessness may probably have to be as high as 80-90% to achieve customer satisfaction with the service. Personally, I think it can, and should be higher). > > > By reasonable assurance, I go back to what I stated in > reply to James: > > > > handovers will fail. However, handovers failures due to CT failures > > must not be relatively insignificant (e.g. <<1%). > > It's probably a great goal, but I can't see why you would > want to restrict context transfers to only those scenarios > offering high reliability. Do you mean reliability of handover? Reliability of handover is not the same as reliability of the bearer packet transport. Reliability of handover impacts customer perception of a smoothly operating, dependable, predicable service. In truth, above a lower limit, consistency in handover performance is more important then maximization (e.g. variance in performance is more noticeable and irritating to the user). From a personal perspective again (for I have not seen any human factors studies on the subject), I believe that a successful wireless offering means that the user receives a consistent, predictable communications service, and does not experience *any* handovers (but perhaps, the *rare* drop of a session). The user should not have to care about "cell boundaries" (I'm talking about real users, not techies at IETF conferences :-} ). > > > > > Are you really willing to make the restriction that [seamoby] > > > only deals with such networks that satisfy this criterion? > > > > It would be preferable if we had a protocol that was both fast > > and reliable - e.g. one that optimized for very short bursts of > > data. However, we (seamoby) are not going to be defining that > > protocol, > > as far as I can tell. > > > > I'm still waiting for a practical description of a wired network or > > group > > of wired networks where this "restriction" is impractical. For a > > handover > > to occur seamlessly between two networks, many, many facilities have > > to > > be pre-established. It would seem to me that requiring a > tunnel for CT > > > > between the two is a very small additional requirement. > > Your statement is not true for the prototype implementation > we have. Requiring another tunnel for CT is just not > necessary, and isn't such a trivial requirement anyway. Well, I guess that I cannot speak to your implementation. It might help if you explained to the wg why establishing and maintaining a TCP connection between two ARs is non-trivial for your implementation. Nothing is more useful then real implementation experience. > > > Regardless, the idea of defining an ack/retx capability on top of > > UDP/ICMP > > is still transport protocol design. Arguably, TCP is simply UDP with > > ack/retx > > and window flow control (and a pile of other stuff designed > to make it > > all > > work in various situations). > > A pile here, a pile there, and pretty soon you're talking > about real protocol. Yup. So either we are using an existing protocol, with no modifications, or we are designing a new transport protocol. Talking about putting ack/retx on UDP/ICMP is miss-leading, it would be a new transport protocol. > > > > > Why not simply put all feature contexts into one transport > > exchange? > > > > Which hopefully means, one IP packet. > > > > > > That's what my "program" does! Please have another look. > > > > No it doesn't. It puts each context into it's own transport > protocol. > > That's > > not, in my view, one transport exchange (each protocol sets up it's > > own > > exchange), and not one IP packet, in anyone's view. > > Well, with apologies to others, here is what I said: > > > 1. Find the most urgent context. Encapsulate it using the transport > > it specifies (which won't be TCP, I reckon, for extremely urgent > > contexts). Fill the rest of the context feature data structure > > with the most urgent other contexts that will fit, and which are > > compatible with the chosen transport. If the chosen transport > > is not a reliable transport, schedule a retransmission if any > > context transfer requires acknowledgement. > > The third sentence refutes your characterization. How many > transports do you think there are, anyway? "Encapsulate it using the transport it specifies". ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Note: one thing that bothers me about this discussion is that idea that TCP is inherently slow. On a good link (i.e. just about any wired link in a well engineered network) and with no congestion in any of the nodes (which is easily done using Diff Serv and traffic engineering, for example; and, just how many routers will be between two neighbouring ARs? one? two?). An established TCP connection is just as fast as UDP. > > Typically, there would be one packet per transport type, and > that's unlikely to be more than two packets. But I still do not see the advantage. In one scenario you have feature contexts being transferred over individual transports, in another (my ideal) you have all features multiplexed onto one packet, and travelling to the destination AR in one packet. With a "permanent" TCP connection to the new AR, the transit time is the same as UDP/ICMP. If the packet gets "lost" and handover is in progress, then the new AR has to decide if it should wait for the re-transmission, begin forwarding the MNs packets, re-negotiate services, or drop the session. *IF* a packet gets lost - do you think it is possible to keep the packet loss probability in a well engineered network to below 1%? If so, then the last three options are probably appropriate options (1 in 100 handovers require re-negotiation, perhaps while the forwarding proceeds with degraded service). I think that .001% packet lost probability is easy to achieve - this is not transport across the global internet. BTW: I am not a proponent of TCP for the transport. Indeed, if you follow the above argument, and loss rates of <1% are easily achievable, then UDP should be reliable enough. > > > > Good to know. But then, I am confused over the relevance of > HI/HAck to > > > > the discussion. > > They are one good place to put context feature data, but > not the only good place. Good is subjective. > > Put another way, if the old access router is already sending > HI to the new access router, there's no reason that urgent > context feature data should not be included with the base > handover information. And the reason for piggy-backing the information is to save one packet transmission per handover? At the cost of having feature ct's occur sequentially and asynchronously? It does not seem worth the trouble, honestly. > > > I guess I shall remain confused. You introduced HI/HAck as > a mechanism > > > > for CT. I don't see the relevance. If the *only* context I have to > > transfer fits into HI/HAck and HI/HAck provides the necessary > > transport > > characteristics, then yes, it would be nice if CT could run over > > Hi/HAck. > > That's all I meant. > > > Does this mean that CT should be tailored so that it runs over > > Hi/HAck? > > Of course not -- depending on what you meant by "tailored". > I think it should be convenient to do it either way. > > > I guess it should be shown that tailoring CT for this purpose is > > significantly > > superior then running CT in parallel (or before, as with in > > "proactively"). > > Two packets takes longer than one. Exactly. So you agree ct is faster sent over one transport packet. > > > Onwards and downwards, > > Gary > > Somehow that means you are unlikely to welcome this response. > But I'm trying to be constructive. No, not at all. Just being sardonic. Sorry. I think that, as with the last go round, we really need to get either a ct solution out for everyone to debate, or we need to get some feature context transport requirements analysis out for everyone to ponder and debate. All I want, is for the requirement wording to be changed to indicate that goal is to minimize the complexity of the transport, with one transport protocol for ct being a desirable objective. Cheerio, Gary > > Regards, > Charlie P. > > > ------_=_NextPart_001_01C242D4.761012A0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

Charlie:

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 12, 2002 22:49
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> Continuing...
>
> Gary Kenward wrote:
>
> > I agree. TCP has limitations for short bursts of traffic such as CT.
> > *Except* for the cases of an ad-hoc network, or a network
> with mobile
> > routers, I do not see any reason why a TCP connection
> cannot be simply
> >
> > opened and kept open.
>
> I agree this would be possible, and would provide
> reasonable performance in a lot of cases.  It would
> penalize mobile nodes moving to "uninitialized"
> access routers that do not need reliable transfers,
> and for that reason seems to be unnecessarily heavy
> handed.  So, I'd say it's not the best approach.
>

I don't understand the concept of an "uninitialized access router".
Is this a router at the north pole that few people roam within range of?

Roaming happens between adjacent cells. If there is activity in a cell,
there's likely to be roaming. Making it a condition that an AR have
an open TCP connection to it's neighbour for it to support roaming is
not burdensome. It's the same as saying that the AR have the various capabilities
to support roaming.

> > See above. Any overhead introduced during a handover takes us away
> > from seamlessness.
> >
> > And so, following your logic, I question the rational with
> doing CARD
> > =>
> > CT => handover with a video stream.
>
> How about "Handover + CT"?  That would work.

How about CT => handover, that would work better :-)

>
> > > The actual requirement for some contexts is low latency, not
> > > separate transports.  The other actual requirement (for other
> > > contexts) is reliability (again, not separate
> transports).  I do not
> >
> > > have confidence that TCP can meet _both_ requirements.
> >
> > You are presuming here that the handover can proceed without the
> > second context.
>
> Not exactly.  In my opinion, we MUST arrange it so
> that all handovers can complete even if all context
> transfers fail.  Successful context transfers will have
> the effect of improving performance.
>
> Thus, one effect of this is that, yes, the handover could
> complete without the second (or any other) context.

Agreed. But it will not be true in all cases. Consider: should security
context transfer be timely or reliable? Some might have a problem with it
being unreliable. However, allowing forwarding to proceed at the
new AR without security ct because it is being transferred with a reliable
transport is almost the same as security ct being unreliable.

Note: this is the point we came to during the last transport requirements
discussion. So much depends on what the feature contexts each might require,
and under what conditions. Since the working group has chosen not to work on
the feature context requirements, yet, no new information is available.

>
> > I have a feeling, a strong feeling that this is all moot. I do not
> > know of any context that can be transferred unreliably - that is,
> > there has to be a reasonable assurance that CT will succeed in order
> > for it to "enhance" handover. If a CT fails as a consequence of an
> > unrealizable transport being used, what is the result?
>
> How about header compression?  If the state does
> not make it, then it can be re-established.

Sure. Not seamless though. Particularly if the compression is
not ROHC. In truth, everything can be re-established. The trick
for establishing seamlessness is to avoid this time consuming
activities.

>
> How about QoS?  If the state does not make it, the
> mobile node could renegotiate.
>
> In fact, I think this is true for _all_ contexts: if the
> transfer fails, the mobile node has to be robust
> enough to renegotiate, re-establish, or request
> retransmission of data.

See above.

It's all relative: performance gain relative to cost. If ct provides
seamlessness 50% of the time, and the rest of the time some renegotiation
goes on, then it's not worth implementing (users are typically conditioned
by the exception, not the rule, and so the frequency of seamlessness may
probably have to be as high as 80-90% to achieve customer satisfaction with
the service. Personally, I think it can, and should be higher).

>
> > By reasonable assurance, I go back to what I stated in
> reply to James:
> >
> > handovers will fail. However, handovers failures due to CT failures
> > must not be relatively insignificant (e.g. <<1%).
>
> It's probably a great goal, but I can't see why you would
> want to restrict context transfers to only those scenarios
> offering high reliability.

Do you mean reliability of handover? Reliability of handover is not
the same as reliability of the bearer packet transport. Reliability of
handover impacts customer perception of a smoothly operating, dependable,
predicable service. In truth, above a lower limit, consistency in handover
performance is more important then maximization (e.g. variance in performance
is more noticeable and irritating to the user).

From a personal perspective again (for I have not seen any human factors studies
on the subject), I believe that a successful wireless offering means that the
user receives a consistent, predictable communications service, and does not
experience *any* handovers (but perhaps, the *rare* drop of a session). The
user should not have to care about "cell boundaries" (I'm talking about real
users, not techies at IETF conferences :-} ).
>
>
> > > Are you really willing to make the restriction that [seamoby]
> > > only deals with such networks that satisfy this criterion?
> >
> > It would be preferable if we had a protocol that was both fast
> > and reliable - e.g. one that optimized for very short bursts of
> > data. However, we (seamoby) are not going to be defining that
> > protocol,
> > as far as I can tell.
> >
> > I'm still waiting for a practical description of a wired network or
> > group
> > of wired networks where this "restriction" is impractical. For a
> > handover
> > to occur seamlessly between two networks, many, many facilities have
> > to
> > be pre-established. It would seem to me that requiring a
> tunnel for CT
> >
> > between the two is a very small additional requirement.
>
> Your statement is not true for the prototype implementation
> we have.  Requiring another tunnel for CT is just not
> necessary, and isn't such a trivial requirement anyway.

Well, I guess that I cannot speak to your implementation. It might help
if you explained to the wg why establishing and maintaining a TCP connection
between two ARs is non-trivial for your implementation. Nothing is more
useful then real implementation experience.

>
> > Regardless, the idea of defining an ack/retx capability on top of
> > UDP/ICMP
> > is still transport protocol design. Arguably, TCP is simply UDP with
> > ack/retx
> > and window flow control (and a pile of other stuff designed
> to make it
> > all
> > work in various situations).
>
> A pile here, a pile there, and pretty soon you're talking
> about real protocol.

Yup. So either we are using an existing protocol, with no modifications, or we
are designing a new transport protocol. Talking about putting ack/retx
on UDP/ICMP is miss-leading, it would be a new transport protocol.

>
> > > > Why not simply put all feature contexts into one transport
> > exchange?
> > > > Which hopefully means, one IP packet.
> > >
> > > That's what my "program" does!  Please have another look.
> >
> > No it doesn't. It puts each context into it's own transport
> protocol.
> > That's
> > not, in my view, one transport exchange (each protocol sets up it's
> > own
> > exchange), and not one IP packet, in anyone's view.
>
> Well, with apologies to others, here is what I said:
>
> > 1. Find the most urgent context.  Encapsulate it using the transport
> >    it specifies (which won't be TCP, I reckon, for extremely urgent
> >    contexts).   Fill the rest of the context feature data structure
> >    with the most urgent other contexts that will fit, and which are
> >    compatible with the chosen transport.  If the chosen transport
> >    is not a reliable transport, schedule a retransmission if any
> >    context transfer requires acknowledgement.
>
> The third sentence refutes your characterization.  How many
> transports do you think there are, anyway?

"Encapsulate it using the transport it specifies".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note: one thing that bothers me about this discussion is that idea that
TCP is inherently slow. On a good link (i.e. just about any
wired link in a well engineered network) and with no congestion in any
of the nodes (which is easily done using Diff Serv and traffic engineering,
for example; and, just how many routers will be between two neighbouring ARs?
one? two?). An established TCP connection is just as fast as UDP.
>
> Typically, there would be one packet per transport type, and
> that's unlikely to be more than two packets.

But I still do not see the advantage. In one scenario you have
feature contexts being transferred over individual transports,
in another (my ideal) you have all features multiplexed onto one
packet, and travelling to the destination AR in one packet. With
a "permanent" TCP connection to the new AR, the transit time is the
same as UDP/ICMP. If the packet gets "lost" and handover is in progress,
then the new AR has to decide if it should wait for the re-transmission,
begin forwarding the MNs packets, re-negotiate services, or drop the
session. *IF* a packet gets lost - do you think it is possible to
keep the packet loss probability in a well engineered network to below
1%? If so, then the last three options are probably appropriate options
(1 in 100 handovers require re-negotiation, perhaps while the forwarding
proceeds with degraded service). I think that .001% packet lost probability
is easy to achieve - this is not transport across the global internet.

BTW: I am not a proponent of TCP for the transport. Indeed, if you follow
the above argument, and loss rates of <1% are easily achievable, then
UDP should be reliable enough.

>
>
> > Good to know. But then, I am confused over the relevance of
> HI/HAck to
> >
> > the discussion.
>
> They are one good place to put context feature data, but
> not the only good place.

Good is subjective.

>
> Put another way, if the old access router is already sending
> HI to the new access router, there's no reason that urgent
> context feature data should not be included with the base
> handover information.

And the reason for piggy-backing the information is to save one
packet transmission per handover? At the cost of having feature
ct's occur sequentially and asynchronously? It does not seem
worth the trouble, honestly.

>
> > I guess I shall remain confused. You introduced HI/HAck as
> a mechanism
> >
> > for CT. I don't see the relevance. If the *only* context I have to
> > transfer fits into HI/HAck and HI/HAck provides the necessary
> > transport
> > characteristics, then yes, it would be nice if CT could run over
> > Hi/HAck.
>
> That's all I meant.
>
> > Does this mean that CT should be tailored so that it runs over
> > Hi/HAck?
>
> Of course not -- depending on what you meant by "tailored".
> I think it should be convenient to do it either way.
>
> > I guess it should be shown that tailoring CT for this purpose is
> > significantly
> > superior then running CT in parallel (or before, as with in
> > "proactively").
>
> Two packets takes longer than one.

Exactly. So you agree ct is faster sent over one transport packet.

>
> > Onwards and downwards,
> > Gary
>
> Somehow that means you are unlikely to welcome this response.
> But I'm trying to be constructive.

No, not at all. Just being sardonic. Sorry.

I think that, as with the last go round, we really need to get either
a ct solution out for everyone to debate, or we need to get some feature
context transport requirements analysis out for everyone to ponder and
debate.

All I want, is for the requirement wording to be changed to indicate that
goal is to minimize the complexity of the transport, with one transport
protocol for ct being a desirable objective.

Cheerio,
Gary

>
> Regards,
> Charlie P.
>
>
>

------_=_NextPart_001_01C242D4.761012A0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 13 11:18: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 LAA15742 for ; Tue, 13 Aug 2002 11:18:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15782; Tue, 13 Aug 2002 11:17:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15755 for ; Tue, 13 Aug 2002 11:17:42 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15655 for ; Tue, 13 Aug 2002 11:16:23 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA11032 for ; Tue, 13 Aug 2002 08:17:39 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id IAA25522 for ; Tue, 13 Aug 2002 08:18:02 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 13 Aug 2002 10:17:38 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD570E@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 Date: Tue, 13 Aug 2002 10:17:36 -0500 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 Agree with 1, Disagree with 2, Regards, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 6:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 The following are proposals for Section 5.5. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ---------- Proposal 1: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. 5.5.4 The base context transfer protocol MUST allow individual feature context specifications to define their own update procedures if required. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the general CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Feature contexts will differ in whether or not they require update. A feature context such as QoS parameters for the service level agreement with a user may not involve dynamically changing information, but it may change during or after context transfer. Such feature contexts may benefit from allowing the context to change after the transfer is completed. Other feature contexts, such as header compression, may be tightly synchronized with external events and changes on the old router need to be discarded since the new router's state may already have been modified. ---------- Proposal 2: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol MUST NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. Since the base context transfer protocol must accommodate a wide range of potential feature contexts, the base protocol design must not contain any specification concerning update and synchronization. --------------- _______________________________________________ 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 daemon@optimus.ietf.org Tue Aug 13 11:18: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 LAA15751 for ; Tue, 13 Aug 2002 11:18:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15888 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 11:19:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15782; Tue, 13 Aug 2002 11:17:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15755 for ; Tue, 13 Aug 2002 11:17:42 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15655 for ; Tue, 13 Aug 2002 11:16:23 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA11032 for ; Tue, 13 Aug 2002 08:17:39 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id IAA25522 for ; Tue, 13 Aug 2002 08:18:02 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 13 Aug 2002 10:17:38 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD570E@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 Date: Tue, 13 Aug 2002 10:17:36 -0500 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 Agree with 1, Disagree with 2, Regards, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 6:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 The following are proposals for Section 5.5. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ---------- Proposal 1: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. 5.5.4 The base context transfer protocol MUST allow individual feature context specifications to define their own update procedures if required. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the general CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Feature contexts will differ in whether or not they require update. A feature context such as QoS parameters for the service level agreement with a user may not involve dynamically changing information, but it may change during or after context transfer. Such feature contexts may benefit from allowing the context to change after the transfer is completed. Other feature contexts, such as header compression, may be tightly synchronized with external events and changes on the old router need to be discarded since the new router's state may already have been modified. ---------- Proposal 2: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol MUST NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. Since the base context transfer protocol must accommodate a wide range of potential feature contexts, the base protocol design must not contain any specification concerning update and synchronization. --------------- _______________________________________________ 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 Aug 13 11:18: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 LAA15769 for ; Tue, 13 Aug 2002 11:18:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15055; Tue, 13 Aug 2002 11:09:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15026 for ; Tue, 13 Aug 2002 11:09:23 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15258 for ; Tue, 13 Aug 2002 11:08:04 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA12013 for ; Tue, 13 Aug 2002 08:09:21 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA24945 for ; Tue, 13 Aug 2002 08:09:20 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Tue, 13 Aug 2002 10:09:20 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD570C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Co ntext Standardization Date: Tue, 13 Aug 2002 10:09:17 -0500 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 Disagree with 1 Prefer 3 over 2. Agree with 3. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 6:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Context Standardization The following are proposals adding text on feature context standardization. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ------------ Proposal 1: Do not add anything on feature context standardization. ------------ ------------ Proposal 2: Add the following text: Section 6: Standardization of Feature Contexts The context transfer protocol provides a basic framework in which feature contexts of varying types can be transferred. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, the base context transfer protocol requirements are designed to not constrain how the context transfer protocol is used for particular feature contexts with respect to these points. In addition, some feature contexts may require additional processing on the target access router before they can be of use. Individual feature contexts will be standardized by the method of IETF standards action. The standardizationof a feature context should describe how a feature context utilizes the base context transfer protocol; if update, synchronization, and additional proccessing are required, and, if so, how they are achieved; and the transport used for the feature context. ------------ Proposal 3: Add the following text: 5.8 Feature Context Specifications The context transfer protocol provides a basic framework in which feature contexts of varying types can be transfered. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, this section contains requirements on the feature context specifications. Note that these requirements do not constrain the actual feature context protocols themselves, but only their specification. 5.8.1 A feature context specification MUST contain an IANA assigned type code for the particular feature context. If an experimental feature context protocol is being developed, a type code from the context transfer protocol's experimental range SHOULD be used. The type code is used in the context transfer container to identify the feature context. 5.8.2 A feature context specification MUST define the byte layout of the individual elements of the feature context, and how those map into the context transfer protocol's container. The byte layout SHOULD obey standard IETF conventions with regard to mapping of data into on the wire format. 5.8.3 If the feature context is transferred using an IETF transport layer protocol, and relying on specific mechanisms of the transport layer protocol, such as reliability or timing mechanisms, then the feature context specification MUST include the full details of how the transport layer protocol is used. One must note that employing different transport mechanisms for different feature context might lead to limited possibility of multiplexing various feature contexts If the feature context is transferred as an option on another IETF protocol, then the feature context specification MUST define the mapping of the context transfer container into the other protocol's standard option format. If the feature context is transferred through a non-IETF protocol (such as IAPP [4]), then the feature context protocol specification MUST define how the standard context transfer container is mapped into the non-IETF transport. 5.8.4 A feature context specification MUST indicate whether update to context information is allowed if changes in the source occur after the context is transferred. If such changes are allowed, the feature context specification MUST define the change protocol message format using the standard context transfer container, and MUST include details of how the update is accomplished and triggered. 5.8.5 A feature context specification MUST indicate whether the context transfer is tightly synchronized with external events, such as handover. The feature context specification MUST indicate what event or events trigger transfer. 6.0 References [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. -------------- _______________________________________________ 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 daemon@optimus.ietf.org Tue Aug 13 11:18: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 LAA15777 for ; Tue, 13 Aug 2002 11:18:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15899 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 11:19:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15055; Tue, 13 Aug 2002 11:09:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15026 for ; Tue, 13 Aug 2002 11:09:23 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15258 for ; Tue, 13 Aug 2002 11:08:04 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA12013 for ; Tue, 13 Aug 2002 08:09:21 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA24945 for ; Tue, 13 Aug 2002 08:09:20 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Tue, 13 Aug 2002 10:09:20 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD570C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Co ntext Standardization Date: Tue, 13 Aug 2002 10:09:17 -0500 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 Disagree with 1 Prefer 3 over 2. Agree with 3. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 6:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Context Standardization The following are proposals adding text on feature context standardization. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ------------ Proposal 1: Do not add anything on feature context standardization. ------------ ------------ Proposal 2: Add the following text: Section 6: Standardization of Feature Contexts The context transfer protocol provides a basic framework in which feature contexts of varying types can be transferred. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, the base context transfer protocol requirements are designed to not constrain how the context transfer protocol is used for particular feature contexts with respect to these points. In addition, some feature contexts may require additional processing on the target access router before they can be of use. Individual feature contexts will be standardized by the method of IETF standards action. The standardizationof a feature context should describe how a feature context utilizes the base context transfer protocol; if update, synchronization, and additional proccessing are required, and, if so, how they are achieved; and the transport used for the feature context. ------------ Proposal 3: Add the following text: 5.8 Feature Context Specifications The context transfer protocol provides a basic framework in which feature contexts of varying types can be transfered. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, this section contains requirements on the feature context specifications. Note that these requirements do not constrain the actual feature context protocols themselves, but only their specification. 5.8.1 A feature context specification MUST contain an IANA assigned type code for the particular feature context. If an experimental feature context protocol is being developed, a type code from the context transfer protocol's experimental range SHOULD be used. The type code is used in the context transfer container to identify the feature context. 5.8.2 A feature context specification MUST define the byte layout of the individual elements of the feature context, and how those map into the context transfer protocol's container. The byte layout SHOULD obey standard IETF conventions with regard to mapping of data into on the wire format. 5.8.3 If the feature context is transferred using an IETF transport layer protocol, and relying on specific mechanisms of the transport layer protocol, such as reliability or timing mechanisms, then the feature context specification MUST include the full details of how the transport layer protocol is used. One must note that employing different transport mechanisms for different feature context might lead to limited possibility of multiplexing various feature contexts If the feature context is transferred as an option on another IETF protocol, then the feature context specification MUST define the mapping of the context transfer container into the other protocol's standard option format. If the feature context is transferred through a non-IETF protocol (such as IAPP [4]), then the feature context protocol specification MUST define how the standard context transfer container is mapped into the non-IETF transport. 5.8.4 A feature context specification MUST indicate whether update to context information is allowed if changes in the source occur after the context is transferred. If such changes are allowed, the feature context specification MUST define the change protocol message format using the standard context transfer container, and MUST include details of how the update is accomplished and triggered. 5.8.5 A feature context specification MUST indicate whether the context transfer is tightly synchronized with external events, such as handover. The feature context specification MUST indicate what event or events trigger transfer. 6.0 References [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. -------------- _______________________________________________ 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 Aug 13 11:20: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 LAA15865 for ; Tue, 13 Aug 2002 11:20:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15241; Tue, 13 Aug 2002 11:12:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15211 for ; Tue, 13 Aug 2002 11:12:51 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15356 for ; Tue, 13 Aug 2002 11:11:32 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA26897 for ; Tue, 13 Aug 2002 08:11:20 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA25171 for ; Tue, 13 Aug 2002 08:10:57 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Tue, 13 Aug 2002 10:12:47 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD570D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5 .2 Date: Tue, 13 Aug 2002 10:12:38 -0500 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 Disagree with 1 and 3. Agree with 2. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 6:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 The following are proposals for Section 5.2. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ----------- Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the requirements. ----------- ----------- Proposal 2: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified so that it is independent of the underlying transport. Recognizing that the transport characteristics for context transfer will depend on the particular application, it should be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extension on another protocol, such as handover signaling. ----------- ----------- Proposal 3: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified to utilize a reliable transport protocol as a default, unreliable transport MAY also be optionally allowed. Recognizing that context transfer may be crucial for successful handover, the context transfer protocol must specify operation on a default reliable transport. The context transfer protocol may optionally allow transfer on unreliable transport. 5.2.2 The context transfer protocol MUST run directly on top of a transport protocol. Context transfer within another application layer protocol MUST NOT be allowed. In order to preserve the unity of context transport across all feature applications, context transfer must run directly on top of a transport protocol. Running context transfer as an option on another application layer protocol is prohibited. ----------- _______________________________________________ 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 daemon@optimus.ietf.org Tue Aug 13 11:20: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 LAA15879 for ; Tue, 13 Aug 2002 11:20:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16053 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 11:21:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15241; Tue, 13 Aug 2002 11:12:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15211 for ; Tue, 13 Aug 2002 11:12:51 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15356 for ; Tue, 13 Aug 2002 11:11:32 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA26897 for ; Tue, 13 Aug 2002 08:11:20 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA25171 for ; Tue, 13 Aug 2002 08:10:57 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Tue, 13 Aug 2002 10:12:47 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD570D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5 .2 Date: Tue, 13 Aug 2002 10:12:38 -0500 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 Disagree with 1 and 3. Agree with 2. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 6:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 The following are proposals for Section 5.2. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ----------- Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the requirements. ----------- ----------- Proposal 2: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified so that it is independent of the underlying transport. Recognizing that the transport characteristics for context transfer will depend on the particular application, it should be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extension on another protocol, such as handover signaling. ----------- ----------- Proposal 3: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified to utilize a reliable transport protocol as a default, unreliable transport MAY also be optionally allowed. Recognizing that context transfer may be crucial for successful handover, the context transfer protocol must specify operation on a default reliable transport. The context transfer protocol may optionally allow transfer on unreliable transport. 5.2.2 The context transfer protocol MUST run directly on top of a transport protocol. Context transfer within another application layer protocol MUST NOT be allowed. In order to preserve the unity of context transport across all feature applications, context transfer must run directly on top of a transport protocol. Running context transfer as an option on another application layer protocol is prohibited. ----------- _______________________________________________ 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 Aug 13 11:27: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 LAA16212 for ; Tue, 13 Aug 2002 11:27:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16296; Tue, 13 Aug 2002 11:22:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16267 for ; Tue, 13 Aug 2002 11:22:37 -0400 (EDT) Received: from bsn-mail-01.bstormnetworks.com ([209.11.156.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15959 for ; Tue, 13 Aug 2002 11:21:18 -0400 (EDT) Subject: RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5 .2 From: Pat Calhoun To: Nakhjiri Madjid-MNAKHJI1 Cc: "'James Kempf'" , seamoby@ietf.org In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B08AD570D@IL27EXM10.cig.mot.com> References: <35DBB8B7AC89D4118E98009027B1009B08AD570D@IL27EXM10.cig.mot.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 13 Aug 2002 08:22:10 -0700 Message-Id: <1029252130.10616.27.camel@dhcp-229-243> Mime-Version: 1.0 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 Wonder which order I should be looking at your e-mails... is the last of the two your preferred response? Seriously, the issue with 1 & 2 is that they are non-requirements... not specifying a transport, and saying that anything could be used are basically the same. Although this may be fine, and we can try to push this through, this is the state we were at when Alison informed us that we would be getting some help from the transport directorate (which, of course, never happened). So if folks prefer 2, let's try it and see what happens. At this point, there isn't much to lose :( PatC On Tue, 2002-08-13 at 08:12, Nakhjiri Madjid-MNAKHJI1 wrote: > Disagree with 1 and 3. > Agree with 2. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, August 12, 2002 6:22 PM > To: seamoby@ietf.org > Subject: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 > > > The following are proposals for Section 5.2. Please indicate which proposal > you > AGREE with (if any), and which proposals you DISAGREE with. Please *only* > indicate AGREE with only one proposal. > > ----------- > Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the > requirements. > ----------- > > ----------- > Proposal 2: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer > transport. > > 5.2.1 The context transfer protocol MUST be specified so that it is > independent of the underlying transport. > > Recognizing that the transport characteristics for context > transfer > will depend on the particular application, it should be possible > to > transfer context directly on top of reliable transports, such as > TCP > or SCTP, unreliable transports, such as UDP, or as an option or > extension on another protocol, such as handover signaling. > > ----------- > > ----------- > Proposal 3: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer > transport. > > 5.2.1 The context transfer protocol MUST be specified to utilize a > reliable > transport protocol as a default, unreliable transport MAY > also be > optionally allowed. > > Recognizing that context transfer may be crucial for > successful > handover, the context transfer protocol must specify > operation > on a default reliable transport. The context transfer protocol > may > optionally allow transfer on unreliable transport. > > 5.2.2 The context transfer protocol MUST run directly on top of a > transport > protocol. Context transfer within another application layer > protocol MUST NOT be allowed. > > In order to preserve the unity of context transport across all > feature applications, context transfer must run directly on > top of > a transport protocol. Running context transfer as an option on > another application layer protocol is prohibited. > ----------- > > > > > > > _______________________________________________ > 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 daemon@optimus.ietf.org Tue Aug 13 11:27: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 LAA16218 for ; Tue, 13 Aug 2002 11:27:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16670 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 11:28:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16296; Tue, 13 Aug 2002 11:22:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16267 for ; Tue, 13 Aug 2002 11:22:37 -0400 (EDT) Received: from bsn-mail-01.bstormnetworks.com ([209.11.156.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15959 for ; Tue, 13 Aug 2002 11:21:18 -0400 (EDT) Subject: RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5 .2 From: Pat Calhoun To: Nakhjiri Madjid-MNAKHJI1 Cc: "'James Kempf'" , seamoby@ietf.org In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B08AD570D@IL27EXM10.cig.mot.com> References: <35DBB8B7AC89D4118E98009027B1009B08AD570D@IL27EXM10.cig.mot.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 13 Aug 2002 08:22:10 -0700 Message-Id: <1029252130.10616.27.camel@dhcp-229-243> Mime-Version: 1.0 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 Wonder which order I should be looking at your e-mails... is the last of the two your preferred response? Seriously, the issue with 1 & 2 is that they are non-requirements... not specifying a transport, and saying that anything could be used are basically the same. Although this may be fine, and we can try to push this through, this is the state we were at when Alison informed us that we would be getting some help from the transport directorate (which, of course, never happened). So if folks prefer 2, let's try it and see what happens. At this point, there isn't much to lose :( PatC On Tue, 2002-08-13 at 08:12, Nakhjiri Madjid-MNAKHJI1 wrote: > Disagree with 1 and 3. > Agree with 2. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, August 12, 2002 6:22 PM > To: seamoby@ietf.org > Subject: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 > > > The following are proposals for Section 5.2. Please indicate which proposal > you > AGREE with (if any), and which proposals you DISAGREE with. Please *only* > indicate AGREE with only one proposal. > > ----------- > Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the > requirements. > ----------- > > ----------- > Proposal 2: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer > transport. > > 5.2.1 The context transfer protocol MUST be specified so that it is > independent of the underlying transport. > > Recognizing that the transport characteristics for context > transfer > will depend on the particular application, it should be possible > to > transfer context directly on top of reliable transports, such as > TCP > or SCTP, unreliable transports, such as UDP, or as an option or > extension on another protocol, such as handover signaling. > > ----------- > > ----------- > Proposal 3: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer > transport. > > 5.2.1 The context transfer protocol MUST be specified to utilize a > reliable > transport protocol as a default, unreliable transport MAY > also be > optionally allowed. > > Recognizing that context transfer may be crucial for > successful > handover, the context transfer protocol must specify > operation > on a default reliable transport. The context transfer protocol > may > optionally allow transfer on unreliable transport. > > 5.2.2 The context transfer protocol MUST run directly on top of a > transport > protocol. Context transfer within another application layer > protocol MUST NOT be allowed. > > In order to preserve the unity of context transport across all > feature applications, context transfer must run directly on > top of > a transport protocol. Running context transfer as an option on > another application layer protocol is prohibited. > ----------- > > > > > > > _______________________________________________ > 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 Aug 13 12:06: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 MAA18020 for ; Tue, 13 Aug 2002 12:06:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20176; Tue, 13 Aug 2002 12:03:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20149 for ; Tue, 13 Aug 2002 12:03:05 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17767 for ; Tue, 13 Aug 2002 12:01:43 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA26986 for ; Tue, 13 Aug 2002 09:02:59 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA13969 for ; Tue, 13 Aug 2002 09:02:55 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Tue, 13 Aug 2002 11:02:55 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD570F@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5 .2 Date: Tue, 13 Aug 2002 11:02:38 -0500 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 Pat, Please see embedded replies. BR, Madjid -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Tuesday, August 13, 2002 10:22 AM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5 .2 Wonder which order I should be looking at your e-mails... is the last of the two your preferred response? Madjid>>Well, I responded to 3 different issues in 3 different emails, maybe I need another coffee, did I miss something ? :) Seriously, the issue with 1 & 2 is that they are non-requirements... not specifying a transport, and saying that anything could be used are basically the same. Although this may be fine, and we can try to push this through, this is the state we were at when Alison informed us that we would be getting some help from the transport directorate (which, of course, never happened). Madjid>>I thought we were supposed to pick one, without arguments, so I am trying to be a good citizen :) There are things in 3 that are not acceptable, that's all. "The context transfer protocol MUST run directly on top of a transport protocol." rules out tying CT and MIP signaling for efficiency. I don't think anybody believes that you can use say TCP for all features, and using UDP when you need reliability can be pointless overhead. So if folks prefer 2, let's try it and see what happens. At this point, there isn't much to lose :( PatC On Tue, 2002-08-13 at 08:12, Nakhjiri Madjid-MNAKHJI1 wrote: > Disagree with 1 and 3. > Agree with 2. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, August 12, 2002 6:22 PM > To: seamoby@ietf.org > Subject: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 > > > The following are proposals for Section 5.2. Please indicate which proposal > you > AGREE with (if any), and which proposals you DISAGREE with. Please *only* > indicate AGREE with only one proposal. > > ----------- > Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the > requirements. > ----------- > > ----------- > Proposal 2: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer > transport. > > 5.2.1 The context transfer protocol MUST be specified so that it is > independent of the underlying transport. > > Recognizing that the transport characteristics for context > transfer > will depend on the particular application, it should be possible > to > transfer context directly on top of reliable transports, such as > TCP > or SCTP, unreliable transports, such as UDP, or as an option or > extension on another protocol, such as handover signaling. > > ----------- > > ----------- > Proposal 3: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer > transport. > > 5.2.1 The context transfer protocol MUST be specified to utilize a > reliable > transport protocol as a default, unreliable transport MAY > also be > optionally allowed. > > Recognizing that context transfer may be crucial for > successful > handover, the context transfer protocol must specify > operation > on a default reliable transport. The context transfer protocol > may > optionally allow transfer on unreliable transport. > > 5.2.2 The context transfer protocol MUST run directly on top of a > transport > protocol. Context transfer within another application layer > protocol MUST NOT be allowed. > > In order to preserve the unity of context transport across all > feature applications, context transfer must run directly on > top of > a transport protocol. Running context transfer as an option on > another application layer protocol is prohibited. > ----------- > > > > > > > _______________________________________________ > 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 daemon@optimus.ietf.org Tue Aug 13 12:06: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 MAA18028 for ; Tue, 13 Aug 2002 12:06:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20277 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 12:07:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20176; Tue, 13 Aug 2002 12:03:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20149 for ; Tue, 13 Aug 2002 12:03:05 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17767 for ; Tue, 13 Aug 2002 12:01:43 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA26986 for ; Tue, 13 Aug 2002 09:02:59 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA13969 for ; Tue, 13 Aug 2002 09:02:55 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Tue, 13 Aug 2002 11:02:55 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD570F@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5 .2 Date: Tue, 13 Aug 2002 11:02:38 -0500 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 Pat, Please see embedded replies. BR, Madjid -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Tuesday, August 13, 2002 10:22 AM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5 .2 Wonder which order I should be looking at your e-mails... is the last of the two your preferred response? Madjid>>Well, I responded to 3 different issues in 3 different emails, maybe I need another coffee, did I miss something ? :) Seriously, the issue with 1 & 2 is that they are non-requirements... not specifying a transport, and saying that anything could be used are basically the same. Although this may be fine, and we can try to push this through, this is the state we were at when Alison informed us that we would be getting some help from the transport directorate (which, of course, never happened). Madjid>>I thought we were supposed to pick one, without arguments, so I am trying to be a good citizen :) There are things in 3 that are not acceptable, that's all. "The context transfer protocol MUST run directly on top of a transport protocol." rules out tying CT and MIP signaling for efficiency. I don't think anybody believes that you can use say TCP for all features, and using UDP when you need reliability can be pointless overhead. So if folks prefer 2, let's try it and see what happens. At this point, there isn't much to lose :( PatC On Tue, 2002-08-13 at 08:12, Nakhjiri Madjid-MNAKHJI1 wrote: > Disagree with 1 and 3. > Agree with 2. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, August 12, 2002 6:22 PM > To: seamoby@ietf.org > Subject: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 > > > The following are proposals for Section 5.2. Please indicate which proposal > you > AGREE with (if any), and which proposals you DISAGREE with. Please *only* > indicate AGREE with only one proposal. > > ----------- > Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the > requirements. > ----------- > > ----------- > Proposal 2: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer > transport. > > 5.2.1 The context transfer protocol MUST be specified so that it is > independent of the underlying transport. > > Recognizing that the transport characteristics for context > transfer > will depend on the particular application, it should be possible > to > transfer context directly on top of reliable transports, such as > TCP > or SCTP, unreliable transports, such as UDP, or as an option or > extension on another protocol, such as handover signaling. > > ----------- > > ----------- > Proposal 3: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer > transport. > > 5.2.1 The context transfer protocol MUST be specified to utilize a > reliable > transport protocol as a default, unreliable transport MAY > also be > optionally allowed. > > Recognizing that context transfer may be crucial for > successful > handover, the context transfer protocol must specify > operation > on a default reliable transport. The context transfer protocol > may > optionally allow transfer on unreliable transport. > > 5.2.2 The context transfer protocol MUST run directly on top of a > transport > protocol. Context transfer within another application layer > protocol MUST NOT be allowed. > > In order to preserve the unity of context transport across all > feature applications, context transfer must run directly on > top of > a transport protocol. Running context transfer as an option on > another application layer protocol is prohibited. > ----------- > > > > > > > _______________________________________________ > 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 Aug 13 14:44: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 OAA13288 for ; Tue, 13 Aug 2002 14:44:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27352; Tue, 13 Aug 2002 14:36:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27323 for ; Tue, 13 Aug 2002 14:36:22 -0400 (EDT) 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 OAA12960 for ; Tue, 13 Aug 2002 14:35:03 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA27357; Tue, 13 Aug 2002 11:35:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7DIZnW06223; Tue, 13 Aug 2002 11:35:50 -0700 X-mProtect: <200208131835> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdf3Cr8i; Tue, 13 Aug 2002 11:35:48 PDT Message-ID: <3D595184.8AA83CF3@iprg.nokia.com> Date: Tue, 13 Aug 2002 11:35:48 -0700 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: seamoby@ietf.org Subject: Re: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 References: <004e01c24257$d43471f0$296015ac@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 Agree with proposal 2 Disagree with 3. -Rajeev James Kempf wrote: > The following are proposals for Section 5.2. Please indicate which proposal you > AGREE with (if any), and which proposals you DISAGREE with. Please *only* > indicate AGREE with only one proposal. > > ----------- > Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the > requirements. > ----------- > > ----------- > Proposal 2: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer transport. > > 5.2.1 The context transfer protocol MUST be specified so that it is > independent of the underlying transport. > > Recognizing that the transport characteristics for context transfer > will depend on the particular application, it should be possible to > transfer context directly on top of reliable transports, such as TCP > or SCTP, unreliable transports, such as UDP, or as an option or > extension on another protocol, such as handover signaling. > > ----------- > > ----------- > Proposal 3: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer transport. > > 5.2.1 The context transfer protocol MUST be specified to utilize a reliable > transport protocol as a default, unreliable transport MAY also be > optionally allowed. > > Recognizing that context transfer may be crucial for successful > handover, the context transfer protocol must specify operation > on a default reliable transport. The context transfer protocol may > optionally allow transfer on unreliable transport. > > 5.2.2 The context transfer protocol MUST run directly on top of a transport > protocol. Context transfer within another application layer > protocol MUST NOT be allowed. > > In order to preserve the unity of context transport across all > feature applications, context transfer must run directly on top of > a transport protocol. Running context transfer as an option on > another application layer protocol is prohibited. > ----------- > > _______________________________________________ > 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 daemon@optimus.ietf.org Tue Aug 13 14:44: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 OAA13295 for ; Tue, 13 Aug 2002 14:44:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27756 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 14:45:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27352; Tue, 13 Aug 2002 14:36:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27323 for ; Tue, 13 Aug 2002 14:36:22 -0400 (EDT) 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 OAA12960 for ; Tue, 13 Aug 2002 14:35:03 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA27357; Tue, 13 Aug 2002 11:35:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7DIZnW06223; Tue, 13 Aug 2002 11:35:50 -0700 X-mProtect: <200208131835> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdf3Cr8i; Tue, 13 Aug 2002 11:35:48 PDT Message-ID: <3D595184.8AA83CF3@iprg.nokia.com> Date: Tue, 13 Aug 2002 11:35:48 -0700 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: seamoby@ietf.org Subject: Re: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 References: <004e01c24257$d43471f0$296015ac@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 Agree with proposal 2 Disagree with 3. -Rajeev James Kempf wrote: > The following are proposals for Section 5.2. Please indicate which proposal you > AGREE with (if any), and which proposals you DISAGREE with. Please *only* > indicate AGREE with only one proposal. > > ----------- > Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the > requirements. > ----------- > > ----------- > Proposal 2: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer transport. > > 5.2.1 The context transfer protocol MUST be specified so that it is > independent of the underlying transport. > > Recognizing that the transport characteristics for context transfer > will depend on the particular application, it should be possible to > transfer context directly on top of reliable transports, such as TCP > or SCTP, unreliable transports, such as UDP, or as an option or > extension on another protocol, such as handover signaling. > > ----------- > > ----------- > Proposal 3: Replace Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context transfer transport. > > 5.2.1 The context transfer protocol MUST be specified to utilize a reliable > transport protocol as a default, unreliable transport MAY also be > optionally allowed. > > Recognizing that context transfer may be crucial for successful > handover, the context transfer protocol must specify operation > on a default reliable transport. The context transfer protocol may > optionally allow transfer on unreliable transport. > > 5.2.2 The context transfer protocol MUST run directly on top of a transport > protocol. Context transfer within another application layer > protocol MUST NOT be allowed. > > In order to preserve the unity of context transport across all > feature applications, context transfer must run directly on top of > a transport protocol. Running context transfer as an option on > another application layer protocol is prohibited. > ----------- > > _______________________________________________ > 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 Aug 13 14:45: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 OAA13331 for ; Tue, 13 Aug 2002 14:45:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27478; Tue, 13 Aug 2002 14:39:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27451 for ; Tue, 13 Aug 2002 14:39:42 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13057 for ; Tue, 13 Aug 2002 14:38:22 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DIck518694; Tue, 13 Aug 2002 14:38:47 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 14:38:46 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4CA0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: "'seamoby@ietf.org'" Subject: Recall: [Seamoby] New Section 5.8 - Requirements on Feature Conte xt Specifications Date: Tue, 13 Aug 2002 14:38:42 -0400 Expiry-Date: Thu, 15 Aug 2002 14:35:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C242F8.A5BFDD54" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C242F8.A5BFDD54 Content-Type: text/plain Kenward, Gary [WDLN2:AN10:EXCH] would like to recall the message, "[Seamoby] New Section 5.8 - Requirements on Feature Context Specifications". ------_=_NextPart_001_01C242F8.A5BFDD54 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Recall: [Seamoby] New Section 5.8 - Requirements on Feature = Context Specifications

Kenward, Gary [WDLN2:AN10:EXCH] would like to recall = the message, "[Seamoby] New Section 5.8 - Requirements on Feature = Context   Specifications".

------_=_NextPart_001_01C242F8.A5BFDD54-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 13 14:45: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 OAA13336 for ; Tue, 13 Aug 2002 14:45:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27774 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 14:46:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27478; Tue, 13 Aug 2002 14:39:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27451 for ; Tue, 13 Aug 2002 14:39:42 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13057 for ; Tue, 13 Aug 2002 14:38:22 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DIck518694; Tue, 13 Aug 2002 14:38:47 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 14:38:46 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4CA0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: "'seamoby@ietf.org'" Subject: Recall: [Seamoby] New Section 5.8 - Requirements on Feature Conte xt Specifications Date: Tue, 13 Aug 2002 14:38:42 -0400 Expiry-Date: Thu, 15 Aug 2002 14:35:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C242F8.A5BFDD54" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C242F8.A5BFDD54 Content-Type: text/plain Kenward, Gary [WDLN2:AN10:EXCH] would like to recall the message, "[Seamoby] New Section 5.8 - Requirements on Feature Context Specifications". ------_=_NextPart_001_01C242F8.A5BFDD54 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Recall: [Seamoby] New Section 5.8 - Requirements on Feature = Context Specifications

Kenward, Gary [WDLN2:AN10:EXCH] would like to recall = the message, "[Seamoby] New Section 5.8 - Requirements on Feature = Context   Specifications".

------_=_NextPart_001_01C242F8.A5BFDD54-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 13 14: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 OAA13371 for ; Tue, 13 Aug 2002 14:45:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27600; Tue, 13 Aug 2002 14:41:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27534 for ; Tue, 13 Aug 2002 14:41:05 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13126 for ; Tue, 13 Aug 2002 14:39:45 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DIeF518793; Tue, 13 Aug 2002 14:40:15 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 14:40:15 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4CA1@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Tue, 13 Aug 2002 14:40:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C242F8.A5E602F4" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C242F8.A5E602F4 Content-Type: text/plain; charset="iso-8859-1" Charlie: > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: August 12, 2002 22:49 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > Continuing... > > Gary Kenward wrote: > > > I agree. TCP has limitations for short bursts of traffic such as CT. > > *Except* for the cases of an ad-hoc network, or a network > with mobile > > routers, I do not see any reason why a TCP connection > cannot be simply > > > > opened and kept open. > > I agree this would be possible, and would provide > reasonable performance in a lot of cases. It would > penalize mobile nodes moving to "uninitialized" > access routers that do not need reliable transfers, > and for that reason seems to be unnecessarily heavy > handed. So, I'd say it's not the best approach. > I don't understand the concept of an "uninitialized access router". Is this a router at the north pole that few people roam within range of? Roaming happens between adjacent cells. If there is activity in a cell, there's likely to be roaming. Making it a condition that an AR have an open TCP connection to it's neighbour for it to support roaming is not burdensome. It's the same as saying that the AR have the various capabilities to support roaming. > > See above. Any overhead introduced during a handover takes us away > > from seamlessness. > > > > And so, following your logic, I question the rational with > doing CARD > > => > > CT => handover with a video stream. > > How about "Handover + CT"? That would work. How about CT => handover, that would work better :-) > > > > The actual requirement for some contexts is low latency, not > > > separate transports. The other actual requirement (for other > > > contexts) is reliability (again, not separate > transports). I do not > > > > > have confidence that TCP can meet _both_ requirements. > > > > You are presuming here that the handover can proceed without the > > second context. > > Not exactly. In my opinion, we MUST arrange it so > that all handovers can complete even if all context > transfers fail. Successful context transfers will have > the effect of improving performance. > > Thus, one effect of this is that, yes, the handover could > complete without the second (or any other) context. Agreed. But it will not be true in all cases. Consider: should security context transfer be timely or reliable? Some might have a problem with it being unreliable. However, allowing forwarding to proceed at the new AR without security ct because it is being transferred with a reliable transport is almost the same as security ct being unreliable. Note: this is the point we came to during the last transport requirements discussion. So much depends on what the feature contexts each might require, and under what conditions. Since the working group has chosen not to work on the feature context requirements, yet, no new information is available. > > > I have a feeling, a strong feeling that this is all moot. I do not > > know of any context that can be transferred unreliably - that is, > > there has to be a reasonable assurance that CT will succeed in order > > for it to "enhance" handover. If a CT fails as a consequence of an > > unrealizable transport being used, what is the result? > > How about header compression? If the state does > not make it, then it can be re-established. Sure. Not seamless though. Particularly if the compression is not ROHC. In truth, everything can be re-established. The trick for establishing seamlessness is to avoid this time consuming activities. > > How about QoS? If the state does not make it, the > mobile node could renegotiate. > > In fact, I think this is true for _all_ contexts: if the > transfer fails, the mobile node has to be robust > enough to renegotiate, re-establish, or request > retransmission of data. See above. It's all relative: performance gain relative to cost. If ct provides seamlessness 50% of the time, and the rest of the time some renegotiation goes on, then it's not worth implementing (users are typically conditioned by the exception, not the rule, and so the frequency of seamlessness may probably have to be as high as 80-90% to achieve customer satisfaction with the service. Personally, I think it can, and should be higher). > > > By reasonable assurance, I go back to what I stated in > reply to James: > > > > handovers will fail. However, handovers failures due to CT failures > > must not be relatively insignificant (e.g. <<1%). > > It's probably a great goal, but I can't see why you would > want to restrict context transfers to only those scenarios > offering high reliability. Do you mean reliability of handover? Reliability of handover is not the same as reliability of the bearer packet transport. Reliability of handover impacts customer perception of a smoothly operating, dependable, predicable service. In truth, above a lower limit, consistency in handover performance is more important then maximization (e.g. variance in performance is more noticeable and irritating to the user). From a personal perspective again (for I have not seen any human factors studies on the subject), I believe that a successful wireless offering means that the user receives a consistent, predictable communications service, and does not experience *any* handovers (but perhaps, the *rare* drop of a session). The user should not have to care about "cell boundaries" (I'm talking about real users, not techies at IETF conferences :-} ). > > > > > Are you really willing to make the restriction that [seamoby] > > > only deals with such networks that satisfy this criterion? > > > > It would be preferable if we had a protocol that was both fast > > and reliable - e.g. one that optimized for very short bursts of > > data. However, we (seamoby) are not going to be defining that > > protocol, > > as far as I can tell. > > > > I'm still waiting for a practical description of a wired network or > > group > > of wired networks where this "restriction" is impractical. For a > > handover > > to occur seamlessly between two networks, many, many facilities have > > to > > be pre-established. It would seem to me that requiring a > tunnel for CT > > > > between the two is a very small additional requirement. > > Your statement is not true for the prototype implementation > we have. Requiring another tunnel for CT is just not > necessary, and isn't such a trivial requirement anyway. Well, I guess that I cannot speak to your implementation. It might help if you explained to the wg why establishing and maintaining a TCP connection between two ARs is non-trivial for your implementation. Nothing is more useful then real implementation experience. > > > Regardless, the idea of defining an ack/retx capability on top of > > UDP/ICMP > > is still transport protocol design. Arguably, TCP is simply UDP with > > ack/retx > > and window flow control (and a pile of other stuff designed > to make it > > all > > work in various situations). > > A pile here, a pile there, and pretty soon you're talking > about real protocol. Yup. So either we are using an existing protocol, with no modifications, or we are designing a new transport protocol. Talking about putting ack/retx on UDP/ICMP is miss-leading, it would be a new transport protocol. > > > > > Why not simply put all feature contexts into one transport > > exchange? > > > > Which hopefully means, one IP packet. > > > > > > That's what my "program" does! Please have another look. > > > > No it doesn't. It puts each context into it's own transport > protocol. > > That's > > not, in my view, one transport exchange (each protocol sets up it's > > own > > exchange), and not one IP packet, in anyone's view. > > Well, with apologies to others, here is what I said: > > > 1. Find the most urgent context. Encapsulate it using the transport > > it specifies (which won't be TCP, I reckon, for extremely urgent > > contexts). Fill the rest of the context feature data structure > > with the most urgent other contexts that will fit, and which are > > compatible with the chosen transport. If the chosen transport > > is not a reliable transport, schedule a retransmission if any > > context transfer requires acknowledgement. > > The third sentence refutes your characterization. How many > transports do you think there are, anyway? "Encapsulate it using the transport it specifies". ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Note: one thing that bothers me about this discussion is that idea that TCP is inherently slow. On a good link (i.e. just about any wired link in a well engineered network) and with no congestion in any of the nodes (which is easily done using Diff Serv and traffic engineering, for example; and, just how many routers will be between two neighbouring ARs? one? two?). An established TCP connection is just as fast as UDP. > > Typically, there would be one packet per transport type, and > that's unlikely to be more than two packets. But I still do not see the advantage. In one scenario you have feature contexts being transferred over individual transports, in another (my ideal) you have all features multiplexed onto one packet, and travelling to the destination AR in one packet. With a "permanent" TCP connection to the new AR, the transit time is the same as UDP/ICMP. If the packet gets "lost" and handover is in progress, then the new AR has to decide if it should wait for the re-transmission, begin forwarding the MNs packets, re-negotiate services, or drop the session. *IF* a packet gets lost - do you think it is possible to keep the packet loss probability in a well engineered network to below 1%? If so, then the last three options are probably appropriate options (1 in 100 handovers require re-negotiation, perhaps while the forwarding proceeds with degraded service). I think that .001% packet lost probability is easy to achieve - this is not transport across the global internet. BTW: I am not a proponent of TCP for the transport. Indeed, if you follow the above argument, and loss rates of <1% are easily achievable, then UDP should be reliable enough. > > > > Good to know. But then, I am confused over the relevance of > HI/HAck to > > > > the discussion. > > They are one good place to put context feature data, but > not the only good place. Good is subjective. > > Put another way, if the old access router is already sending > HI to the new access router, there's no reason that urgent > context feature data should not be included with the base > handover information. And the reason for piggy-backing the information is to save one packet transmission per handover? At the cost of having feature ct's occur sequentially and asynchronously? It does not seem worth the trouble, honestly. > > > I guess I shall remain confused. You introduced HI/HAck as > a mechanism > > > > for CT. I don't see the relevance. If the *only* context I have to > > transfer fits into HI/HAck and HI/HAck provides the necessary > > transport > > characteristics, then yes, it would be nice if CT could run over > > Hi/HAck. > > That's all I meant. > > > Does this mean that CT should be tailored so that it runs over > > Hi/HAck? > > Of course not -- depending on what you meant by "tailored". > I think it should be convenient to do it either way. > > > I guess it should be shown that tailoring CT for this purpose is > > significantly > > superior then running CT in parallel (or before, as with in > > "proactively"). > > Two packets takes longer than one. Exactly. So you agree ct is faster sent over one transport packet. > > > Onwards and downwards, > > Gary > > Somehow that means you are unlikely to welcome this response. > But I'm trying to be constructive. No, not at all. Just being cynical about the state of the world. It was not a comment on our conversation. Sorry for the misconception. And besides, downwards can be a good thing... I think that, as with the last go round, we really need to get either a ct solution out for everyone to debate, or we need to get some feature context transport requirements analysis out for everyone to ponder and debate. All I want, is for the requirement wording to be changed to indicate that goal is to minimize the complexity of the transport, with one transport protocol for ct being a desirable objective. Cheerio, Gary > > Regards, > Charlie P. > > > ------_=_NextPart_001_01C242F8.A5E602F4 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

Charlie:

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 12, 2002 22:49
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> Continuing...
>
> Gary Kenward wrote:
>
> > I agree. TCP has limitations for short bursts of traffic such as CT.
> > *Except* for the cases of an ad-hoc network, or a network
> with mobile
> > routers, I do not see any reason why a TCP connection
> cannot be simply
> >
> > opened and kept open.
>
> I agree this would be possible, and would provide
> reasonable performance in a lot of cases.  It would
> penalize mobile nodes moving to "uninitialized"
> access routers that do not need reliable transfers,
> and for that reason seems to be unnecessarily heavy
> handed.  So, I'd say it's not the best approach.
>

I don't understand the concept of an "uninitialized access router".
Is this a router at the north pole that few people roam within range of?

Roaming happens between adjacent cells. If there is activity in a cell,
there's likely to be roaming. Making it a condition that an AR have
an open TCP connection to it's neighbour for it to support roaming is
not burdensome. It's the same as saying that the AR have the various capabilities
to support roaming.

> > See above. Any overhead introduced during a handover takes us away
> > from seamlessness.
> >
> > And so, following your logic, I question the rational with
> doing CARD
> > =>
> > CT => handover with a video stream.
>
> How about "Handover + CT"?  That would work.

How about CT => handover, that would work better :-)

>
> > > The actual requirement for some contexts is low latency, not
> > > separate transports.  The other actual requirement (for other
> > > contexts) is reliability (again, not separate
> transports).  I do not
> >
> > > have confidence that TCP can meet _both_ requirements.
> >
> > You are presuming here that the handover can proceed without the
> > second context.
>
> Not exactly.  In my opinion, we MUST arrange it so
> that all handovers can complete even if all context
> transfers fail.  Successful context transfers will have
> the effect of improving performance.
>
> Thus, one effect of this is that, yes, the handover could
> complete without the second (or any other) context.

Agreed. But it will not be true in all cases. Consider: should security
context transfer be timely or reliable? Some might have a problem with it
being unreliable. However, allowing forwarding to proceed at the
new AR without security ct because it is being transferred with a reliable
transport is almost the same as security ct being unreliable.

Note: this is the point we came to during the last transport requirements
discussion. So much depends on what the feature contexts each might require,
and under what conditions. Since the working group has chosen not to work on
the feature context requirements, yet, no new information is available.

>
> > I have a feeling, a strong feeling that this is all moot. I do not
> > know of any context that can be transferred unreliably - that is,
> > there has to be a reasonable assurance that CT will succeed in order
> > for it to "enhance" handover. If a CT fails as a consequence of an
> > unrealizable transport being used, what is the result?
>
> How about header compression?  If the state does
> not make it, then it can be re-established.

Sure. Not seamless though. Particularly if the compression is
not ROHC. In truth, everything can be re-established. The trick
for establishing seamlessness is to avoid this time consuming
activities.

>
> How about QoS?  If the state does not make it, the
> mobile node could renegotiate.
>
> In fact, I think this is true for _all_ contexts: if the
> transfer fails, the mobile node has to be robust
> enough to renegotiate, re-establish, or request
> retransmission of data.

See above.

It's all relative: performance gain relative to cost. If ct provides
seamlessness 50% of the time, and the rest of the time some renegotiation
goes on, then it's not worth implementing (users are typically conditioned
by the exception, not the rule, and so the frequency of seamlessness may
probably have to be as high as 80-90% to achieve customer satisfaction with
the service. Personally, I think it can, and should be higher).

>
> > By reasonable assurance, I go back to what I stated in
> reply to James:
> >
> > handovers will fail. However, handovers failures due to CT failures
> > must not be relatively insignificant (e.g. <<1%).
>
> It's probably a great goal, but I can't see why you would
> want to restrict context transfers to only those scenarios
> offering high reliability.

Do you mean reliability of handover? Reliability of handover is not
the same as reliability of the bearer packet transport. Reliability of
handover impacts customer perception of a smoothly operating, dependable,
predicable service. In truth, above a lower limit, consistency in handover
performance is more important then maximization (e.g. variance in performance
is more noticeable and irritating to the user).

From a personal perspective again (for I have not seen any human factors studies
on the subject), I believe that a successful wireless offering means that the
user receives a consistent, predictable communications service, and does not
experience *any* handovers (but perhaps, the *rare* drop of a session). The
user should not have to care about "cell boundaries" (I'm talking about real
users, not techies at IETF conferences :-} ).
>
>
> > > Are you really willing to make the restriction that [seamoby]
> > > only deals with such networks that satisfy this criterion?
> >
> > It would be preferable if we had a protocol that was both fast
> > and reliable - e.g. one that optimized for very short bursts of
> > data. However, we (seamoby) are not going to be defining that
> > protocol,
> > as far as I can tell.
> >
> > I'm still waiting for a practical description of a wired network or
> > group
> > of wired networks where this "restriction" is impractical. For a
> > handover
> > to occur seamlessly between two networks, many, many facilities have
> > to
> > be pre-established. It would seem to me that requiring a
> tunnel for CT
> >
> > between the two is a very small additional requirement.
>
> Your statement is not true for the prototype implementation
> we have.  Requiring another tunnel for CT is just not
> necessary, and isn't such a trivial requirement anyway.

Well, I guess that I cannot speak to your implementation. It might help
if you explained to the wg why establishing and maintaining a TCP connection
between two ARs is non-trivial for your implementation. Nothing is more
useful then real implementation experience.

>
> > Regardless, the idea of defining an ack/retx capability on top of
> > UDP/ICMP
> > is still transport protocol design. Arguably, TCP is simply UDP with
> > ack/retx
> > and window flow control (and a pile of other stuff designed
> to make it
> > all
> > work in various situations).
>
> A pile here, a pile there, and pretty soon you're talking
> about real protocol.

Yup. So either we are using an existing protocol, with no modifications, or we
are designing a new transport protocol. Talking about putting ack/retx
on UDP/ICMP is miss-leading, it would be a new transport protocol.

>
> > > > Why not simply put all feature contexts into one transport
> > exchange?
> > > > Which hopefully means, one IP packet.
> > >
> > > That's what my "program" does!  Please have another look.
> >
> > No it doesn't. It puts each context into it's own transport
> protocol.
> > That's
> > not, in my view, one transport exchange (each protocol sets up it's
> > own
> > exchange), and not one IP packet, in anyone's view.
>
> Well, with apologies to others, here is what I said:
>
> > 1. Find the most urgent context.  Encapsulate it using the transport
> >    it specifies (which won't be TCP, I reckon, for extremely urgent
> >    contexts).   Fill the rest of the context feature data structure
> >    with the most urgent other contexts that will fit, and which are
> >    compatible with the chosen transport.  If the chosen transport
> >    is not a reliable transport, schedule a retransmission if any
> >    context transfer requires acknowledgement.
>
> The third sentence refutes your characterization.  How many
> transports do you think there are, anyway?

"Encapsulate it using the transport it specifies".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note: one thing that bothers me about this discussion is that idea that
TCP is inherently slow. On a good link (i.e. just about any
wired link in a well engineered network) and with no congestion in any
of the nodes (which is easily done using Diff Serv and traffic engineering,
for example; and, just how many routers will be between two neighbouring ARs?
one? two?). An established TCP connection is just as fast as UDP.
>
> Typically, there would be one packet per transport type, and
> that's unlikely to be more than two packets.

But I still do not see the advantage. In one scenario you have
feature contexts being transferred over individual transports,
in another (my ideal) you have all features multiplexed onto one
packet, and travelling to the destination AR in one packet. With
a "permanent" TCP connection to the new AR, the transit time is the
same as UDP/ICMP. If the packet gets "lost" and handover is in progress,
then the new AR has to decide if it should wait for the re-transmission,
begin forwarding the MNs packets, re-negotiate services, or drop the
session. *IF* a packet gets lost - do you think it is possible to
keep the packet loss probability in a well engineered network to below
1%? If so, then the last three options are probably appropriate options
(1 in 100 handovers require re-negotiation, perhaps while the forwarding
proceeds with degraded service). I think that .001% packet lost probability
is easy to achieve - this is not transport across the global internet.

BTW: I am not a proponent of TCP for the transport. Indeed, if you follow
the above argument, and loss rates of <1% are easily achievable, then
UDP should be reliable enough.

>
>
> > Good to know. But then, I am confused over the relevance of
> HI/HAck to
> >
> > the discussion.
>
> They are one good place to put context feature data, but
> not the only good place.

Good is subjective.

>
> Put another way, if the old access router is already sending
> HI to the new access router, there's no reason that urgent
> context feature data should not be included with the base
> handover information.

And the reason for piggy-backing the information is to save one
packet transmission per handover? At the cost of having feature
ct's occur sequentially and asynchronously? It does not seem
worth the trouble, honestly.

>
> > I guess I shall remain confused. You introduced HI/HAck as
> a mechanism
> >
> > for CT. I don't see the relevance. If the *only* context I have to
> > transfer fits into HI/HAck and HI/HAck provides the necessary
> > transport
> > characteristics, then yes, it would be nice if CT could run over
> > Hi/HAck.
>
> That's all I meant.
>
> > Does this mean that CT should be tailored so that it runs over
> > Hi/HAck?
>
> Of course not -- depending on what you meant by "tailored".
> I think it should be convenient to do it either way.
>
> > I guess it should be shown that tailoring CT for this purpose is
> > significantly
> > superior then running CT in parallel (or before, as with in
> > "proactively").
>
> Two packets takes longer than one.

Exactly. So you agree ct is faster sent over one transport packet.

>
> > Onwards and downwards,
> > Gary
>
> Somehow that means you are unlikely to welcome this response.
> But I'm trying to be constructive.

No, not at all. Just being cynical about the state of the world. It was
not a comment on our conversation. Sorry for the misconception. And besides,
downwards can be a good thing...

I think that, as with the last go round, we really need to get either
a ct solution out for everyone to debate, or we need to get some feature
context transport requirements analysis out for everyone to ponder and
debate.

All I want, is for the requirement wording to be changed to indicate that
goal is to minimize the complexity of the transport, with one transport
protocol for ct being a desirable objective.

Cheerio,
Gary

>
> Regards,
> Charlie P.
>
>
>

------_=_NextPart_001_01C242F8.A5E602F4-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 13 14: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 OAA13381 for ; Tue, 13 Aug 2002 14:45:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27813 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 14:46:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27600; Tue, 13 Aug 2002 14:41:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27534 for ; Tue, 13 Aug 2002 14:41:05 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13126 for ; Tue, 13 Aug 2002 14:39:45 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DIeF518793; Tue, 13 Aug 2002 14:40:15 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 14:40:15 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4CA1@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Tue, 13 Aug 2002 14:40:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C242F8.A5E602F4" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C242F8.A5E602F4 Content-Type: text/plain; charset="iso-8859-1" Charlie: > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: August 12, 2002 22:49 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on > Feature Context > Specifications > > > > Hello Gary, > > Continuing... > > Gary Kenward wrote: > > > I agree. TCP has limitations for short bursts of traffic such as CT. > > *Except* for the cases of an ad-hoc network, or a network > with mobile > > routers, I do not see any reason why a TCP connection > cannot be simply > > > > opened and kept open. > > I agree this would be possible, and would provide > reasonable performance in a lot of cases. It would > penalize mobile nodes moving to "uninitialized" > access routers that do not need reliable transfers, > and for that reason seems to be unnecessarily heavy > handed. So, I'd say it's not the best approach. > I don't understand the concept of an "uninitialized access router". Is this a router at the north pole that few people roam within range of? Roaming happens between adjacent cells. If there is activity in a cell, there's likely to be roaming. Making it a condition that an AR have an open TCP connection to it's neighbour for it to support roaming is not burdensome. It's the same as saying that the AR have the various capabilities to support roaming. > > See above. Any overhead introduced during a handover takes us away > > from seamlessness. > > > > And so, following your logic, I question the rational with > doing CARD > > => > > CT => handover with a video stream. > > How about "Handover + CT"? That would work. How about CT => handover, that would work better :-) > > > > The actual requirement for some contexts is low latency, not > > > separate transports. The other actual requirement (for other > > > contexts) is reliability (again, not separate > transports). I do not > > > > > have confidence that TCP can meet _both_ requirements. > > > > You are presuming here that the handover can proceed without the > > second context. > > Not exactly. In my opinion, we MUST arrange it so > that all handovers can complete even if all context > transfers fail. Successful context transfers will have > the effect of improving performance. > > Thus, one effect of this is that, yes, the handover could > complete without the second (or any other) context. Agreed. But it will not be true in all cases. Consider: should security context transfer be timely or reliable? Some might have a problem with it being unreliable. However, allowing forwarding to proceed at the new AR without security ct because it is being transferred with a reliable transport is almost the same as security ct being unreliable. Note: this is the point we came to during the last transport requirements discussion. So much depends on what the feature contexts each might require, and under what conditions. Since the working group has chosen not to work on the feature context requirements, yet, no new information is available. > > > I have a feeling, a strong feeling that this is all moot. I do not > > know of any context that can be transferred unreliably - that is, > > there has to be a reasonable assurance that CT will succeed in order > > for it to "enhance" handover. If a CT fails as a consequence of an > > unrealizable transport being used, what is the result? > > How about header compression? If the state does > not make it, then it can be re-established. Sure. Not seamless though. Particularly if the compression is not ROHC. In truth, everything can be re-established. The trick for establishing seamlessness is to avoid this time consuming activities. > > How about QoS? If the state does not make it, the > mobile node could renegotiate. > > In fact, I think this is true for _all_ contexts: if the > transfer fails, the mobile node has to be robust > enough to renegotiate, re-establish, or request > retransmission of data. See above. It's all relative: performance gain relative to cost. If ct provides seamlessness 50% of the time, and the rest of the time some renegotiation goes on, then it's not worth implementing (users are typically conditioned by the exception, not the rule, and so the frequency of seamlessness may probably have to be as high as 80-90% to achieve customer satisfaction with the service. Personally, I think it can, and should be higher). > > > By reasonable assurance, I go back to what I stated in > reply to James: > > > > handovers will fail. However, handovers failures due to CT failures > > must not be relatively insignificant (e.g. <<1%). > > It's probably a great goal, but I can't see why you would > want to restrict context transfers to only those scenarios > offering high reliability. Do you mean reliability of handover? Reliability of handover is not the same as reliability of the bearer packet transport. Reliability of handover impacts customer perception of a smoothly operating, dependable, predicable service. In truth, above a lower limit, consistency in handover performance is more important then maximization (e.g. variance in performance is more noticeable and irritating to the user). From a personal perspective again (for I have not seen any human factors studies on the subject), I believe that a successful wireless offering means that the user receives a consistent, predictable communications service, and does not experience *any* handovers (but perhaps, the *rare* drop of a session). The user should not have to care about "cell boundaries" (I'm talking about real users, not techies at IETF conferences :-} ). > > > > > Are you really willing to make the restriction that [seamoby] > > > only deals with such networks that satisfy this criterion? > > > > It would be preferable if we had a protocol that was both fast > > and reliable - e.g. one that optimized for very short bursts of > > data. However, we (seamoby) are not going to be defining that > > protocol, > > as far as I can tell. > > > > I'm still waiting for a practical description of a wired network or > > group > > of wired networks where this "restriction" is impractical. For a > > handover > > to occur seamlessly between two networks, many, many facilities have > > to > > be pre-established. It would seem to me that requiring a > tunnel for CT > > > > between the two is a very small additional requirement. > > Your statement is not true for the prototype implementation > we have. Requiring another tunnel for CT is just not > necessary, and isn't such a trivial requirement anyway. Well, I guess that I cannot speak to your implementation. It might help if you explained to the wg why establishing and maintaining a TCP connection between two ARs is non-trivial for your implementation. Nothing is more useful then real implementation experience. > > > Regardless, the idea of defining an ack/retx capability on top of > > UDP/ICMP > > is still transport protocol design. Arguably, TCP is simply UDP with > > ack/retx > > and window flow control (and a pile of other stuff designed > to make it > > all > > work in various situations). > > A pile here, a pile there, and pretty soon you're talking > about real protocol. Yup. So either we are using an existing protocol, with no modifications, or we are designing a new transport protocol. Talking about putting ack/retx on UDP/ICMP is miss-leading, it would be a new transport protocol. > > > > > Why not simply put all feature contexts into one transport > > exchange? > > > > Which hopefully means, one IP packet. > > > > > > That's what my "program" does! Please have another look. > > > > No it doesn't. It puts each context into it's own transport > protocol. > > That's > > not, in my view, one transport exchange (each protocol sets up it's > > own > > exchange), and not one IP packet, in anyone's view. > > Well, with apologies to others, here is what I said: > > > 1. Find the most urgent context. Encapsulate it using the transport > > it specifies (which won't be TCP, I reckon, for extremely urgent > > contexts). Fill the rest of the context feature data structure > > with the most urgent other contexts that will fit, and which are > > compatible with the chosen transport. If the chosen transport > > is not a reliable transport, schedule a retransmission if any > > context transfer requires acknowledgement. > > The third sentence refutes your characterization. How many > transports do you think there are, anyway? "Encapsulate it using the transport it specifies". ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Note: one thing that bothers me about this discussion is that idea that TCP is inherently slow. On a good link (i.e. just about any wired link in a well engineered network) and with no congestion in any of the nodes (which is easily done using Diff Serv and traffic engineering, for example; and, just how many routers will be between two neighbouring ARs? one? two?). An established TCP connection is just as fast as UDP. > > Typically, there would be one packet per transport type, and > that's unlikely to be more than two packets. But I still do not see the advantage. In one scenario you have feature contexts being transferred over individual transports, in another (my ideal) you have all features multiplexed onto one packet, and travelling to the destination AR in one packet. With a "permanent" TCP connection to the new AR, the transit time is the same as UDP/ICMP. If the packet gets "lost" and handover is in progress, then the new AR has to decide if it should wait for the re-transmission, begin forwarding the MNs packets, re-negotiate services, or drop the session. *IF* a packet gets lost - do you think it is possible to keep the packet loss probability in a well engineered network to below 1%? If so, then the last three options are probably appropriate options (1 in 100 handovers require re-negotiation, perhaps while the forwarding proceeds with degraded service). I think that .001% packet lost probability is easy to achieve - this is not transport across the global internet. BTW: I am not a proponent of TCP for the transport. Indeed, if you follow the above argument, and loss rates of <1% are easily achievable, then UDP should be reliable enough. > > > > Good to know. But then, I am confused over the relevance of > HI/HAck to > > > > the discussion. > > They are one good place to put context feature data, but > not the only good place. Good is subjective. > > Put another way, if the old access router is already sending > HI to the new access router, there's no reason that urgent > context feature data should not be included with the base > handover information. And the reason for piggy-backing the information is to save one packet transmission per handover? At the cost of having feature ct's occur sequentially and asynchronously? It does not seem worth the trouble, honestly. > > > I guess I shall remain confused. You introduced HI/HAck as > a mechanism > > > > for CT. I don't see the relevance. If the *only* context I have to > > transfer fits into HI/HAck and HI/HAck provides the necessary > > transport > > characteristics, then yes, it would be nice if CT could run over > > Hi/HAck. > > That's all I meant. > > > Does this mean that CT should be tailored so that it runs over > > Hi/HAck? > > Of course not -- depending on what you meant by "tailored". > I think it should be convenient to do it either way. > > > I guess it should be shown that tailoring CT for this purpose is > > significantly > > superior then running CT in parallel (or before, as with in > > "proactively"). > > Two packets takes longer than one. Exactly. So you agree ct is faster sent over one transport packet. > > > Onwards and downwards, > > Gary > > Somehow that means you are unlikely to welcome this response. > But I'm trying to be constructive. No, not at all. Just being cynical about the state of the world. It was not a comment on our conversation. Sorry for the misconception. And besides, downwards can be a good thing... I think that, as with the last go round, we really need to get either a ct solution out for everyone to debate, or we need to get some feature context transport requirements analysis out for everyone to ponder and debate. All I want, is for the requirement wording to be changed to indicate that goal is to minimize the complexity of the transport, with one transport protocol for ct being a desirable objective. Cheerio, Gary > > Regards, > Charlie P. > > > ------_=_NextPart_001_01C242F8.A5E602F4 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

Charlie:

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: August 12, 2002 22:49
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> Specifications
>
>
>
> Hello Gary,
>
> Continuing...
>
> Gary Kenward wrote:
>
> > I agree. TCP has limitations for short bursts of traffic such as CT.
> > *Except* for the cases of an ad-hoc network, or a network
> with mobile
> > routers, I do not see any reason why a TCP connection
> cannot be simply
> >
> > opened and kept open.
>
> I agree this would be possible, and would provide
> reasonable performance in a lot of cases.  It would
> penalize mobile nodes moving to "uninitialized"
> access routers that do not need reliable transfers,
> and for that reason seems to be unnecessarily heavy
> handed.  So, I'd say it's not the best approach.
>

I don't understand the concept of an "uninitialized access router".
Is this a router at the north pole that few people roam within range of?

Roaming happens between adjacent cells. If there is activity in a cell,
there's likely to be roaming. Making it a condition that an AR have
an open TCP connection to it's neighbour for it to support roaming is
not burdensome. It's the same as saying that the AR have the various capabilities
to support roaming.

> > See above. Any overhead introduced during a handover takes us away
> > from seamlessness.
> >
> > And so, following your logic, I question the rational with
> doing CARD
> > =>
> > CT => handover with a video stream.
>
> How about "Handover + CT"?  That would work.

How about CT => handover, that would work better :-)

>
> > > The actual requirement for some contexts is low latency, not
> > > separate transports.  The other actual requirement (for other
> > > contexts) is reliability (again, not separate
> transports).  I do not
> >
> > > have confidence that TCP can meet _both_ requirements.
> >
> > You are presuming here that the handover can proceed without the
> > second context.
>
> Not exactly.  In my opinion, we MUST arrange it so
> that all handovers can complete even if all context
> transfers fail.  Successful context transfers will have
> the effect of improving performance.
>
> Thus, one effect of this is that, yes, the handover could
> complete without the second (or any other) context.

Agreed. But it will not be true in all cases. Consider: should security
context transfer be timely or reliable? Some might have a problem with it
being unreliable. However, allowing forwarding to proceed at the
new AR without security ct because it is being transferred with a reliable
transport is almost the same as security ct being unreliable.

Note: this is the point we came to during the last transport requirements
discussion. So much depends on what the feature contexts each might require,
and under what conditions. Since the working group has chosen not to work on
the feature context requirements, yet, no new information is available.

>
> > I have a feeling, a strong feeling that this is all moot. I do not
> > know of any context that can be transferred unreliably - that is,
> > there has to be a reasonable assurance that CT will succeed in order
> > for it to "enhance" handover. If a CT fails as a consequence of an
> > unrealizable transport being used, what is the result?
>
> How about header compression?  If the state does
> not make it, then it can be re-established.

Sure. Not seamless though. Particularly if the compression is
not ROHC. In truth, everything can be re-established. The trick
for establishing seamlessness is to avoid this time consuming
activities.

>
> How about QoS?  If the state does not make it, the
> mobile node could renegotiate.
>
> In fact, I think this is true for _all_ contexts: if the
> transfer fails, the mobile node has to be robust
> enough to renegotiate, re-establish, or request
> retransmission of data.

See above.

It's all relative: performance gain relative to cost. If ct provides
seamlessness 50% of the time, and the rest of the time some renegotiation
goes on, then it's not worth implementing (users are typically conditioned
by the exception, not the rule, and so the frequency of seamlessness may
probably have to be as high as 80-90% to achieve customer satisfaction with
the service. Personally, I think it can, and should be higher).

>
> > By reasonable assurance, I go back to what I stated in
> reply to James:
> >
> > handovers will fail. However, handovers failures due to CT failures
> > must not be relatively insignificant (e.g. <<1%).
>
> It's probably a great goal, but I can't see why you would
> want to restrict context transfers to only those scenarios
> offering high reliability.

Do you mean reliability of handover? Reliability of handover is not
the same as reliability of the bearer packet transport. Reliability of
handover impacts customer perception of a smoothly operating, dependable,
predicable service. In truth, above a lower limit, consistency in handover
performance is more important then maximization (e.g. variance in performance
is more noticeable and irritating to the user).

From a personal perspective again (for I have not seen any human factors studies
on the subject), I believe that a successful wireless offering means that the
user receives a consistent, predictable communications service, and does not
experience *any* handovers (but perhaps, the *rare* drop of a session). The
user should not have to care about "cell boundaries" (I'm talking about real
users, not techies at IETF conferences :-} ).
>
>
> > > Are you really willing to make the restriction that [seamoby]
> > > only deals with such networks that satisfy this criterion?
> >
> > It would be preferable if we had a protocol that was both fast
> > and reliable - e.g. one that optimized for very short bursts of
> > data. However, we (seamoby) are not going to be defining that
> > protocol,
> > as far as I can tell.
> >
> > I'm still waiting for a practical description of a wired network or
> > group
> > of wired networks where this "restriction" is impractical. For a
> > handover
> > to occur seamlessly between two networks, many, many facilities have
> > to
> > be pre-established. It would seem to me that requiring a
> tunnel for CT
> >
> > between the two is a very small additional requirement.
>
> Your statement is not true for the prototype implementation
> we have.  Requiring another tunnel for CT is just not
> necessary, and isn't such a trivial requirement anyway.

Well, I guess that I cannot speak to your implementation. It might help
if you explained to the wg why establishing and maintaining a TCP connection
between two ARs is non-trivial for your implementation. Nothing is more
useful then real implementation experience.

>
> > Regardless, the idea of defining an ack/retx capability on top of
> > UDP/ICMP
> > is still transport protocol design. Arguably, TCP is simply UDP with
> > ack/retx
> > and window flow control (and a pile of other stuff designed
> to make it
> > all
> > work in various situations).
>
> A pile here, a pile there, and pretty soon you're talking
> about real protocol.

Yup. So either we are using an existing protocol, with no modifications, or we
are designing a new transport protocol. Talking about putting ack/retx
on UDP/ICMP is miss-leading, it would be a new transport protocol.

>
> > > > Why not simply put all feature contexts into one transport
> > exchange?
> > > > Which hopefully means, one IP packet.
> > >
> > > That's what my "program" does!  Please have another look.
> >
> > No it doesn't. It puts each context into it's own transport
> protocol.
> > That's
> > not, in my view, one transport exchange (each protocol sets up it's
> > own
> > exchange), and not one IP packet, in anyone's view.
>
> Well, with apologies to others, here is what I said:
>
> > 1. Find the most urgent context.  Encapsulate it using the transport
> >    it specifies (which won't be TCP, I reckon, for extremely urgent
> >    contexts).   Fill the rest of the context feature data structure
> >    with the most urgent other contexts that will fit, and which are
> >    compatible with the chosen transport.  If the chosen transport
> >    is not a reliable transport, schedule a retransmission if any
> >    context transfer requires acknowledgement.
>
> The third sentence refutes your characterization.  How many
> transports do you think there are, anyway?

"Encapsulate it using the transport it specifies".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note: one thing that bothers me about this discussion is that idea that
TCP is inherently slow. On a good link (i.e. just about any
wired link in a well engineered network) and with no congestion in any
of the nodes (which is easily done using Diff Serv and traffic engineering,
for example; and, just how many routers will be between two neighbouring ARs?
one? two?). An established TCP connection is just as fast as UDP.
>
> Typically, there would be one packet per transport type, and
> that's unlikely to be more than two packets.

But I still do not see the advantage. In one scenario you have
feature contexts being transferred over individual transports,
in another (my ideal) you have all features multiplexed onto one
packet, and travelling to the destination AR in one packet. With
a "permanent" TCP connection to the new AR, the transit time is the
same as UDP/ICMP. If the packet gets "lost" and handover is in progress,
then the new AR has to decide if it should wait for the re-transmission,
begin forwarding the MNs packets, re-negotiate services, or drop the
session. *IF* a packet gets lost - do you think it is possible to
keep the packet loss probability in a well engineered network to below
1%? If so, then the last three options are probably appropriate options
(1 in 100 handovers require re-negotiation, perhaps while the forwarding
proceeds with degraded service). I think that .001% packet lost probability
is easy to achieve - this is not transport across the global internet.

BTW: I am not a proponent of TCP for the transport. Indeed, if you follow
the above argument, and loss rates of <1% are easily achievable, then
UDP should be reliable enough.

>
>
> > Good to know. But then, I am confused over the relevance of
> HI/HAck to
> >
> > the discussion.
>
> They are one good place to put context feature data, but
> not the only good place.

Good is subjective.

>
> Put another way, if the old access router is already sending
> HI to the new access router, there's no reason that urgent
> context feature data should not be included with the base
> handover information.

And the reason for piggy-backing the information is to save one
packet transmission per handover? At the cost of having feature
ct's occur sequentially and asynchronously? It does not seem
worth the trouble, honestly.

>
> > I guess I shall remain confused. You introduced HI/HAck as
> a mechanism
> >
> > for CT. I don't see the relevance. If the *only* context I have to
> > transfer fits into HI/HAck and HI/HAck provides the necessary
> > transport
> > characteristics, then yes, it would be nice if CT could run over
> > Hi/HAck.
>
> That's all I meant.
>
> > Does this mean that CT should be tailored so that it runs over
> > Hi/HAck?
>
> Of course not -- depending on what you meant by "tailored".
> I think it should be convenient to do it either way.
>
> > I guess it should be shown that tailoring CT for this purpose is
> > significantly
> > superior then running CT in parallel (or before, as with in
> > "proactively").
>
> Two packets takes longer than one.

Exactly. So you agree ct is faster sent over one transport packet.

>
> > Onwards and downwards,
> > Gary
>
> Somehow that means you are unlikely to welcome this response.
> But I'm trying to be constructive.

No, not at all. Just being cynical about the state of the world. It was
not a comment on our conversation. Sorry for the misconception. And besides,
downwards can be a good thing...

I think that, as with the last go round, we really need to get either
a ct solution out for everyone to debate, or we need to get some feature
context transport requirements analysis out for everyone to ponder and
debate.

All I want, is for the requirement wording to be changed to indicate that
goal is to minimize the complexity of the transport, with one transport
protocol for ct being a desirable objective.

Cheerio,
Gary

>
> Regards,
> Charlie P.
>
>
>

------_=_NextPart_001_01C242F8.A5E602F4-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 13 15:16: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 PAA14462 for ; Tue, 13 Aug 2002 15:16:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29020; Tue, 13 Aug 2002 15:09:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28993 for ; Tue, 13 Aug 2002 15:09:06 -0400 (EDT) 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 PAA14107 for ; Tue, 13 Aug 2002 15:07:46 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA29234; Tue, 13 Aug 2002 12:08:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7DJ8YP24807; Tue, 13 Aug 2002 12:08:34 -0700 X-mProtect: <200208131908> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjtGtul; Tue, 13 Aug 2002 12:08:32 PDT Message-ID: <3D595930.CD95C7AC@iprg.nokia.com> Date: Tue, 13 Aug 2002 12:08:32 -0700 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: seamoby@ietf.org Subject: Re: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 References: <004f01c24257$d4b64c20$296015ac@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 Agree with Proposal 2 James Kempf wrote: > The following are proposals for Section 5.5. Please indicate which proposal you > AGREE with (if any), and which proposals you DISAGREE with. Please *only* > indicate AGREE with only one proposal. > > ---------- > > Proposal 1: Replace Section 5.5 with the following text: > > 5.5 Context Update and Synchronization > > 5.5.1 The base context transfer protocol SHOULD NOT provide direct support > for synchronization with outside events, since synchronization is > not a requirement for all or even most feature contexts. > > 5.5.2 The base context transfer protocol MUST allow individual feature > context specifications to define their own synchronization with > external events. > > 5.5.3 The base context transfer protocol SHOULD NOT provide support for > updating context after it is transfered, since individual feature > contexts will differ in their need for update. > > 5.5.4 The base context transfer protocol MUST allow individual feature > context specifications to define their own update procedures if > required. > > Most feature contexts will not require synchronization, however > there are a few that may. Header compression, for example, may require > that the header compressor on the old access router cease and the > compressor on the new router start in synchrony with hand over of > routing to the new router; otherwise, the compressor on the new router > will not be properly synchronized. Since most contexts don't need > synchronization support, the general CT solution need not support it, > but it should not provide a hinderance to those feature contexts > that do. > > Feature contexts will differ in whether or not they require update. > A feature context such as QoS parameters for the service level > agreement with a user may not involve dynamically changing information, > but it may change during or after context transfer. Such feature contexts > may benefit from allowing the context to change after the transfer is > completed. Other feature contexts, such as header compression, may be > tightly synchronized with external events and changes on the old router > need to be discarded since the new router's state may already have been > modified. > > ---------- > > Proposal 2: Replace Section 5.5 with the following text: > > 5.5 Context Update and Synchronization > > 5.5.1 The base context transfer protocol MUST NOT provide direct support > for synchronization with outside events, since synchronization is > not a requirement for all or even most feature contexts. > > 5.5.2 The base context transfer protocol MUST NOT provide support for > updating context after it is transfered, since individual feature > contexts will differ in their need for update. > > Since the base context transfer protocol must accommodate a wide > range of potential feature contexts, the base protocol design must > not contain any specification concerning update and > synchronization. > > --------------- > > _______________________________________________ > 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 daemon@optimus.ietf.org Tue Aug 13 15:16: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 PAA14470 for ; Tue, 13 Aug 2002 15:16:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29260 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 15:18:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29020; Tue, 13 Aug 2002 15:09:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28993 for ; Tue, 13 Aug 2002 15:09:06 -0400 (EDT) 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 PAA14107 for ; Tue, 13 Aug 2002 15:07:46 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA29234; Tue, 13 Aug 2002 12:08:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7DJ8YP24807; Tue, 13 Aug 2002 12:08:34 -0700 X-mProtect: <200208131908> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjtGtul; Tue, 13 Aug 2002 12:08:32 PDT Message-ID: <3D595930.CD95C7AC@iprg.nokia.com> Date: Tue, 13 Aug 2002 12:08:32 -0700 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: seamoby@ietf.org Subject: Re: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 References: <004f01c24257$d4b64c20$296015ac@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 Agree with Proposal 2 James Kempf wrote: > The following are proposals for Section 5.5. Please indicate which proposal you > AGREE with (if any), and which proposals you DISAGREE with. Please *only* > indicate AGREE with only one proposal. > > ---------- > > Proposal 1: Replace Section 5.5 with the following text: > > 5.5 Context Update and Synchronization > > 5.5.1 The base context transfer protocol SHOULD NOT provide direct support > for synchronization with outside events, since synchronization is > not a requirement for all or even most feature contexts. > > 5.5.2 The base context transfer protocol MUST allow individual feature > context specifications to define their own synchronization with > external events. > > 5.5.3 The base context transfer protocol SHOULD NOT provide support for > updating context after it is transfered, since individual feature > contexts will differ in their need for update. > > 5.5.4 The base context transfer protocol MUST allow individual feature > context specifications to define their own update procedures if > required. > > Most feature contexts will not require synchronization, however > there are a few that may. Header compression, for example, may require > that the header compressor on the old access router cease and the > compressor on the new router start in synchrony with hand over of > routing to the new router; otherwise, the compressor on the new router > will not be properly synchronized. Since most contexts don't need > synchronization support, the general CT solution need not support it, > but it should not provide a hinderance to those feature contexts > that do. > > Feature contexts will differ in whether or not they require update. > A feature context such as QoS parameters for the service level > agreement with a user may not involve dynamically changing information, > but it may change during or after context transfer. Such feature contexts > may benefit from allowing the context to change after the transfer is > completed. Other feature contexts, such as header compression, may be > tightly synchronized with external events and changes on the old router > need to be discarded since the new router's state may already have been > modified. > > ---------- > > Proposal 2: Replace Section 5.5 with the following text: > > 5.5 Context Update and Synchronization > > 5.5.1 The base context transfer protocol MUST NOT provide direct support > for synchronization with outside events, since synchronization is > not a requirement for all or even most feature contexts. > > 5.5.2 The base context transfer protocol MUST NOT provide support for > updating context after it is transfered, since individual feature > contexts will differ in their need for update. > > Since the base context transfer protocol must accommodate a wide > range of potential feature contexts, the base protocol design must > not contain any specification concerning update and > synchronization. > > --------------- > > _______________________________________________ > 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 Aug 13 15: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 PAA14782 for ; Tue, 13 Aug 2002 15:25:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29242; Tue, 13 Aug 2002 15:17:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29209 for ; Tue, 13 Aug 2002 15:17:27 -0400 (EDT) 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 PAA14443 for ; Tue, 13 Aug 2002 15:16:07 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA00051; Tue, 13 Aug 2002 12:16:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7DJGt831286; Tue, 13 Aug 2002 12:16:55 -0700 X-mProtect: <200208131916> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyOIiAl; Tue, 13 Aug 2002 12:14:54 PDT Message-ID: <3D595AAE.C1FFA752@iprg.nokia.com> Date: Tue, 13 Aug 2002 12:14:54 -0700 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: seamoby@ietf.org Subject: Re: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Context Standardization References: <005001c24257$d4fca3f0$296015ac@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 Agree with proposal 3 Disagree with 1 and 2 -Rajeev James Kempf wrote: > The following are proposals adding text on feature context standardization. > Please indicate which proposal you AGREE with (if any), and which > proposals you DISAGREE with. Please *only* indicate AGREE > with only one proposal. > > ------------ > Proposal 1: Do not add anything on feature context standardization. > ------------ > > ------------ > Proposal 2: Add the following text: > > Section 6: Standardization of Feature Contexts > > The context transfer protocol provides a basic framework in which feature > contexts of varying types can be transferred. Recognizing that the > particular feature contexts may have very different needs with regard > to update, synchronization, and transport, the base context transfer > protocol requirements are designed to not constrain how the context transfer > protocol is used for particular feature contexts with respect to these > points. In addition, some feature contexts may require additional processing > on the target access router before they can be of use. Individual feature > contexts will be standardized by the method of IETF standards action. > The standardizationof a feature context should describe how a feature > context > utilizes the base context transfer protocol; if update, synchronization, and > additional proccessing are required, and, if so, how they are achieved; and > the > transport used for the feature context. > > ------------ > > Proposal 3: Add the following text: > > 5.8 Feature Context Specifications > > The context transfer protocol provides a basic framework in which feature > contexts of varying types can be transfered. Recognizing that the particular > feature contexts may have very different needs with regard to update, > synchronization, and transport, this section contains requirements on the > feature context specifications. Note that these requirements do not > constrain the actual feature context protocols themselves, but only their > specification. > > 5.8.1 A feature context specification MUST contain an IANA assigned type > code for the particular feature context. If an experimental feature context > protocol is being developed, a type code from the context transfer > protocol's experimental range SHOULD be used. The type code is used in the > context transfer container to identify the feature context. > > 5.8.2 A feature context specification MUST define the byte layout of the > individual elements of the feature context, and how those map into the > context transfer protocol's container. The byte layout SHOULD obey > standard IETF conventions with regard to mapping of data into on the > wire format. > > 5.8.3 If the feature context is transferred using an IETF transport layer > protocol, and relying on specific mechanisms of the transport layer > protocol, such as reliability or timing mechanisms, then > the feature context specification MUST include the full details of how the > transport layer protocol is used. One must note that employing different > transport mechanisms for different feature context might lead to limited > possibility of multiplexing various feature contexts > > If the feature context is transferred as an > option on another IETF protocol, then the feature context specification MUST > define the mapping of the context transfer container into the other > protocol's standard option format. If the feature context is transferred > through a non-IETF protocol (such as IAPP [4]), then the feature context > protocol specification MUST define how the standard context transfer > container is mapped into the non-IETF transport. > > 5.8.4 A feature context specification MUST indicate whether update to > context information is allowed if changes in the source occur after the > context is transferred. If such changes are allowed, the feature context > specification MUST define the change protocol message format using the > standard context transfer container, and MUST include details of how the > update is accomplished and triggered. > > 5.8.5 A feature context specification MUST indicate whether the context > transfer is tightly synchronized with external events, such as handover. > The feature context specification MUST indicate what event or events > trigger transfer. > > 6.0 References > > [4] "Recommended Practice for Multi-vendor Interaccess Point > Interoperability via an Inter-access Point Protocol Across Distribution > Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, > January, 2002. > > -------------- > > _______________________________________________ > 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 daemon@optimus.ietf.org Tue Aug 13 15: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 PAA14787 for ; Tue, 13 Aug 2002 15:25:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29437 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 15:26:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29242; Tue, 13 Aug 2002 15:17:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29209 for ; Tue, 13 Aug 2002 15:17:27 -0400 (EDT) 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 PAA14443 for ; Tue, 13 Aug 2002 15:16:07 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA00051; Tue, 13 Aug 2002 12:16:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7DJGt831286; Tue, 13 Aug 2002 12:16:55 -0700 X-mProtect: <200208131916> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyOIiAl; Tue, 13 Aug 2002 12:14:54 PDT Message-ID: <3D595AAE.C1FFA752@iprg.nokia.com> Date: Tue, 13 Aug 2002 12:14:54 -0700 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: seamoby@ietf.org Subject: Re: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Context Standardization References: <005001c24257$d4fca3f0$296015ac@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 Agree with proposal 3 Disagree with 1 and 2 -Rajeev James Kempf wrote: > The following are proposals adding text on feature context standardization. > Please indicate which proposal you AGREE with (if any), and which > proposals you DISAGREE with. Please *only* indicate AGREE > with only one proposal. > > ------------ > Proposal 1: Do not add anything on feature context standardization. > ------------ > > ------------ > Proposal 2: Add the following text: > > Section 6: Standardization of Feature Contexts > > The context transfer protocol provides a basic framework in which feature > contexts of varying types can be transferred. Recognizing that the > particular feature contexts may have very different needs with regard > to update, synchronization, and transport, the base context transfer > protocol requirements are designed to not constrain how the context transfer > protocol is used for particular feature contexts with respect to these > points. In addition, some feature contexts may require additional processing > on the target access router before they can be of use. Individual feature > contexts will be standardized by the method of IETF standards action. > The standardizationof a feature context should describe how a feature > context > utilizes the base context transfer protocol; if update, synchronization, and > additional proccessing are required, and, if so, how they are achieved; and > the > transport used for the feature context. > > ------------ > > Proposal 3: Add the following text: > > 5.8 Feature Context Specifications > > The context transfer protocol provides a basic framework in which feature > contexts of varying types can be transfered. Recognizing that the particular > feature contexts may have very different needs with regard to update, > synchronization, and transport, this section contains requirements on the > feature context specifications. Note that these requirements do not > constrain the actual feature context protocols themselves, but only their > specification. > > 5.8.1 A feature context specification MUST contain an IANA assigned type > code for the particular feature context. If an experimental feature context > protocol is being developed, a type code from the context transfer > protocol's experimental range SHOULD be used. The type code is used in the > context transfer container to identify the feature context. > > 5.8.2 A feature context specification MUST define the byte layout of the > individual elements of the feature context, and how those map into the > context transfer protocol's container. The byte layout SHOULD obey > standard IETF conventions with regard to mapping of data into on the > wire format. > > 5.8.3 If the feature context is transferred using an IETF transport layer > protocol, and relying on specific mechanisms of the transport layer > protocol, such as reliability or timing mechanisms, then > the feature context specification MUST include the full details of how the > transport layer protocol is used. One must note that employing different > transport mechanisms for different feature context might lead to limited > possibility of multiplexing various feature contexts > > If the feature context is transferred as an > option on another IETF protocol, then the feature context specification MUST > define the mapping of the context transfer container into the other > protocol's standard option format. If the feature context is transferred > through a non-IETF protocol (such as IAPP [4]), then the feature context > protocol specification MUST define how the standard context transfer > container is mapped into the non-IETF transport. > > 5.8.4 A feature context specification MUST indicate whether update to > context information is allowed if changes in the source occur after the > context is transferred. If such changes are allowed, the feature context > specification MUST define the change protocol message format using the > standard context transfer container, and MUST include details of how the > update is accomplished and triggered. > > 5.8.5 A feature context specification MUST indicate whether the context > transfer is tightly synchronized with external events, such as handover. > The feature context specification MUST indicate what event or events > trigger transfer. > > 6.0 References > > [4] "Recommended Practice for Multi-vendor Interaccess Point > Interoperability via an Inter-access Point Protocol Across Distribution > Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, > January, 2002. > > -------------- > > _______________________________________________ > 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 Aug 13 16:11: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 QAA16861 for ; Tue, 13 Aug 2002 16:11:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02295; Tue, 13 Aug 2002 16:06:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02263 for ; Tue, 13 Aug 2002 16:06:37 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16590 for ; Tue, 13 Aug 2002 16:05:17 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DK5g505434; Tue, 13 Aug 2002 16:05:43 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 16:05:43 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01BA9950@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5 .2 Date: Tue, 13 Aug 2002 16:05:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24304.B01C4C90" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24304.B01C4C90 Content-Type: text/plain; charset="iso-8859-1" Agree with Proposal 3, Disagree with 1 & 2. -Hamid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 7:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 The following are proposals for Section 5.2. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ----------- Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the requirements. ----------- ----------- Proposal 2: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified so that it is independent of the underlying transport. Recognizing that the transport characteristics for context transfer will depend on the particular application, it should be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extension on another protocol, such as handover signaling. ----------- ----------- Proposal 3: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified to utilize a reliable transport protocol as a default, unreliable transport MAY also be optionally allowed. Recognizing that context transfer may be crucial for successful handover, the context transfer protocol must specify operation on a default reliable transport. The context transfer protocol may optionally allow transfer on unreliable transport. 5.2.2 The context transfer protocol MUST run directly on top of a transport protocol. Context transfer within another application layer protocol MUST NOT be allowed. In order to preserve the unity of context transport across all feature applications, context transfer must run directly on top of a transport protocol. Running context transfer as an option on another application layer protocol is prohibited. ----------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ------_=_NextPart_001_01C24304.B01C4C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section = 5.2

Agree with Proposal 3, Disagree with 1 & = 2.

-Hamid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
Sent: Monday, August 12, 2002 7:22 PM
To: seamoby@ietf.org
Subject: [Seamoby] Seamoby CT Protocol Requirements = Issue 1: Section 5.2


The following are proposals for Section 5.2. Please = indicate which proposal you
AGREE with (if any), and which proposals you = DISAGREE with. Please *only*
indicate AGREE with only one proposal.

-----------
Proposal 1: Remove Section 5.2 entirely. Say nothing = about transport in the
requirements.
-----------

-----------
Proposal 2: Replace Section 5.2 with the = following:

   5.2 Transport Requirements

        This = section contains requirements on the context transfer transport.

    5.2.1  The context transfer = protocol MUST be specified so that it is
          &nb= sp;    independent of the underlying transport.

          &nb= sp; Recognizing that the transport characteristics for context = transfer
          &nb= sp; will depend on the particular application, it should be possible = to
          &nb= sp; transfer context directly on top of reliable transports, such as = TCP
          &nb= sp; or SCTP, unreliable transports, such as UDP, or as an option = or
          &nb= sp; extension on another protocol, such as handover signaling.

-----------

-----------
Proposal 3: Replace Section 5.2 with the = following:

   5.2 Transport Requirements

        This = section contains requirements on the context transfer transport.

    5.2.1  The context transfer = protocol MUST be specified to utilize a reliable
          &nb= sp;    transport protocol as a default, unreliable = transport MAY also be
          &nb= sp;    optionally allowed.

          &nb= sp;    Recognizing that context transfer may be crucial = for successful
          &nb= sp;    handover, the context transfer protocol must = specify operation
          &nb= sp;   on a default reliable transport. The context transfer = protocol may
          &nb= sp;   optionally allow transfer on unreliable = transport.

    5.2.2  The context transfer = protocol MUST run directly on top of a transport
          &nb= sp;   protocol. Context transfer within another application = layer
          &nb= sp;   protocol MUST NOT be allowed.

          &nb= sp;   In order to preserve the unity of context transport = across all
          &nb= sp;   feature applications, context transfer must run = directly on top of
          &nb= sp;  a transport protocol. Running context transfer as an option = on
          &nb= sp;  another application layer protocol is prohibited.
-----------






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

------_=_NextPart_001_01C24304.B01C4C90-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 13 16:11: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 QAA16880 for ; Tue, 13 Aug 2002 16:11:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03039 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 16:12:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02295; Tue, 13 Aug 2002 16:06:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02263 for ; Tue, 13 Aug 2002 16:06:37 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16590 for ; Tue, 13 Aug 2002 16:05:17 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DK5g505434; Tue, 13 Aug 2002 16:05:43 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 16:05:43 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01BA9950@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5 .2 Date: Tue, 13 Aug 2002 16:05:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24304.B01C4C90" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24304.B01C4C90 Content-Type: text/plain; charset="iso-8859-1" Agree with Proposal 3, Disagree with 1 & 2. -Hamid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 7:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section 5.2 The following are proposals for Section 5.2. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ----------- Proposal 1: Remove Section 5.2 entirely. Say nothing about transport in the requirements. ----------- ----------- Proposal 2: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified so that it is independent of the underlying transport. Recognizing that the transport characteristics for context transfer will depend on the particular application, it should be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extension on another protocol, such as handover signaling. ----------- ----------- Proposal 3: Replace Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.2.1 The context transfer protocol MUST be specified to utilize a reliable transport protocol as a default, unreliable transport MAY also be optionally allowed. Recognizing that context transfer may be crucial for successful handover, the context transfer protocol must specify operation on a default reliable transport. The context transfer protocol may optionally allow transfer on unreliable transport. 5.2.2 The context transfer protocol MUST run directly on top of a transport protocol. Context transfer within another application layer protocol MUST NOT be allowed. In order to preserve the unity of context transport across all feature applications, context transfer must run directly on top of a transport protocol. Running context transfer as an option on another application layer protocol is prohibited. ----------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ------_=_NextPart_001_01C24304.B01C4C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Seamoby CT Protocol Requirements Issue 1: Section = 5.2

Agree with Proposal 3, Disagree with 1 & = 2.

-Hamid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
Sent: Monday, August 12, 2002 7:22 PM
To: seamoby@ietf.org
Subject: [Seamoby] Seamoby CT Protocol Requirements = Issue 1: Section 5.2


The following are proposals for Section 5.2. Please = indicate which proposal you
AGREE with (if any), and which proposals you = DISAGREE with. Please *only*
indicate AGREE with only one proposal.

-----------
Proposal 1: Remove Section 5.2 entirely. Say nothing = about transport in the
requirements.
-----------

-----------
Proposal 2: Replace Section 5.2 with the = following:

   5.2 Transport Requirements

        This = section contains requirements on the context transfer transport.

    5.2.1  The context transfer = protocol MUST be specified so that it is
          &nb= sp;    independent of the underlying transport.

          &nb= sp; Recognizing that the transport characteristics for context = transfer
          &nb= sp; will depend on the particular application, it should be possible = to
          &nb= sp; transfer context directly on top of reliable transports, such as = TCP
          &nb= sp; or SCTP, unreliable transports, such as UDP, or as an option = or
          &nb= sp; extension on another protocol, such as handover signaling.

-----------

-----------
Proposal 3: Replace Section 5.2 with the = following:

   5.2 Transport Requirements

        This = section contains requirements on the context transfer transport.

    5.2.1  The context transfer = protocol MUST be specified to utilize a reliable
          &nb= sp;    transport protocol as a default, unreliable = transport MAY also be
          &nb= sp;    optionally allowed.

          &nb= sp;    Recognizing that context transfer may be crucial = for successful
          &nb= sp;    handover, the context transfer protocol must = specify operation
          &nb= sp;   on a default reliable transport. The context transfer = protocol may
          &nb= sp;   optionally allow transfer on unreliable = transport.

    5.2.2  The context transfer = protocol MUST run directly on top of a transport
          &nb= sp;   protocol. Context transfer within another application = layer
          &nb= sp;   protocol MUST NOT be allowed.

          &nb= sp;   In order to preserve the unity of context transport = across all
          &nb= sp;   feature applications, context transfer must run = directly on top of
          &nb= sp;  a transport protocol. Running context transfer as an option = on
          &nb= sp;  another application layer protocol is prohibited.
-----------






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

------_=_NextPart_001_01C24304.B01C4C90-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 13 16:15: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 QAA17082 for ; Tue, 13 Aug 2002 16:15:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02777; Tue, 13 Aug 2002 16:11:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02710 for ; Tue, 13 Aug 2002 16:11:18 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16753 for ; Tue, 13 Aug 2002 16:09:57 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DKAg505778; Tue, 13 Aug 2002 16:10:42 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 16:10:42 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01BA9951@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 Date: Tue, 13 Aug 2002 16:10:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24305.3A58C4CE" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24305.3A58C4CE Content-Type: text/plain; charset="iso-8859-1" Agree with proposal 1, Disagree with 2. -Hamid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 7:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 The following are proposals for Section 5.5. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ---------- Proposal 1: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. 5.5.4 The base context transfer protocol MUST allow individual feature context specifications to define their own update procedures if required. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the general CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Feature contexts will differ in whether or not they require update. A feature context such as QoS parameters for the service level agreement with a user may not involve dynamically changing information, but it may change during or after context transfer. Such feature contexts may benefit from allowing the context to change after the transfer is completed. Other feature contexts, such as header compression, may be tightly synchronized with external events and changes on the old router need to be discarded since the new router's state may already have been modified. ---------- Proposal 2: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol MUST NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. Since the base context transfer protocol must accommodate a wide range of potential feature contexts, the base protocol design must not contain any specification concerning update and synchronization. --------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ------_=_NextPart_001_01C24305.3A58C4CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Seamoby CT Requirements Issue 2: Section = 5.5

Agree with proposal 1, Disagree with 2.

-Hamid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
Sent: Monday, August 12, 2002 7:22 PM
To: seamoby@ietf.org
Subject: [Seamoby] Seamoby CT Requirements Issue 2: = Section 5.5


The following are proposals for Section 5.5. Please = indicate which proposal you
AGREE with (if any), and which proposals you = DISAGREE with. Please *only*
indicate AGREE with only one proposal.

----------

Proposal 1: Replace Section 5.5 with the following = text:

    5.5 Context Update and = Synchronization

    5.5.1 The base context transfer = protocol SHOULD NOT provide direct support
          &nb= sp;   for synchronization with outside events, since = synchronization is
          &nb= sp;   not a requirement for all or even most feature = contexts.

    5.5.2 The base context transfer = protocol MUST allow individual feature
          &nb= sp;  context specifications to define their own synchronization = with
          &nb= sp;  external events.

    5.5.3 The base context transfer = protocol SHOULD NOT provide support for
          &nb= sp;  updating context after it is transfered, since individual = feature
          &nb= sp;  contexts will differ in their need for update.

    5.5.4 The base context transfer = protocol MUST allow individual feature
          &nb= sp;  context specifications to define their own update procedures = if
          &nb= sp;  required.

        Most = feature contexts will not require synchronization, however
        there are = a few that may. Header compression, for example, may require
        that the = header compressor on the old access router cease and the
        = compressor on the new router start in synchrony with hand over = of
        routing = to the new router; otherwise, the compressor on the new router
        will not = be properly synchronized. Since most contexts don't need
        = synchronization support, the general CT solution need not support = it,
        but it = should not provide a hinderance to those feature contexts
        that = do.

       Feature contexts = will differ in whether or not they require update.
       A feature = context such as QoS parameters for the service level
       agreement with = a user may not involve dynamically changing information,
       but it may = change during or after context transfer. Such feature contexts
       may benefit = from allowing the context to change after the transfer is
       completed. = Other feature contexts, such as header compression, may be
       tightly = synchronized with external events and changes on the old router
       need to be = discarded since the new router's state may already have been
       = modified.

----------

Proposal 2: Replace Section 5.5 with the following = text:

    5.5 Context Update and = Synchronization

    5.5.1 The base context transfer = protocol MUST NOT provide direct support
          &nb= sp;   for synchronization with outside events, since = synchronization is
          &nb= sp;   not a requirement for all or even most feature = contexts.

    5.5.2 The base context transfer = protocol MUST NOT provide support for
          &nb= sp;  updating context after it is transfered, since individual = feature
          &nb= sp;  contexts will differ in their need for update.

          &nb= sp;  Since the base context transfer protocol must accommodate a = wide
          &nb= sp;  range of potential feature contexts, the base protocol design = must
          &nb= sp;  not contain any specification concerning update and
          &nb= sp;  synchronization.

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





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

------_=_NextPart_001_01C24305.3A58C4CE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 13 16:15: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 QAA17091 for ; Tue, 13 Aug 2002 16:15:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03586 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 16:17:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02777; Tue, 13 Aug 2002 16:11:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02710 for ; Tue, 13 Aug 2002 16:11:18 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16753 for ; Tue, 13 Aug 2002 16:09:57 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DKAg505778; Tue, 13 Aug 2002 16:10:42 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 16:10:42 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01BA9951@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 Date: Tue, 13 Aug 2002 16:10:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24305.3A58C4CE" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24305.3A58C4CE Content-Type: text/plain; charset="iso-8859-1" Agree with proposal 1, Disagree with 2. -Hamid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 7:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Requirements Issue 2: Section 5.5 The following are proposals for Section 5.5. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ---------- Proposal 1: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. 5.5.4 The base context transfer protocol MUST allow individual feature context specifications to define their own update procedures if required. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the general CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Feature contexts will differ in whether or not they require update. A feature context such as QoS parameters for the service level agreement with a user may not involve dynamically changing information, but it may change during or after context transfer. Such feature contexts may benefit from allowing the context to change after the transfer is completed. Other feature contexts, such as header compression, may be tightly synchronized with external events and changes on the old router need to be discarded since the new router's state may already have been modified. ---------- Proposal 2: Replace Section 5.5 with the following text: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol MUST NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. Since the base context transfer protocol must accommodate a wide range of potential feature contexts, the base protocol design must not contain any specification concerning update and synchronization. --------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ------_=_NextPart_001_01C24305.3A58C4CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Seamoby CT Requirements Issue 2: Section = 5.5

Agree with proposal 1, Disagree with 2.

-Hamid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
Sent: Monday, August 12, 2002 7:22 PM
To: seamoby@ietf.org
Subject: [Seamoby] Seamoby CT Requirements Issue 2: = Section 5.5


The following are proposals for Section 5.5. Please = indicate which proposal you
AGREE with (if any), and which proposals you = DISAGREE with. Please *only*
indicate AGREE with only one proposal.

----------

Proposal 1: Replace Section 5.5 with the following = text:

    5.5 Context Update and = Synchronization

    5.5.1 The base context transfer = protocol SHOULD NOT provide direct support
          &nb= sp;   for synchronization with outside events, since = synchronization is
          &nb= sp;   not a requirement for all or even most feature = contexts.

    5.5.2 The base context transfer = protocol MUST allow individual feature
          &nb= sp;  context specifications to define their own synchronization = with
          &nb= sp;  external events.

    5.5.3 The base context transfer = protocol SHOULD NOT provide support for
          &nb= sp;  updating context after it is transfered, since individual = feature
          &nb= sp;  contexts will differ in their need for update.

    5.5.4 The base context transfer = protocol MUST allow individual feature
          &nb= sp;  context specifications to define their own update procedures = if
          &nb= sp;  required.

        Most = feature contexts will not require synchronization, however
        there are = a few that may. Header compression, for example, may require
        that the = header compressor on the old access router cease and the
        = compressor on the new router start in synchrony with hand over = of
        routing = to the new router; otherwise, the compressor on the new router
        will not = be properly synchronized. Since most contexts don't need
        = synchronization support, the general CT solution need not support = it,
        but it = should not provide a hinderance to those feature contexts
        that = do.

       Feature contexts = will differ in whether or not they require update.
       A feature = context such as QoS parameters for the service level
       agreement with = a user may not involve dynamically changing information,
       but it may = change during or after context transfer. Such feature contexts
       may benefit = from allowing the context to change after the transfer is
       completed. = Other feature contexts, such as header compression, may be
       tightly = synchronized with external events and changes on the old router
       need to be = discarded since the new router's state may already have been
       = modified.

----------

Proposal 2: Replace Section 5.5 with the following = text:

    5.5 Context Update and = Synchronization

    5.5.1 The base context transfer = protocol MUST NOT provide direct support
          &nb= sp;   for synchronization with outside events, since = synchronization is
          &nb= sp;   not a requirement for all or even most feature = contexts.

    5.5.2 The base context transfer = protocol MUST NOT provide support for
          &nb= sp;  updating context after it is transfered, since individual = feature
          &nb= sp;  contexts will differ in their need for update.

          &nb= sp;  Since the base context transfer protocol must accommodate a = wide
          &nb= sp;  range of potential feature contexts, the base protocol design = must
          &nb= sp;  not contain any specification concerning update and
          &nb= sp;  synchronization.

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





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

------_=_NextPart_001_01C24305.3A58C4CE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 13 16:26: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 QAA17625 for ; Tue, 13 Aug 2002 16:26:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03729; Tue, 13 Aug 2002 16:19:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03700 for ; Tue, 13 Aug 2002 16:19:04 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17179 for ; Tue, 13 Aug 2002 16:17:44 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DKIS506360; Tue, 13 Aug 2002 16:18:28 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 16:18:28 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01BA9952@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Co ntext Standardization Date: Tue, 13 Aug 2002 16:18:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24306.69426960" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24306.69426960 Content-Type: text/plain; charset="iso-8859-1" Agree with proposal 2, Disagree with 1 & 3. -Hamid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 7:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Context Standardization The following are proposals adding text on feature context standardization. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ------------ Proposal 1: Do not add anything on feature context standardization. ------------ ------------ Proposal 2: Add the following text: Section 6: Standardization of Feature Contexts The context transfer protocol provides a basic framework in which feature contexts of varying types can be transferred. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, the base context transfer protocol requirements are designed to not constrain how the context transfer protocol is used for particular feature contexts with respect to these points. In addition, some feature contexts may require additional processing on the target access router before they can be of use. Individual feature contexts will be standardized by the method of IETF standards action. The standardizationof a feature context should describe how a feature context utilizes the base context transfer protocol; if update, synchronization, and additional proccessing are required, and, if so, how they are achieved; and the transport used for the feature context. ------------ Proposal 3: Add the following text: 5.8 Feature Context Specifications The context transfer protocol provides a basic framework in which feature contexts of varying types can be transfered. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, this section contains requirements on the feature context specifications. Note that these requirements do not constrain the actual feature context protocols themselves, but only their specification. 5.8.1 A feature context specification MUST contain an IANA assigned type code for the particular feature context. If an experimental feature context protocol is being developed, a type code from the context transfer protocol's experimental range SHOULD be used. The type code is used in the context transfer container to identify the feature context. 5.8.2 A feature context specification MUST define the byte layout of the individual elements of the feature context, and how those map into the context transfer protocol's container. The byte layout SHOULD obey standard IETF conventions with regard to mapping of data into on the wire format. 5.8.3 If the feature context is transferred using an IETF transport layer protocol, and relying on specific mechanisms of the transport layer protocol, such as reliability or timing mechanisms, then the feature context specification MUST include the full details of how the transport layer protocol is used. One must note that employing different transport mechanisms for different feature context might lead to limited possibility of multiplexing various feature contexts If the feature context is transferred as an option on another IETF protocol, then the feature context specification MUST define the mapping of the context transfer container into the other protocol's standard option format. If the feature context is transferred through a non-IETF protocol (such as IAPP [4]), then the feature context protocol specification MUST define how the standard context transfer container is mapped into the non-IETF transport. 5.8.4 A feature context specification MUST indicate whether update to context information is allowed if changes in the source occur after the context is transferred. If such changes are allowed, the feature context specification MUST define the change protocol message format using the standard context transfer container, and MUST include details of how the update is accomplished and triggered. 5.8.5 A feature context specification MUST indicate whether the context transfer is tightly synchronized with external events, such as handover. The feature context specification MUST indicate what event or events trigger transfer. 6.0 References [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. -------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ------_=_NextPart_001_01C24306.69426960 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Context Standardization

Agree with proposal 2, Disagree with 1 & 3.

-Hamid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Monday, August 12, 2002 7:22 PM
To: seamoby@ietf.org
Subject: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature
Context Standardization


The following are proposals adding text on feature context standardization.
Please indicate which proposal you AGREE with (if any), and which
proposals you DISAGREE with. Please *only* indicate AGREE
with only one proposal.

------------
Proposal 1: Do not add anything on feature context standardization.
------------

------------
Proposal 2:  Add the following text:

    Section 6: Standardization of Feature Contexts

    The context transfer protocol provides a basic framework in which feature
    contexts of varying types can be transferred. Recognizing that the
    particular feature contexts may have very different needs with regard
    to update, synchronization, and transport, the base context transfer
    protocol requirements are designed to not constrain how the context transfer
    protocol is used for particular feature contexts with respect to these
    points. In addition, some feature contexts may require additional processing
    on the target access router before they can be of use. Individual feature
    contexts will be standardized by the method of IETF standards action.
    The standardizationof a feature context should describe how a feature
context
    utilizes the base context transfer protocol; if update, synchronization, and
    additional proccessing are required, and, if so, how they are achieved; and
the
    transport used for the feature context.

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

Proposal 3: Add the following text:

    5.8 Feature Context Specifications

    The context transfer protocol provides a basic framework in which feature
    contexts of varying types can be transfered. Recognizing that the particular
    feature contexts may have very different needs with regard to update,
    synchronization, and transport, this section contains requirements on the
    feature context specifications. Note that these requirements do not
    constrain the actual feature context protocols themselves, but only their
    specification.

    5.8.1 A feature context specification MUST contain an IANA assigned type
    code for the particular feature context. If an experimental feature context
    protocol is being developed, a type code from the context transfer
   protocol's experimental range SHOULD be used. The type code is used in the
   context transfer container to identify the feature context.

    5.8.2 A feature context specification MUST define the byte layout of the
    individual elements of the feature context, and how those map into the
    context transfer protocol's container. The byte layout SHOULD obey
    standard IETF conventions with regard to mapping of data into on the
     wire format.

    5.8.3 If the feature context is transferred using an IETF transport layer
    protocol, and relying on specific mechanisms of the transport layer
    protocol, such as reliability or timing mechanisms, then
    the feature context specification MUST include the full details of how the
    transport layer protocol is used. One must note that employing different
    transport mechanisms for different feature context might lead to limited
    possibility of multiplexing various feature contexts

    If the feature context is transferred as an
    option on another IETF protocol, then the feature context specification MUST
    define the mapping of the context transfer container into the other
     protocol's standard option format. If the feature context is transferred
     through a non-IETF protocol (such as IAPP [4]), then the feature context
    protocol specification MUST define how the standard context transfer
   container is mapped into the non-IETF transport.

    5.8.4 A feature context specification MUST indicate whether update to
    context information is allowed if changes in the source occur after the
    context is transferred. If such changes are allowed, the feature context
    specification MUST define the change protocol message format using the
    standard context transfer container, and MUST include details of how the
    update is accomplished and triggered.

    5.8.5 A feature context specification MUST indicate whether the context
    transfer is tightly synchronized with external events, such as handover.
    The feature context specification MUST indicate what event or events
    trigger transfer.

    6.0 References

    [4]  "Recommended Practice for Multi-vendor Interaccess Point
    Interoperability via an Inter-access Point Protocol Across Distribution
    Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3,
    January, 2002.

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






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

------_=_NextPart_001_01C24306.69426960-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 13 16:26: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 QAA17634 for ; Tue, 13 Aug 2002 16:26:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA06287 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 16:28:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03729; Tue, 13 Aug 2002 16:19:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03700 for ; Tue, 13 Aug 2002 16:19:04 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17179 for ; Tue, 13 Aug 2002 16:17:44 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DKIS506360; Tue, 13 Aug 2002 16:18:28 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 16:18:28 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01BA9952@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Co ntext Standardization Date: Tue, 13 Aug 2002 16:18:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24306.69426960" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24306.69426960 Content-Type: text/plain; charset="iso-8859-1" Agree with proposal 2, Disagree with 1 & 3. -Hamid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, August 12, 2002 7:22 PM To: seamoby@ietf.org Subject: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Context Standardization The following are proposals adding text on feature context standardization. Please indicate which proposal you AGREE with (if any), and which proposals you DISAGREE with. Please *only* indicate AGREE with only one proposal. ------------ Proposal 1: Do not add anything on feature context standardization. ------------ ------------ Proposal 2: Add the following text: Section 6: Standardization of Feature Contexts The context transfer protocol provides a basic framework in which feature contexts of varying types can be transferred. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, the base context transfer protocol requirements are designed to not constrain how the context transfer protocol is used for particular feature contexts with respect to these points. In addition, some feature contexts may require additional processing on the target access router before they can be of use. Individual feature contexts will be standardized by the method of IETF standards action. The standardizationof a feature context should describe how a feature context utilizes the base context transfer protocol; if update, synchronization, and additional proccessing are required, and, if so, how they are achieved; and the transport used for the feature context. ------------ Proposal 3: Add the following text: 5.8 Feature Context Specifications The context transfer protocol provides a basic framework in which feature contexts of varying types can be transfered. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, this section contains requirements on the feature context specifications. Note that these requirements do not constrain the actual feature context protocols themselves, but only their specification. 5.8.1 A feature context specification MUST contain an IANA assigned type code for the particular feature context. If an experimental feature context protocol is being developed, a type code from the context transfer protocol's experimental range SHOULD be used. The type code is used in the context transfer container to identify the feature context. 5.8.2 A feature context specification MUST define the byte layout of the individual elements of the feature context, and how those map into the context transfer protocol's container. The byte layout SHOULD obey standard IETF conventions with regard to mapping of data into on the wire format. 5.8.3 If the feature context is transferred using an IETF transport layer protocol, and relying on specific mechanisms of the transport layer protocol, such as reliability or timing mechanisms, then the feature context specification MUST include the full details of how the transport layer protocol is used. One must note that employing different transport mechanisms for different feature context might lead to limited possibility of multiplexing various feature contexts If the feature context is transferred as an option on another IETF protocol, then the feature context specification MUST define the mapping of the context transfer container into the other protocol's standard option format. If the feature context is transferred through a non-IETF protocol (such as IAPP [4]), then the feature context protocol specification MUST define how the standard context transfer container is mapped into the non-IETF transport. 5.8.4 A feature context specification MUST indicate whether update to context information is allowed if changes in the source occur after the context is transferred. If such changes are allowed, the feature context specification MUST define the change protocol message format using the standard context transfer container, and MUST include details of how the update is accomplished and triggered. 5.8.5 A feature context specification MUST indicate whether the context transfer is tightly synchronized with external events, such as handover. The feature context specification MUST indicate what event or events trigger transfer. 6.0 References [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. -------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ------_=_NextPart_001_01C24306.69426960 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature Context Standardization

Agree with proposal 2, Disagree with 1 & 3.

-Hamid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Monday, August 12, 2002 7:22 PM
To: seamoby@ietf.org
Subject: [Seamoby] Seamoby CT Requirements Issue 3: Text on Feature
Context Standardization


The following are proposals adding text on feature context standardization.
Please indicate which proposal you AGREE with (if any), and which
proposals you DISAGREE with. Please *only* indicate AGREE
with only one proposal.

------------
Proposal 1: Do not add anything on feature context standardization.
------------

------------
Proposal 2:  Add the following text:

    Section 6: Standardization of Feature Contexts

    The context transfer protocol provides a basic framework in which feature
    contexts of varying types can be transferred. Recognizing that the
    particular feature contexts may have very different needs with regard
    to update, synchronization, and transport, the base context transfer
    protocol requirements are designed to not constrain how the context transfer
    protocol is used for particular feature contexts with respect to these
    points. In addition, some feature contexts may require additional processing
    on the target access router before they can be of use. Individual feature
    contexts will be standardized by the method of IETF standards action.
    The standardizationof a feature context should describe how a feature
context
    utilizes the base context transfer protocol; if update, synchronization, and
    additional proccessing are required, and, if so, how they are achieved; and
the
    transport used for the feature context.

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

Proposal 3: Add the following text:

    5.8 Feature Context Specifications

    The context transfer protocol provides a basic framework in which feature
    contexts of varying types can be transfered. Recognizing that the particular
    feature contexts may have very different needs with regard to update,
    synchronization, and transport, this section contains requirements on the
    feature context specifications. Note that these requirements do not
    constrain the actual feature context protocols themselves, but only their
    specification.

    5.8.1 A feature context specification MUST contain an IANA assigned type
    code for the particular feature context. If an experimental feature context
    protocol is being developed, a type code from the context transfer
   protocol's experimental range SHOULD be used. The type code is used in the
   context transfer container to identify the feature context.

    5.8.2 A feature context specification MUST define the byte layout of the
    individual elements of the feature context, and how those map into the
    context transfer protocol's container. The byte layout SHOULD obey
    standard IETF conventions with regard to mapping of data into on the
     wire format.

    5.8.3 If the feature context is transferred using an IETF transport layer
    protocol, and relying on specific mechanisms of the transport layer
    protocol, such as reliability or timing mechanisms, then
    the feature context specification MUST include the full details of how the
    transport layer protocol is used. One must note that employing different
    transport mechanisms for different feature context might lead to limited
    possibility of multiplexing various feature contexts

    If the feature context is transferred as an
    option on another IETF protocol, then the feature context specification MUST
    define the mapping of the context transfer container into the other
     protocol's standard option format. If the feature context is transferred
     through a non-IETF protocol (such as IAPP [4]), then the feature context
    protocol specification MUST define how the standard context transfer
   container is mapped into the non-IETF transport.

    5.8.4 A feature context specification MUST indicate whether update to
    context information is allowed if changes in the source occur after the
    context is transferred. If such changes are allowed, the feature context
    specification MUST define the change protocol message format using the
    standard context transfer container, and MUST include details of how the
    update is accomplished and triggered.

    5.8.5 A feature context specification MUST indicate whether the context
    transfer is tightly synchronized with external events, such as handover.
    The feature context specification MUST indicate what event or events
    trigger transfer.

    6.0 References

    [4]  "Recommended Practice for Multi-vendor Interaccess Point
    Interoperability via an Inter-access Point Protocol Across Distribution
    Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3,
    January, 2002.

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






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

------_=_NextPart_001_01C24306.69426960-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 13 16:47: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 QAA18754 for ; Tue, 13 Aug 2002 16:47:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08908; Tue, 13 Aug 2002 16:39:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08881 for ; Tue, 13 Aug 2002 16:39:58 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18294 for ; Tue, 13 Aug 2002 16:38:37 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DKdP727920 for ; Tue, 13 Aug 2002 16:39:25 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 16:39:25 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4CA4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby@ietf.org'" Date: Tue, 13 Aug 2002 16:39:16 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24309.7DE743B0" Subject: [Seamoby] proposals Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24309.7DE743B0 Content-Type: text/plain; charset="iso-8859-1" Section 5.5: DISAGREE with proposal 1: - Agree with 5.5.1, 5.5.2. - Disagree with 5.5.3 - Agree with 5.5.4 DISAGREE with proposal 2 If I had to chose, it would be proposal 1, but I have a problem with 5.5.3. ============================================================================ ===== Section 6/5.8: I don't understand why one proposal is section 6, and one is 5.8. There seems to be a lot of overlap between proposal 3 and section 5.1, in particular 5.8.1 and 5.1.4 (5.1.4 can be modified to refer to IANA approved codes). AGREE with proposal 1 AGREE with proposal 2 DISAGREE with proposal 3 Prefer proposal 2 ============================================================================ ===== Section 5.2 DISAGREE with proposal 1 DISAGREE with proposal 2 DISAGREE with proposal 3 Force to choose, I would choose proposal 1, although I don't think it will sit well with the IESG. We need to identify somewhere that CT runs over a transport protocol, but without all the implied solutions of proposal 2 and 3. Gary ------_=_NextPart_001_01C24309.7DE743B0 Content-Type: text/html; charset="iso-8859-1" proposals

Section 5.5:

DISAGREE with proposal 1:
    - Agree with 5.5.1, 5.5.2.
    - Disagree with 5.5.3
    - Agree with 5.5.4

DISAGREE with proposal 2

If I had to chose, it would be proposal 1, but I have a problem with 5.5.3.

=================================================================================

Section 6/5.8:

I don't understand why one proposal is section 6, and one is 5.8.

There seems to be a lot of overlap between proposal 3 and section 5.1, in
particular 5.8.1 and 5.1.4 (5.1.4 can be modified to refer to IANA approved codes).

AGREE with proposal 1
AGREE with proposal 2
DISAGREE with proposal 3

Prefer proposal 2

=================================================================================

Section 5.2

DISAGREE with proposal 1
DISAGREE with proposal 2
DISAGREE with proposal 3

Force to choose, I would choose proposal 1, although I don't think it will sit well with the IESG.
We need to identify somewhere that CT runs over a transport protocol, but without all the implied
solutions of proposal 2 and 3.

Gary
 

------_=_NextPart_001_01C24309.7DE743B0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 13 16:47: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 QAA18761 for ; Tue, 13 Aug 2002 16:47:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09991 for seamoby-archive@odin.ietf.org; Tue, 13 Aug 2002 16:48:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08908; Tue, 13 Aug 2002 16:39:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08881 for ; Tue, 13 Aug 2002 16:39:58 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18294 for ; Tue, 13 Aug 2002 16:38:37 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7DKdP727920 for ; Tue, 13 Aug 2002 16:39:25 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 16:39:25 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4CA4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby@ietf.org'" Date: Tue, 13 Aug 2002 16:39:16 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24309.7DE743B0" Subject: [Seamoby] proposals Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C24309.7DE743B0 Content-Type: text/plain; charset="iso-8859-1" Section 5.5: DISAGREE with proposal 1: - Agree with 5.5.1, 5.5.2. - Disagree with 5.5.3 - Agree with 5.5.4 DISAGREE with proposal 2 If I had to chose, it would be proposal 1, but I have a problem with 5.5.3. ============================================================================ ===== Section 6/5.8: I don't understand why one proposal is section 6, and one is 5.8. There seems to be a lot of overlap between proposal 3 and section 5.1, in particular 5.8.1 and 5.1.4 (5.1.4 can be modified to refer to IANA approved codes). AGREE with proposal 1 AGREE with proposal 2 DISAGREE with proposal 3 Prefer proposal 2 ============================================================================ ===== Section 5.2 DISAGREE with proposal 1 DISAGREE with proposal 2 DISAGREE with proposal 3 Force to choose, I would choose proposal 1, although I don't think it will sit well with the IESG. We need to identify somewhere that CT runs over a transport protocol, but without all the implied solutions of proposal 2 and 3. Gary ------_=_NextPart_001_01C24309.7DE743B0 Content-Type: text/html; charset="iso-8859-1" proposals

Section 5.5:

DISAGREE with proposal 1:
    - Agree with 5.5.1, 5.5.2.
    - Disagree with 5.5.3
    - Agree with 5.5.4

DISAGREE with proposal 2

If I had to chose, it would be proposal 1, but I have a problem with 5.5.3.

=================================================================================

Section 6/5.8:

I don't understand why one proposal is section 6, and one is 5.8.

There seems to be a lot of overlap between proposal 3 and section 5.1, in
particular 5.8.1 and 5.1.4 (5.1.4 can be modified to refer to IANA approved codes).

AGREE with proposal 1
AGREE with proposal 2
DISAGREE with proposal 3

Prefer proposal 2

=================================================================================

Section 5.2

DISAGREE with proposal 1
DISAGREE with proposal 2
DISAGREE with proposal 3

Force to choose, I would choose proposal 1, although I don't think it will sit well with the IESG.
We need to identify somewhere that CT runs over a transport protocol, but without all the implied
solutions of proposal 2 and 3.

Gary
 

------_=_NextPart_001_01C24309.7DE743B0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Aug 16 18:45: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 SAA03139 for ; Fri, 16 Aug 2002 18:45:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02863; Fri, 16 Aug 2002 18:40:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02834 for ; Fri, 16 Aug 2002 18:40:22 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02988 for ; Fri, 16 Aug 2002 18:39:00 -0400 (EDT) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7GMdop19502 for ; Fri, 16 Aug 2002 18:39:51 -0400 (EDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Aug 2002 18:39:50 -0400 Message-ID: From: "Chuah, Mooi Choo (Mooi)" To: seamoby@ietf.org Date: Fri, 16 Aug 2002 18:39:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Seamoby] FW: WCNC 2003 - PAPER DEADLINE EXTENDED TO 1 SEPTEMBER, 2002. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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: CommunicationsSociety@comsoc.org [mailto:CommunicationsSociety@comsoc.org] Sent: Friday, August 16, 2002 3:12 PM To: Conferencesa@comsoc.org Subject: WCNC 2003 - PAPER DEADLINE EXTENDED TO 1 SEPTEMBER, 2002. "The Dawn of Pervasive Communication" is the WCNC 2003 theme. WCNC'03 will cover in depth the physical layer, networks, and services. At www.wcnc.org/2003 you will find a list of technical paper topics plus the call for papers. Or, if your preference is panels, you'll also find all the information you need to chair a panel (or become a panelist). WCNC'03 will take place from 16-20 March 2003 in New Orleans, LA, USA - a favorite city for many ComSoc attendees. Once again, we are planning to co-locate again with CTIA, the largest and the highest ranked wireless show in the world. Whether you wish to be presenter or a panelist, join us at WCNC 2003, ComSoc's flagship conference in the area of wireless communications and technology. J. Roberto B. de Marca Chair WCNC'03 Technical Program Committee _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Aug 16 19:37: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 SAA03144 for ; Fri, 16 Aug 2002 18:45:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03072 for seamoby-archive@odin.ietf.org; Fri, 16 Aug 2002 18:46:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02863; Fri, 16 Aug 2002 18:40:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02834 for ; Fri, 16 Aug 2002 18:40:22 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02988 for ; Fri, 16 Aug 2002 18:39:00 -0400 (EDT) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7GMdop19502 for ; Fri, 16 Aug 2002 18:39:51 -0400 (EDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Aug 2002 18:39:50 -0400 Message-ID: From: "Chuah, Mooi Choo (Mooi)" To: seamoby@ietf.org Date: Fri, 16 Aug 2002 18:39:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Seamoby] FW: WCNC 2003 - PAPER DEADLINE EXTENDED TO 1 SEPTEMBER, 2002. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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: CommunicationsSociety@comsoc.org [mailto:CommunicationsSociety@comsoc.org] Sent: Friday, August 16, 2002 3:12 PM To: Conferencesa@comsoc.org Subject: WCNC 2003 - PAPER DEADLINE EXTENDED TO 1 SEPTEMBER, 2002. "The Dawn of Pervasive Communication" is the WCNC 2003 theme. WCNC'03 will cover in depth the physical layer, networks, and services. At www.wcnc.org/2003 you will find a list of technical paper topics plus the call for papers. Or, if your preference is panels, you'll also find all the information you need to chair a panel (or become a panelist). WCNC'03 will take place from 16-20 March 2003 in New Orleans, LA, USA - a favorite city for many ComSoc attendees. Once again, we are planning to co-locate again with CTIA, the largest and the highest ranked wireless show in the world. Whether you wish to be presenter or a panelist, join us at WCNC 2003, ComSoc's flagship conference in the area of wireless communications and technology. J. Roberto B. de Marca Chair WCNC'03 Technical Program Committee _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Aug 20 11:33:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17498 for ; Tue, 20 Aug 2002 11:33:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15398; Tue, 20 Aug 2002 11:29:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15362 for ; Tue, 20 Aug 2002 11:29:03 -0400 (EDT) Received: from server.westuchurch.com (adsl-64-218-224-193.dsl.hstntx.swbell.net [64.218.224.193]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17389; Tue, 20 Aug 2002 11:27:40 -0400 (EDT) Received: from mail251.finestoffers.com ([61.145.75.241]) by server.westuchurch.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 Aug 2002 10:32:15 -0500 Date: Tue, 20 Aug 2002 23:30:29 +0800 From: "Rudy Rutledge" X-Mailer: The Bat! (v1.53d) X-Priority: 3 To: seamo27@yahoo.com CC: seamoby-request@ietf.org, seamoby@ietf.org, seamon@usa.net, seamonds@iei.net Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 20 Aug 2002 15:32:16.0536 (UTC) FILETIME=[C396C980:01C2485E] Content-Transfer-Encoding: 7bit Subject: [Seamoby] HGH Myth(s) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, seamo27@yahoo.com

Human Growth Hormone Therapy

Lose weight while building lean muscle mass
and reversing the ravages of aging all at once.
As seen on NBC, CBS, and CNN, and even Oprah! The health
discovery that actually reverses aging while burning fat,
without dieting or exercise! This proven discovery has even
been reported on by the New England Journal of Medicine.
Forget aging and dieting forever! And it's Guaranteed!

Lose Weight
Build Muscle Tone
Reverse Aging
Increased Libido
Duration Of Penile Erection

Healthier Bones
Improved Memory
Improved skin
New Hair Growth
Wrinkle Disappearance

Visit Our Web Site and Learn The Facts : Click Here

OR Here


You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here
_______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Aug 20 11:34: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 LAA17506 for ; Tue, 20 Aug 2002 11:34:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16066 for seamoby-archive@odin.ietf.org; Tue, 20 Aug 2002 11:35:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15398; Tue, 20 Aug 2002 11:29:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15362 for ; Tue, 20 Aug 2002 11:29:03 -0400 (EDT) Received: from server.westuchurch.com (adsl-64-218-224-193.dsl.hstntx.swbell.net [64.218.224.193]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17389; Tue, 20 Aug 2002 11:27:40 -0400 (EDT) Received: from mail251.finestoffers.com ([61.145.75.241]) by server.westuchurch.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 Aug 2002 10:32:15 -0500 Date: Tue, 20 Aug 2002 23:30:29 +0800 From: "Rudy Rutledge" X-Mailer: The Bat! (v1.53d) X-Priority: 3 To: seamo27@yahoo.com CC: seamoby-request@ietf.org, seamoby@ietf.org, seamon@usa.net, seamonds@iei.net Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 20 Aug 2002 15:32:16.0536 (UTC) FILETIME=[C396C980:01C2485E] Content-Transfer-Encoding: 7bit Subject: [Seamoby] HGH Myth(s) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, seamo27@yahoo.com

Human Growth Hormone Therapy

Lose weight while building lean muscle mass
and reversing the ravages of aging all at once.
As seen on NBC, CBS, and CNN, and even Oprah! The health
discovery that actually reverses aging while burning fat,
without dieting or exercise! This proven discovery has even
been reported on by the New England Journal of Medicine.
Forget aging and dieting forever! And it's Guaranteed!

Lose Weight
Build Muscle Tone
Reverse Aging
Increased Libido
Duration Of Penile Erection

Healthier Bones
Improved Memory
Improved skin
New Hair Growth
Wrinkle Disappearance

Visit Our Web Site and Learn The Facts : Click Here

OR Here


You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here
_______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Aug 22 22:24:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16425 for ; Thu, 22 Aug 2002 22:24:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7N2Pfo01276; Thu, 22 Aug 2002 22:25:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7N2Mto01207 for ; Thu, 22 Aug 2002 22:22:55 -0400 Received: from bumilnet.com ([211.195.1.234]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16347 for ; Thu, 22 Aug 2002 22:21:21 -0400 (EDT) From: voki@voki.co.kr Received: (from nobody@localhost) by bumilnet.com (8.11.3/8.11.3) id g7N2N2Z08780 for seamoby@ietf.org; Fri, 23 Aug 2002 11:23:02 +0900 Date: Fri, 23 Aug 2002 11:23:02 +0900 Message-Id: <200208230223.g7N2N2Z08780@bumilnet.com> X-Authentication-Warning: bumilnet.com: nobody set sender to voki@voki.co.kr using -f To: seamoby@ietf.org Content-Type: text/html;charset=EUC-KR Subject: [Seamoby] [±¤°í] ÃÖ°íÀÇ º¹±Ç¸í´ç º¸Å°¸¦ ¾Æ½Ê´Ï±î? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , º¹±Ç¸í´ç º¸Å°
_______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Aug 22 22:26:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16465 for ; Thu, 22 Aug 2002 22:26:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7N2R4l01363 for seamoby-archive@odin.ietf.org; Thu, 22 Aug 2002 22:27:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7N2R3o01360 for ; Thu, 22 Aug 2002 22:27:03 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16450 for ; Thu, 22 Aug 2002 22:25:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7N2Pfo01276; Thu, 22 Aug 2002 22:25:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7N2Mto01207 for ; Thu, 22 Aug 2002 22:22:55 -0400 Received: from bumilnet.com ([211.195.1.234]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16347 for ; Thu, 22 Aug 2002 22:21:21 -0400 (EDT) From: voki@voki.co.kr Received: (from nobody@localhost) by bumilnet.com (8.11.3/8.11.3) id g7N2N2Z08780 for seamoby@ietf.org; Fri, 23 Aug 2002 11:23:02 +0900 Date: Fri, 23 Aug 2002 11:23:02 +0900 Message-Id: <200208230223.g7N2N2Z08780@bumilnet.com> X-Authentication-Warning: bumilnet.com: nobody set sender to voki@voki.co.kr using -f To: seamoby@ietf.org Content-Type: text/html;charset=EUC-KR Subject: [Seamoby] [±¤°í] ÃÖ°íÀÇ º¹±Ç¸í´ç º¸Å°¸¦ ¾Æ½Ê´Ï±î? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , º¹±Ç¸í´ç º¸Å°
_______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 26 15:34:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20237 for ; Mon, 26 Aug 2002 15:34:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QJWpo17539; Mon, 26 Aug 2002 15:32:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QJVIo17495 for ; Mon, 26 Aug 2002 15:31:18 -0400 Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20007 for ; Mon, 26 Aug 2002 15:29:44 -0400 (EDT) Message-ID: <021801c24d36$d3b78e30$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 26 Aug 2002 12:09:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] WG Last Call Conclusion on draft-seamoby-card-requirements-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Working Group Last Call has concluded on draft-seamoby-card-requirements-01.txt. There were no comments from the Working Group. The document will now be sent to the IESG for approval. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Aug 26 15:35:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20274 for ; Mon, 26 Aug 2002 15:35:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QJafV17655 for seamoby-archive@odin.ietf.org; Mon, 26 Aug 2002 15:36:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QJafo17652 for ; Mon, 26 Aug 2002 15:36:41 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20262 for ; Mon, 26 Aug 2002 15:35:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QJWpo17539; Mon, 26 Aug 2002 15:32:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QJVIo17495 for ; Mon, 26 Aug 2002 15:31:18 -0400 Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20007 for ; Mon, 26 Aug 2002 15:29:44 -0400 (EDT) Message-ID: <021801c24d36$d3b78e30$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 26 Aug 2002 12:09:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] WG Last Call Conclusion on draft-seamoby-card-requirements-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Working Group Last Call has concluded on draft-seamoby-card-requirements-01.txt. There were no comments from the Working Group. The document will now be sent to the IESG for approval. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Aug 26 16:28:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21418 for ; Mon, 26 Aug 2002 16:28:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QKQLo19921; Mon, 26 Aug 2002 16:26:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QKQ0o19906 for ; Mon, 26 Aug 2002 16:26:00 -0400 Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21368 for ; Mon, 26 Aug 2002 16:24:25 -0400 (EDT) Message-ID: <028c01c24d3e$8d5898a0$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 26 Aug 2002 13:24:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Fw: Results of CT Requirements Concensus Call Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think the IETF lists were down at the beginning of last week, so this never went out. jak ----- Original Message ----- From: "James Kempf" To: Sent: Tuesday, August 20, 2002 12:59 PM Subject: Results of CT Requirements Concensus Call > So it looks as if we have rough concensus around the following two issues: > > Issue 1 (Section 5.2): Preference is for Proposal 2, namely to say that the > protocol must support any transport but does not include a specific default. > > Issue 2 (Section 5.5): Preference is for Proposal 1, namely to include language > specifying requirements on the feature context specifications with regard to the > items that the generic CT protocol doesn't support. > > The text for these two is included below. Gary, can you please put this text > into the document? > > The comments came back split on Issue 3. Half the people supported Proposal 2, > to include a separate section with a paragraph stating that feature contexts > must be standardized but not in requirements language. The other half supported > Proposal 3, which establishes specific requirements on feature context > standardization. > > Given that Proposal 1 for Issue 2 already has a few requirements on feature > context standardization, I'd like to suggest that we go with Proposal 2 for > Issue 3, a separate section with a few general statements about what feature > context standards must support, but not specific requirements. > > The text for Proposal 2 of Issue 3 is included below. > > Comments? > > jak > > -------------------------------------------- > Issue 1: Concensus text > -------------------------------------------- > > 5.2 Transport Requirements > > This section contains requirements on the context transfer transport. > > 5.2.1 The context transfer protocol MUST be specified so that it is > independent of the underlying transport. > > Recognizing that the transport characteristics for context transfer > will depend on the particular application, it should be possible to > transfer context directly on top of reliable transports, such as TCP > or SCTP, unreliable transports, such as UDP, or as an option or > extension on another protocol, such as handover signaling. > > ------------------------------------------- > Issue 2: Concensus text > ------------------------------------------- > > 5.5 Context Update and Synchronization > > 5.5.1 The base context transfer protocol SHOULD NOT provide direct support > for synchronization with outside events, since synchronization is > not a requirement for all or even most feature contexts. > > 5.5.2 The base context transfer protocol MUST allow individual feature > context specifications to define their own synchronization with > external events. > > 5.5.3 The base context transfer protocol SHOULD NOT provide support for > updating context after it is transfered, since individual feature > contexts will differ in their need for update. > > 5.5.4 The base context transfer protocol MUST allow individual feature > context specifications to define their own update procedures if > required. > > Most feature contexts will not require synchronization, however > there are a few that may. Header compression, for example, may require > that the header compressor on the old access router cease and the > compressor on the new router start in synchrony with hand over of > routing to the new router; otherwise, the compressor on the new router > will not be properly synchronized. Since most contexts don't need > synchronization support, the general CT solution need not support it, > but it should not provide a hinderance to those feature contexts > that do. > > Feature contexts will differ in whether or not they require update. > A feature context such as QoS parameters for the service level > agreement with a user may not involve dynamically changing information, > but it may change during or after context transfer. Such feature contexts > may benefit from allowing the context to change after the transfer is > completed. Other feature contexts, such as header compression, may be > tightly synchronized with external events and changes on the old router > need to be discarded since the new router's state may already have been > modified. > > ------------------------------------- > Issue 3: Proposed Compromise Text > ------------------------------------- > > Section 6: Standardization of Feature Contexts > > The context transfer protocol provides a basic framework in which feature > contexts of varying types can be transferred. Recognizing that the > particular feature contexts may have very different needs with regard > to update, synchronization, and transport, the base context transfer > protocol requirements are designed to not constrain how the context transfer > protocol is used for particular feature contexts with respect to these > points. In addition, some feature contexts may require additional processing > on the target access router before they can be of use. Individual feature > contexts will be standardized by the method of IETF standards action. > The standardizationof a feature context should describe how a feature > context utilizes the base context transfer protocol; if update, > synchronization, > and additional proccessing are required, and, if so, how they are achieved; > and the transport used for the feature context. > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Aug 26 16:29:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21449 for ; Mon, 26 Aug 2002 16:29:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QKUYl20044 for seamoby-archive@odin.ietf.org; Mon, 26 Aug 2002 16:30:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QKUYo20041 for ; Mon, 26 Aug 2002 16:30:34 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21441 for ; Mon, 26 Aug 2002 16:28:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QKQLo19921; Mon, 26 Aug 2002 16:26:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QKQ0o19906 for ; Mon, 26 Aug 2002 16:26:00 -0400 Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21368 for ; Mon, 26 Aug 2002 16:24:25 -0400 (EDT) Message-ID: <028c01c24d3e$8d5898a0$296015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 26 Aug 2002 13:24:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Fw: Results of CT Requirements Concensus Call Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think the IETF lists were down at the beginning of last week, so this never went out. jak ----- Original Message ----- From: "James Kempf" To: Sent: Tuesday, August 20, 2002 12:59 PM Subject: Results of CT Requirements Concensus Call > So it looks as if we have rough concensus around the following two issues: > > Issue 1 (Section 5.2): Preference is for Proposal 2, namely to say that the > protocol must support any transport but does not include a specific default. > > Issue 2 (Section 5.5): Preference is for Proposal 1, namely to include language > specifying requirements on the feature context specifications with regard to the > items that the generic CT protocol doesn't support. > > The text for these two is included below. Gary, can you please put this text > into the document? > > The comments came back split on Issue 3. Half the people supported Proposal 2, > to include a separate section with a paragraph stating that feature contexts > must be standardized but not in requirements language. The other half supported > Proposal 3, which establishes specific requirements on feature context > standardization. > > Given that Proposal 1 for Issue 2 already has a few requirements on feature > context standardization, I'd like to suggest that we go with Proposal 2 for > Issue 3, a separate section with a few general statements about what feature > context standards must support, but not specific requirements. > > The text for Proposal 2 of Issue 3 is included below. > > Comments? > > jak > > -------------------------------------------- > Issue 1: Concensus text > -------------------------------------------- > > 5.2 Transport Requirements > > This section contains requirements on the context transfer transport. > > 5.2.1 The context transfer protocol MUST be specified so that it is > independent of the underlying transport. > > Recognizing that the transport characteristics for context transfer > will depend on the particular application, it should be possible to > transfer context directly on top of reliable transports, such as TCP > or SCTP, unreliable transports, such as UDP, or as an option or > extension on another protocol, such as handover signaling. > > ------------------------------------------- > Issue 2: Concensus text > ------------------------------------------- > > 5.5 Context Update and Synchronization > > 5.5.1 The base context transfer protocol SHOULD NOT provide direct support > for synchronization with outside events, since synchronization is > not a requirement for all or even most feature contexts. > > 5.5.2 The base context transfer protocol MUST allow individual feature > context specifications to define their own synchronization with > external events. > > 5.5.3 The base context transfer protocol SHOULD NOT provide support for > updating context after it is transfered, since individual feature > contexts will differ in their need for update. > > 5.5.4 The base context transfer protocol MUST allow individual feature > context specifications to define their own update procedures if > required. > > Most feature contexts will not require synchronization, however > there are a few that may. Header compression, for example, may require > that the header compressor on the old access router cease and the > compressor on the new router start in synchrony with hand over of > routing to the new router; otherwise, the compressor on the new router > will not be properly synchronized. Since most contexts don't need > synchronization support, the general CT solution need not support it, > but it should not provide a hinderance to those feature contexts > that do. > > Feature contexts will differ in whether or not they require update. > A feature context such as QoS parameters for the service level > agreement with a user may not involve dynamically changing information, > but it may change during or after context transfer. Such feature contexts > may benefit from allowing the context to change after the transfer is > completed. Other feature contexts, such as header compression, may be > tightly synchronized with external events and changes on the old router > need to be discarded since the new router's state may already have been > modified. > > ------------------------------------- > Issue 3: Proposed Compromise Text > ------------------------------------- > > Section 6: Standardization of Feature Contexts > > The context transfer protocol provides a basic framework in which feature > contexts of varying types can be transferred. Recognizing that the > particular feature contexts may have very different needs with regard > to update, synchronization, and transport, the base context transfer > protocol requirements are designed to not constrain how the context transfer > protocol is used for particular feature contexts with respect to these > points. In addition, some feature contexts may require additional processing > on the target access router before they can be of use. Individual feature > contexts will be standardized by the method of IETF standards action. > The standardizationof a feature context should describe how a feature > context utilizes the base context transfer protocol; if update, > synchronization, > and additional proccessing are required, and, if so, how they are achieved; > and the transport used for the feature context. > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Aug 28 17:21:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19792 for ; Wed, 28 Aug 2002 17:21:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SLLUo23269; Wed, 28 Aug 2002 17:21:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RJGho28219 for ; Tue, 27 Aug 2002 15:16:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Date: Tue, 27 Aug 2002 14:44:44 -0400 Subject: [Seamoby] Nomcom call for volunteers Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Aug 28 17:22:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19838 for ; Wed, 28 Aug 2002 17:22:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SLNAn23310 for seamoby-archive@odin.ietf.org; Wed, 28 Aug 2002 17:23:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SLN9o23307 for ; Wed, 28 Aug 2002 17:23:09 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19825 for ; Wed, 28 Aug 2002 17:21:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SLLUo23269; Wed, 28 Aug 2002 17:21:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RJGho28219 for ; Tue, 27 Aug 2002 15:16:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Date: Tue, 27 Aug 2002 14:44:44 -0400 Subject: [Seamoby] Nomcom call for volunteers Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Aug 29 06:00:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14417 for ; Thu, 29 Aug 2002 06:00:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TA0so02388; Thu, 29 Aug 2002 06:00:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7T9xOo02325 for ; Thu, 29 Aug 2002 05:59:24 -0400 Received: from yahoo.com ([218.76.241.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14386 for ; Thu, 29 Aug 2002 05:57:30 -0400 (EDT) From: gtts1@cable.net.co Received: from unknown (HELO rly-xw05.mx.aol.com) (245.158.118.110) by rly-xw01.mx.aol.com with local; Tue, 27 Aug 2002 18:56:53 -1000 Reply-To: Message-ID: <163FF88B-BAE1-11D6-B365-00E0188F81AA@9BWEXW6x> To: Date: Thu, 29 Aug 2002 05:59:17 -0400 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A1_11D12G3I.J1343N65" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal Subject: [Seamoby] Laser Toner Cartridges At Low Prices. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , ------=_NextPart_000_00A1_11D12G3I.J1343N65 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+DQo8eC10YWI+DQoNCjxoZWFkPg0KPC9oZWFkPg0KDQo8cCBhbGlnbj0iY2VudGVyIj4N CjxiPjxhIGhyZWY9Im1haWx0bzpndHRzMUBjYWJsZS5uZXQuY28iPjxmb250IGNvbG9yPSIjMDAw MDgwIiBzaXplPSIzIiBmYWNlPSJBcmlhbCI+R1QgVE9ORVINClNVUFBMSUVTPGJyPkxhc2VyIHBy aW50ZXIgYW5kIGNvbXB1dGVyIHN1cHBsaWVzPGJyPg0KICAxLTg2Ni0yMzctNzM5NzwvZm9udD48 L2E+PC9iPg0KDQo8cCBhbGlnbj0iY2VudGVyIj4NCjxpbWcgYm9yZGVyPSIwIiANCnNyYz0iaHR0 cDovL2ltYWdlcy5nb29nbGUuY29tL2ltYWdlcz9xPXRibjp0R2kyNWJCR000b0M6ZGF0YWRldmlj ZXMuaG9tZS5taW5kc3ByaW5nLmNvbS80MDAwcHJpbnRlci5qcGciIHdpZHRoPSI4MSIgDQpoZWln aHQ9IjY5Ij4NCjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly9pbWFnZXMuZ29vZ2xlLmNvbS9p bWFnZXM/cT10Ym46WW9BdDRyVG1aOHNDOnd3dy5jYXJ0cmlkZ2UtZmlsbC5jby51ay9ncm9vcHBy aW50ZXIuZ2lmIiANCndpZHRoPSI4MSIgaGVpZ2h0PSI2OSI+DQo8cD4NCjxiPjxpPjxmb250IGNv bG9yPSIjODA4MDAwIiBmYWNlPSJBcmlhbCIgc2l6ZT0iNCI+U2F2ZSB1cCB0byA0MCUgZnJvbSBy ZXRhaWwgcHJpY2Ugb24gbGFzZXIgcHJpbnRlciB0b25lcg0KY2FydHJpZGdlcyw8YnI+DQpjb3Bp ZXIgYW5kIGZheCBjYXJ0cmlkZ2VzLjwvZm9udD48L2k+DQo8L2I+IDwvcD4NCjxwPg0KPGI+PGk+ PGEgaHJlZj0iI3ByaWNlcyI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyIgc2l6ZT0iMyIgY29s b3I9IiMwMDAwRkYiPkNIRUNLIE9VVCBPVVIgR1JFQVQNClBSSUNFUyE8L2ZvbnQ+PC9hPjwvaT4N CjwvYj4gPC9wPg0KPHA+PGI+PGk+PGZvbnQgY29sb3I9IiM4MDAwMCIgc2l6ZT0iMyIgZmFjZT0i Q29taWMgU2FucyBNUyI+SWYgeW91IHJlY2VpdmVkIHRoaXMgZW1haWwgb24gZXJyb3IsIHBsZWFz ZSByZXBseSB0byANCmd0dHMxQGNhYmxlLm5ldC5jbyB3aXRoIHN1YmplY3Q6IFJFTU9WRS4uLiBz b3JyeSBmb3IgdGhlIGluY29udmVuaWVuY2UuDQo8cD48Yj48aT48Zm9udCBjb2xvcj0iIzgwODAw MCIgc2l6ZT0iNCIgZmFjZT0iQXJpYWwiPlBsZWFzZSBmb3J3YXJkIHRvIHRoZSBwZXJzb24gcmVz cG9uc2libGUgZm9yIHB1cmNoYXNpbmcgeW91ciBsYXNlciANCnByaW50ZXINCnN1cHBsaWVzLjwv Zm9udD48L2k+DQo8L3A+DQo8cD48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PGZvbnQgY29s b3I9IiM4MDgwMDAiPjx4LXRhYj4mbmJzcDsmbmJzcDsmbmJzcDsgT3JkZXIgYnkNCnBob25lOiAo dG9sbCBmcmVlKSAxLTg2Ni0yMzctNzM5Nw0KPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDgwIj4g PGJyPg0KPC9mb250Pg0KPC9wPg0KPC9mb250Pjxmb250IGNvbG9yPSIjODA4MDAwIj48eC10YWI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9yZGVyIGJ5IGVtYWlsOiA8L2ZvbnQ+DQo8L2ZvbnQ+DQo8Zm9u dCBjb2xvcj0iIzAwMDBGRiIgZmFjZT0iQXJpYWwiIHNpemU9IjMiPlNpbXBseSByZXBseTwvZm9u dD48Zm9udCBjb2xvcj0iIzAwMDA4MCI+IHRoaXMgbWVzc2FnZSBvciA8L2ZvbnQ+PGEgDQpocmVm PSJtYWlsdG86Z3R0czFAY2FibGUubmV0LmNvIj48Zm9udCBjb2xvcj0iIzAwMDBGRiIgZmFjZT0i QXJpYWwiIHNpemU9IjMiPmNsaWNrIGhlcmU8L2ZvbnQ+PC9hPjxmb250IGZhY2U9IkFyaWFsIiAN CnNpemU9IjIiPjxmb250IGNvbG9yPSIjODA4MDAwIj4mbmJzcDsNCndpdGggc3ViamVjdDogPC9m b250Pjxmb250IGNvbG9yPSIjMDAwMDgwIj4gT1JERVI8L2ZvbnQ+DQo8L2ZvbnQ+DQo8L3A+DQo8 cD48Zm9udCBmYWNlPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9mb250PjwvYj4gPGZvbnQg ZmFjZT0iQXJpYWwiPiA8Yj4gPGZvbnQgc2l6ZT0iMiI+IDxmb250IGNvbG9yPSIjODA4MDAwIj5F bWFpbA0KcmVtb3ZhbDogPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDgwIj5TaW1wbHkgcmVwbHkg dGhpcyBtZXNzYWdlIG9yIDwvZm9udD4NCjwvZm9udD4NCjxhIGhyZWY9Im1haWx0bzpndHRzMUBj YWJsZS5uZXQuY28iPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMDAwMEZGIj5jbGljayBoZXJlPC9m b250PjwvYT4gPGZvbnQgc2l6ZT0iMiI+IDxmb250IA0KY29sb3I9IiM4MDgwMDAiPg0KPHgtdGFi PiZuYnNwOyB3aXRoIHN1YmplY3Q6DQo8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwODAiPiBSRU1P VkU8L2ZvbnQ+PGZvbnQgY29sb3I9IiM4MDgwMDAiPg0KPGJyPjxicj4NCjwvZm9udD4NCjwvZm9u dD4NCjxmb250IGNvbG9yPSIjMDAwMDgwIiBzaXplPSI0Ij5Vbml2ZXJzaXR5PC9mb250PiA8Zm9u dCBzaXplPSIyIj4gIGFuZC9vcg0KPC9mb250Pg0KPGZvbnQgY29sb3I9IiMwMDAwODAiIHNpemU9 IjQiPlNjaG9vbDwvZm9udD48Zm9udCBzaXplPSIzIj4gPC9mb250PiA8Zm9udCBzaXplPSIyIj4g cHVyY2hhc2UNCm9yZGVycyBXRUxDT01FLiAobm8gY3JlZGl0IGFwcHJvdmFsIHJlcXVpcmVkKTxi cj4NClBheSBieSBjaGVjaywgYy5vLmQsIG9yIHB1cmNoYXNlIG9yZGVyIChuZXQgMzAgZGF5cyku DQo8L2ZvbnQ+DQo8L2I+DQo8L2ZvbnQ+DQo8L3A+DQo8cD48Yj48aT48Zm9udCBjb2xvcj0iIzAw MDA4MCIgc2l6ZT0iMyI+V0UgQUNDRVBUIEFMTCBNQUpPUiBDUkVESVQgQ0FSRFMhPC9mb250Pjwv aT48L2I+DQo8L3A+DQo8cD48Yj48YSBocmVmPSIjY29sb3IiPjxmb250IGZhY2U9IkFyaWFsIiBz aXplPSIzIj5OZXchIEhQIDQ1MDAvNDU1MCBzZXJpZXMgY29sb3INCmNhcnRyaWRnZXMgaW4gc3Rv Y2shPC9mb250PjwvYT48L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVmdCI+IDxmb250IHNpemU9IjIi PiA8Yj4NCjxpPjxmb250IGNvbG9yPSIjODA4MDAwIiBmYWNlPSJBcmlhbCI+DQpPdXIgY2FydHJp ZGdlIHByaWNlcyBhcmUgYXMgZm9sbG93czogPGJyPg0KKHBsZWFzZSBvcmRlciBieSBpdGVtIG51 bWJlcik8L2ZvbnQ+PC9pPg0KPC9iPg0KPC9mb250Pg0KPC9wPg0KPHAgYWxpZ249ImxlZnQiPiA8 Yj48Zm9udCBmYWNlPSJMdWNpZGEgU2FucyBUeXBld3JpdGVyIiBjb2xvcj0iIzAwMDAwMCIgDQpz aXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpIZXdsZXR0DQog ICAgIFBhY2thcmQ8YSANCm5hbWU9InByaWNlcyI+PC9hPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYg0Kc3A7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+DQo8L3A+DQo8 cCBhbGlnbj0ibGVmdCI+IDx0dD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGI+PGZvbnQgc2l6ZT0i MiI+MSAtLSA5MjI3NEEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCA0TCwgNE1MLCA0UCwg NE1QDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0kNDcuNTA8YnI+DQo8L2ZvbnQ+DQo8c3BhbiBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+DQo8Zm9udCBzaXplPSIyIj4NCjIgLS0g QzQwOTJBIEJsYWNrIFRvbmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgMTEwMEEsIEFTRSwgMzIw MFNFLS0tLS0tLS0tLS0tLS0tLS0kNDUuNTA8YnI+DQo8L2ZvbnQ+DQo8L3NwYW4+DQo8Zm9udCBz aXplPSIyIj4NCjJBIC0gQzcxMTVBIFRvbmVyIENhcnRyaWRnZSBGb3IgSFAgTGFzZXJKZXQgMTAw MCwgMTIwMCwgMzMzMCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0kNTUuNTA8YnI+DQo8c3BhbiBzdHls ZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+DQoyQiAtIEM3MTE1WCBIaWdoIENhcGFjaXR5 IFRvbmVyIENhcnRyaWRnZSBmb3IgSFAgTGFzZXJKZXQgMTAwMCwgMTIwMCwgMzMzMCAtLS0tLS0t JDY1LjUwPGJyPg0KPC9zcGFuPg0KMyAtLSA5MjI5NUEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNl ckpldCBJSSwgSUlELCBJSUksIElJSUQgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ0OS41MDxicj4N CjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4NCjQgLS0gOTIyNzVBIFRv bmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgSUlQLCBJSVArLCBJSUlQIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0kNTUuNTA8YnI+DQo8L3NwYW4+DQo1IC0tIEMzOTAzQSBUb25lciBDYXJ0cmlk Z2UgZm9yIExhc2VySmV0IDVQLCA1TVAsIDZQLCA2UHNlLCA2TVAsIDZQeGkgLS0tLS0tLS0tLS0t JDQ2LjUwPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPg0KNiAt LSBDMzkwOUEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCA1U2ksIDVTaU1YLCA1U2kgQ29w aWVyLCA4MDAwIC0tLS0tLS0tLS0tLSQ5Mi41MDxicj4NCjwvc3Bhbj4NCjcgLS0gQzQwOTZBIFRv bmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgMjEwMCwgMjIwMERTRSwgMjIwMERUTiAtLS0tLS0t LS0tLS0tLS0tLS0kNzIuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0 QzRBNiI+DQo4IC0gQzQxODJYIFVsdHJhUHJlY2lzZSBIaWdoIENhcGFjaXR5IFRvbmVyIENhcnRy aWRnZSBmb3IgTGFzZXJKZXQgODEwMCBTZXJpZXMtLS0kMTI1LjUwPGJyPg0KPC9zcGFuPg0KOSAt LSBDMzkwNkEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCA1TCwgNUwgWHRyYSwgNkxzZSwg NkwsIDZMeGksIDMxMDBzZS0tLS0tLSQ0Mi41MCA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogI0M0QzRBNiI+DQo5QSAtIEMzOTA2QSBUb25lciBDYXJ0cmlkZ2UgZm9yIExhc2Vy SmV0IDMxMDAsIDMxNTAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJDQyLjUwPGJyPg0K PC9zcGFuPg0KMTAgLSBDMzkwMEEgQmxhY2sgVG9uZXIgQ2FydHJpZGdlIGZvciBIUCBMYXNlckpl dCA0TVYsIDRWIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ4OS41MDxicj4NCjxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4NCjExIC0gQzQxMjdBIEJsYWNrIFRvbmVyIENh cnRyaWRnZSBmb3IgTGFzZXJKZXQgNDAwMFNFLCA0MDAwTiwgNDAwMFQsIDQwMDBUTiAtLS0tLS0k NzYuNTA8YnI+DQo8L3NwYW4+DQoxMUEtIEM4MDYxQSBCbGFjayBMYXNlciBUb25lciBmb3IgSFAg TGFzZXJKZXQgNDEwMCwgNDEwME4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJDc2LjUwPGJyPg0K PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPg0KMTFCLSBDODA2MVggSGln aCBDYXBhY2l0eSBUb25lciBDYXJ0cmlkZ2UgZm9yIExKNDEwMCwgNDEwME4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSQ4NS41MDxicj4NCjwvc3Bhbj4NCjExQy0gQzQxMjdYIEhpZ2ggQ2FwYWNpdHkg QmxhY2sgQ2FydHJpZGdlIGZvciBMYXNlckpldCA0MDAwU0UsNDAwME4sNDAwMFQsNDAwMFRODQot JDg0LjUwPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPg0KMTIg LSA5MjI5MUEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCBJSUlTaSwgNFNpLCA0U2lNWCAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ1Ny41MDxicj4NCjwvc3Bhbj4NCjEzIC0gOTIyOThBIFRv bmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgNCwgNCBQbHVzLCA0TSwgNE0gUGx1cywgNSwgNXNl LCA1TSwgNU4NCi0tJDQ2LjUwPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICND NEM0QTYiPg0KMTQgLSBDNDEyOVggSGlnaCBDYXBhY2l0eSBCbGFjayBUb25lciBDYXJ0cmlkZ2Ug Zm9yIExhc2VySmV0IDUwMDBOIC0tLS0tLS0tLS0tLS0tLSQ5Ny41MDxicj4NCjwvc3Bhbj4NCjE1 IC0gTEFTRVJGQVggNTAwLCA3MDAgKEZYMSkgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0kNDkuMDA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogI0M0QzRBNiI+DQoxNiAtIExBU0VSRkFYIDUwMDAsIDcwMDAgKEZYMikgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJDU0LjAwPGJyPg0K PC9zcGFuPg0KMTcgLSBMQVNFUkZBWCAoRlgzKSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ0OS4wMDwvZm9udD48L2I+PGZvbnQg c2l6ZT0iMiI+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYi Pg0KMTggLSBMQVNFUkZBWCAoRlg0KSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ0OS4wMDwvc3Bhbj48L2I+PC9mb250PjwvZm9u dD48L3R0Pg0KPC9wPg0KPHAgYWxpZ249ImxlZnQiPiA8Yj48Zm9udCBmYWNlPSJMdWNpZGEgU2Fu cyBUeXBld3JpdGVyIiANCnNpemU9IjMiPkl0ZW0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCkhld2xldHQgUGFja2FyZCAt IENvbG9yPGEgDQpuYW1lPSJjb2xvciI+PC9hPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KJm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVm dCI+IDx0dD48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGZvbnQg ZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRlciIgc2l6ZT0iMiIgDQpjb2xvcj0iIzAwMDAwMCI+ QzEgLS0gQzQxOTRhIFRvbmVyDQpDYXJ0cmlkZ2UsDQpZZWxsb3cgKGNvbG9yIGxqIDQ1MDAvNDU1 MCBzZXJpZXMpLS0tLS0tLS0tLS0tLS0tLS0tICQgODkuNTA8YnI+DQo8L2ZvbnQ+PC9zcGFuPjxm b250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIHNpemU9IjIiIGNvbG9yPSIjMDAwMDAw Ij5DMiAtLSBDNDE5M2EgVG9uZXINCkNhcnRyaWRnZSwgTWFnZW50YSAoY29sb3IgbGogNDUwMC80 NTUwIHNlcmllcyktLS0tLS0tLS0tLS0tLS0tLQ0KJCA4OS41MDxicj4NCjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij5DMyAtLSBDNDE5MmEgdG9uZXIgY2FydHJpZGdlLCBj eWFuIChjb2xvciBsaiA0NTAwLzQ1NTAgc2VyaWVzKS0tLS0tLS0tLS0tLS0tLS0tLS0tICQNCjg5 LjUwPGJyPg0KPC9zcGFuPkM0IC0tIGM0MTkxYSB0b25lciBjYXJ0cmlkZ2UsIGJsYWNrIChjb2xv ciBsaiA0NTAwLzQ1NTAgc2VyaWVzKS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNzQuNTA8L2ZvbnQ+ PC9iPjwvdHQ+DQo8L3A+DQo8cCBhbGlnbj0ibGVmdCI+IDxiPjxmb250IGZhY2U9Ikx1Y2lkYSBT YW5zIFR5cGV3cml0ZXIiIA0Kc2l6ZT0iMyI+SXRlbSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnMNCnA7Jm5ic3A7Jm5ic3A7DQpMZXhtYXJrJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm4NCmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNClByaWNlPC9mb250PjwvYj4NCjwvcD4NCjxwIGFsaWduPSJsZWZ0 Ij4gPHR0Pjxmb250IHNpemU9IjIiIGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIGNvbG9y PSIjMDAwMDAwIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogDQojQzRDNEE2Ij4x OSAtIDEzODA1MjAgSGlnaCBZaWVsZCBCbGFjayBMYXNlciBUb25lciBmb3IgNDAxOSwgNDAxOUUs IDQwMjgsIDQwMjksIDYsIDEwLCAxMEwgLS0gJDEwOS41MDxicj4NCjwvc3Bhbj4yMCAtIDEzODIx NTAgSGlnaCBZaWVsZCBUb25lciBmb3IgMzExMiwgMzExNiwgNDAzOS0xMCssIDQwNDktIE1vZGVs IDEyTCwxNlIsDQpPcHRyYSAtICQxMDkuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1j b2xvcjogI0M0QzRBNiI+MjEgLSA2OUc4MjU2IExhc2VyIENhcnRyaWRnZSBmb3IgT3B0cmEgRSwN CkUrLCBFUCwgRVMsIDQwMjYsIDQwMjYgKDZBLDZCLDZELDZFKSZuYnNwOyAtLS0tICQgNDkuMDA8 YnI+DQo8L3NwYW4+MjIgLSAxM1QwMTAxIEhpZ2ggWWllbGQgVG9uZXIgQ2FydHJpZGdlIGZvciBM ZXhtYXJrIE9wdHJhIEUzMTAsIEUzMTIsIEUzMTJMIC0tLS0tLS0tICQgODkuMDA8YnI+DQo8c3Bh biBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+MjMgLSAxMzgyNjI1IEhpZ2gtWWll bGQgTGFzZXIgVG9uZXIgQ2FydHJpZGdlIGZvciBMZXhtYXJrIE9wdHJhIFMgKDQwNTkpIC0tLS0t LS0tLS0tIA0KJDEyOS41MDxicj4NCjwvc3Bhbj4yNCAtIDEyQTU3NDUgSGlnaCBZaWVsZCBMYXNl ciBUb25lciBmb3IgTGV4bWFyayBPcHRyYSBUNjEwLCA2MTIsIDYxNCAoNDA2OSkgLS0tLS0tLS0g JDE2NS4wMDwvYj48L2ZvbnQ+PC90dD4NCjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij4gPGI+PGZvbnQg ZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRlciIgDQpzaXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpFcHNvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnMNCnA7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+DQo8 L3A+DQo8cCBhbGlnbj0ibGVmdCI+PHR0Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBm YWNlPSJMdWNpZGEgU2FucyBUeXBld3JpdGVyIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1j b2xvcjogDQojQzRDNEE2Ij4yNQ0KLS0tLSBTMDUxMDA5IFRvbmVyIENhcnRyaWRnZSBmb3IgRXBz b24gRVBMNzAwMCwgNzUwMCwgODAwMCsgLSAkMTE1LjUwPGJyPg0KPC9zcGFuPjI1QSAtLS0gUzA1 MTAwOSBMUC0zMDAwIFBTIDcwMDAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gJDEx NS41MDxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4yNiAtLS0t IEFTMDUxMDExIEltYWdpbmcgQ2FydHJpZGdlIGZvcg0KQWN0aW9uTGFzZXItMTAwMCwgMTUwMCAt LSAkIDk5LjUwPGJyPg0KPC9zcGFuPjI2QSAtLS0gQVMwNTEwMTEgRVBMLTUwMDAsIEVQTC01MTAw LCBFUEwtNTIwMCAtLS0tLS0tLS0tLS0tLS0tLS0gJCA5OS41MDxicj48L2I+PC9mb250Pg0KPC90 dD48L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGI+PGZvbnQgZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdy aXRlciIgDQpzaXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpQYW5hc29uaWMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNClByaWNlPC9mb250PjwvYj48L3A+DQo8cCBhbGlnbj0ibGVmdCI+ PHR0PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij48Zm9udCBjb2xvcj0i IzAwMDAwMCIgZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRlciIgDQpzaXplPSIyIj48Yj4yNw0K LS0tLS0tTmVjIHNlcmllcyAyIG1vZGVscyA5MCBhbmQgOTUgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSAkMTA5LjUwPGJyPjwvYj48L2ZvbnQ+PC9zcGFuPjwvdHQ+PC9wPg0KPHAgYWxpZ249ImxlZnQi PjxiPjxmb250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIA0Kc2l6ZT0iMyI+SXRlbSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQpBcHBsZSZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnMNCnA7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+PC9wPg0KPHAgYWxpZ249Imxl ZnQiPjx0dD48Yj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiIgY29sb3I9IiMwMDAw MDAiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4yOCANCi0tLS0gMjQ3 M0cvQSBMYXNlciBUb25lciBmb3IgTGFzZXJXcml0ZXIgUHJvIDYwMCwgNjMwLCBMYXNlcldyaXRl ciAxNi82MDAgUFMgLQ0KJCA1Ny41MDxicj4NCjwvc3Bhbj4yOSAtLS0tIDE5NjBHL0EgTGFzZXIg VG9uZXIgZm9yIEFwcGxlIExhc2VyV3JpdGVyIFNlbGVjdCwgMzAwLCAzMTAsIDM2MCAtLS0tLS0t LS0gJA0KNzEuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+ MzAgLS0tLSBNMDA4OUxML0EgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlcndyaXRlciAzMDAsIDMy MCAoNzRBKSAtLS0tLS0tLS0tLS0tLS0tICQNCjUyLjUwPGJyPg0KPC9zcGFuPjMxIC0tLS0gTTYw MDIgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlcndyaXRlciBJSU5ULCBJSU5UWCwgSUlTQywgSUlG LCBJSUcgKDk1QSkgLSAkDQo0Ny41MDxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OiAjQzRDNEE2Ij4zMUEgLS0tIE0wMDg5TEwvQSBUb25lciBDYXJ0cmlkZ2UgZm9yIExhc2Vyd3Jp dGVyDQpMUywgTlQsIE5UUiwgU0MgKDc1QSkgLS0tLS0tLS0tICQNCjU1LjUwPGJyPg0KPC9zcGFu PjMyIC0tLS0gTTQ2ODNHL0EgTGFzZXIgVG9uZXIgZm9yIExhc2VyV3JpdGVyIDEyLCA2NDBQUyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KJCA4NS41MDxicj48L2ZvbnQ+PC9iPg0KPC90dD48 L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGI+PGZvbnQgZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRl ciIgDQpzaXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpDYW5v biZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnMNCnA7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9u dD48L2I+PC9wPg0KPHA+PHR0Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBmYWNlPSJM dWNpZGEgU2FucyBUeXBld3JpdGVyIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog I0M0QzRBNiI+MzMgLS0tIA0KRmF4DQpDRlgtTDM1MDAsIENGWC00MDAwIENGWC1MNDUwMCwgQ0ZY LUw0NTAwSUUgJmFtcDsgSUYgRlgzIC0tLS0tLS0tLS0tICQgNDkuNTA8YnI+DQo8L3NwYW4+MzNB IC0tIEwtMjUwLCBMLTI2MGksIEwtMzAwIEZYMyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+MzNCIC0tIExBU0VSIENMQVNTIDIwNjAsIDIwNjBQLCA0MDAwIEZYMyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzQgLS0t IExBU0VSIENMQVNTIDUwMDAsIDU1MDAsIDcwMDAsIDcxMDAsIDc1MDAsIDYwMDAgRlgyIC0tLS0t LS0tLS0tLS0tLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRB NiI+PGJyPg0KMzUgLS0tIEZBWCA1MDAwIEZYMiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzYgLS0tIExB U0VSIENMQVNTIDg1MDAsIDkwMDAsIDkwMDBMLCA5MDAwTVMsIDk1MDAsIDk1MDAgTVMsIDk1MDAg UyBGWDQgLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+ PGJyPg0KMzZBIC0tIEZheCBMNzAwLDcyMCw3NjAsNzcwLDc3NSw3NzcsNzgwLDc4NSw3OTAsICZh bXA7IEwzMzAwIEZYMQ0KLS0tLS0tLS0tLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjM2QiAtLSBM LTgwMCwgTC05MDAgRlg0IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQokIDQ5LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYi Pjxicj4NCjM3IC0tLSBBMzBSIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNiwgNlJFLCA3LCAxMSwg MTIgLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQokIDU5LjUwPGJyPg0KPC9zcGFuPjM4IC0tLSBFLTQw IFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNzIwLCA3NDAsIDc3MCwgNzkwLDc5NSwgOTIwLCA5NTAs IDk4MCAtDQokIDg1LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPjxi cj4NCjM4QSAtLSBFLTIwIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtMzEwLCAzMjUsIDMzMCwgMzMw TCwgNDAwLCA0MjAsIDQzMCAtLS0tDQokIDg1LjUwPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJyPjwvc3Bhbj48L2ZvbnQ+DQo8L3R0PjwvcD4NCjxw PjxiPjxmb250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIHNpemU9IjMiPkl0ZW0mbmJz cDsmbmJzcDsNClhlcm94Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByaWNlPC9mb250PjwvYj48L3A+DQo8 cD48dHQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjIiIGZhY2U9Ikx1Y2lkYSBTYW5zIFR5 cGV3cml0ZXIiPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4zOSAt LS0tIA0KNlI5MDAgNzVBIC0tLS0gJCA1NS41MDxicj4NCjwvc3Bhbj40MCAtLS0tIDZSOTAzIDk4 QSAtLS0tICQgNDYuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJy Pg0KNDEgLS0tLSA2UjkwMiA5NUEgLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjQyIC0tLS0gNlI5 MDEgOTFBIC0tLS0gJCA2NS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2 Ij48YnI+DQo0MyAtLS0tIDZSOTA4IDA2QSAtLS0tICQgNDIuNTA8YnI+DQo8L3NwYW4+NDQgLS0t LSA2Ujg5OSA3NEEgLS0tLSAkIDQ3LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICND NEM0QTYiPjxicj4NCjQ1IC0tLS0gNlI5MjggOTZBIC0tLS0gJCA3Mi41MDxicj4NCjwvc3Bhbj40 NiAtLS0tIDZSOTI2IDI3WCAtLS0tICQgODQuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+PGJyPg0KNDcgLS0tLSA2UjkwNiAwOUEgLS0tLSAkIDkyLjUwPGJyPg0KPC9z cGFuPjQ4IC0tLS0gNlI5MDcgNE1WIC0tLS0gJCA4OS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiAjQzRDNEE2Ij48YnI+DQo0OSAtLS0tIDZSOTA1IDAzQSAtLS0tICQgNDYuNTA8L3Nw YW4+PC9iPjwvZm9udD48L3R0PjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48Yj48aT48Zm9udCBjb2xv cj0iIzgwODAwMCIgc2l6ZT0iMyIgZmFjZT0iQXJpYWwiPjMwIERheSB1bmxpbWl0ZWQgd2FycmFu dHkgaW5jbHVkZWQgb24gYWxsDQpwcm9kdWN0czxicj4NCkdUIFRvbmVyIFN1cHBsaWVzIGd1YXJh bnRlZXMgdGhlc2UgY2FydHJpZGdlcyB0byBiZSBmcmVlIGZyb20gZGVmZWN0cyBpbg0Kd29ya21h bnNoaXAgYW5kIG1hdGVyaWFsLjwvZm9udD48L2k+DQo8L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVm dCI+PGI+PGk+PGZvbnQgY29sb3I9IiMwMDAwRkYiIHNpemU9IjMiIGZhY2U9IkFyaWFsIj5XZSBs b29rDQpmb3J3YXJkIGluIGRvaW5nIGJ1c2luZXNzIHdpdGggeW91LjwvZm9udD48L2k+PC9iPg0K PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxpPjxmb250IGNvbG9yPSIjMDAwMEZGIiBzaXplPSIz IiBmYWNlPSJBcmlhbCI+Q3VzdG9tZXImbmJzcDsNClNhdGlzZmFjdGlvbiBndWFyYW50ZWVkPC9m b250PjwvaT48L2I+DQo8L3A+DQo8cD4NCjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj5J PGZvbnQgY29sb3I9IiMwMDAwODAiPmYgeW91IGFyZSBvcmRlcmluZyBieSBlLW1haWwgb3INCmMu by5kLiBwbGVhc2UgZmlsbCBvdXQgYW4gb3JkZXI8YnI+DQpmb3JtIHdpdGggdGhlIGZvbGxvd2lu ZyBpbmZvcm1hdGlvbjo8L2ZvbnQ+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxpPiZuYnNwOyZuYnNw OyZuYnNwOzwvaT48L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwODAiPg0KPC9mb250PjxpPiZuYnNw OyZuYnNwOyZuYnNwOzwvaT48Zm9udCBjb2xvcj0iIzAwMDA4MCIgZmFjZT0iQXJpYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvZm9udD48Zm9udCANCmNvbG9yPSIjMDAwMEZGIj4N CjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+PGk+Jm5ic3A7PC9pPjwvZm9udD48Zm9udCBj b2xvcj0iIzAwMDA4MCI+PGJyPjxicj4NCjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+cGhv bmUgbnVtYmVyPGJyPg0KY29tcGFueSBuYW1lPGJyPg0KZmlyc3QgYW5kIGxhc3QgbmFtZTxicj4N CnN0cmVldCBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L2ZvbnQ+PC9iPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+PGI+PGk+ PGEgaHJlZj0ibWFpbHRvOmd0dHMxQGNhYmxlLm5ldC5jbyI+PGZvbnQgY29sb3I9IiMwMDAwRkYi Pk9yZGVyIA0KTm93PC9mb250PjwvYT4gPC9pPjxmb250IGNvbG9yPSIjMDAwMDgwIj5vcg0KY2Fs bCB0b2xsIGZyZWUgPC9mb250Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjMDAwMEZGIj4gMS04NjYt MjM3LTczOTc8L2ZvbnQ+IDwvYj48L2ZvbnQ+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+ PGI+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxicj48YnI+DQo8L2ZvbnQ+PGZvbnQgY29sb3I9IiMw MDAwODAiPklmIHlvdSBhcmUgb3JkZXJpbmcgYnkgcHVyY2hhc2Ugb3JkZXIgcGxlYXNlIGZpbGwg b3V0IGFuIG9yZGVyIGZvcm08YnI+DQp3aXRoIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb246Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvZm9udD48aT4mbmJzcDsmbmJzcDsmbmJzcDs8L2k+PGZvbnQgY29s b3I9IiMwMDAwODAiIA0KZmFjZT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9m b250PjwvYj48L2ZvbnQ+PC9wPg0KPHA+PGI+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjODA4 MDAwIiBzaXplPSIyIj5wdXJjaGFzZSBvcmRlciBudW1iZXI8YnI+DQpwaG9uZSBudW1iZXI8YnI+ DQpjb21wYW55IG9yIHNjaG9vbCBuYW1lPGJyPg0Kc2hpcHBpbmcgYWRkcmVzcyBhbmQgYmlsbGlu ZyBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj48aT48YSBocmVmPSJtYWls dG86Z3R0czFAY2FibGUubmV0LmNvIj48Zm9udCBjb2xvcj0iIzAwMDBGRiI+T3JkZXINCk5vdzwv Zm9udD48L2E+PC9pPjwvYj48L2ZvbnQ+PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxmb250IHNp emU9IjIiPjxpPjxmb250IGNvbG9yPSIjODAwMDAwIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+QWxs IHRyYWRlIG1hcmtzIGFuZCBicmFuZCBuYW1lcyBsaXN0ZWQgDQphYm92ZSBhcmUgcHJvcGVydHkN Cm9mIHRoZSByZXNwZWN0aXZlPGJyPg0KaG9sZGVycyBhbmQgdXNlZCBmb3IgZGVzY3JpcHRpdmUg cHVycG9zZXMgb25seS48L2ZvbnQ+DQo8L2k+DQo8L2ZvbnQ+DQo8L2I+DQo8L3A+DQo= DQpQcmljZTwvZm9u dD48L2I+PC9wPg0KPHA+PHR0Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBmYWNlPSJM dWNpZGEgU2FucyBUeXBld3JpdGVyIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog I0M0QzRBNiI+MzMgLS0tIA0KRmF4DQpDRlgtTDM1MDAsIENGWC00MDAwIENGWC1MNDUwMCwgQ0ZY LUw0NTAwSUUgJmFtcDsgSUYgRlgzIC0tLS0tLS0tLS0tICQgNDkuNTA8YnI+DQo8L3NwYW4+MzNB IC0tIEwtMjUwLCBMLTI2MGksIEwtMzAwIEZYMyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+MzNCIC0tIExBU0VSIENMQVNTIDIwNjAsIDIwNjBQLCA0MDAwIEZYMyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzQgLS0t IExBU0VSIENMQVNTIDUwMDAsIDU1MDAsIDcwMDAsIDcxMDAsIDc1MDAsIDYwMDAgRlgyIC0tLS0t LS0tLS0tLS0tLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRB NiI+PGJyPg0KMzUgLS0tIEZBWCA1MDAwIEZYMiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzYgLS0tIExB U0VSIENMQVNTIDg1MDAsIDkwMDAsIDkwMDBMLCA5MDAwTVMsIDk1MDAsIDk1MDAgTVMsIDk1MDAg UyBGWDQgLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+ PGJyPg0KMzZBIC0tIEZheCBMNzAwLDcyMCw3NjAsNzcwLDc3NSw3NzcsNzgwLDc4NSw3OTAsICZh bXA7IEwzMzAwIEZYMQ0KLS0tLS0tLS0tLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjM2QiAtLSBM LTgwMCwgTC05MDAgRlg0IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQokIDQ5LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYi Pjxicj4NCjM3IC0tLSBBMzBSIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNiwgNlJFLCA3LCAxMSwg MTIgLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQokIDU5LjUwPGJyPg0KPC9zcGFuPjM4IC0tLSBFLTQw IFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNzIwLCA3NDAsIDc3MCwgNzkwLDc5NSwgOTIwLCA5NTAs IDk4MCAtDQokIDg1LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPjxi cj4NCjM4QSAtLSBFLTIwIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtMzEwLCAzMjUsIDMzMCwgMzMw TCwgNDAwLCA0MjAsIDQzMCAtLS0tDQokIDg1LjUwPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJyPjwvc3Bhbj48L2ZvbnQ+DQo8L3R0PjwvcD4NCjxw PjxiPjxmb250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIHNpemU9IjMiPkl0ZW0mbmJz cDsmbmJzcDsNClhlcm94Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByaWNlPC9mb250PjwvYj48L3A+DQo8 cD48dHQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjIiIGZhY2U9Ikx1Y2lkYSBTYW5zIFR5 cGV3cml0ZXIiPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4zOSAt LS0tIA0KNlI5MDAgNzVBIC0tLS0gJCA1NS41MDxicj4NCjwvc3Bhbj40MCAtLS0tIDZSOTAzIDk4 QSAtLS0tICQgNDYuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJy Pg0KNDEgLS0tLSA2UjkwMiA5NUEgLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjQyIC0tLS0gNlI5 MDEgOTFBIC0tLS0gJCA2NS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2 Ij48YnI+DQo0MyAtLS0tIDZSOTA4IDA2QSAtLS0tICQgNDIuNTA8YnI+DQo8L3NwYW4+NDQgLS0t LSA2Ujg5OSA3NEEgLS0tLSAkIDQ3LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICND NEM0QTYiPjxicj4NCjQ1IC0tLS0gNlI5MjggOTZBIC0tLS0gJCA3Mi41MDxicj4NCjwvc3Bhbj40 NiAtLS0tIDZSOTI2IDI3WCAtLS0tICQgODQuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+PGJyPg0KNDcgLS0tLSA2UjkwNiAwOUEgLS0tLSAkIDkyLjUwPGJyPg0KPC9z cGFuPjQ4IC0tLS0gNlI5MDcgNE1WIC0tLS0gJCA4OS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiAjQzRDNEE2Ij48YnI+DQo0OSAtLS0tIDZSOTA1IDAzQSAtLS0tICQgNDYuNTA8L3Nw YW4+PC9iPjwvZm9udD48L3R0PjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48Yj48aT48Zm9udCBjb2xv cj0iIzgwODAwMCIgc2l6ZT0iMyIgZmFjZT0iQXJpYWwiPjMwIERheSB1bmxpbWl0ZWQgd2FycmFu dHkgaW5jbHVkZWQgb24gYWxsDQpwcm9kdWN0czxicj4NCkdUIFRvbmVyIFN1cHBsaWVzIGd1YXJh bnRlZXMgdGhlc2UgY2FydHJpZGdlcyB0byBiZSBmcmVlIGZyb20gZGVmZWN0cyBpbg0Kd29ya21h bnNoaXAgYW5kIG1hdGVyaWFsLjwvZm9udD48L2k+DQo8L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVm dCI+PGI+PGk+PGZvbnQgY29sb3I9IiMwMDAwRkYiIHNpemU9IjMiIGZhY2U9IkFyaWFsIj5XZSBs b29rDQpmb3J3YXJkIGluIGRvaW5nIGJ1c2luZXNzIHdpdGggeW91LjwvZm9udD48L2k+PC9iPg0K PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxpPjxmb250IGNvbG9yPSIjMDAwMEZGIiBzaXplPSIz IiBmYWNlPSJBcmlhbCI+Q3VzdG9tZXImbmJzcDsNClNhdGlzZmFjdGlvbiBndWFyYW50ZWVkPC9m b250PjwvaT48L2I+DQo8L3A+DQo8cD4NCjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj5J PGZvbnQgY29sb3I9IiMwMDAwODAiPmYgeW91IGFyZSBvcmRlcmluZyBieSBlLW1haWwgb3INCmMu by5kLiBwbGVhc2UgZmlsbCBvdXQgYW4gb3JkZXI8YnI+DQpmb3JtIHdpdGggdGhlIGZvbGxvd2lu ZyBpbmZvcm1hdGlvbjo8L2ZvbnQ+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxpPiZuYnNwOyZuYnNw OyZuYnNwOzwvaT48L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwODAiPg0KPC9mb250PjxpPiZuYnNw OyZuYnNwOyZuYnNwOzwvaT48Zm9udCBjb2xvcj0iIzAwMDA4MCIgZmFjZT0iQXJpYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvZm9udD48Zm9udCANCmNvbG9yPSIjMDAwMEZGIj4N CjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+PGk+Jm5ic3A7PC9pPjwvZm9udD48Zm9udCBj b2xvcj0iIzAwMDA4MCI+PGJyPjxicj4NCjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+cGhv bmUgbnVtYmVyPGJyPg0KY29tcGFueSBuYW1lPGJyPg0KZmlyc3QgYW5kIGxhc3QgbmFtZTxicj4N CnN0cmVldCBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L2ZvbnQ+PC9iPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+PGI+PGk+ PGEgaHJlZj0ibWFpbHRvOmd0dHMxQGNhYmxlLm5ldC5jbyI+PGZvbnQgY29sb3I9IiMwMDAwRkYi Pk9yZGVyIA0KTm93PC9mb250PjwvYT4gPC9pPjxmb250IGNvbG9yPSIjMDAwMDgwIj5vcg0KY2Fs bCB0b2xsIGZyZWUgPC9mb250Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjMDAwMEZGIj4gMS04NjYt MjM3LTczOTc8L2ZvbnQ+IDwvYj48L2ZvbnQ+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+ PGI+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxicj48YnI+DQo8L2ZvbnQ+PGZvbnQgY29sb3I9IiMw MDAwODAiPklmIHlvdSBhcmUgb3JkZXJpbmcgYnkgcHVyY2hhc2Ugb3JkZXIgcGxlYXNlIGZpbGwg b3V0IGFuIG9yZGVyIGZvcm08YnI+DQp3aXRoIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb246Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvZm9udD48aT4mbmJzcDsmbmJzcDsmbmJzcDs8L2k+PGZvbnQgY29s b3I9IiMwMDAwODAiIA0KZmFjZT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9m b250PjwvYj48L2ZvbnQ+PC9wPg0KPHA+PGI+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjODA4 MDAwIiBzaXplPSIyIj5wdXJjaGFzZSBvcmRlciBudW1iZXI8YnI+DQpwaG9uZSBudW1iZXI8YnI+ DQpjb21wYW55IG9yIHNjaG9vbCBuYW1lPGJyPg0Kc2hpcHBpbmcgYWRkcmVzcyBhbmQgYmlsbGlu ZyBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj48aT48YSBocmVmPSJtYWls dG86Z3R0czFAY2FibGUubmV0LmNvIj48Zm9udCBjb2xvcj0iIzAwMDBGRiI+T3JkZXINCk5vdzwv Zm9udD48L2E+PC9pPjwvYj48L2ZvbnQ+PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxmb250IHNp emU9IjIiPjxpPjxmb250IGNvbG9yPSIjODAwMDAwIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+QWxs IHRyYWRlIG1hcmtzIGFuZCBicmFuZCBuYW1lcyBsaXN0ZWQgDQphYm92ZSBhcmUgcHJvcGVydHkN Cm9mIHRoZSByZXNwZWN0aXZlPGJyPg0KaG9sZGVycyBhbmQgdXNlZCBmb3IgZGVzY3JpcHRpdmUg cHVycG9zZXMgb25seS48L2ZvbnQ+DQo8L2k+DQo8L2ZvbnQ+DQo8L2I+DQo8L3A+DQo= DQpQcmljZTwvZm9u dD48L2I+PC9wPg0KPHA+PHR0Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBmYWNlPSJM dWNpZGEgU2FucyBUeXBld3JpdGVyIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog I0M0QzRBNiI+MzMgLS0tIA0KRmF4DQpDRlgtTDM1MDAsIENGWC00MDAwIENGWC1MNDUwMCwgQ0ZY LUw0NTAwSUUgJmFtcDsgSUYgRlgzIC0tLS0tLS0tLS0tICQgNDkuNTA8YnI+DQo8L3NwYW4+MzNB IC0tIEwtMjUwLCBMLTI2MGksIEwtMzAwIEZYMyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+MzNCIC0tIExBU0VSIENMQVNTIDIwNjAsIDIwNjBQLCA0MDAwIEZYMyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzQgLS0t IExBU0VSIENMQVNTIDUwMDAsIDU1MDAsIDcwMDAsIDcxMDAsIDc1MDAsIDYwMDAgRlgyIC0tLS0t LS0tLS0tLS0tLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRB NiI+PGJyPg0KMzUgLS0tIEZBWCA1MDAwIEZYMiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzYgLS0tIExB U0VSIENMQVNTIDg1MDAsIDkwMDAsIDkwMDBMLCA5MDAwTVMsIDk1MDAsIDk1MDAgTVMsIDk1MDAg UyBGWDQgLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+ PGJyPg0KMzZBIC0tIEZheCBMNzAwLDcyMCw3NjAsNzcwLDc3NSw3NzcsNzgwLDc4NSw3OTAsICZh bXA7IEwzMzAwIEZYMQ0KLS0tLS0tLS0tLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjM2QiAtLSBM LTgwMCwgTC05MDAgRlg0IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQokIDQ5LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYi Pjxicj4NCjM3IC0tLSBBMzBSIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNiwgNlJFLCA3LCAxMSwg MTIgLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQokIDU5LjUwPGJyPg0KPC9zcGFuPjM4IC0tLSBFLTQw IFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNzIwLCA3NDAsIDc3MCwgNzkwLDc5NSwgOTIwLCA5NTAs IDk4MCAtDQokIDg1LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPjxi cj4NCjM4QSAtLSBFLTIwIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtMzEwLCAzMjUsIDMzMCwgMzMw TCwgNDAwLCA0MjAsIDQzMCAtLS0tDQokIDg1LjUwPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJyPjwvc3Bhbj48L2ZvbnQ+DQo8L3R0PjwvcD4NCjxw PjxiPjxmb250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIHNpemU9IjMiPkl0ZW0mbmJz cDsmbmJzcDsNClhlcm94Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByaWNlPC9mb250PjwvYj48L3A+DQo8 cD48dHQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjIiIGZhY2U9Ikx1Y2lkYSBTYW5zIFR5 cGV3cml0ZXIiPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4zOSAt LS0tIA0KNlI5MDAgNzVBIC0tLS0gJCA1NS41MDxicj4NCjwvc3Bhbj40MCAtLS0tIDZSOTAzIDk4 QSAtLS0tICQgNDYuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJy Pg0KNDEgLS0tLSA2UjkwMiA5NUEgLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjQyIC0tLS0gNlI5 MDEgOTFBIC0tLS0gJCA2NS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2 Ij48YnI+DQo0MyAtLS0tIDZSOTA4IDA2QSAtLS0tICQgNDIuNTA8YnI+DQo8L3NwYW4+NDQgLS0t LSA2Ujg5OSA3NEEgLS0tLSAkIDQ3LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICND NEM0QTYiPjxicj4NCjQ1IC0tLS0gNlI5MjggOTZBIC0tLS0gJCA3Mi41MDxicj4NCjwvc3Bhbj40 NiAtLS0tIDZSOTI2IDI3WCAtLS0tICQgODQuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+PGJyPg0KNDcgLS0tLSA2UjkwNiAwOUEgLS0tLSAkIDkyLjUwPGJyPg0KPC9z cGFuPjQ4IC0tLS0gNlI5MDcgNE1WIC0tLS0gJCA4OS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiAjQzRDNEE2Ij48YnI+DQo0OSAtLS0tIDZSOTA1IDAzQSAtLS0tICQgNDYuNTA8L3Nw YW4+PC9iPjwvZm9udD48L3R0PjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48Yj48aT48Zm9udCBjb2xv cj0iIzgwODAwMCIgc2l6ZT0iMyIgZmFjZT0iQXJpYWwiPjMwIERheSB1bmxpbWl0ZWQgd2FycmFu dHkgaW5jbHVkZWQgb24gYWxsDQpwcm9kdWN0czxicj4NCkdUIFRvbmVyIFN1cHBsaWVzIGd1YXJh bnRlZXMgdGhlc2UgY2FydHJpZGdlcyB0byBiZSBmcmVlIGZyb20gZGVmZWN0cyBpbg0Kd29ya21h bnNoaXAgYW5kIG1hdGVyaWFsLjwvZm9udD48L2k+DQo8L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVm dCI+PGI+PGk+PGZvbnQgY29sb3I9IiMwMDAwRkYiIHNpemU9IjMiIGZhY2U9IkFyaWFsIj5XZSBs b29rDQpmb3J3YXJkIGluIGRvaW5nIGJ1c2luZXNzIHdpdGggeW91LjwvZm9udD48L2k+PC9iPg0K PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxpPjxmb250IGNvbG9yPSIjMDAwMEZGIiBzaXplPSIz IiBmYWNlPSJBcmlhbCI+Q3VzdG9tZXImbmJzcDsNClNhdGlzZmFjdGlvbiBndWFyYW50ZWVkPC9m b250PjwvaT48L2I+DQo8L3A+DQo8cD4NCjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj5J PGZvbnQgY29sb3I9IiMwMDAwODAiPmYgeW91IGFyZSBvcmRlcmluZyBieSBlLW1haWwgb3INCmMu by5kLiBwbGVhc2UgZmlsbCBvdXQgYW4gb3JkZXI8YnI+DQpmb3JtIHdpdGggdGhlIGZvbGxvd2lu ZyBpbmZvcm1hdGlvbjo8L2ZvbnQ+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxpPiZuYnNwOyZuYnNw OyZuYnNwOzwvaT48L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwODAiPg0KPC9mb250PjxpPiZuYnNw OyZuYnNwOyZuYnNwOzwvaT48Zm9udCBjb2xvcj0iIzAwMDA4MCIgZmFjZT0iQXJpYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvZm9udD48Zm9udCANCmNvbG9yPSIjMDAwMEZGIj4N CjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+PGk+Jm5ic3A7PC9pPjwvZm9udD48Zm9udCBj b2xvcj0iIzAwMDA4MCI+PGJyPjxicj4NCjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+cGhv bmUgbnVtYmVyPGJyPg0KY29tcGFueSBuYW1lPGJyPg0KZmlyc3QgYW5kIGxhc3QgbmFtZTxicj4N CnN0cmVldCBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L2ZvbnQ+PC9iPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+PGI+PGk+ PGEgaHJlZj0ibWFpbHRvOmd0dHMxQGNhYmxlLm5ldC5jbyI+PGZvbnQgY29sb3I9IiMwMDAwRkYi Pk9yZGVyIA0KTm93PC9mb250PjwvYT4gPC9pPjxmb250IGNvbG9yPSIjMDAwMDgwIj5vcg0KY2Fs bCB0b2xsIGZyZWUgPC9mb250Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjMDAwMEZGIj4gMS04NjYt MjM3LTczOTc8L2ZvbnQ+IDwvYj48L2ZvbnQ+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+ PGI+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxicj48YnI+DQo8L2ZvbnQ+PGZvbnQgY29sb3I9IiMw MDAwODAiPklmIHlvdSBhcmUgb3JkZXJpbmcgYnkgcHVyY2hhc2Ugb3JkZXIgcGxlYXNlIGZpbGwg b3V0IGFuIG9yZGVyIGZvcm08YnI+DQp3aXRoIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb246Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvZm9udD48aT4mbmJzcDsmbmJzcDsmbmJzcDs8L2k+PGZvbnQgY29s b3I9IiMwMDAwODAiIA0KZmFjZT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9m b250PjwvYj48L2ZvbnQ+PC9wPg0KPHA+PGI+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjODA4 MDAwIiBzaXplPSIyIj5wdXJjaGFzZSBvcmRlciBudW1iZXI8YnI+DQpwaG9uZSBudW1iZXI8YnI+ DQpjb21wYW55IG9yIHNjaG9vbCBuYW1lPGJyPg0Kc2hpcHBpbmcgYWRkcmVzcyBhbmQgYmlsbGlu ZyBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj48aT48YSBocmVmPSJtYWls dG86Z3R0czFAY2FibGUubmV0LmNvIj48Zm9udCBjb2xvcj0iIzAwMDBGRiI+T3JkZXINCk5vdzwv Zm9udD48L2E+PC9pPjwvYj48L2ZvbnQ+PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxmb250IHNp emU9IjIiPjxpPjxmb250IGNvbG9yPSIjODAwMDAwIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+QWxs IHRyYWRlIG1hcmtzIGFuZCBicmFuZCBuYW1lcyBsaXN0ZWQgDQphYm92ZSBhcmUgcHJvcGVydHkN Cm9mIHRoZSByZXNwZWN0aXZlPGJyPg0KaG9sZGVycyBhbmQgdXNlZCBmb3IgZGVzY3JpcHRpdmUg cHVycG9zZXMgb25seS48L2ZvbnQ+DQo8L2k+DQo8L2ZvbnQ+DQo8L2I+DQo8L3A+DQo= ------=_NextPart_000_00A1_11D12G3I.J1343N65-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Aug 29 06:02:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14448 for ; Thu, 29 Aug 2002 06:02:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7TA32C02478 for seamoby-archive@odin.ietf.org; Thu, 29 Aug 2002 06:03:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TA32o02475 for ; Thu, 29 Aug 2002 06:03:02 -0400 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14442 for ; Thu, 29 Aug 2002 06:01:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TA0so02388; Thu, 29 Aug 2002 06:00:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7T9xOo02325 for ; Thu, 29 Aug 2002 05:59:24 -0400 Received: from yahoo.com ([218.76.241.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14386 for ; Thu, 29 Aug 2002 05:57:30 -0400 (EDT) From: gtts1@cable.net.co Received: from unknown (HELO rly-xw05.mx.aol.com) (245.158.118.110) by rly-xw01.mx.aol.com with local; Tue, 27 Aug 2002 18:56:53 -1000 Reply-To: Message-ID: <163FF88B-BAE1-11D6-B365-00E0188F81AA@9BWEXW6x> To: Date: Thu, 29 Aug 2002 05:59:17 -0400 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A1_11D12G3I.J1343N65" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal Subject: [Seamoby] Laser Toner Cartridges At Low Prices. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , ------=_NextPart_000_00A1_11D12G3I.J1343N65 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+DQo8eC10YWI+DQoNCjxoZWFkPg0KPC9oZWFkPg0KDQo8cCBhbGlnbj0iY2VudGVyIj4N CjxiPjxhIGhyZWY9Im1haWx0bzpndHRzMUBjYWJsZS5uZXQuY28iPjxmb250IGNvbG9yPSIjMDAw MDgwIiBzaXplPSIzIiBmYWNlPSJBcmlhbCI+R1QgVE9ORVINClNVUFBMSUVTPGJyPkxhc2VyIHBy aW50ZXIgYW5kIGNvbXB1dGVyIHN1cHBsaWVzPGJyPg0KICAxLTg2Ni0yMzctNzM5NzwvZm9udD48 L2E+PC9iPg0KDQo8cCBhbGlnbj0iY2VudGVyIj4NCjxpbWcgYm9yZGVyPSIwIiANCnNyYz0iaHR0 cDovL2ltYWdlcy5nb29nbGUuY29tL2ltYWdlcz9xPXRibjp0R2kyNWJCR000b0M6ZGF0YWRldmlj ZXMuaG9tZS5taW5kc3ByaW5nLmNvbS80MDAwcHJpbnRlci5qcGciIHdpZHRoPSI4MSIgDQpoZWln aHQ9IjY5Ij4NCjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly9pbWFnZXMuZ29vZ2xlLmNvbS9p bWFnZXM/cT10Ym46WW9BdDRyVG1aOHNDOnd3dy5jYXJ0cmlkZ2UtZmlsbC5jby51ay9ncm9vcHBy aW50ZXIuZ2lmIiANCndpZHRoPSI4MSIgaGVpZ2h0PSI2OSI+DQo8cD4NCjxiPjxpPjxmb250IGNv bG9yPSIjODA4MDAwIiBmYWNlPSJBcmlhbCIgc2l6ZT0iNCI+U2F2ZSB1cCB0byA0MCUgZnJvbSBy ZXRhaWwgcHJpY2Ugb24gbGFzZXIgcHJpbnRlciB0b25lcg0KY2FydHJpZGdlcyw8YnI+DQpjb3Bp ZXIgYW5kIGZheCBjYXJ0cmlkZ2VzLjwvZm9udD48L2k+DQo8L2I+IDwvcD4NCjxwPg0KPGI+PGk+ PGEgaHJlZj0iI3ByaWNlcyI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyIgc2l6ZT0iMyIgY29s b3I9IiMwMDAwRkYiPkNIRUNLIE9VVCBPVVIgR1JFQVQNClBSSUNFUyE8L2ZvbnQ+PC9hPjwvaT4N CjwvYj4gPC9wPg0KPHA+PGI+PGk+PGZvbnQgY29sb3I9IiM4MDAwMCIgc2l6ZT0iMyIgZmFjZT0i Q29taWMgU2FucyBNUyI+SWYgeW91IHJlY2VpdmVkIHRoaXMgZW1haWwgb24gZXJyb3IsIHBsZWFz ZSByZXBseSB0byANCmd0dHMxQGNhYmxlLm5ldC5jbyB3aXRoIHN1YmplY3Q6IFJFTU9WRS4uLiBz b3JyeSBmb3IgdGhlIGluY29udmVuaWVuY2UuDQo8cD48Yj48aT48Zm9udCBjb2xvcj0iIzgwODAw MCIgc2l6ZT0iNCIgZmFjZT0iQXJpYWwiPlBsZWFzZSBmb3J3YXJkIHRvIHRoZSBwZXJzb24gcmVz cG9uc2libGUgZm9yIHB1cmNoYXNpbmcgeW91ciBsYXNlciANCnByaW50ZXINCnN1cHBsaWVzLjwv Zm9udD48L2k+DQo8L3A+DQo8cD48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PGZvbnQgY29s b3I9IiM4MDgwMDAiPjx4LXRhYj4mbmJzcDsmbmJzcDsmbmJzcDsgT3JkZXIgYnkNCnBob25lOiAo dG9sbCBmcmVlKSAxLTg2Ni0yMzctNzM5Nw0KPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDgwIj4g PGJyPg0KPC9mb250Pg0KPC9wPg0KPC9mb250Pjxmb250IGNvbG9yPSIjODA4MDAwIj48eC10YWI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9yZGVyIGJ5IGVtYWlsOiA8L2ZvbnQ+DQo8L2ZvbnQ+DQo8Zm9u dCBjb2xvcj0iIzAwMDBGRiIgZmFjZT0iQXJpYWwiIHNpemU9IjMiPlNpbXBseSByZXBseTwvZm9u dD48Zm9udCBjb2xvcj0iIzAwMDA4MCI+IHRoaXMgbWVzc2FnZSBvciA8L2ZvbnQ+PGEgDQpocmVm PSJtYWlsdG86Z3R0czFAY2FibGUubmV0LmNvIj48Zm9udCBjb2xvcj0iIzAwMDBGRiIgZmFjZT0i QXJpYWwiIHNpemU9IjMiPmNsaWNrIGhlcmU8L2ZvbnQ+PC9hPjxmb250IGZhY2U9IkFyaWFsIiAN CnNpemU9IjIiPjxmb250IGNvbG9yPSIjODA4MDAwIj4mbmJzcDsNCndpdGggc3ViamVjdDogPC9m b250Pjxmb250IGNvbG9yPSIjMDAwMDgwIj4gT1JERVI8L2ZvbnQ+DQo8L2ZvbnQ+DQo8L3A+DQo8 cD48Zm9udCBmYWNlPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9mb250PjwvYj4gPGZvbnQg ZmFjZT0iQXJpYWwiPiA8Yj4gPGZvbnQgc2l6ZT0iMiI+IDxmb250IGNvbG9yPSIjODA4MDAwIj5F bWFpbA0KcmVtb3ZhbDogPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDgwIj5TaW1wbHkgcmVwbHkg dGhpcyBtZXNzYWdlIG9yIDwvZm9udD4NCjwvZm9udD4NCjxhIGhyZWY9Im1haWx0bzpndHRzMUBj YWJsZS5uZXQuY28iPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMDAwMEZGIj5jbGljayBoZXJlPC9m b250PjwvYT4gPGZvbnQgc2l6ZT0iMiI+IDxmb250IA0KY29sb3I9IiM4MDgwMDAiPg0KPHgtdGFi PiZuYnNwOyB3aXRoIHN1YmplY3Q6DQo8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwODAiPiBSRU1P VkU8L2ZvbnQ+PGZvbnQgY29sb3I9IiM4MDgwMDAiPg0KPGJyPjxicj4NCjwvZm9udD4NCjwvZm9u dD4NCjxmb250IGNvbG9yPSIjMDAwMDgwIiBzaXplPSI0Ij5Vbml2ZXJzaXR5PC9mb250PiA8Zm9u dCBzaXplPSIyIj4gIGFuZC9vcg0KPC9mb250Pg0KPGZvbnQgY29sb3I9IiMwMDAwODAiIHNpemU9 IjQiPlNjaG9vbDwvZm9udD48Zm9udCBzaXplPSIzIj4gPC9mb250PiA8Zm9udCBzaXplPSIyIj4g cHVyY2hhc2UNCm9yZGVycyBXRUxDT01FLiAobm8gY3JlZGl0IGFwcHJvdmFsIHJlcXVpcmVkKTxi cj4NClBheSBieSBjaGVjaywgYy5vLmQsIG9yIHB1cmNoYXNlIG9yZGVyIChuZXQgMzAgZGF5cyku DQo8L2ZvbnQ+DQo8L2I+DQo8L2ZvbnQ+DQo8L3A+DQo8cD48Yj48aT48Zm9udCBjb2xvcj0iIzAw MDA4MCIgc2l6ZT0iMyI+V0UgQUNDRVBUIEFMTCBNQUpPUiBDUkVESVQgQ0FSRFMhPC9mb250Pjwv aT48L2I+DQo8L3A+DQo8cD48Yj48YSBocmVmPSIjY29sb3IiPjxmb250IGZhY2U9IkFyaWFsIiBz aXplPSIzIj5OZXchIEhQIDQ1MDAvNDU1MCBzZXJpZXMgY29sb3INCmNhcnRyaWRnZXMgaW4gc3Rv Y2shPC9mb250PjwvYT48L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVmdCI+IDxmb250IHNpemU9IjIi PiA8Yj4NCjxpPjxmb250IGNvbG9yPSIjODA4MDAwIiBmYWNlPSJBcmlhbCI+DQpPdXIgY2FydHJp ZGdlIHByaWNlcyBhcmUgYXMgZm9sbG93czogPGJyPg0KKHBsZWFzZSBvcmRlciBieSBpdGVtIG51 bWJlcik8L2ZvbnQ+PC9pPg0KPC9iPg0KPC9mb250Pg0KPC9wPg0KPHAgYWxpZ249ImxlZnQiPiA8 Yj48Zm9udCBmYWNlPSJMdWNpZGEgU2FucyBUeXBld3JpdGVyIiBjb2xvcj0iIzAwMDAwMCIgDQpz aXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpIZXdsZXR0DQog ICAgIFBhY2thcmQ8YSANCm5hbWU9InByaWNlcyI+PC9hPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYg0Kc3A7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+DQo8L3A+DQo8 cCBhbGlnbj0ibGVmdCI+IDx0dD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGI+PGZvbnQgc2l6ZT0i MiI+MSAtLSA5MjI3NEEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCA0TCwgNE1MLCA0UCwg NE1QDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0kNDcuNTA8YnI+DQo8L2ZvbnQ+DQo8c3BhbiBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+DQo8Zm9udCBzaXplPSIyIj4NCjIgLS0g QzQwOTJBIEJsYWNrIFRvbmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgMTEwMEEsIEFTRSwgMzIw MFNFLS0tLS0tLS0tLS0tLS0tLS0kNDUuNTA8YnI+DQo8L2ZvbnQ+DQo8L3NwYW4+DQo8Zm9udCBz aXplPSIyIj4NCjJBIC0gQzcxMTVBIFRvbmVyIENhcnRyaWRnZSBGb3IgSFAgTGFzZXJKZXQgMTAw MCwgMTIwMCwgMzMzMCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0kNTUuNTA8YnI+DQo8c3BhbiBzdHls ZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+DQoyQiAtIEM3MTE1WCBIaWdoIENhcGFjaXR5 IFRvbmVyIENhcnRyaWRnZSBmb3IgSFAgTGFzZXJKZXQgMTAwMCwgMTIwMCwgMzMzMCAtLS0tLS0t JDY1LjUwPGJyPg0KPC9zcGFuPg0KMyAtLSA5MjI5NUEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNl ckpldCBJSSwgSUlELCBJSUksIElJSUQgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ0OS41MDxicj4N CjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4NCjQgLS0gOTIyNzVBIFRv bmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgSUlQLCBJSVArLCBJSUlQIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0kNTUuNTA8YnI+DQo8L3NwYW4+DQo1IC0tIEMzOTAzQSBUb25lciBDYXJ0cmlk Z2UgZm9yIExhc2VySmV0IDVQLCA1TVAsIDZQLCA2UHNlLCA2TVAsIDZQeGkgLS0tLS0tLS0tLS0t JDQ2LjUwPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPg0KNiAt LSBDMzkwOUEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCA1U2ksIDVTaU1YLCA1U2kgQ29w aWVyLCA4MDAwIC0tLS0tLS0tLS0tLSQ5Mi41MDxicj4NCjwvc3Bhbj4NCjcgLS0gQzQwOTZBIFRv bmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgMjEwMCwgMjIwMERTRSwgMjIwMERUTiAtLS0tLS0t LS0tLS0tLS0tLS0kNzIuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0 QzRBNiI+DQo4IC0gQzQxODJYIFVsdHJhUHJlY2lzZSBIaWdoIENhcGFjaXR5IFRvbmVyIENhcnRy aWRnZSBmb3IgTGFzZXJKZXQgODEwMCBTZXJpZXMtLS0kMTI1LjUwPGJyPg0KPC9zcGFuPg0KOSAt LSBDMzkwNkEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCA1TCwgNUwgWHRyYSwgNkxzZSwg NkwsIDZMeGksIDMxMDBzZS0tLS0tLSQ0Mi41MCA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogI0M0QzRBNiI+DQo5QSAtIEMzOTA2QSBUb25lciBDYXJ0cmlkZ2UgZm9yIExhc2Vy SmV0IDMxMDAsIDMxNTAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJDQyLjUwPGJyPg0K PC9zcGFuPg0KMTAgLSBDMzkwMEEgQmxhY2sgVG9uZXIgQ2FydHJpZGdlIGZvciBIUCBMYXNlckpl dCA0TVYsIDRWIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ4OS41MDxicj4NCjxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4NCjExIC0gQzQxMjdBIEJsYWNrIFRvbmVyIENh cnRyaWRnZSBmb3IgTGFzZXJKZXQgNDAwMFNFLCA0MDAwTiwgNDAwMFQsIDQwMDBUTiAtLS0tLS0k NzYuNTA8YnI+DQo8L3NwYW4+DQoxMUEtIEM4MDYxQSBCbGFjayBMYXNlciBUb25lciBmb3IgSFAg TGFzZXJKZXQgNDEwMCwgNDEwME4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJDc2LjUwPGJyPg0K PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPg0KMTFCLSBDODA2MVggSGln aCBDYXBhY2l0eSBUb25lciBDYXJ0cmlkZ2UgZm9yIExKNDEwMCwgNDEwME4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSQ4NS41MDxicj4NCjwvc3Bhbj4NCjExQy0gQzQxMjdYIEhpZ2ggQ2FwYWNpdHkg QmxhY2sgQ2FydHJpZGdlIGZvciBMYXNlckpldCA0MDAwU0UsNDAwME4sNDAwMFQsNDAwMFRODQot JDg0LjUwPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPg0KMTIg LSA5MjI5MUEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCBJSUlTaSwgNFNpLCA0U2lNWCAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ1Ny41MDxicj4NCjwvc3Bhbj4NCjEzIC0gOTIyOThBIFRv bmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgNCwgNCBQbHVzLCA0TSwgNE0gUGx1cywgNSwgNXNl LCA1TSwgNU4NCi0tJDQ2LjUwPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICND NEM0QTYiPg0KMTQgLSBDNDEyOVggSGlnaCBDYXBhY2l0eSBCbGFjayBUb25lciBDYXJ0cmlkZ2Ug Zm9yIExhc2VySmV0IDUwMDBOIC0tLS0tLS0tLS0tLS0tLSQ5Ny41MDxicj4NCjwvc3Bhbj4NCjE1 IC0gTEFTRVJGQVggNTAwLCA3MDAgKEZYMSkgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0kNDkuMDA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogI0M0QzRBNiI+DQoxNiAtIExBU0VSRkFYIDUwMDAsIDcwMDAgKEZYMikgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJDU0LjAwPGJyPg0K PC9zcGFuPg0KMTcgLSBMQVNFUkZBWCAoRlgzKSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ0OS4wMDwvZm9udD48L2I+PGZvbnQg c2l6ZT0iMiI+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYi Pg0KMTggLSBMQVNFUkZBWCAoRlg0KSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ0OS4wMDwvc3Bhbj48L2I+PC9mb250PjwvZm9u dD48L3R0Pg0KPC9wPg0KPHAgYWxpZ249ImxlZnQiPiA8Yj48Zm9udCBmYWNlPSJMdWNpZGEgU2Fu cyBUeXBld3JpdGVyIiANCnNpemU9IjMiPkl0ZW0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCkhld2xldHQgUGFja2FyZCAt IENvbG9yPGEgDQpuYW1lPSJjb2xvciI+PC9hPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KJm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVm dCI+IDx0dD48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGZvbnQg ZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRlciIgc2l6ZT0iMiIgDQpjb2xvcj0iIzAwMDAwMCI+ QzEgLS0gQzQxOTRhIFRvbmVyDQpDYXJ0cmlkZ2UsDQpZZWxsb3cgKGNvbG9yIGxqIDQ1MDAvNDU1 MCBzZXJpZXMpLS0tLS0tLS0tLS0tLS0tLS0tICQgODkuNTA8YnI+DQo8L2ZvbnQ+PC9zcGFuPjxm b250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIHNpemU9IjIiIGNvbG9yPSIjMDAwMDAw Ij5DMiAtLSBDNDE5M2EgVG9uZXINCkNhcnRyaWRnZSwgTWFnZW50YSAoY29sb3IgbGogNDUwMC80 NTUwIHNlcmllcyktLS0tLS0tLS0tLS0tLS0tLQ0KJCA4OS41MDxicj4NCjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij5DMyAtLSBDNDE5MmEgdG9uZXIgY2FydHJpZGdlLCBj eWFuIChjb2xvciBsaiA0NTAwLzQ1NTAgc2VyaWVzKS0tLS0tLS0tLS0tLS0tLS0tLS0tICQNCjg5 LjUwPGJyPg0KPC9zcGFuPkM0IC0tIGM0MTkxYSB0b25lciBjYXJ0cmlkZ2UsIGJsYWNrIChjb2xv ciBsaiA0NTAwLzQ1NTAgc2VyaWVzKS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNzQuNTA8L2ZvbnQ+ PC9iPjwvdHQ+DQo8L3A+DQo8cCBhbGlnbj0ibGVmdCI+IDxiPjxmb250IGZhY2U9Ikx1Y2lkYSBT YW5zIFR5cGV3cml0ZXIiIA0Kc2l6ZT0iMyI+SXRlbSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnMNCnA7Jm5ic3A7Jm5ic3A7DQpMZXhtYXJrJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm4NCmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNClByaWNlPC9mb250PjwvYj4NCjwvcD4NCjxwIGFsaWduPSJsZWZ0 Ij4gPHR0Pjxmb250IHNpemU9IjIiIGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIGNvbG9y PSIjMDAwMDAwIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogDQojQzRDNEE2Ij4x OSAtIDEzODA1MjAgSGlnaCBZaWVsZCBCbGFjayBMYXNlciBUb25lciBmb3IgNDAxOSwgNDAxOUUs IDQwMjgsIDQwMjksIDYsIDEwLCAxMEwgLS0gJDEwOS41MDxicj4NCjwvc3Bhbj4yMCAtIDEzODIx NTAgSGlnaCBZaWVsZCBUb25lciBmb3IgMzExMiwgMzExNiwgNDAzOS0xMCssIDQwNDktIE1vZGVs IDEyTCwxNlIsDQpPcHRyYSAtICQxMDkuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1j b2xvcjogI0M0QzRBNiI+MjEgLSA2OUc4MjU2IExhc2VyIENhcnRyaWRnZSBmb3IgT3B0cmEgRSwN CkUrLCBFUCwgRVMsIDQwMjYsIDQwMjYgKDZBLDZCLDZELDZFKSZuYnNwOyAtLS0tICQgNDkuMDA8 YnI+DQo8L3NwYW4+MjIgLSAxM1QwMTAxIEhpZ2ggWWllbGQgVG9uZXIgQ2FydHJpZGdlIGZvciBM ZXhtYXJrIE9wdHJhIEUzMTAsIEUzMTIsIEUzMTJMIC0tLS0tLS0tICQgODkuMDA8YnI+DQo8c3Bh biBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+MjMgLSAxMzgyNjI1IEhpZ2gtWWll bGQgTGFzZXIgVG9uZXIgQ2FydHJpZGdlIGZvciBMZXhtYXJrIE9wdHJhIFMgKDQwNTkpIC0tLS0t LS0tLS0tIA0KJDEyOS41MDxicj4NCjwvc3Bhbj4yNCAtIDEyQTU3NDUgSGlnaCBZaWVsZCBMYXNl ciBUb25lciBmb3IgTGV4bWFyayBPcHRyYSBUNjEwLCA2MTIsIDYxNCAoNDA2OSkgLS0tLS0tLS0g JDE2NS4wMDwvYj48L2ZvbnQ+PC90dD4NCjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij4gPGI+PGZvbnQg ZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRlciIgDQpzaXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpFcHNvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnMNCnA7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+DQo8 L3A+DQo8cCBhbGlnbj0ibGVmdCI+PHR0Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBm YWNlPSJMdWNpZGEgU2FucyBUeXBld3JpdGVyIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1j b2xvcjogDQojQzRDNEE2Ij4yNQ0KLS0tLSBTMDUxMDA5IFRvbmVyIENhcnRyaWRnZSBmb3IgRXBz b24gRVBMNzAwMCwgNzUwMCwgODAwMCsgLSAkMTE1LjUwPGJyPg0KPC9zcGFuPjI1QSAtLS0gUzA1 MTAwOSBMUC0zMDAwIFBTIDcwMDAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gJDEx NS41MDxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4yNiAtLS0t IEFTMDUxMDExIEltYWdpbmcgQ2FydHJpZGdlIGZvcg0KQWN0aW9uTGFzZXItMTAwMCwgMTUwMCAt LSAkIDk5LjUwPGJyPg0KPC9zcGFuPjI2QSAtLS0gQVMwNTEwMTEgRVBMLTUwMDAsIEVQTC01MTAw LCBFUEwtNTIwMCAtLS0tLS0tLS0tLS0tLS0tLS0gJCA5OS41MDxicj48L2I+PC9mb250Pg0KPC90 dD48L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGI+PGZvbnQgZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdy aXRlciIgDQpzaXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpQYW5hc29uaWMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNClByaWNlPC9mb250PjwvYj48L3A+DQo8cCBhbGlnbj0ibGVmdCI+ PHR0PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij48Zm9udCBjb2xvcj0i IzAwMDAwMCIgZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRlciIgDQpzaXplPSIyIj48Yj4yNw0K LS0tLS0tTmVjIHNlcmllcyAyIG1vZGVscyA5MCBhbmQgOTUgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSAkMTA5LjUwPGJyPjwvYj48L2ZvbnQ+PC9zcGFuPjwvdHQ+PC9wPg0KPHAgYWxpZ249ImxlZnQi PjxiPjxmb250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIA0Kc2l6ZT0iMyI+SXRlbSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQpBcHBsZSZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnMNCnA7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+PC9wPg0KPHAgYWxpZ249Imxl ZnQiPjx0dD48Yj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiIgY29sb3I9IiMwMDAw MDAiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4yOCANCi0tLS0gMjQ3 M0cvQSBMYXNlciBUb25lciBmb3IgTGFzZXJXcml0ZXIgUHJvIDYwMCwgNjMwLCBMYXNlcldyaXRl ciAxNi82MDAgUFMgLQ0KJCA1Ny41MDxicj4NCjwvc3Bhbj4yOSAtLS0tIDE5NjBHL0EgTGFzZXIg VG9uZXIgZm9yIEFwcGxlIExhc2VyV3JpdGVyIFNlbGVjdCwgMzAwLCAzMTAsIDM2MCAtLS0tLS0t LS0gJA0KNzEuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+ MzAgLS0tLSBNMDA4OUxML0EgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlcndyaXRlciAzMDAsIDMy MCAoNzRBKSAtLS0tLS0tLS0tLS0tLS0tICQNCjUyLjUwPGJyPg0KPC9zcGFuPjMxIC0tLS0gTTYw MDIgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlcndyaXRlciBJSU5ULCBJSU5UWCwgSUlTQywgSUlG LCBJSUcgKDk1QSkgLSAkDQo0Ny41MDxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OiAjQzRDNEE2Ij4zMUEgLS0tIE0wMDg5TEwvQSBUb25lciBDYXJ0cmlkZ2UgZm9yIExhc2Vyd3Jp dGVyDQpMUywgTlQsIE5UUiwgU0MgKDc1QSkgLS0tLS0tLS0tICQNCjU1LjUwPGJyPg0KPC9zcGFu PjMyIC0tLS0gTTQ2ODNHL0EgTGFzZXIgVG9uZXIgZm9yIExhc2VyV3JpdGVyIDEyLCA2NDBQUyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KJCA4NS41MDxicj48L2ZvbnQ+PC9iPg0KPC90dD48 L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGI+PGZvbnQgZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRl ciIgDQpzaXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpDYW5v biZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnMNCnA7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9u dD48L2I+PC9wPg0KPHA+PHR0Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBmYWNlPSJM dWNpZGEgU2FucyBUeXBld3JpdGVyIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog I0M0QzRBNiI+MzMgLS0tIA0KRmF4DQpDRlgtTDM1MDAsIENGWC00MDAwIENGWC1MNDUwMCwgQ0ZY LUw0NTAwSUUgJmFtcDsgSUYgRlgzIC0tLS0tLS0tLS0tICQgNDkuNTA8YnI+DQo8L3NwYW4+MzNB IC0tIEwtMjUwLCBMLTI2MGksIEwtMzAwIEZYMyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+MzNCIC0tIExBU0VSIENMQVNTIDIwNjAsIDIwNjBQLCA0MDAwIEZYMyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzQgLS0t IExBU0VSIENMQVNTIDUwMDAsIDU1MDAsIDcwMDAsIDcxMDAsIDc1MDAsIDYwMDAgRlgyIC0tLS0t LS0tLS0tLS0tLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRB NiI+PGJyPg0KMzUgLS0tIEZBWCA1MDAwIEZYMiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzYgLS0tIExB U0VSIENMQVNTIDg1MDAsIDkwMDAsIDkwMDBMLCA5MDAwTVMsIDk1MDAsIDk1MDAgTVMsIDk1MDAg UyBGWDQgLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+ PGJyPg0KMzZBIC0tIEZheCBMNzAwLDcyMCw3NjAsNzcwLDc3NSw3NzcsNzgwLDc4NSw3OTAsICZh bXA7IEwzMzAwIEZYMQ0KLS0tLS0tLS0tLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjM2QiAtLSBM LTgwMCwgTC05MDAgRlg0IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQokIDQ5LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYi Pjxicj4NCjM3IC0tLSBBMzBSIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNiwgNlJFLCA3LCAxMSwg MTIgLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQokIDU5LjUwPGJyPg0KPC9zcGFuPjM4IC0tLSBFLTQw IFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNzIwLCA3NDAsIDc3MCwgNzkwLDc5NSwgOTIwLCA5NTAs IDk4MCAtDQokIDg1LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPjxi cj4NCjM4QSAtLSBFLTIwIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtMzEwLCAzMjUsIDMzMCwgMzMw TCwgNDAwLCA0MjAsIDQzMCAtLS0tDQokIDg1LjUwPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJyPjwvc3Bhbj48L2ZvbnQ+DQo8L3R0PjwvcD4NCjxw PjxiPjxmb250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIHNpemU9IjMiPkl0ZW0mbmJz cDsmbmJzcDsNClhlcm94Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByaWNlPC9mb250PjwvYj48L3A+DQo8 cD48dHQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjIiIGZhY2U9Ikx1Y2lkYSBTYW5zIFR5 cGV3cml0ZXIiPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4zOSAt LS0tIA0KNlI5MDAgNzVBIC0tLS0gJCA1NS41MDxicj4NCjwvc3Bhbj40MCAtLS0tIDZSOTAzIDk4 QSAtLS0tICQgNDYuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJy Pg0KNDEgLS0tLSA2UjkwMiA5NUEgLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjQyIC0tLS0gNlI5 MDEgOTFBIC0tLS0gJCA2NS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2 Ij48YnI+DQo0MyAtLS0tIDZSOTA4IDA2QSAtLS0tICQgNDIuNTA8YnI+DQo8L3NwYW4+NDQgLS0t LSA2Ujg5OSA3NEEgLS0tLSAkIDQ3LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICND NEM0QTYiPjxicj4NCjQ1IC0tLS0gNlI5MjggOTZBIC0tLS0gJCA3Mi41MDxicj4NCjwvc3Bhbj40 NiAtLS0tIDZSOTI2IDI3WCAtLS0tICQgODQuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+PGJyPg0KNDcgLS0tLSA2UjkwNiAwOUEgLS0tLSAkIDkyLjUwPGJyPg0KPC9z cGFuPjQ4IC0tLS0gNlI5MDcgNE1WIC0tLS0gJCA4OS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiAjQzRDNEE2Ij48YnI+DQo0OSAtLS0tIDZSOTA1IDAzQSAtLS0tICQgNDYuNTA8L3Nw YW4+PC9iPjwvZm9udD48L3R0PjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48Yj48aT48Zm9udCBjb2xv cj0iIzgwODAwMCIgc2l6ZT0iMyIgZmFjZT0iQXJpYWwiPjMwIERheSB1bmxpbWl0ZWQgd2FycmFu dHkgaW5jbHVkZWQgb24gYWxsDQpwcm9kdWN0czxicj4NCkdUIFRvbmVyIFN1cHBsaWVzIGd1YXJh bnRlZXMgdGhlc2UgY2FydHJpZGdlcyB0byBiZSBmcmVlIGZyb20gZGVmZWN0cyBpbg0Kd29ya21h bnNoaXAgYW5kIG1hdGVyaWFsLjwvZm9udD48L2k+DQo8L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVm dCI+PGI+PGk+PGZvbnQgY29sb3I9IiMwMDAwRkYiIHNpemU9IjMiIGZhY2U9IkFyaWFsIj5XZSBs b29rDQpmb3J3YXJkIGluIGRvaW5nIGJ1c2luZXNzIHdpdGggeW91LjwvZm9udD48L2k+PC9iPg0K PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxpPjxmb250IGNvbG9yPSIjMDAwMEZGIiBzaXplPSIz IiBmYWNlPSJBcmlhbCI+Q3VzdG9tZXImbmJzcDsNClNhdGlzZmFjdGlvbiBndWFyYW50ZWVkPC9m b250PjwvaT48L2I+DQo8L3A+DQo8cD4NCjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj5J PGZvbnQgY29sb3I9IiMwMDAwODAiPmYgeW91IGFyZSBvcmRlcmluZyBieSBlLW1haWwgb3INCmMu by5kLiBwbGVhc2UgZmlsbCBvdXQgYW4gb3JkZXI8YnI+DQpmb3JtIHdpdGggdGhlIGZvbGxvd2lu ZyBpbmZvcm1hdGlvbjo8L2ZvbnQ+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxpPiZuYnNwOyZuYnNw OyZuYnNwOzwvaT48L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwODAiPg0KPC9mb250PjxpPiZuYnNw OyZuYnNwOyZuYnNwOzwvaT48Zm9udCBjb2xvcj0iIzAwMDA4MCIgZmFjZT0iQXJpYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvZm9udD48Zm9udCANCmNvbG9yPSIjMDAwMEZGIj4N CjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+PGk+Jm5ic3A7PC9pPjwvZm9udD48Zm9udCBj b2xvcj0iIzAwMDA4MCI+PGJyPjxicj4NCjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+cGhv bmUgbnVtYmVyPGJyPg0KY29tcGFueSBuYW1lPGJyPg0KZmlyc3QgYW5kIGxhc3QgbmFtZTxicj4N CnN0cmVldCBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L2ZvbnQ+PC9iPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+PGI+PGk+ PGEgaHJlZj0ibWFpbHRvOmd0dHMxQGNhYmxlLm5ldC5jbyI+PGZvbnQgY29sb3I9IiMwMDAwRkYi Pk9yZGVyIA0KTm93PC9mb250PjwvYT4gPC9pPjxmb250IGNvbG9yPSIjMDAwMDgwIj5vcg0KY2Fs bCB0b2xsIGZyZWUgPC9mb250Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjMDAwMEZGIj4gMS04NjYt MjM3LTczOTc8L2ZvbnQ+IDwvYj48L2ZvbnQ+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+ PGI+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxicj48YnI+DQo8L2ZvbnQ+PGZvbnQgY29sb3I9IiMw MDAwODAiPklmIHlvdSBhcmUgb3JkZXJpbmcgYnkgcHVyY2hhc2Ugb3JkZXIgcGxlYXNlIGZpbGwg b3V0IGFuIG9yZGVyIGZvcm08YnI+DQp3aXRoIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb246Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvZm9udD48aT4mbmJzcDsmbmJzcDsmbmJzcDs8L2k+PGZvbnQgY29s b3I9IiMwMDAwODAiIA0KZmFjZT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9m b250PjwvYj48L2ZvbnQ+PC9wPg0KPHA+PGI+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjODA4 MDAwIiBzaXplPSIyIj5wdXJjaGFzZSBvcmRlciBudW1iZXI8YnI+DQpwaG9uZSBudW1iZXI8YnI+ DQpjb21wYW55IG9yIHNjaG9vbCBuYW1lPGJyPg0Kc2hpcHBpbmcgYWRkcmVzcyBhbmQgYmlsbGlu ZyBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj48aT48YSBocmVmPSJtYWls dG86Z3R0czFAY2FibGUubmV0LmNvIj48Zm9udCBjb2xvcj0iIzAwMDBGRiI+T3JkZXINCk5vdzwv Zm9udD48L2E+PC9pPjwvYj48L2ZvbnQ+PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxmb250IHNp emU9IjIiPjxpPjxmb250IGNvbG9yPSIjODAwMDAwIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+QWxs IHRyYWRlIG1hcmtzIGFuZCBicmFuZCBuYW1lcyBsaXN0ZWQgDQphYm92ZSBhcmUgcHJvcGVydHkN Cm9mIHRoZSByZXNwZWN0aXZlPGJyPg0KaG9sZGVycyBhbmQgdXNlZCBmb3IgZGVzY3JpcHRpdmUg cHVycG9zZXMgb25seS48L2ZvbnQ+DQo8L2k+DQo8L2ZvbnQ+DQo8L2I+DQo8L3A+DQo= DQpQcmljZTwvZm9u dD48L2I+PC9wPg0KPHA+PHR0Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBmYWNlPSJM dWNpZGEgU2FucyBUeXBld3JpdGVyIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog I0M0QzRBNiI+MzMgLS0tIA0KRmF4DQpDRlgtTDM1MDAsIENGWC00MDAwIENGWC1MNDUwMCwgQ0ZY LUw0NTAwSUUgJmFtcDsgSUYgRlgzIC0tLS0tLS0tLS0tICQgNDkuNTA8YnI+DQo8L3NwYW4+MzNB IC0tIEwtMjUwLCBMLTI2MGksIEwtMzAwIEZYMyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+MzNCIC0tIExBU0VSIENMQVNTIDIwNjAsIDIwNjBQLCA0MDAwIEZYMyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzQgLS0t IExBU0VSIENMQVNTIDUwMDAsIDU1MDAsIDcwMDAsIDcxMDAsIDc1MDAsIDYwMDAgRlgyIC0tLS0t LS0tLS0tLS0tLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRB NiI+PGJyPg0KMzUgLS0tIEZBWCA1MDAwIEZYMiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzYgLS0tIExB U0VSIENMQVNTIDg1MDAsIDkwMDAsIDkwMDBMLCA5MDAwTVMsIDk1MDAsIDk1MDAgTVMsIDk1MDAg UyBGWDQgLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+ PGJyPg0KMzZBIC0tIEZheCBMNzAwLDcyMCw3NjAsNzcwLDc3NSw3NzcsNzgwLDc4NSw3OTAsICZh bXA7IEwzMzAwIEZYMQ0KLS0tLS0tLS0tLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjM2QiAtLSBM LTgwMCwgTC05MDAgRlg0IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQokIDQ5LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYi Pjxicj4NCjM3IC0tLSBBMzBSIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNiwgNlJFLCA3LCAxMSwg MTIgLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQokIDU5LjUwPGJyPg0KPC9zcGFuPjM4IC0tLSBFLTQw IFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNzIwLCA3NDAsIDc3MCwgNzkwLDc5NSwgOTIwLCA5NTAs IDk4MCAtDQokIDg1LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPjxi cj4NCjM4QSAtLSBFLTIwIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtMzEwLCAzMjUsIDMzMCwgMzMw TCwgNDAwLCA0MjAsIDQzMCAtLS0tDQokIDg1LjUwPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJyPjwvc3Bhbj48L2ZvbnQ+DQo8L3R0PjwvcD4NCjxw PjxiPjxmb250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIHNpemU9IjMiPkl0ZW0mbmJz cDsmbmJzcDsNClhlcm94Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByaWNlPC9mb250PjwvYj48L3A+DQo8 cD48dHQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjIiIGZhY2U9Ikx1Y2lkYSBTYW5zIFR5 cGV3cml0ZXIiPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4zOSAt LS0tIA0KNlI5MDAgNzVBIC0tLS0gJCA1NS41MDxicj4NCjwvc3Bhbj40MCAtLS0tIDZSOTAzIDk4 QSAtLS0tICQgNDYuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJy Pg0KNDEgLS0tLSA2UjkwMiA5NUEgLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjQyIC0tLS0gNlI5 MDEgOTFBIC0tLS0gJCA2NS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2 Ij48YnI+DQo0MyAtLS0tIDZSOTA4IDA2QSAtLS0tICQgNDIuNTA8YnI+DQo8L3NwYW4+NDQgLS0t LSA2Ujg5OSA3NEEgLS0tLSAkIDQ3LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICND NEM0QTYiPjxicj4NCjQ1IC0tLS0gNlI5MjggOTZBIC0tLS0gJCA3Mi41MDxicj4NCjwvc3Bhbj40 NiAtLS0tIDZSOTI2IDI3WCAtLS0tICQgODQuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+PGJyPg0KNDcgLS0tLSA2UjkwNiAwOUEgLS0tLSAkIDkyLjUwPGJyPg0KPC9z cGFuPjQ4IC0tLS0gNlI5MDcgNE1WIC0tLS0gJCA4OS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiAjQzRDNEE2Ij48YnI+DQo0OSAtLS0tIDZSOTA1IDAzQSAtLS0tICQgNDYuNTA8L3Nw YW4+PC9iPjwvZm9udD48L3R0PjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48Yj48aT48Zm9udCBjb2xv cj0iIzgwODAwMCIgc2l6ZT0iMyIgZmFjZT0iQXJpYWwiPjMwIERheSB1bmxpbWl0ZWQgd2FycmFu dHkgaW5jbHVkZWQgb24gYWxsDQpwcm9kdWN0czxicj4NCkdUIFRvbmVyIFN1cHBsaWVzIGd1YXJh bnRlZXMgdGhlc2UgY2FydHJpZGdlcyB0byBiZSBmcmVlIGZyb20gZGVmZWN0cyBpbg0Kd29ya21h bnNoaXAgYW5kIG1hdGVyaWFsLjwvZm9udD48L2k+DQo8L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVm dCI+PGI+PGk+PGZvbnQgY29sb3I9IiMwMDAwRkYiIHNpemU9IjMiIGZhY2U9IkFyaWFsIj5XZSBs b29rDQpmb3J3YXJkIGluIGRvaW5nIGJ1c2luZXNzIHdpdGggeW91LjwvZm9udD48L2k+PC9iPg0K PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxpPjxmb250IGNvbG9yPSIjMDAwMEZGIiBzaXplPSIz IiBmYWNlPSJBcmlhbCI+Q3VzdG9tZXImbmJzcDsNClNhdGlzZmFjdGlvbiBndWFyYW50ZWVkPC9m b250PjwvaT48L2I+DQo8L3A+DQo8cD4NCjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj5J PGZvbnQgY29sb3I9IiMwMDAwODAiPmYgeW91IGFyZSBvcmRlcmluZyBieSBlLW1haWwgb3INCmMu by5kLiBwbGVhc2UgZmlsbCBvdXQgYW4gb3JkZXI8YnI+DQpmb3JtIHdpdGggdGhlIGZvbGxvd2lu ZyBpbmZvcm1hdGlvbjo8L2ZvbnQ+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxpPiZuYnNwOyZuYnNw OyZuYnNwOzwvaT48L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwODAiPg0KPC9mb250PjxpPiZuYnNw OyZuYnNwOyZuYnNwOzwvaT48Zm9udCBjb2xvcj0iIzAwMDA4MCIgZmFjZT0iQXJpYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvZm9udD48Zm9udCANCmNvbG9yPSIjMDAwMEZGIj4N CjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+PGk+Jm5ic3A7PC9pPjwvZm9udD48Zm9udCBj b2xvcj0iIzAwMDA4MCI+PGJyPjxicj4NCjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+cGhv bmUgbnVtYmVyPGJyPg0KY29tcGFueSBuYW1lPGJyPg0KZmlyc3QgYW5kIGxhc3QgbmFtZTxicj4N CnN0cmVldCBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L2ZvbnQ+PC9iPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+PGI+PGk+ PGEgaHJlZj0ibWFpbHRvOmd0dHMxQGNhYmxlLm5ldC5jbyI+PGZvbnQgY29sb3I9IiMwMDAwRkYi Pk9yZGVyIA0KTm93PC9mb250PjwvYT4gPC9pPjxmb250IGNvbG9yPSIjMDAwMDgwIj5vcg0KY2Fs bCB0b2xsIGZyZWUgPC9mb250Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjMDAwMEZGIj4gMS04NjYt MjM3LTczOTc8L2ZvbnQ+IDwvYj48L2ZvbnQ+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+ PGI+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxicj48YnI+DQo8L2ZvbnQ+PGZvbnQgY29sb3I9IiMw MDAwODAiPklmIHlvdSBhcmUgb3JkZXJpbmcgYnkgcHVyY2hhc2Ugb3JkZXIgcGxlYXNlIGZpbGwg b3V0IGFuIG9yZGVyIGZvcm08YnI+DQp3aXRoIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb246Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvZm9udD48aT4mbmJzcDsmbmJzcDsmbmJzcDs8L2k+PGZvbnQgY29s b3I9IiMwMDAwODAiIA0KZmFjZT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9m b250PjwvYj48L2ZvbnQ+PC9wPg0KPHA+PGI+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjODA4 MDAwIiBzaXplPSIyIj5wdXJjaGFzZSBvcmRlciBudW1iZXI8YnI+DQpwaG9uZSBudW1iZXI8YnI+ DQpjb21wYW55IG9yIHNjaG9vbCBuYW1lPGJyPg0Kc2hpcHBpbmcgYWRkcmVzcyBhbmQgYmlsbGlu ZyBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj48aT48YSBocmVmPSJtYWls dG86Z3R0czFAY2FibGUubmV0LmNvIj48Zm9udCBjb2xvcj0iIzAwMDBGRiI+T3JkZXINCk5vdzwv Zm9udD48L2E+PC9pPjwvYj48L2ZvbnQ+PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxmb250IHNp emU9IjIiPjxpPjxmb250IGNvbG9yPSIjODAwMDAwIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+QWxs IHRyYWRlIG1hcmtzIGFuZCBicmFuZCBuYW1lcyBsaXN0ZWQgDQphYm92ZSBhcmUgcHJvcGVydHkN Cm9mIHRoZSByZXNwZWN0aXZlPGJyPg0KaG9sZGVycyBhbmQgdXNlZCBmb3IgZGVzY3JpcHRpdmUg cHVycG9zZXMgb25seS48L2ZvbnQ+DQo8L2k+DQo8L2ZvbnQ+DQo8L2I+DQo8L3A+DQo= DQpQcmljZTwvZm9u dD48L2I+PC9wPg0KPHA+PHR0Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBmYWNlPSJM dWNpZGEgU2FucyBUeXBld3JpdGVyIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog I0M0QzRBNiI+MzMgLS0tIA0KRmF4DQpDRlgtTDM1MDAsIENGWC00MDAwIENGWC1MNDUwMCwgQ0ZY LUw0NTAwSUUgJmFtcDsgSUYgRlgzIC0tLS0tLS0tLS0tICQgNDkuNTA8YnI+DQo8L3NwYW4+MzNB IC0tIEwtMjUwLCBMLTI2MGksIEwtMzAwIEZYMyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+MzNCIC0tIExBU0VSIENMQVNTIDIwNjAsIDIwNjBQLCA0MDAwIEZYMyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzQgLS0t IExBU0VSIENMQVNTIDUwMDAsIDU1MDAsIDcwMDAsIDcxMDAsIDc1MDAsIDYwMDAgRlgyIC0tLS0t LS0tLS0tLS0tLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRB NiI+PGJyPg0KMzUgLS0tIEZBWCA1MDAwIEZYMiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzYgLS0tIExB U0VSIENMQVNTIDg1MDAsIDkwMDAsIDkwMDBMLCA5MDAwTVMsIDk1MDAsIDk1MDAgTVMsIDk1MDAg UyBGWDQgLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+ PGJyPg0KMzZBIC0tIEZheCBMNzAwLDcyMCw3NjAsNzcwLDc3NSw3NzcsNzgwLDc4NSw3OTAsICZh bXA7IEwzMzAwIEZYMQ0KLS0tLS0tLS0tLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjM2QiAtLSBM LTgwMCwgTC05MDAgRlg0IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQokIDQ5LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYi Pjxicj4NCjM3IC0tLSBBMzBSIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNiwgNlJFLCA3LCAxMSwg MTIgLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQokIDU5LjUwPGJyPg0KPC9zcGFuPjM4IC0tLSBFLTQw IFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNzIwLCA3NDAsIDc3MCwgNzkwLDc5NSwgOTIwLCA5NTAs IDk4MCAtDQokIDg1LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPjxi cj4NCjM4QSAtLSBFLTIwIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtMzEwLCAzMjUsIDMzMCwgMzMw TCwgNDAwLCA0MjAsIDQzMCAtLS0tDQokIDg1LjUwPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJyPjwvc3Bhbj48L2ZvbnQ+DQo8L3R0PjwvcD4NCjxw PjxiPjxmb250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIHNpemU9IjMiPkl0ZW0mbmJz cDsmbmJzcDsNClhlcm94Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByaWNlPC9mb250PjwvYj48L3A+DQo8 cD48dHQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjIiIGZhY2U9Ikx1Y2lkYSBTYW5zIFR5 cGV3cml0ZXIiPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4zOSAt LS0tIA0KNlI5MDAgNzVBIC0tLS0gJCA1NS41MDxicj4NCjwvc3Bhbj40MCAtLS0tIDZSOTAzIDk4 QSAtLS0tICQgNDYuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJy Pg0KNDEgLS0tLSA2UjkwMiA5NUEgLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjQyIC0tLS0gNlI5 MDEgOTFBIC0tLS0gJCA2NS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2 Ij48YnI+DQo0MyAtLS0tIDZSOTA4IDA2QSAtLS0tICQgNDIuNTA8YnI+DQo8L3NwYW4+NDQgLS0t LSA2Ujg5OSA3NEEgLS0tLSAkIDQ3LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICND NEM0QTYiPjxicj4NCjQ1IC0tLS0gNlI5MjggOTZBIC0tLS0gJCA3Mi41MDxicj4NCjwvc3Bhbj40 NiAtLS0tIDZSOTI2IDI3WCAtLS0tICQgODQuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+PGJyPg0KNDcgLS0tLSA2UjkwNiAwOUEgLS0tLSAkIDkyLjUwPGJyPg0KPC9z cGFuPjQ4IC0tLS0gNlI5MDcgNE1WIC0tLS0gJCA4OS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiAjQzRDNEE2Ij48YnI+DQo0OSAtLS0tIDZSOTA1IDAzQSAtLS0tICQgNDYuNTA8L3Nw YW4+PC9iPjwvZm9udD48L3R0PjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48Yj48aT48Zm9udCBjb2xv cj0iIzgwODAwMCIgc2l6ZT0iMyIgZmFjZT0iQXJpYWwiPjMwIERheSB1bmxpbWl0ZWQgd2FycmFu dHkgaW5jbHVkZWQgb24gYWxsDQpwcm9kdWN0czxicj4NCkdUIFRvbmVyIFN1cHBsaWVzIGd1YXJh bnRlZXMgdGhlc2UgY2FydHJpZGdlcyB0byBiZSBmcmVlIGZyb20gZGVmZWN0cyBpbg0Kd29ya21h bnNoaXAgYW5kIG1hdGVyaWFsLjwvZm9udD48L2k+DQo8L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVm dCI+PGI+PGk+PGZvbnQgY29sb3I9IiMwMDAwRkYiIHNpemU9IjMiIGZhY2U9IkFyaWFsIj5XZSBs b29rDQpmb3J3YXJkIGluIGRvaW5nIGJ1c2luZXNzIHdpdGggeW91LjwvZm9udD48L2k+PC9iPg0K PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxpPjxmb250IGNvbG9yPSIjMDAwMEZGIiBzaXplPSIz IiBmYWNlPSJBcmlhbCI+Q3VzdG9tZXImbmJzcDsNClNhdGlzZmFjdGlvbiBndWFyYW50ZWVkPC9m b250PjwvaT48L2I+DQo8L3A+DQo8cD4NCjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj5J PGZvbnQgY29sb3I9IiMwMDAwODAiPmYgeW91IGFyZSBvcmRlcmluZyBieSBlLW1haWwgb3INCmMu by5kLiBwbGVhc2UgZmlsbCBvdXQgYW4gb3JkZXI8YnI+DQpmb3JtIHdpdGggdGhlIGZvbGxvd2lu ZyBpbmZvcm1hdGlvbjo8L2ZvbnQ+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxpPiZuYnNwOyZuYnNw OyZuYnNwOzwvaT48L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwODAiPg0KPC9mb250PjxpPiZuYnNw OyZuYnNwOyZuYnNwOzwvaT48Zm9udCBjb2xvcj0iIzAwMDA4MCIgZmFjZT0iQXJpYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvZm9udD48Zm9udCANCmNvbG9yPSIjMDAwMEZGIj4N CjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+PGk+Jm5ic3A7PC9pPjwvZm9udD48Zm9udCBj b2xvcj0iIzAwMDA4MCI+PGJyPjxicj4NCjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+cGhv bmUgbnVtYmVyPGJyPg0KY29tcGFueSBuYW1lPGJyPg0KZmlyc3QgYW5kIGxhc3QgbmFtZTxicj4N CnN0cmVldCBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L2ZvbnQ+PC9iPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+PGI+PGk+ PGEgaHJlZj0ibWFpbHRvOmd0dHMxQGNhYmxlLm5ldC5jbyI+PGZvbnQgY29sb3I9IiMwMDAwRkYi Pk9yZGVyIA0KTm93PC9mb250PjwvYT4gPC9pPjxmb250IGNvbG9yPSIjMDAwMDgwIj5vcg0KY2Fs bCB0b2xsIGZyZWUgPC9mb250Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjMDAwMEZGIj4gMS04NjYt MjM3LTczOTc8L2ZvbnQ+IDwvYj48L2ZvbnQ+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+ PGI+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxicj48YnI+DQo8L2ZvbnQ+PGZvbnQgY29sb3I9IiMw MDAwODAiPklmIHlvdSBhcmUgb3JkZXJpbmcgYnkgcHVyY2hhc2Ugb3JkZXIgcGxlYXNlIGZpbGwg b3V0IGFuIG9yZGVyIGZvcm08YnI+DQp3aXRoIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb246Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvZm9udD48aT4mbmJzcDsmbmJzcDsmbmJzcDs8L2k+PGZvbnQgY29s b3I9IiMwMDAwODAiIA0KZmFjZT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9m b250PjwvYj48L2ZvbnQ+PC9wPg0KPHA+PGI+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjODA4 MDAwIiBzaXplPSIyIj5wdXJjaGFzZSBvcmRlciBudW1iZXI8YnI+DQpwaG9uZSBudW1iZXI8YnI+ DQpjb21wYW55IG9yIHNjaG9vbCBuYW1lPGJyPg0Kc2hpcHBpbmcgYWRkcmVzcyBhbmQgYmlsbGlu ZyBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj48aT48YSBocmVmPSJtYWls dG86Z3R0czFAY2FibGUubmV0LmNvIj48Zm9udCBjb2xvcj0iIzAwMDBGRiI+T3JkZXINCk5vdzwv Zm9udD48L2E+PC9pPjwvYj48L2ZvbnQ+PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxmb250IHNp emU9IjIiPjxpPjxmb250IGNvbG9yPSIjODAwMDAwIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+QWxs IHRyYWRlIG1hcmtzIGFuZCBicmFuZCBuYW1lcyBsaXN0ZWQgDQphYm92ZSBhcmUgcHJvcGVydHkN Cm9mIHRoZSByZXNwZWN0aXZlPGJyPg0KaG9sZGVycyBhbmQgdXNlZCBmb3IgZGVzY3JpcHRpdmUg cHVycG9zZXMgb25seS48L2ZvbnQ+DQo8L2k+DQo8L2ZvbnQ+DQo8L2I+DQo8L3A+DQo= ------=_NextPart_000_00A1_11D12G3I.J1343N65-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby